CPU 和 GPU 负载
本页内容
PCBenchmarkX 在每次重复时以固定工作量运行其合成负载，因此可以在不同系统之间进行比较。此类测试不使用游戏录制，最终数字也不等于“某款游戏中的 FPS”。完整的测量周期见方法说明。
目前使用引擎 0.5.2 和负载 phase4.6-dev-1。需要牢记版本：更换场景会使不同版本的结果无法直接比较。
CPU：对象模拟
Section titled “CPU：对象模拟”在 CPU 模块中创建 65 536 个对象，带有坐标、速度和标志。每一步都会重新计算运动、边界反弹和可见性。主线程先连续处理 8 192 个对象，然后把剩余部分交给工作线程，同时并行进行准备工作。随后线程进行同步。
工作线程数量按以下规则选择：
workers = clamp(physical_cores − 1, 1, 6)如果物理核心数未知，则采用逻辑处理器的估算值。线程的核心不会手动固定。这种方式模拟的是“单一主线程”加有限协助的模型，而不是在每个核心上全面并行运行。
对象的状态和遍历顺序是确定性的。在每次测量 CPU 区段之前都会重置，并执行 512 个不计入成绩的准备帧，以免把上一次运行的残留状态带入本轮序列。
负载的确定性并不意味着执行时间相同：频率、温度、调度器和后台进程仍会影响测量。
三种 GPU 负载
Section titled “三种 GPU 负载”GPU 部分通过 Direct3D 12 工作。内部工作纹理具有固定尺寸 1920×1080，与窗口和桌面尺寸无关。
| 负载 | 计算工作 | 有助于区分什么 |
|---|---|---|
| Geometry | 6 次场景绘制，每次 9 216 个实例，以及 2 个后处理通道 | 几何处理和图形工作提交 |
| Shader | 1 次场景绘制，16 个后处理通道，着色器复杂度参数 24 | 像素和纹理负载 |
| Compute | 1920×1080 网格，8×8 工作组，96 次迭代的整数计算 | 计算着色器的执行 |
| Combined | CPU 模拟和固定图形管线 | CPU、驱动和 GPU 的协同工作 |
这些是工作量不同的独立场景。例如，Compute 的 8 000 个条件帧不能读作游戏中的 8 000 FPS，也不能直接与 Geometry 的 800 帧比较。为进行合并，采用分数计算中描述的按场景归一化。
负载基于可移植的功能级别编写：shader model 5.0 和 feature level 11_0，不含厂商扩展。同一份代码可在不同世代和不同厂商的显卡上运行，没有针对特定厂商的单独分支。
测量结束后，引擎会检查每个 GPU 负载的输出：对于 Geometry、Shader、Compute、Combined 以及加载的延迟测试，都固定了校验签名——即结果中一小段片段的预期形态。完成后的片段会与预期值比较；不匹配意味着负载执行不正确，并使本次运行不可用。检查在计分测量之后进行，不影响数字本身。
此测试集中没有单独的磁盘速度和 RAM 吞吐量测试。内存和驱动会影响负载的执行，但基准测试不会单独计算 SSD 和 RAM 的评分。
五项性能负载分三轮执行，并轮换顺序：
| 轮次 | 顺序 |
|---|---|
| 1 | CPU → Geometry → Shader → Compute → Combined |
| 2 | Shader → Compute → Combined → CPU → Geometry |
| 3 | Combined → CPU → Geometry → Shader → Compute |
每项负载在序列中的位置逐轮变化。这减少了其对比较的影响。预热仍可能改变结果，因此对于各区块还会额外保存执行速度的离散度及其从第一个区块到最后一个区块的变化。
评估场景时取其三个区块吞吐量的算术平均值。区块的中位数和几何平均值可作为额外诊断查看，但最终指标仍以该平均值为准。
为什么低分辨率不会减轻主测试
Section titled “为什么低分辨率不会减轻主测试”CPU、GPU 和 Combined 负载在屏幕缓冲区之外执行。其命令提交路径不会触发 Present，也不会等待显示队列限制。即使桌面切换到 800×600，内部纹理仍保持 1920×1080。
界面和延迟测试通过单独的输出路径工作。因此，仅改变桌面分辨率本身并不会减轻负载。不过，仍不能认为在任何分辨率下结果都“完全一致”：输出环节会涉及驱动和系统的当前状态。
使用 1920×1080、1280×768 和 800×600 进行的实际验证见关于可重复性的文章。
已针对所述实现验证：2026-09-20。