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 gameplay recordings, and the resulting numbers are not equal to “FPS in a specific game”. The full measurement cycle is described in the methodology.

Currently the engine 0.5.2 and the workload phase4.6-dev-1 are in use. The version must be kept in mind: a change of scenario makes results from different releases directly incomparable.

CPU: object simulation

The CPU block creates 65 536 objects with coordinates, velocities and flags. On every 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 the threads are not pinned manually. This approach imitates a “single lead” thread model with limited assistance, rather than a total parallel run on every core.

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

The determinism of the workload does not mean identical execution time: frequencies, temperature, the scheduler and background processes continue to influence 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 to distinguish
Geometry	6 scene draws with 9 216 instances each and 2 post-processing passes	Geometry processing and graphics work submission
Shader	1 scene draw, 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 conventional 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, 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.

After the measurements, the engine checks the output of each GPU workload: for Geometry, Shader, Compute, Combined and the loaded latency test, a control signature is recorded — the expected form of a small fragment of the result. The fragment read after completion is compared with the expected one; a mismatch means that the workload executed incorrectly and makes the run unusable. The check is performed after the scored measurements and does not affect the numbers themselves.

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

Repetition of blocks

The five performance workloads are performed 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 a 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 presentation queue limits. 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 state of the system participate in the output stage.

A practical check with 1920×1080, 1280×768 and 800×600 is given in the article on repeatability.

Verified for the described implementation: 2026-09-20.