Linuxにおける入力遅延の測定：X11対Wayland、VRR、DXVK

MARCO NETT MARCO NETT 私について 会社概要 フォルダ sublime-open Sketchで作成 blog Linuxにおける入力遅延の測定：X11対Wayland、VRR、DXVK 古いドアベルを、ベル自体から給電してHome Assistantに組み込む Quake Liveのフレームレートをアンキャップする「com_maxfps 250x」とは Linuxにおける入力遅延の測定：X11対Wayland、VRR、DXVK 2026-07-13 2年前、私はゲーミングPCをLinuxに切り替えました。人々は私に、FPS、フレームペーシング、入力遅延に関してWindowsよりもはるかに優れたパフォーマンスを発揮できると繰り返し言っていましたが、実際に試してみると、確かにずっと良くなったと感じました。インターネット上には、Linuxをゲーミング用に最適化するためのアドバイスが溢れています：Waylandは入力遅延が大きい、X11を使用する コンポジットを無効にする（「フリップモードを使用」） 低遅延のDXVKフォークを使用する ゲーミング専用カーネルスケジューラを使用する など。私は競技型FPSゲームをプレイするため、低遅延、一貫したフレームタイム、高FPSが私にとって重要です。Linuxには、これらのために調整できる無数の設定があります（マジック環境変数、gamescope、gamemode、さらに多くのDXVKフォークなど）。しかし、何かが実際にシステムの遅延を低下させたのか、それとも単なるまやかし、プラセボ効果、あるいは気づかないうちに実際には悪化していたのかを検証する信頼できる方法がなかったことが、常に私を悩ませていました。デバイス アイデアはシンプルです：ライトセンサーを備えたデバイスをモニターに固定し、USB経由でPCに接続してマウスのクリックをシミュレートします。クリック時に、クリックから画面上の明るさの変化をライトセンサーが検出するまでの時間を測定します。これにより、エンドツーエンドのシステム遅延を測定できます。© NVIDIAはこれを非常によくまとめた画像を持っています。現在、このようなオープンソースデバイスがいくつか利用可能ですが（m2p-latencyやOpen-Source-LDATなど）、このサイドプロジェクトを開始したときにはOSLTTしかなく、ハードウェアについて何も知らなかった私は、その回路図を勉強し、それにゆるやかに基づいた設計をすることに満足していました。しかし、このプロジェクトを今月完了した結果、他の2つのプロジェクトのアイデアもたくさん取り入れることになりました。パーフォレーションボード上のQT Py RP2040、トランスインピーダンスアンプ、BPW34フォトダイオード。エンクロージャーには「翼」が付いており、ゴムバンドでモニターに固定できます。長くなりましたが、マイクロコントローラー、はんだ付け、Arduinoファームウェア開発、積分時間、トランスインピーダンスアンプ、KiCad（少しだけ）、エンクロージャーデザインについて多くのことを学びました。私がたどり着いたのは次のとおりです：Adafruit QT Py RP2040が1000HzのポーリングレートでUSB HIDマウスとして動作し、クリックを発火させます。クリックを送信した瞬間に、フォトダイオードからのサンプリング（約24µsごと）を開始します。クリックごとに12,000サンプルのデータがシリアル経由でホストにストリーミングされ、CSVに記録されます。サンプリングデータに基づき、ホスト上のツールがクリックごとのベースラインを確立し、次にベースラインから特定の量だけ外れた最初のサンプルを見つけます。12kサンプルの収集にかかる時間は固定されているため、クリックの送信から画面上の明るさの変化を検出するまでの時間を計算できます。テストシナリオ 私は3つの異なることをテストしたかったのです。ディスプレイサーバー（X11対ネイティブWayland） 多くの人々はまだWaylandよりもX11を使用しています。なぜなら、Waylandは入力遅延がはるかに悪いと言われているからです。それを検索するだけで、Waylandが「調子がおかしい」と不満を言う人がたくさんいます。VRR（オン対オフ） 可変リフレッシュレート / G-Sync / FreeSync / 何と呼びたいか。これも非常に議論されています。DXVK低遅延フォーク（オン対オフ） 今後、dxvk-low-latencyまたはlow-latencyと呼びます。このフォークのメンテナーであるnetborgは、このフレームペーサーの開発に多大な労力を費やしており、最近公式のproton-cachyosパッケージに統合され、環境変数PROTON_DXVK_LOWLATENCY=1で有効化されます。このフォークの約束は、私がデスクトップLinuxを再び試すことを決めた要因の1つでした。ボーナス：dxvk-low-latency対デフォルトのDXVKアンキャップ フレームペーサーであるdxvk-low-latencyがもたらす最大の利点は、フレームタイムの変動を吸収し、レンダリングキューの蓄積を防ぐことです。私が使用したテスト方法（静的なゲーム内シーン、詳細は以下を参照）では、すべてのテストが純粋にCPUバウンドなシナリオを生成したため、観察すべきフレームタイムの変動はありませんでした。しかし、これは通常、ゲーム内またはゲーム外（例：他のプロセスがリソースを使用している）で発生するフレームタイムの変動が起こりうる実際のゲームセッションをほとんど反映していません。そのため、ペーサーの動作を示すために、アンキャップされたテストケースを2つ追加しました。ボーナス：ネイティブWayland対XWayland 私はすでにXWaylandが遅延を導入することを知っていたため、すべてのWaylandテストケースをネイティブWayland（PROTON_ENABLE_WAYLAND=1）で実行しました。しかし、比較のために、XWaylandのテストケースを2つ追加しました（VRRオフのみ）。テスト条件 ハードウェア AMD Ryzen 7 5800X3D NVIDIA GeForce RTX 4070 SUPER 2x8 GB DDR4 3200 MHz MSI MAG 272QP QD-OLED 2560×1440 / 500 Hz MSI B450 GAMING PRO CARBON AC テスト中はディスプレイは1つだけ接続されていました。ソフトウェア バージョン CachyOS-Kernel 7.1.3-2-cachyos NVIDIA driver 610.43.03-1 KDE Plasma 6.7.2-1.1 xorg-server 21.1.24-1.1 proton-cachyos-native 1:11.0.20260602-3 dxvk (proton-cachyos経由) 3.0 デフォルトのCachyOSカーネルスケジューラが使用されました。システム設定 システム設定で500 Hzのリフレッシュレート X11でのフリップモード：nvidia-settings経由で有効化 Waylandでのフリップモード：有効化を確認済み（有効化方法は以下参照） X11でのVRR：nvidia-settings経由で有効化（変更には再起動が必要） WaylandでのVRR：KDE設定メニュー経由で有効化（再起動不要） Waylandでのフリップモード（または「ダイレクトスキャンアウト」）対ブリットモード（コンポジット）：設定項目はありません。コンポジターが自分でコンポジットするかダイレクトスキャンアウトを使用するかを決定します。ゲームがフリップモードで実行されていることを確認するには：「KWin Debug Console」（GUIツール）を開き、「Effects」タブでshowcompositingを有効にします。次に、ゲームが完全にフォーカスされており、フルスクリーンモードで画面上の唯一のものになっていることを確認します。ゲームの端の周りに赤い境界線が表示されない場合、それはフリップモードです。dxvk 比較を公平にするために、シナリオに応じて最適化されたdxvk.confが使用されました： VRRが無効な場合、dxgi.maxFrameRate = 500（FPSを画面のリフレッシュレートにキャップ） VRRが有効でdxvk-low-latencyが無効な場合、dxgi.maxFrameRate = 497（FPSを画面リフレッシュレートよりわずかに低くキャップ） VRRが有効でdxvk-low-latencyが有効な場合、低遅延VRRフレームペーシングを利用するために以下が使用されました： dxgi.maxFrameRate = 480 dxvk.lowLatencyOffset = 70 dxvk.framePace = "low-latency-vrr-500" dxvk.lowLatencyAllowCpuFramesOverlap = False すべての場合において、d3d11.cachedDynamicResources = "c" が設定されました。ゲームと方法論 使用したゲームはDiaboticalで、Heroic経由でProtonを介して起動されたDirectX 11ゲームです。ゲーム設定 ネイティブ画面解像度 100% レンダースケール Vsyncオフ その他のビデオ設定は可能な限り低く設定 隠しコマンドがあり、UIを短時間非表示にできます。そのコマンドを左クリックにバインドし（/bind mouse_left testlatency）、大きな白いボックスを表示するHUDを設定することで、クリック時に大きな明るさの違いを生み出すことができました。Diaboticalでのデバイスの動作。方法論 不要なソフトウェアを閉じます。ゲームを起動します。ローカルマッチサーバーを起動します（毎回同じモードとマップ）。特定の場所に移動し、マウスを特定のランドマークに置きます。テストケースのイテレーションを実行します（100クリック、約2分間実行）。テストが完了したら、次のテストケースのイテレーションを開始します（合計3回）。ゲーム内条件：ボットなし、他のプレイヤーなし、移動なし、ラウンドリスタートなし。基本的に、これは無限に続く静的なシーンです。システム条件：テスト中、他の重要なプロセスはシステムで実行されていないはずです。測定デバイスは、すべてのテストで同じ位置に保たれました（ビデオを参照）。結果 click2photon latency: X11 / Wayland, VRR, low-latency Diabotical, 500 Hz QD-OLED, RTX 4070 SUPER, 300 clicks per case. すべてのキャップされたテストケースは、テスト中にフレームレートキャップを安定して維持し、ゲームは全体を通してCPUバウンドのままでした。データはクリーンに見えます：どのテストケースも極端な外れ値を生成せず、各ケースは