レンダリングキュー遅延と低遅延技術：NVIDIA Reflex、AMD Anti-Lag、およびGPU高負荷時の入力遅延解消ガイド

高フレームレートにおける「入力遅延のパラドックス」

PCゲーミングの世界では、「フレームレート（FPS）さえ高ければ、操作の入力遅延は必然的に最小化される」という誤解が広く信じられています。多くの競技プレイヤーが高性能なグラフィックスカードを導入し、画質設定を競技用プリセットまで下げて画面上のFPSカウンターが140〜240FPS以上を維持しているにもかかわらず、急激なエイム操作時にマウスが画面上で「浮いているような感覚」や鈍重な遅延を感じることがあります。

この違和感の根本原因は、「スループット（Throughput）」と「レスポンス性（Responsiveness）」の混同にあります。

+--------------------------------------------------------------------------+
|                  スループット（処理量）とレスポンス性（応答速度）            |
+--------------------------------------------------------------------------+
|  フレームレート（スループット / Throughput）                             |
|  - ハードウェアが1秒間に処理・表示できる完全なフレーム数。                 |
|  - 指標：FPS またはフレームタイム（ms = 1000 / FPS）。                   |
|  - 映像のなめらかさ、視覚的明瞭度、網膜上の残像感軽減に寄与する。          |
+--------------------------------------------------------------------------+
|  システム遅延（レスポンス性 / Responsiveness）                           |
|  - プレイヤーのマウス入力（クリック・移動）から画面上のピクセル発光までの全時間。|
|  - 指標：エンドツーエンド遅延（ミリ秒 ms）。                               |
|  - パイプライン内でフレーム待機列が発生すると、高FPS下でも大幅に悪化する。  |
+--------------------------------------------------------------------------+

ゲームが GPUバウンド（GPU負荷率が98%〜100%に達した飽和状態） になると、システム全体のボトルネックはソフトウェアのレンダリングキュー（Render Queue）に移行します。このとき、描画負荷から解放されているCPUは、手一杯のGPUよりも遥かに速いペースで物理演算を行い、描画命令（Draw Calls）を発行し続けます。GPUが命令待ちで遊休状態（Starvation）に陥るのを防ぐため、グラフィックスAPIとディスプレイドライバは未処理フレームをバッファに蓄積します。

この事前レンダリングバッファはGPUを常にフル稼働させて平均FPSを最大化する一方で、深刻な入力ペナルティをもたらします。ゲームエンジンがCPUシミュレーション段階でマウス操作をサンプリングしても、そのフレームデータはバッファ内で前の2〜3フレームがGPUで描画完了するのを待たされます。その結果、画面に現れるクロスヘアの動きは、実際には数十ミリ秒前の過去の操作を反映したものになってしまいます。

エンドツーエンド遅延パイプラインの構造

レンダリングキュー遅延がどこで発生するかを特定するには、マウスクリックから光子がディスプレイから放たれるまでの全経路を把握する必要があります。

[ マウス / キーボード周辺機器 ]
        |
        | 1. ペリフェラル遅延（スイッチデバウンス、マイコン処理、USBポーリング）
        v
[ OSおよびゲームエンジン ]
        |
        | 2. 入力サンプリングとワールドシミュレーション（CPUが位置・視点・物理を更新）
        v
[ レンダリングスレッド ]
        |
        | 3. 描画命令の発行と送信（CPUがDraw Callを構築してAPIにディスパッチ）
        v
+==========================================================================+
| 4. ドライバおよびAPIレンダリングキュー（最大のボトルネック段階）         |
|    - GPU利用率が99%〜100%の飽和時に発生                                   |
|    - キュー深度：通常1〜3フレーム分の事前レンダリングバッファ              |
|    - 遅延蓄積量：キュー深度 * 単一フレーム描画時間                        |
+==========================================================================+
        |
        v
[ グラフィックスプロセッサ（GPU） ]
        |
        | 5. GPU描画処理（頂点変換、ラスタライズ、ピクセルシェーディング、ポストエフェクト）
        v
[ ディスプレイ出力パイプライン ]
        |
        | 6. フレーム提示（Present）、垂直同期（V-Sync）、パネルスキャンアウト
        v
[ ディスプレイから放たれた光子が目に届く ]

レンダリングキュー遅延の定量的影響

フレームタイム $16.67\text{ ms}$ の60 FPSで動作しているゲームを例にとると、グラフィックスドライバが2フレーム分の事前レンダリングバッファを保持している場合：

$$\text{キュー遅延} = 2 \times 16.67\text{ ms} = 33.34\text{ ms}$$

これに周辺機器のサンプリング、エンジン処理、GPU自体の描画時間（仮に $25\text{ ms}$）を加えると、プレイヤーが体感する総合エンドツーエンド遅延は $60\text{ ms}$ 近くに達します。

最新ハードウェアで144 FPS（フレームタイム $6.94\text{ ms}$）まで引き上げた環境であっても、2フレームの未処理キューは純粋な待機時間として約 $14\text{ ms}$ を加算します。ミリ秒単位の反射速度と筋肉記憶に依存する競技対戦において、状況によって激しく変動するレンダリング待機時間は、射撃精度の不安定さを引き起こす主要因となります。

ドライバレベル低遅延モード vs 組み込み型SDK

レンダリングキューの滞留を解消するため、GPUベンダーは当初ディスプレイドライバ側での制御を試みました。しかし、モダンな低レベルグラフィックスAPIの登場によりドライバ介入の限界が露呈し、ゲームエンジン自体に深く統合されるSDKアプローチへと進化しました。

1. ドライバレベル制御：NVIDIA Ultra-Low Latency と AMD Radeon Anti-Lag 1

グラフィックスコントロールパネルで提供される低遅延設定（NVIDIAコントロールパネルの「低遅延モード：オフ / オン / ウルトラ」およびAMDの初代「Radeon Anti-Lag」）は、ゲームプロセスの外部で動作します。

• 「オン（On）」モード：ドライバレベルでの事前レンダリングフレーム数を、デフォルトの2〜3フレームから厳格に1フレームへと制限します。
• 「ウルトラ（Ultra）」モード：ディスプレイのリフレッシュタイミングに合わせ、フレームの描画送信タイミングを可能な限り遅らせてジャストインタイム描画を試みます。

DirectX 12 および Vulkan における機能不全

ドライバレベルのキュー制御は、DirectX 9やDirectX 11といった従来の高レベルAPI向けに設計されたものでした。これらのAPIでは、グラフィックスドライバがパイプラインキューとバックバッファを完全に掌握していたためです。

しかし、モダンな DirectX 12 や Vulkan では、スワップチェーンの割り当て、フレーム待機オブジェクト（DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT など）、およびコマンドキューのスケジューリング権限がドライバから剥奪され、ゲームエンジン内部へと直接委ねられています。

ドライバがゲーム自身のコマンドリストを強引にブロックしようとすると、プログラムのデッドロックや重度のマイクロスタッター（Micro-stutter）を誘発するため、ネイティブDX12/Vulkanタイトルではドライバ側の「低遅延ウルトラ」設定はほとんど効果を発揮しません。

2. 組み込み型SDK：NVIDIA Reflex と AMD Radeon Anti-Lag 2

モダンなグラフィックスアーキテクチャでキュー滞留を完全に克服するため、低遅延制御はゲームエンジンのコアループへと移植されました。NVIDIA Reflex SDK および AMD Radeon Anti-Lag 2 SDK は、エンジンの物理シミュレーションとレンダリングループに直接組み込まれます。

従来のレンダリングパイプライン（GPUバウンド時）：
CPU: [ シミュ 1 ][ 送信 1 ][ シミュ 2 ][ 送信 2 ][ シミュ 3 ][ 送信 3 ]
GPU:                      [------- GPU 描画 1 -------][------- GPU 描画 2 -------]
キュー:                   | 第2フレームがメモリで待機  | 第3フレームがメモリで待機
遅延状態: 非常に高い（入力が早すぎる段階でサンプリングされ、キュー内に長期間滞留）

組み込み型同期パイプライン（Reflex / Anti-Lag 2 有効時）：
CPU:          [ シミュ 1 ][ 送信 1 ]         [ シミュ 2 ][ 送信 2 ]         [ シミュ 3 ]
GPU:                               [-- GPU 描画 1 --]          [-- GPU 描画 2 --]
キュー:                            | キュー完全消滅（待機ゼロ） | キュー完全消滅（待機ゼロ）
遅延状態: 最小（GPUが空く直前までCPUが意図的に休止し、直前に最新入力をサンプリング）

エンジン内の要所に明示的な同期マーカー（SetLatencyMarker(SIMULATION_START) や SetLatencyMarker(RENDERSUBMIT_START) など）を配置することで、ゲームエンジンはGPUの描画完了状態をリアルタイムで直接問い合わせます。

GPUの満載を検知すると、CPUは無駄な先行フレームを生成するのを止め、能動的にスリープ（一時休止） します。そして、GPUが直前のフレームを描画し終えて次の命令を受け付けられる「直前の1ミリ秒」まで、マウスやキーボードの入力サンプリングを意図的に引き延ばします。

この仕組みにより、以下の2大メリットがもたらされます：

1. レンダリングキューの完全崩壊：未処理フレームキューの深さが従来の2〜3フレームから事実上の「ゼロ」へと圧縮されます。
2. 極限まで新鮮な入力の反映：サンプリングされた物理入力が一切待たされることなく即座にGPUへと送られ、画質や平均フレームレートを犠牲にすることなく、入力遅延が大幅に削減されます。

NVIDIA Reflex の詳細分析：「On」と「On + Boost」の違い

Reflex対応タイトルでは、通常「On」と「On + Boost」の2つの動作モードが用意されています。それぞれのハードウェアレベルでの挙動を理解しておくことで、誤った設定を防ぐことができます。

+-------------------------------------------------------------------------------+
|                        NVIDIA REFLEX 動作モードの比較                         |
+-------------------------------------------------------------------------------+
|  Reflex Off（無効）                                                           |
|  - エンジン側で同期制御を行わず、GPU負荷時にレンダリングキューが蓄積。        |
|  - 純粋な最大スループットは得られるが、入力遅延が著しく増加・不安定化する。   |
+-------------------------------------------------------------------------------+
|  Reflex On（有効）                                                            |
|  - CPUシミュレーションとGPU描画のタイミングを動的に同期。                    |
|  - GPUバウンド時におけるレンダリングキューの待機列を完全に排除。              |
|  - グラフィックスカードの標準的な省電力およびクロックスケーリングは維持。     |
+-------------------------------------------------------------------------------+
|  Reflex On + Boost（ブースト有効）                                            |
|  - 「Reflex On」の同期・遅延削減機能をすべて網羅。                            |
|  - GPUの動的クロック低下メカニズム（P-states）を強制オーバーライド。          |
|  - 一時的なCPUボトルネック等でGPU負荷が下がった際も、コアとVRAMの高周波数を維持。|
+-------------------------------------------------------------------------------+

Boostモードの真の動作特性

• オーバークロックではない：Boostは最大クロックの上限を引き上げたり、温度や消費電力のリミット（TDP）を突破したりする機能ではありません。
• 一時的なクロック低下の防止：激しい銃撃戦では、視界の開けた屋外（GPU負荷が高い環境）と、障害物やプレイヤーモデルが密集する室内乱戦（CPU負荷が高まりGPU負荷が低下する環境）が頻繁に入れ替わります。GPU負荷が一時的に下がると、省電力機能が働いてGPUコアクロックが低いP-stateへと移行します。
• その直後にスモークや激しい爆発エフェクトが発生すると、GPUクロックが最大周波数へと復帰するまでに数サイクルの時間を要し、突発的なフレーム遅延（スパイク）が発生します。
• 最大クロックの即時待機：Reflex BoostはGPUクロックの引き下げを阻止し、常に最高動作周波数を維持させることで、突発的な描画負荷に対しても即座に最小のフレームタイムで処理を完了させます。

Boostモードの選択基準

• デスクトップPC：十分な冷却性能を持つデスクトップ環境では、競技タイトルにおいて「On + Boost」の常時使用が推奨されます。
• ゲーミングノートPC：ノートPCはCPUとGPUがヒートパイプやベイパーチャンバーを共有しているケースが大半です。GPUを高クロックで維持し続けると熱が蓄積し、CPU側がサーマルスロットリング（温度限界による強制クロック低下）を起こして激しいスタッターを招くリスクがあります。そのため、ノートPCでは安定した「Reflex On」の選択が適しています。

技術仕様の横断比較

G-SYNC / FreeSync およびフレームリミッターとの連携

可変リフレッシュレート（VRR）ディスプレイと低遅延技術を併用する際、組み込み型SDKは極めて重要な自動化制御を提供します。

画面全体のテアリングを完全に防ぐため、G-SYNC / FreeSync とグラフィックスコントロールパネルの 垂直同期（V-Sync） を併用する構成は定番です。しかし、ゲームのフレームレートがディスプレイの最大リフレッシュレートを超過すると、ドライバは画面のブランキング期間を待つために描画完了フレームの送出を保留し、表示側に重大なバッファ蓄積（バックプレッシャー）が発生して遅延が急増します。

この遅延トラップを防ぐため：

1. 自動フレームレート上限制御：NVIDIA Reflexは、G-SYNCと垂直同期の同時有効化を検知すると、自動的にディスプレイ最大リフレッシュレートの直下にFPS上限を適用します。
   • 144Hz ディスプレイの場合：Reflexは約 138 FPS で自動制御。
   • 240Hz ディスプレイの場合：約 225 FPS で自動制御。
   • 360Hz ディスプレイの場合：約 338 FPS で自動制御。
2. これにより、ゲームの描画出力は常にテアリングのないVRR有効レンジ内に収まり、従来の垂直同期が引き起こしていた表示待機キューの蓄積を完全に防止できます。

最適化とトラブルシューティングの判断フロー

ゲームが採用しているAPIと低遅延技術の対応状況に応じて、以下のフローに従って設定を行います。

[ ゲームの低遅延技術対応状況を確認 ]
           |
           +-------------------------------------+
           |                                     |
           v                                     v
[ ゲーム内設定に Reflex / Anti-Lag 2 が存在 ]  [ 組み込み型SDK非対応のゲーム ]
           |                                     |
           |                                     |
           v                                     v
1. ゲーム内オプションを有効化：        1. 採用APIを確認：
   - NVIDIA環境：Reflex を「On」に設定   - DX9 / DX11 の場合：
     （デスクトップで冷却に余裕があれば     NVIDIAコントロールパネル ->
      「On + Boost」を選択）                低遅延モードを「ウルトラ」に設定
   - AMD環境：Anti-Lag 2 を「有効」に設定   AMD Software -> Anti-Lag を「有効」に設定
2. ドライバ側の低遅延設定をオフにする    - DX12 / Vulkan の場合：
   （ドライバのフックとエンジンスケジュー   ドライバ側の低遅延設定は無効
    ラの競合を防ぐ）                  2. 手動フレーム制限を実施：
3. VRRディスプレイ環境の推奨設定：       - ゲーム内リミッターまたはRTSSを使用
   - コントロールパネルで G-SYNC を有効  - リフレッシュレートより 3〜5 FPS 下に制限
   - コントロールパネルで 垂直同期 を有効- またはGPU使用率が95%未満に収まる値に設定
   - Reflex が安全な上限制御を自動処理

マウス操作の違和感や鈍重さが、GPUレンダリングキューの滞留、垂直同期のバッファバックプレッシャー、あるいはペリフェラルのポーリング不整合のいずれに起因しているかを切り分ける際には、365Finds の検証済みハードウェア・ディスプレイ診断ガイドラインを参照することで、不確実なドライバ設定変更を繰り返すことなく、パイプラインの真のボトルネックを特定できます。

遅延削減効果の測定とテレメトリ診断

レンダリングキューが正常に排除されたかどうかは、対応ゲームが備える内蔵パフォーマンスオーバーレイを用いて客観的に数値検証できます。

1. ゲーム内の主要テレメトリ指標

• Game to Render Latency（ゲーム〜描画レイテンシ）：エンジンが入力をサンプリングしてから、CPUがそのフレームの描画命令発行を完了するまでの時間。
• Render Latency（描画レイテンシ）：GPUハードウェアがそのフレームの全描画タスクを完了するのに要した時間。
• PC Latency（PC遅延）：シミュレーション、レンダリングキュー待機、およびGPU描画時間の総和。

数値の見方と診断基準：

• 未最適化状態（レンダリングキューが滞留）： $$\text{Render Latency} = 10\text{ ms}, \quad \text{PC Latency} = 38\text{ ms}$$ 両者の間に約 $28\text{ ms}$ もの巨大な乖離が存在し、フレームがGPUに渡る前にキュー内で2〜3フレーム分待たされていることを示します。
• 最適化完了状態（Reflex / Anti-Lag 2 が正常動作）： $$\text{Render Latency} = 10\text{ ms}, \quad \text{PC Latency} = 13\text{ ms}$$ 差額がCPUの純粋なシミュレーション時間（$2〜3\text{ ms}$）のみに縮小し、未処理キューが完全に排除されていることが証明されます。

2. 避けるべき設定上の落とし穴

• ドライバ設定とエンジン設定の二重適用：ゲーム内でReflexを有効にしている状態で、NVIDIAコントロールパネルの低遅延モードを「ウルトラ」に設定してはいけません。ドライバ側のフック処理とエンジンの内部スケジューラが描画送信タイミングを取り合い、フレームタイムに突発的なスパイクが生じる原因となります。
• 1〜2 FPSの平均値向上を求めてReflexを無効化しない：Reflexをオフにすると、GPUが休止せずフル稼働するためベンチマーク上の平均FPSがごくわずかに上昇することがありますが、その代償として入力遅延が20〜40ms以上も跳ね上がり、操作性が著しく損なわれます。

参考資料

• Reflex SDK | NVIDIA Developer
• Introducing NVIDIA Reflex: Optimize and Measure Latency in Competitive Games | GeForce News | NVIDIA
• How To Reduce Lag - A Guide To Better System Latency | GeForce News | NVIDIA
• GitHub - GPUOpen-LibrariesAndSDKs/AntiLag2-SDK: The main repository for the AMD Radeon Anti-Lag 2 SDK. · GitHub
• Reduce latency with DXGI 1.3 swap chains - UWP applications | Microsoft Learn