コンテンツにスキップ

レイテンシ計測とPresentMon

目次

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

独自のソフトウェア刺激

Section titled “独自のソフトウェア刺激”

定常ストリームは、決定論的な間隔 8-12 ミリ秒 で信号を生成します。Windowsが許せば、高精度の待機タイマーを作成します。そうでなければ、通常の待機タイマーを使用します。イベントの待機は、カーネルを占有してしまう連続ポーリングなしで行われます。このとき、システムタイマーのグローバル解像度は変更されません。

各信号について、予定された期限、生成側の起床、実際の信号、受信側の起床、シミュレーション、コマンド送信、GPUタイムスタンプ、表示イベントがログに記録されます。共通のフレーム識別子がすべての段階を結び付けます。

予定された期限 → 生成側の起床 → 信号
                                            ↓
                               受信側の起床
                                            ↓
                                CPU → コマンド → GPU
                                            ↓
                            Present → 出力イベント

これらのタイムラインでは、タイマーの遅れと受信側の起床遅延が別々に確認できます。Core Latencyの開始点は実際の信号です。そのため、この指標では予定された期限から信号までのステップは計算されません。

遅延経路の段階別内訳

Section titled “遅延経路の段階別内訳”

結果には、測定された経路 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

Section titled “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

Section titled “BaselineとLoaded”

Baselineは、この負荷の最小構成での遅延を測定します。Loadedは、8,333333 ミリ秒 にキャリブレーションされたGPU負荷、つまり約120 Hzの計算バジェットで動作します。物理モニターは別のリフレッシュレートである可能性があります。

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

Performanceでは作業量は固定です。Loaded Latencyでは、GPU作業時間が異なるビデオカードで近くなるように負荷がキャリブレーションされます。取得されたタイムスタンプは測定後に正規化されません。

遅延テストのフレーム出力は、別のプレゼンテーションパスを通ります: flip-discardモードのボーダーレスウィンドウ、最大フレーム遅延(maximum frame latency)1、DXGIの待機オブジェクト、およびシステムが対応していればtearingです。このパスは、画面バッファ外で実行され Present を引き起こさない固定のパフォーマンス負荷とは分離されています。

PresentMonの役割

Section titled “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指標の精度の制限を指摘しています。そのため、エンジンは独自のGPU timestampsをETWからの推定で置き換えません。

PCBenchmarkXで開発されたもの

Section titled “PCBenchmarkXで開発されたもの”

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

技術情報と外部ソースは、エンジン 0.5.2 について 2026-09-20 に検証されました。