延遲測量與 PresentMon

本頁內容

PCBenchmarkX 分別量測內部處理延遲與畫面輸出延遲。這些軟體指標並不描述從滑鼠點擊到螢幕像素發光的完整路徑。完整的量測週期描述於方法論。

自有軟體刺激

固定串流以確定性間隔 8-12 毫秒產生訊號。若 Windows 允許，它會建立高精度的等待計時器；否則使用一般的等待計時器。等待事件不需持續輪詢，因為持續輪詢會佔用核心。系統計時器的全域解析度不會因此改變。

每個訊號都會記錄預定時限、產生器喚醒、實際訊號、接收端喚醒、模擬、指令送出、GPU 時間戳與顯示事件。共同的畫面識別碼會串連所有階段。

預定時限 → 產生器喚醒 → 訊號
                                            ↓
                               接收端喚醒
                                            ↓
                                CPU → 指令 → GPU
                                            ↓
                            Present → 輸出事件

在這些時間軸中，計時器延誤與接收端喚醒延遲可分別看出。Core Latency 的起點是實際訊號，因此在此指標中，從預定時限到訊號的這一步不計入。

延遲路徑的逐階段拆解

結果包含所量測路徑 latency_path 的逐階段拆解——分別針對 Baseline 與 Loaded。各階段從實際訊號起算：

階段	量測內容
`signal_to_consumer_wake`	從訊號到接收端喚醒
`cpu_processing`	CPU 處理：畫面的模擬與資料準備
`cpu_end_to_submit_start`	從 CPU 工作結束到開始準備送出的空檔
`workload_submit_cpu_span`	圖形 API 指令的準備與寫入
`submit_start_to_gpu_begin`	從開始準備到 GPU 工作開始；這不是純粹的佇列延遲
`gpu_execution`	GPU 工作本身的執行，以 GPU 時脈計
presentation spans	顯示：`Present` 的包裝，以及從訊號與從 GPU 工作結束到 `ScreenTime` 的間隔

每個階段都以包含統計量與百分位數的分布呈現。各區段是針對每一對標記分別計算，而非以兩個中位數相減。若某階段的最終標記缺失或不可靠，其分布會保持空白——不會有替代數值。計時器延誤（預定時限與實際訊號的落差）會記錄為訊號前的獨立診斷，不計入路徑的總計值。

QPC 與自有 GPU timestamps

CPU 時間透過 QueryPerformanceCounter 記錄。對於 GPU，引擎會在量測的工作前後各放置一個 timestamp query，透過 GetTimestampFrequency 取得佇列頻率，並將時脈差換算為毫秒：

GPU work, ms = (GPU_end − GPU_begin) × 1000 / GPU_frequency

根據 Microsoft 關於 D3D12 timing 的文件，timestamp query 反映工作進行到管線末端，而 GPU 與 CPU 計數器則透過 GetClockCalibration 相互對應。

GPU/QPC 校準配對可讓 GPU 工作的完成以與訊號相同的時間軸表示：

GPU_completion_QPC = calibration_QPC +
  (GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency

Core Latency, ms =
  (GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

此估算的準確度在很大程度上取決於 CPU 與 GPU 時鐘對應的精確程度。它仍然不涵蓋滑鼠的 USB 路徑、矩陣掃描時間或像素反應。Microsoft 另外說明了高精度 QPC 標記的細節。

Baseline 與 Loaded

Baseline 量測此負載在最小配置下的延遲。Loaded 則搭配校準至 8,333333 毫秒的 GPU 負載運作，也就是約 120 Hz 的運算預算。實際螢幕可能有不同的頻率。

校準會在 1-4096 的範圍內改變著色器內部的複雜度。通道數保持固定：四個後處理通道。首先在目標時間附近調整範圍，接著再細化，並驗證所選的配置。若要在快速的顯示卡上佔用相同時間，就需要更複雜的工作。

在效能測試中，工作量是固定的。在 Loaded Latency 中，負載會經過校準，使 GPU 工作時間在不同顯示卡上相近。量測後取得的時間標記不會被正規化。

延遲測試的畫面輸出走獨立的呈現路徑：flip-discard 模式下的無邊框視窗、最大畫面延遲（maximum frame latency）1、預期的 DXGI 物件，以及系統支援時的 tearing。此路徑與固定的效能負載分開，後者在螢幕緩衝區之外執行，且不會觸發 Present。

PresentMon 的角色

顯示事件使用 PresentMon 2.5.1 程式庫。這是一個分析 Windows 圖形事件的 ETW 專案，由其作者所描述。此量測流程中不使用 Procmon / Process Monitor。

PCBenchmarkX 會啟動自己的收集工作階段，篩選自身程序的事件，並將畫面與軟體訊號關聯起來。這不需要獨立的服務，也不需要手動啟動個別的 PresentMon。

會保存額外的間隔：

從訊號到 Present；
從 Present 到 ScreenTime；
從訊號到 ScreenTime。

ScreenTime 是軟體的畫面顯示事件；不使用光電二極體來量測螢幕的光。在基礎的 CPU/GPU/Latency 模型中，Baseline 與 Loaded 的權重在延遲元件內為 20/80。顯示指標不計入 PC Score；計入的項目描述於分數計算。啟動 ETW 工作階段可能需要以系統管理員身分執行，或隸屬於「效能記錄使用者」群組。若工作階段無法啟動，就不會有此診斷區塊，而失敗會明確記錄在結果中。資料缺失不等於零延遲。

PresentMon 的 GPU 時間也與自有的 D3D12 時間分開保存。PresentMon 的開發者指出 HAGS 下 GPU 指標的準確度限制。因此引擎不會以 ETW 的估算取代自有的 GPU timestamps。

PCBenchmarkX 中自行開發的部分

在 PCBenchmarkX 中自行開發的有：訊號產生器、畫面階段對應、CPU 模擬、D3D12 負載、Loaded 校準、重複區塊的順序、量測收集、統計處理與分數模型。QPC 與 D3D12 由 Windows 提供。透過 ETW 收集圖形事件則使用開放原始碼專案 PresentMon。

量測說明已針對引擎 0.8.0 更新於 2026-10-02。Microsoft 關於 QPC 與 D3D12 的文件已於此日期重新查核。PresentMon 的連結對應於所使用的版本 2.5.1。