Latency measurement and PresentMon

PCBenchmarkX separately measures the internal processing latency and the frame output latency. These software metrics do not describe the entire path from a mouse click to a pixel lighting up on the screen. The full measurement cycle is described in the methodology.

Proprietary software stimulus

A continuous stream generates signals at deterministic intervals of 8-12 ms. If Windows allows, it creates a high-precision waitable timer; otherwise it uses a regular waitable timer. Waiting for the event avoids continuous polling, which would occupy the core. The global system timer resolution is not changed.

For each signal, the scheduled deadline, generator wake-up, actual signal, receiver wake-up, simulation, command submission, GPU timestamps and presentation events are logged. A common frame identifier links all stages.

Scheduled deadline → generator wake-up → signal
                                            ↓
                               receiver wake-up
                                            ↓
                                CPU → commands → GPU
                                            ↓
                            Present → output event

In these timelines, both the timer delay and the receiver wake-up latency are visible separately. The start of Core Latency is the actual signal, so the step from the scheduled deadline to the signal is not counted in this metric.

Per-stage breakdown of the latency path

The result contains a per-stage breakdown of the measured path latency_path — separately for Baseline and Loaded. The stages are counted from the actual signal:

Stage	What it measures
signal_to_consumer_wake	from the signal to the receiver wake-up
cpu_processing	CPU processing: simulation and frame data preparation
cpu_end_to_submit_start	the pause from the end of CPU work to the start of submission preparation
workload_submit_cpu_span	preparation and recording of graphics API commands
submit_start_to_gpu_begin	from the start of preparation to the start of GPU work; this is not pure queue latency
gpu_execution	the GPU work itself, in GPU ticks
presentation spans	presentation: the Present wrapper and the intervals from the signal and from the end of GPU work to ScreenTime

Each stage is given as a distribution with statistics and percentiles. Segments are computed for each pair of marks separately, not by subtracting two medians. If a stage’s end mark is missing or unreliable, its distribution remains empty — there are no substitute values. The timer delay (the discrepancy between the scheduled deadline and the actual signal) is recorded as a separate diagnostic before the signal and is not included in the total path values.

QPC and proprietary GPU timestamps

CPU time is recorded via QueryPerformanceCounter. For the GPU, the engine places two timestamp queries around the measured work, obtains the queue frequency via GetTimestampFrequency and converts the tick difference into milliseconds:

GPU work, ms = (GPU_end − GPU_begin) × 1000 / GPU_frequency

According to the Microsoft documentation on D3D12 timing, timestamp query reflects the progress of work to the end of the pipeline, and the GPU and CPU counters are linked via GetClockCalibration.

A GPU/QPC calibration pair allows expressing the completion of GPU work on the same time scale as the signal:

GPU_completion_QPC = calibration_QPC +
  (GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency

Core Latency, ms =
  (GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

The accuracy of this estimate largely depends on how precisely the CPU and GPU clocks are matched. It still does not cover the mouse USB path, the matrix scan time or the pixel response. Microsoft separately describes the nuances of high-precision QPC marks.

Baseline and Loaded

Baseline measures latency in the minimal configuration of this workload. Loaded runs with a GPU load calibrated to 8.333333 ms, that is, to a compute budget of approximately 120 Hz. The physical monitor may have a different refresh rate.

Calibration changes the complexity inside the shader within the range 1-4096. The number of passes remains fixed: four post-passes. First, a range around the target time is selected, then it is refined and the chosen configuration is verified. To occupy the same time on a fast graphics card, more complex work is needed.

In Performance, the amount of work is fixed. In Loaded Latency, the load is calibrated so that the GPU work time is similar across different graphics cards. The resulting timestamps are not normalized after measurement.

Frame output for the latency test goes through a separate presentation path: a borderless window in flip-discard mode, maximum frame latency 1, a DXGI waitable object and tearing if the system supports it. This path is separate from the fixed performance load, which runs off-screen and does not trigger Present.

The role of PresentMon

The PresentMon 2.5.1 library is used for presentation events. It is an ETW project for analyzing graphics events in Windows, described by its authors. Procmon / Process Monitor is not used in this measurement pipeline.

PCBenchmarkX starts its own collection session, filters events of its own process and links frames to software signals. This does not require a separate service or manually launching a separate PresentMon.

Additional intervals are stored:

• from the signal to Present;
• from Present to ScreenTime;
• from the signal to ScreenTime.

ScreenTime is a software frame presentation event; a photodiode for measuring light from the screen is not used. Presentation metrics are not included in PC Score; what is included is described in the score calculation. Starting an ETW session may require running as administrator or membership in the “Performance Log Users” group. If the session could not be started, this diagnostic block will be absent, and the failure is recorded explicitly in the result. Absence of data does not equal zero latency.

PresentMon’s GPU time is also stored separately from the proprietary D3D12 time. The PresentMon developers note the accuracy limitations of GPU metrics with HAGS. Therefore, the engine does not replace proprietary GPU timestamps with an estimate from ETW.

What is developed in PCBenchmarkX

PCBenchmarkX develops the signal generator, frame stage matching, CPU simulation, D3D12 workloads, Loaded calibration, the order of repeating blocks, measurement collection, statistical processing and the score model. QPC and D3D12 are provided by Windows. The open-source PresentMon project is used to collect graphics events via ETW.

Technical details and external sources were verified on 2026-09-20 for engine 0.5.2.