レイテンシ測定とPresentMon

PCBenchmarkXは内部処理遅延とフレーム出力遅延を別々に測定します。これらのソフトウェアメトリクスは、マウスクリックから画面上のピクセルが発光するまでの経路全体を記述するものではありません。完全な測定サイクルは手法に記載されています。

独自のソフトウェア刺激

定常ストリームは8-12 msの決定論的な間隔で信号を生成します。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`までの間隔

各段階は統計とパーセンタイルを含む分布として提供されます。セグメントは2つの中央値の減算ではなく、各マークのペアごとに個別に計算されます。段階の終了マークが存在しないか信頼できない場合、その分布は空のままです — 代用値はありません。タイマーの遅延(予定時刻と実際の信号の不一致)は、信号前の別の診断として記録され、経路の合計値には含まれません。

QPCと独自のGPU timestamps

CPU時間はQueryPerformanceCounterを通じて記録されます。GPUについては、エンジンは測定対象の処理の前後に2つの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 msにキャリブレーションされたGPU負荷で動作します。つまり、約120 Hzの計算バジェットです。物理モニターは異なるリフレッシュレートを持つ場合があります。

キャリブレーションはシェーダー内の複雑さを1-4096の範囲で変更します。パス数は固定のままです: 4つのポストパス。まず目標時間の周辺で範囲が選択され、次にそれが絞り込まれ、選択された構成が検証されます。高速なビデオカードで同じ時間を占めるには、より複雑な処理が必要です。

パフォーマンステストでは、処理量は固定です。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メトリクスの精度の制限を指摘しています。そのため、エンジンは独自のGPU timestampsをETWからの推定で置き換えません。

PCBenchmarkXで開発されたもの

PCBenchmarkXでは、信号ジェネレーター、フレーム段階のマッピング、CPUシミュレーション、D3D12負荷、Loadedのキャリブレーション、繰り返しブロックの順序、測定の収集、統計処理、スコアモデルが開発されています。QPCとD3D12はWindowsが提供します。ETWを通じたグラフィックスイベントの収集には、オープンソースプロジェクトPresentMonが使用されます。

測定の説明はエンジン0.8.0向けに2026-10-02に更新されました。QPCとD3D12に関するMicrosoftのドキュメントはこの日付で再確認されました。PresentMonの参照は使用バージョン2.5.1に対応します。