CPU 與 GPU 負載

PCBenchmarkX 在每次重複時以固定工作量啟動其合成負載，因此可以在不同系統之間進行比較。這類測試不使用遊戲錄影，最終數字也不等於「特定遊戲中的 FPS」。完整的量測週期描述於方法論中。

目前採用引擎 0.5.2 與負載 phase4.6-dev-1。版本必須謹記：更換情境會使不同版本的結果無法直接互相比較。

CPU：物件模擬

在 CPU 區塊中會建立 65 536 個物件，帶有座標、速度與旗標。每一步都會重新計算移動、邊界反彈與可見性。主執行緒先連續處理 8 192 個物件，接著將剩餘部分交給工作執行緒，並同時進行準備工作。之後執行緒會同步。

工作執行緒的數量依下列規則選擇：

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

若物理核心數未知，則採用邏輯處理器的估計值。執行緒的核心不會手動固定。這種做法模擬「單一主導」執行緒搭配有限協助的模型，而非在每個核心上全面平行化的執行。

物件狀態與走訪順序是確定性的。在每次 CPU 區段量測前都會重設，並執行 512 個不計入成績的準備幀，以免把上一次執行的殘留狀態帶入系列中。

負載的確定性並不代表執行時間相同：頻率、溫度、排程器與背景程序仍會持續影響量測。

三種 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 的協同運作

這些是工作量各異的獨立情境。例如，8 000 個 Compute 的條件幀不能解讀為遊戲中的 8 000 FPS，也不能直接與 800 幀的 Geometry 相比。若要合併，則採用分數計算中所述的情境正規化。

負載以可攜的效能層級撰寫：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

每項負載在序列中的位置會逐輪改變。這能降低其對比較的影響。暖機仍可能改變結果，因此對於各區塊會額外保存執行速度的離散程度，以及其從第一個區塊到最後一個區塊的變化。

情境的評估採用其三個區塊 throughput 的算術平均。區塊的中位數與幾何平均可作為額外診斷查看，但最終指標仍以此平均值為準。

為什麼低解析度不會減輕主要測試

CPU、GPU 與 Combined 負載在螢幕緩衝區之外執行。其命令提交路徑不會觸發 Present，也不會等待顯示佇列的限制。即使桌面切換為 800×600，內部紋理仍保持 1920×1080。

介面與延遲測試透過獨立的輸出路径運作。因此，僅變更桌面解析度本身並不會減輕負載。儘管如此，仍不能將任何解析度下的結果解讀為「完全一致」：在輸出環節中，驅動程式與系統的當前狀態都會參與。

以 1920×1080、1280×768 與 800×600 進行的實務驗證見於關於可重複性的文章。

已針對所述實作驗證：2026-09-20。