見出し画像

8000Hzのマウスを低DPIで使うのは損をしているのか

ytty

ポーリングレート計測ツールを起動して、こんな数字を見たことはないでしょうか。設定は8000Hz、しかし計測値は1000Hz前後。「騙されたのか？」と思う前に、一歩立ち止まってほしいのです。

この「計測できない」という現象は、マウスの問題でも計測ツールの問題でもありません。Windowsのカーネルが持つdelta filteringという仕様——移動量ゼロのレポートをシステムコール以前に棄却する機構——が原因です。つまり計測ツールが見ているのは「フィルタを通過したもの」だけで、8000Hz動作の全体像ではありません。

ただし「計測できないなら意味がない」という結論も正確ではありません。8000Hzの恩恵が発現する経路は複数あり、delta filterの上流と下流に分かれています。そしてその恩恵が「コストに見合うか」は、あなたのDPI設定、CPUアーキテクチャ、そしてゲームエンジンの実装によって変わります。

数字よりも機序を理解することで、自分の環境における正しい判断ができるようになります。

なぜ低DPIだと8000Hzとして計測されないのか

Windowsのマウス入力は、HIDデバイスから届いたレポートが以下のパイプラインを通ります。

マウス（USB）→ mouhid.sys → mouclass.sys → ゲーム（Raw Input）

このパイプラインにdelta filteringという処理が存在します。mouhid.sysがHIDデバイスレポートをパースしてMOUSE_INPUT_DATAに変換し、mouclass.sysに渡す段階で、移動量がゼロのレポートは後続処理に渡されません。この棄却処理の正確な実装層はMicrosoftの非公開実装であり、「mouclass.sys内」という表現は慣例的な説明として広く使われていますが、公式ドキュメントによる一次確認には限界があります。ただし「Raw Inputより上流でdelta=0レポートが間引かれる」という現象自体は、計測ツールの出力で再現可能な事実です。

低DPIの場合、物理的な移動量がカウントに変換されにくいです。

物理移動 0.1mm × 400DPI = 0.04カウント → 切り捨てで0 → 後続処理へ渡されない

8000Hzでレポートを送り続けていても、その大半がdelta=0として棄却されてしまいます。ブラウザのJSイベントやRaw Inputはこのフィルタより後段のデータしか見えないため、計測ツール上では8000Hzとして検出されません。

高DPIにすると、同じ物理移動でもカウントに変換される頻度が上がるので「意味のある情報」の割合が増え、計測ツール上でも8000Hzとして見えるようになります。

では低DPIで8000Hzを使うのは無意味なのか

そうではありません。8000Hzの効果が出る場所は2つあり、どちらもdelta filterより上流に存在します。

① 動き始めのタイミング精度

マウスセンサーのスキャンレートとUSBポーリングレートは、独立したクロックドメインで動作します。センサーが検知した変位はまずセンサー内部のアキュムレータに蓄積され、次のUSBポーリングスロットのタイミングで転送されます。ポーリングレートが低いほど「1パケットに複数フレーム分の移動量が混入する」確率が高くなり、入力の時間分解能が落ちます。8000Hz化の主な設計意図は、アキュムレータの蓄積時間を0.125msに短縮することにあります。センサーの物理サンプリング精度の向上とは、厳密には別の問題です。

この構造により、delta=0フィルタで間引かれても、「センサーが変位を検知してからPCに転送されるまでの最大待ち時間が1ms→0.125msに縮まる」というUSBポールのタイミング精度改善は、低DPI環境でも物理的に有効です。

② 届いたレポートの間隔精度（ジッター）

delta≠0のレポートが届く間隔の均一性も、ポーリングレートに依存します。ただしこの恩恵を受けられるかどうかは、ゲームエンジンの入力処理実装に依存します。Windows Raw InputはAPIレベルでタイムスタンプを持っていますが、そのタイムスタンプを補間に利用するかどうかはタイトル側の実装次第です。DX11以前のゲームやフレームレートと入力処理を同期しているエンジンでは、ポーリング間隔の精度向上が操作感に直接影響しない場合があります。Overwatch 2（DX12）など、独立した入力処理スレッドを持つタイトルでは、この差が出やすいとされていますが、タイトル固有のベンチマークによる実証が判断の前提です。

低DPI × 8000Hzは「コストだけ払って恩恵が減る」状態

400〜800DPIの低DPI環境では、1m/s未満の常用速度域においてカウントが0.125ms周期で発生しない状態が続きます。delta=0レポートが大量発生して後続処理へ渡されない一方、CPUはUSB ISRを8000回/秒処理し続けます。

8000Hz動作では、xhci.sysなどUSBホストコントローラドライバのISRとDPCが8000回/秒のペースで処理されます。DPCはIRQL（割り込み要求レベル）DISPATCH_LEVELで動作するため、通常スレッドのIRQLであるPASSIVE_LEVELより高い優先度を持ちます。これはコンテキストスイッチの阻害ではなく、実行中のゲームスレッドがCPUコアから強制退避させられ、DPCルーチンが完了するまでその実行が停止されるという挙動です。8000Hz環境でのフレームタイムスパイクの実態は「コンテキストスイッチのオーバーヘッド」ではなく、「ゲームスレッドの実行時間がUSB ISR/DPCによって0.125msピッチで細切れに削り取られること」です。

ゲームに届く情報密度は1000Hzと大差ない可能性がある一方で、このDPCコストは8000Hz分フルにかかります。8000Hzの恩恵を最大化したいなら高DPIとセットで運用するのが筋です。ただし高DPIにした分、ゲーム内感度を下げて実効感度を合わせる必要があります。

「高DPI + 8000Hzが最適」は環境によって変わる

高DPI + 8000Hzが理論上の性能上限であることは事実ですが、「だから全員そうすべき」は別の話です。以下の条件によって最適解は変わります。

CPUアーキテクチャと割り込み処理の相性

Intel 12世代以降のP/E-coreハイブリッド構成では、Windowsスケジューラ（Thread Director）がDPCをE-coreに配置することがあります。E-coreはP-coreと比較してISRのスループットが低く、8000Hzの高頻度割り込みがフレームタイムの安定性に悪影響を与えるケースが報告されています。IRQアフィニティをP-coreに明示的に設定していない構成では、この問題が顕在化する可能性があります。

AMDの3D V-Cacheアーキテクチャ（例：Ryzen 7 9800X3D）では、キャッシュ集約的なゲームスレッドと割り込み処理のコア競合が独特の形で現れることがあります。現時点では9800X3D + 8000Hz環境での体系的なベンチマークは限られており、「問題ない」とも「問題がある」とも断言できません。

ゲームAPIと入力処理の実装差

DX11ベースのゲームと、独立した入力スレッドを持つDX12/Vulkanゲームでは、ポーリングレートの恩恵の出方が異なります。自分がプレイするタイトルの実装を確認することが先決です。

センサーモデルによるDPI精度の差

高DPIでジッターが増加するセンサーは旧世代品に多く見られました。PAW3950等の現行ハイエンドセンサーでは、常用DPI帯（800〜3200）ではジッターの実用的な差は無視できるレベルとされています。ただしセンサーの実測データはメーカー公称値ではなく、Sensor.fyi等の第三者計測データを参照することを推奨します。

「そこまで精密にマウスを動かせない」問題

これは正しい認識で、人間側がボトルネックになります。

ただし8000Hzの恩恵は「意図した動き」より「意図しない動き」のほうで出やすいです。手ブレや微振動をセンサーが高密度で拾い続けるため、ゲームエンジンの補間処理に渡るデータの規則性が上がります。ただしこれは裏返すと、意図しない微小な振動もそのままゲーム側に送り続けるということでもあります。エイムが細かくブレるように感じるかどうかは好みが分かれるところで、「データ密度の向上が操作感にとって常にプラスとは限らない」という点は念頭に置いておく必要があります。

それを踏まえても、240Hz環境で詰めるなら優先順位は以下の順です。

モニター > フレームタイム安定 > IRQ設定 > 8000Hz

CPU負荷が増えてフレームタイムが悪化するなら、8000Hzにしない方が速いです。

実証のための評価手順

設定変更の効果を「体感」ではなく数値で判断するための手順です。

前提条件の固定

  • 計測中はバックグラウンドアプリ（ブラウザ、Discord等）を終了

  • GPUドライバのオーバーレイをすべてOFF（MSI Afterburner等）

  • Windows電源プランを「高パフォーマンス」に設定

  • ゲーム内グラフィック設定・解像度を計測間で変更しない

手順 1：ベースライン取得（1000Hz）

  1. マウスのポーリングレートを1000Hzに設定

  2. CapFrameXを起動し、「Capture」タブで対象ゲームの実行ファイルを指定

  3. 負荷が一定のシーン（特定マップ・コース等）で120秒以上キャプチャ

  4. 「Analysis」タブで以下を記録：

    • P1 / P0.1 frametimeのミリ秒値（平均FPSではなくパーセンタイル低値の悪化が重要）

    • フレームタイムグラフの時系列スパイクの有無と頻度

手順 2：8000Hz化後の取得

  1. ポーリングレートを8000Hzに変更し、PCを再起動

  2. 同一シーン・同一時間でキャプチャ（手順1と条件を完全に一致させる）

  3. 同一の数値を記録

手順 3：比較と判定

P1 frametimeは1000Hz比で1ms以内の悪化であれば許容範囲です。注視すべきはフレームタイムスパイクの頻度と振幅で、増加が見られる場合はDPC干渉が疑われます。平均FPSは参考値に留め、これ単独で採否を判断しないでください。レイテンシとは別の指標です。

フレームタイムの悪化が確認された場合は、IRQアフィニティの調整を試みてください。GoInterruptPolicy等でUSB xHCIコントローラのIRQアフィニティを設定する前に、MSI（Message Signaled Interrupts）モードで動作していることを確認してください。レガシーINTx割り込みが有効なままではアフィニティ設定が無視されます。確認はデバイスマネージャーで対象xHCIコントローラのプロパティ→「リソース」タブのIRQタイプ、またはMSIInfo等のツールで行います。MSIモードが確認できた上で、xHCIの割り込み先をゲームスレッドが使用するコアとは異なるコアにバインドし、再計測してください。それでも悪化が残る場合は、8000Hzを採用しない判断が合理的です。

まとめ：自分の環境での判断フロー

Q1. 使用DPIは？
    ├─ 400〜800DPI → delta≠0レポートの密度は低い
    │   USBポールのタイミング精度改善（最大待ち時間1ms→0.125ms）は有効だが
    │   情報密度の恩恵は限定的。CPU負荷はフルにかかるため計測必須。
    └─ 1600DPI以上 → delta≠0レポートの密度が上がり恩恵が最大化されやすい

Q2. CapFrameXでフレームタイム悪化は確認されたか？
    ├─ 悪化なし → 8000Hzを採用してよい
    ├─ 悪化あり・MSI確認 + IRQ調整後に改善 → IRQ設定とセットで採用
    └─ 悪化あり・調整後も改善なし → 採用しない

Q3. プレイタイトルの入力処理実装は？
    ├─ DX12/Vulkan + 独立入力スレッド（例：OW2）→ 恩恵が出やすい
    └─ DX11 or フレーム同期入力 → ポーリング間隔精度の恩恵がほぼ出ない可能性

8000Hzは「計測できなければ無意味」でも「高DPIにすれば全員得をする」でもない。

delta filteringはWindowsカーネルの設計上の事実であり、低DPI環境でのdelta=0棄却も事実です。しかしUSBポーリングの物理的な転送精度（0.125msの時間分解能）は、それとは独立して存在しています。あなたのDPI・CPU・タイトルの組み合わせが「その精度を活かせる構成か」を、フレームタイムの実測で確認する——これが唯一の根拠ある判断基準です。

設定変更の前後で必ず計測し、数値が悪化しないことを確認してから採用する。この順序だけは守ってください。


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