延遲測量與 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 的範圍內改變著色器內部的複雜度。通道數維持固定：四個後處理通道。首先在目標時間附近選定範圍，接著加以細化並驗證所選配置。若要在快速的顯示卡上佔用相同時間，就需要更複雜的工作。

在 Performance 中，工作量是固定的。在 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 是畫面顯示的軟體事件；不使用光電二極體來量測螢幕發光。顯示指標不計入 PC Score；計入的項目記載於分數計算中。建立 ETW 工作階段可能需要以系統管理員身分執行，或隸屬於「效能記錄使用者」群組。若工作階段無法建立，就不會有此診斷區塊，而失敗會明確記錄在結果中。缺少資料不等於零延遲。

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

PCBenchmarkX 自行開發的部分

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

技術資訊與外部來源已針對引擎 0.5.2 於 2026-09-20 查核。