跳转到内容

CPU 和 GPU 负载

本页内容

PCBenchmarkX 在每次重复时都以固定的工作量运行其合成负载,因此它们可以在不同系统之间进行比较。此类测试不使用游戏录像,最终数字也不等于“某款游戏中的 FPS”。完整的测量循环见方法说明。

本说明适用于引擎 0.8.0。不同版本之间 GPU 场景的执行方式发生了变化,因此旧测量结果不能仅通过重新计算分数就视为与新结果等价。若要验证驱动或超频,请使用同一引擎版本。

在 CPU 模块中创建 65 536 个对象,带有坐标、速度和标志。每一步都会重新计算运动、边界反弹和可见性。主线程先连续处理 8 192 个对象,然后把剩余部分交给工作线程,并同时进行准备工作。随后线程同步。

工作线程数量按以下规则选择:

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

如果物理核心数未知,则按逻辑处理器进行估算。线程的核心不会手动固定。这种方式模拟的是“一个主线程”加有限协助的模型,而不是在每个核心上全面并行运行。

对象的状态和遍历顺序是确定性的。在每次测量 CPU 区段之前都会重置,并执行 512 个不计入成绩的准备帧,以免把上一次运行的残留状态带入本轮系列。

负载的确定性并不意味着执行时间相同:频率、温度、调度器和后台进程仍会影响测量。

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,不使用厂商扩展。同一份代码可在不同世代和不同厂商的显卡上执行,没有针对特定厂商的单独分支。

负载执行的正确性会与速度分开检查。若出错,请依据程序提示,排除原因后重新测试。

本套件中没有单独的磁盘速度和 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。

界面和延迟测试通过单独的输出路径工作。因此,仅改变桌面分辨率本身并不会减轻负载。不过,仍不能把任何分辨率下的结果都读作“完全一致”:输出环节仍涉及驱动和系统当前状态。

版本 0.5.2 在 1920×1080、1280×768 和 800×600 下的存档验证见可重复性文章。在 GPU 场景变更后,它不能替代新一轮测试。

Geometry、Shader 和 Compute 检验不同的执行路径。同一块显卡可能在一个场景中更快,在另一个场景中更慢。驱动版本、频率、功耗限制和命令提交都可能改变结果。仅凭 Compute 一项存在差异,不足以把差异只归因于驱动。请比较多次重复、引擎版本以及每个场景的单独结果。

降低桌面分辨率不会减小 Compute 的工作网格。该测试使用自己的计算着色器,而不是窗口显示的 FPS。Compute 在基础 GPU Score 中的权重为 10%;详情见公式。

已针对所述实现验证:2026-10-02。