（2026年版）NVIDIAコントロールパネルのディスプレイスケーリングの最適解　FPSゲーマー設定

最適化おじさん(K)PCゲームのあれこれ

2025年12月25日 06:34

RefTComputer × 最適化K コラボPC

ただの情報記事だと思って読んでください。
前半は理論的な説明で、後半に実践的な設定があります。
一番伝えたいことは

ゲームをFPS無制限でするなということ。

では行こう↓↓

モニターの性能を殺しているのは、あなたの「設定」だ。ドライバ内の『特急券』を奪い取れ。

「FPSはただの数字に過ぎない。我々が求めるのは、OSを完全に無視した『生』のピクセル転送だ！！迫真」

競技シーンにおいて、1000FPSや500FPSといった数字に一喜一憂するのはもう終わりにしましょう。
重要なのは、GPUが描き終えたフレームを、Windowsの合成処理（DWM）という巨大なラグの温床に触れさせることなく、いかに「そのまま」モニターへ叩き込めるか。ただそれだけなんです。

NVIDIAドライバ内部には、条件を満たしたフレームにだけ発行される低遅延フラグ（以下名称：特急券か低遅延フラグ）が存在します。
このフラグを手に入れたフレームだけが、Windowsという検問所をスルーし、最短経路で画面に現れる権利を得るのです（はなほじ）

なぜ「スペックは最高なのに、操作が重い」のか

「最新のRTX、Core i9、そして240Hzモニター。設定は全てLow。なのに、なぜかマウスの反応に粘り気を感じる。あるいは、敵と撃ち合った瞬間にだけ映像がわずかに引っかかる気がする」

この違和感は、あなたの直感が正しいです。
ドライバはあなたの設定を見て、密かにこう判断しています。「このフレームはGPUスケーリングで加工されているな」「このタイミングではバッファの整合性が取れないな」
そう判断された瞬間、あなたのフレームから特急券は剥奪され、強制的に「各駅停車ルート（DWM合成）」へと回されます。

そこではOSによる再合成が行われ、物理的に数ミリ秒の待機時間が追加されます。これが、高FPSが出ているにもかかわらず操作が重いと感じる「入力遅延の正体」です。

「無制限FPS」という信仰が、皮肉にもカクつきを生んでいる

多くのプレイヤーは「FPSは高ければ高いほど遅延が減る」と信じ、上限を解除します。しかし、ドライバの内部ロジックを覗けば、それがかえって自分を苦しめていることが分かります（てか制限した方がFPSの底値も安定します）

不規則なリズムで届くフレームは、ドライバ内の「検問所」にとって最も嫌われる存在。検問の瞬間にフレームが届いていなかったり、バッファの状態が不安定だったりすると、ドライバは安全策として低遅延パスを閉じます。我々が感じる「理由のないカクつき」は、この「特急ルート」と「遅延ルート」が激しく入れ替わる際のガタつきに他なりません。

ゲーム内のFPS値は「モニターヘルツ」で固定せよ。
ゲーム内でちゃんと安定して整数倍FPS値が出る場合のみ、「モニターヘルツの整数倍」まで上げる「例えば、240Hzモニターなら→480Hzでゲーム内制限をかける」
ドライバは、VBlank（画面更新タイミング）ごとにバッファのリストをスキャンしています（↓ロジックコード、分かりやすくしてます）

/**
 * @name nv_disp_mpo_find_ready_buffer
 * @brief 表示キューから準備完了状態の最新バッファを抽出
 * * @param pPlaneContext プレーン（階層）ごとの管理コンテキスト
 * @return 最適な表示対象バッファのポインタ。未完成ならNULL。
 */
PVOID nv_disp_mpo_find_ready_buffer(PNV_PLANE_CONTEXT pPlaneContext) {
    uint32_t current_index = pPlaneContext->PresentQueueIndex;
    PBUFFER_LIST pQueueBase = (PBUFFER_LIST)(pPlaneContext + 0x83d0); // 内部キューのオフセット

    // バッファリストを最新から順にスキャンするループ
    for (uint32_t i = 0; i < pPlaneContext->QueueDepth; i++) {
        // オフセット 0x11 (17) 単位で並ぶバッファ構造体へアクセス
        // 8ビット単位のポインタ計算によるアドレス特定
        PFRM_BUFFER_ENTRY pEntry = *(PFRM_BUFFER_ENTRY*)(pQueueBase + (current_index + i * 0x11) * 8);

        /**
         * ハードウェア・書き込み完了フラグの確認
         * 0xfb68: GPUの表示エンジンが「このメモリは読み取り可能」とマークするオフセット
         * 値が 1 (NV_PRESENT_STATUS_READY) であることが絶対条件
         */
        if (pEntry->HardwareStatusFlags[0xfb68] == NV_PRESENT_STATUS_READY) {
            // 検問合格：このバッファを現在の VBlank での表示対象 (Direct Flip) に採用
            return (PVOID)pEntry;
        }

        // 不合格の場合、このフレームは「まだGPUが描いている途中」とみなされ、
        // 次の古いバッファをチェックするか、フォールバックが発生する
    }

    return NULL;
}・非整数倍（例として240Hzモニター使用で：300FPSで制限をかける）↓※300 FPSの場合、1フレームの生成時間は約3.33msです。

フェーズのズレ→モニターの周期（4.16ms）とフレームの周期（3.33ms）が一致しないため、VBlankが来るタイミングとフレームが完成するタイミングの相対的な位置関係が、毎回少しずつズレていきます。
検問での不合格→この「ズレ」が積み重なると、ドライバがスキャンを行ったまさにその瞬間に、最新のバッファが「あと0.1msで書き込み完了する」という状態が統計的に必ず発生します。
結果→ ドライバは「最新フレームは未完成」と判断し、特急ルートを解除して安全な「各駅停車ルート（DWM合成）」へフォールバックします。これが入力遅延のスパイク（一瞬の重み）の正体。
・整数倍（例：240Hzモニターなら240FPSまたは480FPSでゲーム内制限をかける）↓
モニターの更新周期に合わせて、常に完璧なリズムでバッファが準備されます。
「整数倍」というルールにおいて、1倍（240FPS）も2倍（480FPS）も、ドライバ内の検問をパスするための「位相同期（Phase Lock）」という条件を等しく満たしているからです。

対策→240Hz環境なら、FPSリミッターで「240Hz」または「480FPS」に固定してください。

FPS「無制限」より良いのか？

1000 FPS出していれば低遅延最強列伝卍
ルートの切り替え遅延→特急ルート（Direct Flip）と通常ルート（DWM合成）が入れ替わること自体が、システムに大きなジッターを与えます。

GPU負荷の安定→整数倍で制限をかけることで、GPUが常にフル稼働（100%）して描画命令が「行列（キュー）」に並ぶのを防ぎ、別処理（高速コピー）などの処理に余裕を持たせることができます。

「FPSは高ければ高いほど遅延が下がる」という考え方は、理論上は正しいですが、現代の複雑なOSとドライバの仕組みにおいては「落とし穴」です。

結論から言えば、無制限FPSは「平均的なレンダリング遅延」をわずかに下げるかもしれませんが、引き換えに「特急ルート（Direct Flip）の剥奪」と「遅延のバラつき（ジッター）」を引き起こすリスクを抱えています。
安定したエイムとなると・・・わかるよね・・・？

低遅延フラグを確実に維持するための物理的な条件「特急ルートふぁああああああ」

ドライバ内の関数は、現在の表示設定に「加工」が必要かどうかをビット単位で監視しています＝Bit 11の検問です。
NVIDIAコントロールパネルで「GPUスケーリング」を選択すると、このBit 11が強制的に立ちます。すると、呼び出し元の関数は「加工が必要なバッファはそのまま送れない」と判断して、制限マスクを生成して特急券を破棄します。

解決策→スケーリングを実行するデバイスは必ず「ディスプレイ」に設定してください。モニター側に拡大を任せることで、GPU内の加工ビットを0に保ち、直通パスを確保できます。

ほんならなぜ「GPUスケーリング」という機能が存在するんかえ？

結論から言えば、GPUスケーリングは「互換性と機能性のための妥協案」になる

モニターの性能不足の補完→全てのモニターが高性能なスケーリングチップを搭載しているわけではなく。特定の解像度（例：1280x960の4:3）を正しく引き延ばせない、あるいは表示すらできないモニターが存在するため、GPU側で計算して「ネイティブ解像度の信号」として送り出す必要がある。
アスペクト比の強制制御→モニター側の設定に関わらず、黒帯（ブラックバー）を入れるか、引き延ばすかをOS側で確実に制御したい場合に必要となる。
新機能（整数スケーリング）の実装→ドット絵のようなゲームをボケさせずに拡大する「整数スケーリング」はGPUの演算が必要なため、この機能を有効にするにはGPUスケーリングが必須。

なぜ多くのゲーマーが「GPUスケーリング」を選択しているのか？

これは完全に「体感上の理由」と「過去の蓄積」やね。

モニター側のスケーラーが「遅すぎる」ケース
安価モニターや古い製品では、モニター内部の画像処理チップ（スケーラー）の遅延が非常に大きい場合がある。この場合、GPUが「Bit 11」の検問に引っかかってDWM合成（遅延ルート）に回されたとしても、モニター側の物理的な遅延よりはマシという逆転現象が起きる。

画面切り替え（Alt+Tab）の高速化
GPUスケーリングを使うと、モニターへ送る信号の解像度は「常にネイティブ（例→1920x1080）」で固定されます。ゲーム内解像度を変えてもモニターの信号自体は変わらないため、画面が暗転して同期し直す時間が短縮される。

「GPUの方が速い」という情報の定着
「GPUは並列計算が得意だから、専用チップのモニターより速いはずだ」という推測が広まりましたが、これは「ドライバ内のプレゼンテーション・パス（表示経路）の分岐」という視点が抜け落ちた議論になる（そんなんわからんしねぇ）

「GPUの方が計算が速い」という主張に対してこう言える。

「GPUの計算速度（ナノ秒単位）の問題ではなく、ドライバ内の論理的な条件分岐の問題だ。GPUスケーリングを選択した時点で、ドライバはプレゼンテーション・パスを『特急（Direct Flip）』から『各駅（DWM合成）』へ切り替えてしまう。計算がどれだけ速くても、ルート自体が遅い方に固定されるなら意味がない」あーめん。

メモリ境界の整合性：4KBアライメントの維持

((local_a0 ^ local_68) & 0xfff) != 0

という判定式は、フレームが格納されているメモリの「番地」を見ています。
内容: データの先頭が4KB（0xfff）の境界に整列していない場合、表示エンジンは高速転送（Direct Flip）を拒否します（下記詳細↓）

コンピュータのメモリ管理において、最小の単位は通常 4KB（4096バイト） です。これを「ページ」と呼びます。

16進数の計算→4096バイトを16進数で表すと0x1000です。
マスク処理→& 0xfff（下位12ビットの抽出）を行うと、そのアドレスが「4KBの境界からどれだけズレているか」がわかります。
XOR（^）の役割→local_a0（現在表示中のアドレス）と local_68（次に表示するアドレス）を比較して「両方のバッファが、4KBページの開始地点から全く同じオフセット（ズレ）で配置されているか」を確認します。

もし、この結果が 0 でない場合、ドライバは「メモリ配置が不規則である」と判断し、ハードウェアによる直接転送（Direct Flip）を断念します。

ハードウェアの制約、DMA転送の「高速道路」

GPUの表示エンジン（Display Engine）がフレームバッファを読み取るとき、CPUを介さず直接メモリにアクセスする DMA（Direct Memory Access） という仕組みを使います。

物理的な読み取りルール

GPU内のDMAコントローラは、効率を最大化するために「4KBの境界」を基準にデータを読み込むように設計されています。

アライメントが一致している場合→GPUは「ページの先頭から読み込む」という単純な命令だけで、最短サイクルでピクセルデータを吸い上げ、モニターへ送出できます。これが Direct Flip（特急ルート） の物理的な条件。
アライメントがズレている場合（非整列）→データの先頭がページ境界を跨いでいると、ハードウェアは1回の読み取りで済むところを「2つのページからデータを取ってきて繋ぎ合わせる」という余計な処理を強いられます。この「データの繋ぎ合わせ」が発生する状態では、ハードウェアは Direct Flip の高速回路を使用できず、OSの合成エンジン（DWM）に処理を委ねる 「普通ルート（各駅停車）」 へと切り替わります。

解決策→ウィンドウを他のモニターに跨がせたり、プレイ中に解像度を頻繁に変えるのは避けてください。メモリの再確保（アライメントのズレ）を招き、低遅延フラグが折れる原因になります。

「解像度変更」や「モニター跨ぎ」が危険な理由

なぜ「解像度を頻繁に変えるな」「モニターを跨がせるな」という解決策に繋がるのか、その裏側で起きているメモリの挙動を説明します。

メモリの再確保と断片化

ゲームの解像度を変更したり、ウィンドウを別のモニターへ移動させると、ドライバは新しい画面環境に合わせてフレームバッファを 「再確保」 します。

断片化（フラグメンテーション）PCを長時間起動していたり、多くのアプリを開いていると、メモリ空間が虫食い状態に。
不適切な配置、再確保の際、OSが「ちょうどいい4KB境界の空き地」を見つけられないと、境界から少しズレた場所にバッファを配置してしまうことがある。
検問での不合格→一度ズレた場所に配置されると、先ほどの ((local_a0 ^ local_68) & 0xfff) != 0 のチェックに永遠に引っかかり続け、再起動するか配置が直るまで、そのゲームの低遅延フラグは折れたままに。

※マルチモニターの罠

特に異なるリフレッシュレートや解像度のモニターを跨ぐと、Windowsのグラフィックススタック（dxgkrnl.sys）がバッファの管理方式を強制的に切り替えるため、アライメントの不一致が極めて発生しやすくなります。

解像度の固定: ゲーム起動後に解像度をガチャガチャと変えると、メモリの再確保が繰り返され、アライメントが崩れる確率が上がります。
定期的な再起動: 長時間プレイやブラウザの多用でメモリが断片化すると、バッファが「汚い場所」に配置されやすくなります。

「メモリ境界」は目に見えませんが、GPUにとっては「線路の継ぎ目」のようなもの。継ぎ目がズレていれば、列車（フレーム）は脱線を防ぐために減速（別ルートへフォールバック）せざるを得ません。4KBの境界を完璧に揃えることは、GPUに「全力で走っていいぞ」という許可を与える行為なのです（特大はなくそ）

MPO（マルチプレーン・オーバーレイ）の活用

MPO：GPU内部の「デジタル・マージ機」

MPOは、簡単に言えばGPUの出力ユニットの中に搭載された、モニターへ送る直前に映像を重ね合わせる専用のハードウェア。

デスクトップに複数のウィンドウ（ゲーム、Discord、ブラウザなど）がある場合、Windows OS（DWM）がそれらを一枚の絵に「合成」してからGPUに渡す。
この合成工程で遅延が発生。しかし、MPOが機能すると、GPUは「ゲームの層」と「Discordの層」を別々のバッファ（メモリ領域）のまま保持し、モニターへ出力するまさにその瞬間に、ハードウェア的に重ね合わせます。

だがしかしオーバーレイが破壊する。

nvlddmkmのループ処理では、画面上にあるすべての「プレーン（階層）」に対して、一つずつ適格性チェックを行っています↓（わかりやすくしてます）

/**
 * @brief マルチプレーン・オーバーレイ（MPO）の整合性チェック
 * 各表示プレーンが Independent Flip（独立フリップ）を維持できるか判定する
 */

uint32_t PlaneIndex = 0;
uint32_t PlaneCount = pDisplayConfig->TotalPlaneCount; // 画面上の全階層数
NTSTATUS Status;

do {
    // 1. 各プレーンのステータスおよびメモリ配置の取得
    // FUN_140d7cc40: 指定されたインデックスのプレーンハンドルを検証
    PPLANE_STATE pPlaneState = GetPlaneState(pContext, PlaneIndex);

    // 2. ディスプレイエンジンへのハードウェア支援問い合わせ
    // 0x5a8: CheckMultiPlaneOverlaySupport プロトタイプへのオフセット
    // ここで「スケーリング加工が必要か」「アルファ合成が必要か」を確認する
    BOOLEAN IsHardwareSupportValid = pDisplayEngine->VTable->CheckMpoSupport(
        pDisplayEngine,
        pPlaneState,
        &MpoCaps
    );

    // 【運命の分岐点】
    // プレーンが1枚でも「ハードウェアによる即時フリップ」に不適合な場合
    if (!IsHardwareSupportValid) {
        // LAB_14162937f: 直接転送フラグ (Direct Flip) の剥奪処理へ移行
        // 全ての階層を DWM（デスクトップ・ウィンドウ・マネージャー）に集約し、合成させる
        goto FALLBACK_TO_DWM_COMPOSITION;
    }

    // 次のプレーン（オーバーレイ等）へ
    PlaneIndex++;

} while (PlaneIndex < PlaneCount);

// 全てのプレーンが合格した場合のみ、低遅延フラグを維持・発行
CurrentPresentFlags |= PRESENT_FLAG_DIRECT_FLIP; // 0x80000000

例えばDiscordのオーバーレイやWindowsの通知バナーは、しばしば「半透明処理（アルファブレンディング）」や「角の丸み」などの加工を必要とする。
この「1枚でも加工が必要なレイヤー」が混ざった瞬間、GPUのハードウェアスケーラーは「手に負えない」と判断→その結果、ゲーム画面がどれほど完璧な状態（フラグ維持可能）であっても、システム全体が遅延の多いDWMルートへ強制送還されます。

Windows 11「ウィンドウゲームの最適化」が与える引数　

この設定を有効にすると、OSはゲームに対して「Independent Flip（IFlip：独立フリップ）」という特権を与えます。

判定の「隔離」→OSが「ゲーム画面だけは、他のプレーンの不具合に巻き込まない」という属性をカーネルに伝えます。
メタデータの書き換え→（OSからのメタデータ）の中に、「この階層は独立してDirect Flipして良い」というフラグが立ちやすい。
結果→Discordのオーバーレイが「不合格」を出したとしても、ゲーム画面のプレーンだけはMPOのハードウェアによって単独で特急ルート（Direct Flip）を維持できる可能性が劇的に高まる。

対策↓
・不要なオーバーレイの排除
・「ウィンドウゲームの最適化」の有効化（現状バグも多い）
・ハードウェア・スケーリングの活用→NVIDIAパネルで「ディスプレイ側スケーリング」にしていれば、MPOエンジンが持つハードウェアスケーラーと干渉せず、より安定して独立フリップ（IFlip）が成立します。

ある程度、話が分かると出てくる疑問・・・フルスクリーンでプレイしているなら関係なくない？

「フルスクリーンならOSを無視できるはずだ」という直感は正しいですが、「フルスクリーン」は免罪符ではないです（キッパリ）

「専用フルスクリーン」を選択したとしても、GPUがモニターへピクセルを送り出す物理的な経路（プレゼンテーション・パイプライン）は、 nvlddmkm.sys のValidateMpoIndependentFlipSupportを必ず通過します。

判定の継続→フルスクリーンモードは、ドライバに対して「Direct Flip（特急ルート）を使って良い」という優先権を与えるだけです。
フラグの剥奪→フルスクリーンであっても、ドライバ内の検問（Bit 11やメモリ整合性）で「不適合」と判定されれば、その優先権は即座に剥奪されます。結果として、フルスクリーンなのに遅延が発生する「擬似的な各駅停車状態」に陥ります。

最近の Windows では、「フルスクリーンの最適化（FSO）」が標準で有効です。これにより、フルスクリーンは実質的に「OSが最大限に便宜を図ったウィンドウモード」として動作します。

MPO の介入→フルスクリーン中に「音量バー」を出したり、Discord の通知が来たりした際、MPO（マルチプレーン・オーバーレイ）がそれらを「別の階層」として処理しようとします。
リスク→もしオーバーレイ側が「不合格」を出せば、フルスクリーンのゲーム画面も道連れにされて遅延ルートへ叩き落とされます。

ほいなら、「全画面表示の最適化を無効にする」にチェックいれたらいいんじゃないんかぇ？

結論から申し上げます。「全画面表示の最適化を無効にする」にチェックを入れることは、MPOによる道連れリスクを回避する「強硬手段」としては有効ですが、現代のWindows 10/11においては「最速ルート」を自ら捨てることにもなりかねない諸刃の剣です。

「全画面表示の最適化を無効」にした際の物理的挙動の変化

このチェックを入れると、ゲームは現代的な「FSO（Fullscreen Optimizations）」ルートを離れ、「レガシー専用フルスクリーン（Legacy Exclusive Fullscreen）」という古い方式で動作します。

ドライバ内のフラグ処理への影響

MPOの完全シャットアウト→FSOを無効にすると、Windowsのグラフィックススタック（dxgkrnl.sys）はMPOの使用を停止します。 Discordなどのオーバーレイが「不合格」を出してゲームを道連れにするリスクは物理的に消滅。
ハードウェアの排他的占有→ゲームがディスプレイ出力を文字通り「独占」します。コード検問において、OSからの干渉が最小限になり、ゲーム単体での Direct Flip（特急券） が発行されやすくなります。

なぜ「無効化」が解決策として不完全なのか

一見するとメリットしかないように思えますが、現代のOS環境では以下の「検問エラー」を誘発する原因になります。

① 「最適化されたフリップモデル」の喪失

現代のWindows 10/11では、FSOが有効な状態での「独立フリップ（Independent Flip）」こそが、レガシーなフルスクリーンよりも低遅延であるケースが多い。 FSOを無効にすると、このハードウェアアクセラレーションをフルに活用した最新のプレゼンテーションパスが使えなくなる。

② 切替時の「Bit 11（加工フラグ）」の再浮上

レガシーフルスクリーンでは、Alt+Tabでの画面切り替え時にモニターの再同期（暗転）が発生。

この瞬間、ドライバ内ではメモリの再確保（再アライメント）が走り、内部コード↓

((local_a0 ^ local_68) & 0xfff) != 0（4KBアライメントチェック）

に引っかかる確率が急上昇。一度このチェックで「不一致」が起きると、ゲームを再起動するまで特急ルートが閉ざされるリスクが出てくる。

MPOの道連れリスクを恐れて「全画面表示の最適化を無効にする」べきかどうかは、あなたのプレイPC環境によります。

「無効」にチェックを入れても良い人

サブモニターを使わず、ゲーム中にオーバーレイも一切出さない。
Windows 10の古いバージョンを使用しており、MPOの挙動が不安定。
とにかく「OS側の干渉」という不確定要素をバイナリレベルで排除したい。

「有効（チェックなし）」のままにすべき人（推奨）

Windows 11を使用している。（OS側のMPO制御が高度化しているため）
「ウィンドウゲームの最適化」をONにしている（アンチ）
RTX 30シリーズ以降を使用しており、ハードウェアMPOの性能が高い。

「4:3は罪ではない。スケーリングの『場所』が罪なのだ。」

ゲーム内FPS制限はモニターHzと同じか、上げるなら整数倍である

144Hzモニターであれば「144FPS」または「288FPS」に固定する。
240Hzモニターであれば「240FPS」または「480FPS」に固定するといったように（ただしこれは理想であり下記の追記に実践的な設定方法を説明しています）
全ては準備完了のリズムを同期させ、バッファ選別ミスによるフォールバックを防ぐため。

追記:（2025年12月27日）

下の画像はVALORANTで320Hzモニターに対してFPS制限を設け計測したものです。同期率の話なので実践的ではないですが、６０秒計測、各FPS制限に張り付く形でデーターをとりました。（所詮は情報だ！と思ってみてください）

320FPS / 321FPS: 数値がほぼゼロ（0.03ms）に張り付いており、モニターの更新周期（3.125ms間隔）と完璧同期。 326FPS以上からFPSを少しずらしたり無制限に近づけるだけで、この数値が跳ね上がる。フレームがモニターの準備ができていないタイミングで届き、表示を待たされる「位相のズレ」が激しく発生している証拠にしたい（はなくそおおｋおれは）

これはフレームタイムの安定性。1フレームごとの生成時間のバラつき。
320FPS / 321FPS→箱が非常に薄く、全てのフレームが同じリズムで生成。 326FPS以上→箱が広がり、リズムが不規則になっていく。これが操作感の「ノイズ」や、滑らかさの欠如として体感される原因。

データの整合性は、 320FPS / 321FPSが60秒間で 18,598枚（320FPS）という、計算上の理論値通りのフレームが完璧に記録。10msを超えるスパイク（カクツキ）は 0回＝320FPS (0.032ms)モニターの更新（3.125ms間隔）に対し、常に同じタイミングでフレームを届けている

326FPS以上→FPS設定を上げているはずなのに、実際に記録された正常なフレーム数は 14,271枚（326FPS）、8,286枚（388FPS）と、大幅に減少。

326FPS (1.884ms)FPSを6上げるだけで、ズレが 58倍に跳ね上がる。フレームが届くタイミングが「更新の直前」だったり「更新の直後」だったりと、リフレッシュ周期の中で激しく前後（ドリフト）している・・・

ちなみFPS無制限は見るまでもなく無残な結果だった・・・

ただ上記はあくまで理想と理論であり、実践（コンペやランク等）に行くとエフェクトやオブジェクト、スキルなどが飛び交い「ネガティブフレームキャップ（制限値より実測が下がる現象）」がかかる、なのでそれを考慮して閾値をさらに数fps上乗せする考え方が生まれてくる。

制限設定値 = モニターHz（例:240） + 位相同期のための遊び（5） + リミッター補正（2〜3） = 247〜248 FPS

こんな感じで。

K式・FPS最適化アルゴリズム　1:x 閾値理論

基準式：実測値を 1（Hz）に固定するためのリミット設定

リミッター（ゲームエンジンや外部ツール）には必ず「計算の端数」や「遅延」が発生するため、実測値を Hz 以下に落とさないための補正係数（x） を導入します。

リミット値（x） = 絶対値（Hz） + 閾値（α + β）

（x）321〜326 に調整する

α（リミッター補正）: リミッターの精度誤差（通常 +1～+3 FPS）
β（ゲームエンジン余力）: 負荷変動時に Hz を下回らないための安全マージン（通常 +2～+5 FPS）

閾値の動的決定ルール

閾値は「多すぎず、少なすぎず」が絶対条件です。

下限の保証が必要 実測値が（例:この場合だと320Hzモニターに対してFPS320.00を0.001秒たりとも下回らないこと（FPS制限より上振れるのはいいとして下に落ちるのがナンセンスです）
- 下回った瞬間に「位相ロック」が外れ、スタッターが発生します。
上限の抑制（無駄な出力の排除）閾値を上げすぎないこと（例：320Hzモニターなのにゲーム内制限を388 FPSにする）。
- 超過 FPS が増えるほど、OS の管理コストが増大し、ジッターが 0.03ms から 3ms 以上へ爆増 します。

ゲーム内のFPS天井とモニターhz、スペックのバランスを見ないといけないし、モニター本体の実践値+プレイ中の実践値+調整が必要（某D氏の受け売り）

見ている方が Apex や VALORANT で設定を作る際のステップはこうなります。

モニターの物理 Hz を確認する（例：320Hz
仮の閾値（+1～+3）で計測する
- もし 321 制限で実測平均が 318 になるなら、「ネガティブフレームキャップ」が発生している。
閾値を微増させる
- 実測平均が 320 になるまで 1 FPS ずつ上げる（例：323 や 324）
できるなら「Jitter 0.05ms以下」を確認する
- この状態が 「1（実測）：x（リミット）」が物理周期と完璧に噛み合った瞬間 です。

この上記の話は、モニターHzまでゲーム内FPSのaverageが届いている前提となっています。

仮に320Hzモニターを使用していて、ゲーム内でMax（average）FPSが150なら、モニターHzに合わせた設定ではなく、現状出ているゲーム内FPSで合わせましょう（苦肉の策）

「全画面表示の最適化を無効」は自身の環境で考える。

バグがないなら、ウィンドウゲームの最適化もONにする。

FPSを無制限にするのは、脳まで筋肉馬鹿による解決だ。
整数倍でリズムを整え、ドライバ内の検問をノーパスで通り抜けることこそが、知性による最適化である。OSという中間管理職を解雇し、GPUとモニターを直結せよ（はなほじ）

とりあえずごちゃごちゃ言ったけど、一番伝えたいのは
ゲーム内FPS無制限は無価値だということです！

おまけ↓

ゲーム側で対策されていたり、別の機能があるんじゃないの？

確かに、ゲーム側やOS側にも「多少のズレ」を吸収し、低遅延を維持しようとする強力な機能は存在する。
それらはあくまで「タイミングを合わせるための補助」であり、ドライバ内の物理的な検問（Bit 11やメモリ整合性）を無効化するものではありません。

ゲーム側の対策「NVIDIA Reflex」と「MPO」の限界

【結論】Reflexは「遅延を減らす」が、ドライバの「検問」を免除する権利はない。

ゲーム側の最大の対策は NVIDIA Reflex 。
これは、CPUが描画命令を送るタイミングをGPUの空き状況に合わせて「待機（Sleep）」させることで、レンダリング待ちの行列（キュー）を排除します。しかし、Reflexがどれほど完璧にフレームを送り出しても、受け取り側のドライバが「このフレームは加工済みだ（Bit 11）」や「メモリ配置が不正だ」と判断すれば、そのフレームは強制的に遅延ルート（DWM合成）へ回される。うーん・・・あーめん。

ゲーム側の防衛策：NVIDIA Reflex（管制塔の役割）

「ゲーム側の対策」の筆頭がこれです。

通常、CPUはGPUの状況に関わらず全速力でフレームを作りますが、Reflexは「GPUが空く直前」までCPUを寝かせます。（ON+ブーストはステート管理）
これによって、ドライバ内の「バッファ準備完了（0xfb68）」フラグが、検問のタイミングに対して「新しすぎることも古すぎることもない」絶妙な状態で届くようになる。

OS/ハードウェア側の防衛策：MPO（階層の独立）

もう一つの強力な機能が上でも話をしたMPO (Multi-Plane Overlay) だね。

画面を「ゲーム階層」と「その他（ブラウザ等）階層」に分けます。
たとえブラウザ側で遅延が起きたり、タイミングがズレたりしても、ゲームのプレーンだけを「独立してフリップ（Independent Flip）」させることが可能。
ただし、上記で話した通り、GPUスケーリングが有効だと、この独立したプレーンのスケーラーではなく、手前の描画工程で加工が入るため、MPOによる救済ルート自体が閉ざされてしまう。

「FPS制限、または整数倍制限」は、これらの機能を「100%」活かすための下地である。

ゲーム側（Reflex）やOS側（MPO）がどれだけ頑張って「ズレ」を補正しようとしても、大元のリズムがバラバラ（無制限FPS）だと、ドライバ内部で行われる比較処理（iVar3 != iVar4）の失敗確率はゼロにならない。

「Reflexがあるから設定なんて適当でいいだろ？」

Reflexは『フレームをいつ作るか』を最適化するが、ドライバの nvlddmkm.sys は『届いたフレームをどう映すか』を物理的なビット（Bit 11等）で厳格に検閲してる。

ゲーム側でどれだけタイミングを合わせても、GPUスケーリングをONにした時点で、ドライバは加工が必要と判断して低遅延フラグを折ってしまう。 だからこそ、Reflexを活かすためにも『ディスプレイ側スケーリング』と『整数倍FPS』でドライバの検問をノーパスで通す必要があるんだYO」

ゲーム設定などあります↑

（2026年版）NVIDIAコントロールパネルのディスプレイスケーリングの最適解 FPSゲーマー設定

RefTComputer × 最適化K コラボPC

ゲームをFPS無制限でするなということ。

モニターの性能を殺しているのは、あなたの「設定」だ。ドライバ内の『特急券』を奪い取れ。

「FPSはただの数字に過ぎない。我々が求めるのは、OSを完全に無視した『生』のピクセル転送だ！！迫真」

なぜ「スペックは最高なのに、操作が重い」のか

「無制限FPS」という信仰が、皮肉にもカクつきを生んでいる

対策→240Hz環境なら、FPSリミッターで「240Hz」または「480FPS」に固定してください。

FPS「無制限」より良いのか？

低遅延フラグを確実に維持するための物理的な条件「特急ルートふぁああああああ」

ほんならなぜ「GPUスケーリング」という機能が存在するんかえ？

なぜ多くのゲーマーが「GPUスケーリング」を選択しているのか？

メモリ境界の整合性：4KBアライメントの維持

ハードウェアの制約、DMA転送の「高速道路」

物理的な読み取りルール

「解像度変更」や「モニター跨ぎ」が危険な理由

メモリの再確保と断片化

※マルチモニターの罠

MPO（マルチプレーン・オーバーレイ）の活用

MPO：GPU内部の「デジタル・マージ機」

だがしかしオーバーレイが破壊する。

Windows 11「ウィンドウゲームの最適化」が与える引数

「全画面表示の最適化を無効」にした際の物理的挙動の変化

ドライバ内のフラグ処理への影響

なぜ「無効化」が解決策として不完全なのか

① 「最適化されたフリップモデル」の喪失

② 切替時の「Bit 11（加工フラグ）」の再浮上

「無効」にチェックを入れても良い人

「有効（チェックなし）」のままにすべき人（推奨）

おすすめ設定説明↓

もしゲーム内解像度を変える（4:3等）ならスケーリングモードは「全画面表示です」ゲーム内解像度を変える方ように詳細↓

スケーリングを「ディスプレイ」に任せる

「スケーリングモードにより設定されたプログラムを上書きする」にチェック

「ウィンドウゲームの最適化」を必ずONにする

「4:3は罪ではない。スケーリングの『場所』が罪なのだ。」

ゲーム内FPS制限はモニターHzと同じか、上げるなら整数倍である

追記:（2025年12月27日）

閾値の動的決定ルール

ゲーム内のFPS天井とモニターhz、スペックのバランスを見ないといけないし、モニター本体の実践値+プレイ中の実践値+調整が必要（某D氏の受け売り）

見ている方が Apex や VALORANT で設定を作る際のステップはこうなります。

この上記の話は、モニターHzまでゲーム内FPSのaverageが届いている前提となっています。

「全画面表示の最適化を無効」は自身の環境で考える。

バグがないなら、ウィンドウゲームの最適化もONにする。

とりあえずごちゃごちゃ言ったけど、一番伝えたいのはゲーム内FPS無制限は無価値だということです！

おまけ↓

ゲーム側の対策「NVIDIA Reflex」と「MPO」の限界

【結論】Reflexは「遅延を減らす」が、ドライバの「検問」を免除する権利はない。

ゲーム側の防衛策：NVIDIA Reflex（管制塔の役割）

OS/ハードウェア側の防衛策：MPO（階層の独立）

「FPS制限、または整数倍制限」は、これらの機能を「100%」活かすための下地である。

「Reflexがあるから設定なんて適当でいいだろ？」

いいなと思ったら応援しよう！

（2026年版）NVIDIAコントロールパネルのディスプレイスケーリングの最適解　FPSゲーマー設定

Windows 11「ウィンドウゲームの最適化」が与える引数　

とりあえずごちゃごちゃ言ったけど、一番伝えたいのは
ゲーム内FPS無制限は無価値だということです！