CPU and GPU loads

PCBenchmarkX runs its synthetic workloads with a fixed amount of work on every repetition, so they can be compared across different systems. Such tests do not use game captures, and the resulting numbers are not equal to “FPS in a specific game”. The full measurement cycle is described in the methodology.

This description applies to engine 0.8.0. The execution of GPU scenarios changed between versions, so old measurements cannot be considered equivalent to new ones merely after recalculating scores. To check a driver or overclocking, use a single engine version.

CPU: object simulation

The CPU block creates 65 536 objects with coordinates, velocities and flags. On each step, movement, bouncing off boundaries and visibility are recalculated. The main thread first processes 8 192 objects in a row, then hands the remaining part to worker threads and performs preparation in parallel. The threads are then synchronized.

The number of worker threads is chosen by the rule:

workers = clamp(physical_cores − 1, 1, 6)

If the number of physical cores is unknown, an estimate based on logical processors is used. Cores for threads are not pinned manually. This approach imitates a “single leader” thread model with limited assistance, rather than a fully parallel run on every core.

The state and traversal order of objects are deterministic. Before each measurement of the CPU section, it is reset and performs 512 warm-up frames outside the score, so that residual state from the previous run is not carried into the series.

Determinism of the workload does not mean identical execution time: frequencies, temperature, the scheduler and background processes continue to affect the measurement.

Three GPU workloads

The GPU part works through Direct3D 12. The internal working textures have a fixed size of 1920×1080, regardless of the window and desktop size.

Workload	Computational work	What it helps distinguish
Geometry	6 scene renders of 9 216 instances and 2 post-processing passes	Geometry processing and graphics work submission
Shader	1 scene render, 16 post-processing passes, shader complexity parameter 24	Pixel and texture load
Compute	Grid 1920×1080, groups 8×8, integer computations with 96 iterations	Compute shader execution
Combined	CPU simulation and a fixed graphics pipeline	Joint operation of CPU, driver and GPU

These are separate scenarios with different amounts of work. For example, 8 000 conditional Compute frames cannot be read as 8 000 FPS in a game or directly compared with 800 Geometry frames. To combine them, per-scenario normalization is used, as described in the score calculation.

The workloads are written against a portable feature level: shader model 5.0 and feature level 11_0 without vendor extensions. The same code runs on different generations and manufacturers of video cards, without a separate branch for a specific vendor.

Correctness of workload execution is checked separately from speed. If an error occurs, follow the program’s message and repeat the test after eliminating the cause.

There are no separate disk speed or RAM throughput tests in this set. Memory and the driver affect the execution of the workloads, but the benchmark does not calculate separate SSD and RAM scores.

Repetition of blocks

The five performance workloads are executed in three rounds with a shuffled order:

Round	Order
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

The position of each workload in the sequence changes from round to round. This reduces its influence on the comparison. Warm-up can still change the results, so for the blocks the spread of execution speed and its change from the first block to the last are additionally saved.

To evaluate a scenario, the arithmetic mean of the throughput of its three blocks is taken. The median and geometric mean of the blocks can be viewed as additional diagnostics, but the final metric still remains on this mean.

Why low resolution does not make the main test easier

The CPU, GPU and Combined workloads are executed outside the screen buffer. Their command submission path does not invoke Present and does not wait for a present queue limit. The internal textures remain 1920×1080, even if the desktop is switched to 800×600.

The interface and the latency test work through a separate output path. Therefore, changing the desktop resolution by itself does not make the workload easier. Nevertheless, one still cannot read an “absolutely identical” result at any resolution: the driver and the current system state participate in the output stage.

An archival check of version 0.5.2 with 1920×1080, 1280×768 and 800×600 is given in the article on repeatability. It does not replace a new series after the GPU scenarios change.

Drivers and comparing video cards

Geometry, Shader and Compute test different execution paths. One video card may be faster in one scenario and slower in another. The driver version, frequencies, power limits and command submission can change the result. A single differing Compute is not enough to attribute the difference solely to the driver. Compare several repetitions, the engine version and each scenario separately.

Reducing the desktop resolution does not reduce the Compute working grid. This test uses its own compute shader, not the FPS of window presentation. The weight of Compute in the base GPU Score is 10%; details are given in the formula.

Verified for the described implementation: 2026-10-02.