- 500Hzディスプレイでクリックから画面の輝度変化までを測定した結果、X11・VRR・dxvk-low-latencyをすべて適用しても、デフォルトのWaylandよりエンドツーエンド遅延の中央値が0.72ms低くなるにとどまった
- ネイティブWaylandはX11より0.14〜0.22ms遅い一方、XWaylandはネイティブWaylandに対して最大3.13msを追加し、はるかに大きな差を生んだ
- 可変リフレッシュレート(VRR) はすべての比較で遅延を0.26〜0.45ms減らし、p5〜p95の分布幅も2.6〜3.0msから2.1〜2.2msへと狭めた
- dxvk-low-latencyはフレーム制限時に0.10〜0.29ms、制限解除時に0.84msを削減したが、後者ではGPU使用率を100%ではなく95〜97%に保ちながら、FPSは715から670へ低下した
- 結果は安定したFPSとCPUボトルネックという最適条件および特定のハードウェア・ソフトウェア構成で得られたもので、実際のプレイではVRRによるジッター低減とフレームペーサーによるレンダーキュー抑制が、中央値以上の差を生む可能性がある
最適化アドバイスを自分で検証した理由
- Linuxゲーミングには、WaylandではなくX11を使う、コンポジットを無効化する、遅延最適化されたDXVKフォークを使う、ゲーム向けカーネルスケジューラを使う、gamescope・gamemode・環境変数を適用するなど、数多くの最適化アドバイスが存在する
- 競技系FPSでは低遅延、一貫したフレームタイム、高FPSが重要だが、設定変更が実際に改善なのか、プラセボや逆効果なのかを確認するのは難しい
- 測定装置のハードウェア、エンクロージャ、ファームウェア、解析コード、生データはclick2photon GitHubリポジトリで公開されている
クリックから画面変化までを測る装置
- モニターに装置を取り付け、USBでマウスクリックを発生させたあと、光センサーが画面変化を検知するまでの時間を測ることで、エンドツーエンドのシステム遅延を測定した
- 初期設計は当時利用可能だったOSLTTの回路図を参考にし、完成までの過程でm2p-latencyとOpen-Source-LDATのアイデアも統合した
- 製作にはマイクロコントローラ、はんだ付け、Arduinoファームウェア、積分時間、トランスインピーダンスアンプ、KiCadとエンクロージャ設計が必要だった
- Adafruit QT Py RP2040が1,000HzポーリングのUSB HIDマウスとして動作し、クリックを発生させる
- クリック送信直後から約24µsごとにフォトダイオードのサンプルを収集する
- クリックごとに12,000個のサンプルをシリアル経由でホストへ送り、CSVとして記録する
- ホストツールはクリックごとのベースラインを計算し、ベースラインから一定以上外れた最初のサンプルを探す
- 12,000サンプルの収集時間は固定されているため、クリック送信から画面の輝度変化までにかかった時間を計算できる
比較した画面・レンダリング構成
- X11とネイティブWaylandを比較し、Waylandのほうが体感的に遅いという評価を計測結果と照合した
- G-Sync・FreeSyncを含む可変リフレッシュレート(VRR) の有効・無効を比較した
- dxvk-low-latencyと標準DXVKの違いを測定した
- このフォークのフレームペーサーは公式
proton-cachyosパッケージに統合されており、PROTON_DXVK_LOWLATENCY=1で有効化する
- フレームペーサーがフレームタイム変動を吸収し、レンダーキューの蓄積を防ぐかを確認するため、FPS制限解除のケースを2つ追加した
- 静的なゲームシーンではフレームタイム変動がなく、テストもCPUボトルネック条件だったため、実際のゲームセッションを完全には反映していない
- 実際のセッションではゲーム内の状況や他プロセスのリソース使用に応じてフレームタイムが変化しうる
- Waylandのテストは基本的に
PROTON_ENABLE_WAYLAND=1を使ったネイティブWaylandで実行し、比較のためVRRを無効化したXWaylandのケースも2つ測定した
テストハードウェアとソフトウェア
- テスト中はディスプレイを1台だけ接続し、ハードウェア構成は以下のとおり
- AMD Ryzen 7 5800X3D
- NVIDIA GeForce RTX 4070 SUPER
- DDR4 3,200MHz 8GBモジュール 2枚
- MSI MAG 272QP QD-OLED X50、2560×1440、500Hz
- MSI B450 GAMING PRO CARBON AC
- ソフトウェアスタックは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 3.0を使用した- CachyOSのデフォルトカーネルスケジューラを維持した
ディスプレイとDXVK設定
- システムのリフレッシュレートは500Hzに設定した
- X11では
nvidia-settingsでフリップモードとVRRを有効化し、VRRの変更には再起動が必要だった
- WaylandではKDE設定でVRRを有効化し、再起動は不要だった
- Waylandのフリップモードまたはダイレクトスキャンアウトは、ユーザーが直接設定するのではなく、コンポジタがフレームごとに判断する
- KWin Debug ConsoleのEffectsタブで
showcompositingを有効化する
- ゲームだけをフルスクリーン表示し、完全にフォーカスされた状態で、端に赤い枠線がなければフリップモードと判定する
- 比較条件ごとに最適化した
dxvk.confを使用した
- VRR無効時は
dxgi.maxFrameRate = 500
- VRR有効かつdxvk-low-latency無効時は
dxgi.maxFrameRate = 497
- VRRとdxvk-low-latencyを同時に有効にする場合は、次の設定で500Hz向け低遅延VRRフレームペーシングを使用する
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
- すべての構成で
d3d11.cachedDynamicResources = "c"を適用した
ゲーム環境と反復測定手順
- テストゲームはHeroicとProtonで実行したDirectX 11ゲームDiaboticalである
- ネイティブ解像度と100%レンダー倍率を使い、Vsyncを無効化したうえで、他の映像設定は可能な限り低くした
- UIを一時的に隠す隠しコマンドを
/bind mouse_left testlatencyで左クリックに割り当て、大きな白いボックスを表示するHUDを構成して、クリック時の輝度差を大きくした
- 各テストは同一条件で繰り返した
- 不要なソフトウェアを閉じ、同じモードとマップのローカルサーバーを開始する
- 指定位置でマウスを特定の地形マーカーに合わせる
- 約2分間で100回クリックする工程を計3回繰り返す
- ボット、他プレイヤー、移動、ラウンド再開なしで静的なシーンを維持する
- 有意な他プロセスが動作しないようにし、測定装置の位置もすべてのテストで固定する
全構成の遅延レンジ
- フレーム制限を適用した全ケースが目標FPSを安定維持し、ゲームはテスト中ずっとCPUボトルネック状態だった
- 全ケースは大きな外れ値のないベル型分布を示し、p5からp95までの幅は約2〜3msだった
- 主要8構成の中央値は4.21〜4.93msで、全体差はわずか0.72msだった
- XWaylandは対応するネイティブWayland構成より中央値が最大3.13ms高く、それぞれ8.06msと4.93msを記録した
- FPS制限解除のケースでは、dxvk-low-latencyが標準DXVKより遅延を0.84ms削減した
X11とネイティブWaylandの小さな差
- X11はすべての構成で高速だったが、差は0.14〜0.22msと小さく、Waylandのほうが大幅に遅く感じるという評価を説明するには不十分だった
- low-latencyとVRR有効: X11は4.21ms、Waylandは4.38ms、差は+0.17ms
- low-latencyのみ有効: X11は4.64ms、Waylandは4.83ms、差は+0.19ms
- VRRのみ有効: X11は4.45ms、Waylandは4.67ms、差は+0.22ms
- 両方無効: X11は4.79ms、Waylandは4.93ms、差は+0.14ms
- 両ディスプレイサーバーの遅延分布の形も非常によく似ていた
VRRが遅延と分布に与えた効果
- VRRは比較項目の中でもっとも大きな影響を示し、すべての組み合わせで0.26〜0.45ms高速化した
- X11とlow-latency: 4.64msから4.21msへ0.43ms減少
- X11の標準DXVK: 4.79msから4.45msへ0.34ms減少
- Waylandとlow-latency: 4.83msから4.38msへ0.45ms減少
- Waylandの標準DXVK: 4.93msから4.67msへ0.26ms減少
- p95とp5の間の幅は、VRR使用時が2.1〜2.2ms、未使用時が2.6〜3.0msとなり、遅延分布も狭まった
- VRRではフレームが次のスキャンアウトスロットを待たず、準備でき次第すぐにスキャンアウトされるため、測定結果は動作原理と一致している
dxvk-low-latencyの効果とコスト
- FPS制限ありのケースでは、dxvk-low-latencyはすべての組み合わせで遅延を減らし、平均改善幅は0.20msで、X11とWaylandの平均差0.18msに近かった
- X11とVRR: 4.45msから4.21msへ0.24ms減少
- X11とVRR無効: 4.79msから4.64msへ0.15ms減少
- WaylandとVRR: 4.67msから4.38msへ0.29ms減少
- WaylandとVRR無効: 4.93msから4.83msへ0.10ms減少
- FPS制限解除条件では、ペーサーがレンダーキューの蓄積を防ぎ、不均一なフレームペーシングを緩和する効果がより大きく現れた
- GPUを完全飽和させず、GPUボトルネックに近い状態を維持する
- GPU使用率は標準DXVKで100%、dxvk-low-latencyで95〜97%だった
- 遅延は5.27msから4.43msへ0.84ms減少した
- FPSは715から670へ45FPS低下した
XWaylandが加えた大きな遅延
- Heroic Launcherの
Enable Wine-Wayland (Experimental)またはPROTON_ENABLE_WAYLAND=1を無効にすると、ゲームはXWayland経由で実行される
- XWaylandはネイティブWaylandより大きな遅延を追加した
- low-latency有効: 4.83msから5.95msへ1.12ms増加
- 標準DXVK: 4.93msから8.06msへ3.13ms増加
- 標準DXVKで追加された3.13msは、今回測定した他のすべての効果を合計したより大きく、一部の悪いフレームが平均を押し上げたのではなく、分布全体がシフトしていた
- XWaylandでdxvk-low-latencyを追加すると遅延が2.11ms減少し、全ケース中最大の改善となった
結果の適用範囲と実戦的な解釈
- 測定結果は、安定した制限FPS、CPUボトルネック、静的シーンという最適条件と、特定のハードウェア・ソフトウェアスタックに限定される
- 他環境では絶対的な遅延値は変わりうるが、各構成で発生した増減は概ね再現されうると考えられる
- より低いリフレッシュレートのディスプレイでは、VRRと低遅延ペーサーの改善幅がさらに大きくなる可能性がある
- X11はWaylandより0.14〜0.22ms高速だったが、KWinの最適化作業で差が縮まる可能性があり、他のWaylandコンポジタはすでにより良い可能性もある
- XWaylandを除き、X11・VRR・dxvk-low-latencyをすべて適用すると、デフォルトWayland構成より中央値が0.72ms低くなる
- 中央値の差は小さいが、VRRは遅延ジッターを減らし、dxvk-low-latencyは実ゲームで発生するフレームタイム低下やGPUボトルネック状況を緩和する
類似の入力遅延測定プロジェクト
1件のコメント
Hacker Newsのコメント
Linuxの良い点は、このような分析が可能なだけでなく、実際にエコシステムの改善につながること。結果はグラフィックソフトウェア開発者やディストリビューションのパッケージ管理者に届くが、Microsoftではこうした改善ルートはあまり期待できなさそう
長いあいだWindowsを使っていて最近Linuxに移ったが、KDE PlasmaはWindows 11より軽快で、問題が起きても自分で手を入れて改善できる点が良かった。しばらくLinuxデスクトップを使っていないなら、ゲーム向けに調整されたFedoraであるBazziteを勧めたい。ゲームをしなくても完成度の高いデスクトップをすばやく構築できる
昔は直感的な設定ファイル1つで思いどおりに変えられたが、今ではテーマ・アイコン・ライトモード・ダークモードに無数の抽象化レイヤーができたにもかかわらず、きちんと動く組み合わせを見つけにくい。ライトモードでは明るい灰色の上に灰色の文字が、ダークモードでは黒い背景に黒い文字が出てきて、AdwaitaのようなテーマではPDFビューアーでさえ文字色と背景色を正しく決められないことがある
どのテーマもスクロールバーを十分見やすくしておらず、アクティブウィンドウと非アクティブウィンドウを明確な色で区別もしない。Windows 3.11のほうがスクロールバー、アクティブウィンドウ表示、色のカスタマイズをうまくやっていて、過剰に設計される前のほうがむしろ良かった
Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...)とNvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...)も、同意したユーザーからこうしたデータを集めている。ただしどちらもオプトイン方式なので、熱心なゲーマーのデータはそれほど多くないかもしれない
漸進的な変化は多くても、何年も局所最適に閉じ込められがちだ。それでも内部の動作を比較的容易にのぞき込める点は良く、WindowsやmacOSが必ずクローズドソースでなければならない理由はよく分からない
数か月前にメインOS兼ゲーム環境をFedoraに変えたが、Windowsより全体的に軽快に感じられ、この測定でゲームの入力遅延に関する疑問が少し解けた
最近WaylandベースのHyprlandに移ったので、結果がどう変わるのか気になる。人気も高まっているし、もう一度試してほしい。Gamescopeも検討したが、Nvidiaではうまく動かないという話があり、ゲーム最適化カーネルというものも今回初めて知った。対戦格闘ゲームでは入力遅延が非常に重要なので、似たような最適化を試した話を聞いてみたい
ゲーム用途ではHyprlandが気に入ったし、X11のAwesomeWMを使っていた頃よりGamescope経由で可変リフレッシュレートやティアリングのような細かな設定がしやすかった。Lua設定もAwesomeWMを使っていた身にはなじみやすい
500Hzディスプレイを使った試験なので、低リフレッシュレート画面で現れる問題の多くが隠れていた可能性がある。XWaylandが3ms遅かったというのは、このリフレッシュレートでは1フレーム遅れていた可能性もある
120Hzや60Hzで試せば、微細な実行タイミング差と、丸ごと1フレーム遅れる大きな効果をより明確に区別できるはず
文末で Wayland が遅いと思われている理由を不思議がっているが、XWayland の結果こそがその理由なのかもしれない。Wayland 上で X11 ゲームを動かしたユーザーが、有意な遅延を感じた可能性がある。こうした実測がさまざまな分野でもっと増えるとよい
筆者はほかの交絡要因をかなり取り除いているが、Wayland が遅いと感じたユーザーは、最適化されていない環境から出発し、低遅延構成へ切り替える過程で関連設定も一緒に正したのかもしれない
事実上の標準的な参照実装である Xorg によって、どこでもおおむね似た挙動になる X11 とは異なり、Wayland 実装ごとの差は大きい。テストに使われた KDE Plasma より遅いコンポジターも、速いコンポジターもあり得る
Wayland 入力遅延という表現自体が、
HTTP アニメーションの滑らかさのように異なるレイヤーを混同した言い方だ。この文章が測定したのは Xorg と KWin、そして XWayland であり、ほかの X11・Wayland 実装は特性が異なる可能性がある。ただし XWayland の追加遅延は、単なるオーバーヘッドとして片付けるには疑わしいほど大きい
特に pgtk モードの Emacs は GNOME ではるかによく動くが、KWin ではスクロール時の CPU 使用率が高く、高解像度ではわずかな遅延が出ることもある
同じハードウェアで Windows と比較するとどうなるのかも非常に興味深い
Breaka Club では、改造した Overcooked 2! を使って子どもたちにコーディングを教えており、この問題を直接扱っている。
学校の機器にモッドをインストールしにくいため、モッド込みの OC2 を WebRTC でストリーミングし、子どもたちは iPad の Mobile Safari で画面上のゲームパッドを使ってプレイする。ゲームインスタンスは古い Nvidia ハードウェア上の Kubernetes/k3s の Docker コンテナで動作しており、インターネットと学校のネットワークを経由するため、NVEnc や DMABuf のゼロコピー転送などを使って全体の遅延を減らしている。
現在は XWayland の入力オーバーヘッドに悩まされているが、入力が仮想デバイスなので様子が異なるかもしれない。エンドツーエンド最適化は難しく、現時点の性能は受け入れ可能な水準だ。OC2 コーディング動画: https://www.youtube.com/watch?v=ITWSL5lTLig
OC2 のライセンスは限られた本数だけ購入してあり、Pod の起動時に1本が割り当てられる。すべて使用中なら、子どもたちは別のゲームをプレイする
X11 でコンポジットレンダリングを使う場合、フルスクリーンウィンドウがコンポジターに 非リダイレクトのヒントを送ると、ほかの要素が画面に描画されていない間はコンポジットを停止し、アプリケーションのスワップチェーンを画面へ直接渡せる。実質的に最適な方式なので、これ以上改善するのは難しい。
別のウィンドウが上に現れたり、コンポジターが直接転送できないと判断したりすると、アプリケーションウィンドウとほかの要素を一時バッファに合成する中間段階が発生する。ウィンドウが画面の高さより1ピクセル小さく生成されるなどして非リダイレクトが壊れたり、XWayland を使ったりすると遅延が増える可能性があり、これは根本的な制約なので、ほかの OS のコンポジターでも似た問題が起こる。
Wayland は、GPU ハードウェアが複数レイヤーを直接合成する ディスプレイプレーン（display planes） も探ってきた。これを使えば、ゲームは最大フレームレートでレンダリングしつつ、上に重なるウィンドウは別プレーンに描画して副作用なく合成できるが、実際の製品環境で使われているのかは分からない
コンソールは固定された出力フレームレートと動的解像度を志向する一方、PCは解像度を固定し、フレームレートとフレーム時間間隔を動的にする傾向がある。これが遅延とどう関係するのか気になる。
特に競技ゲームでは、ディスプレイのリフレッシュレートを大きく超えるフレームレートを目標にするが、実際に利点があるのか思い込みなのか確信が持てない
要点は、より多くのフレームを見ることではなく、より新しい情報を見ることにある。画面更新の直前に終わるようレンダリング開始を遅らせることもできるが、少しでもタイミングを外すと激しいカクつきが生じ、GPUの実行時間やCPUの作業投入時間は決定論的ではない
理想的には不要なフレームを作らず、画面更新の直前にレンダリングを開始すればよいが、締め切り時刻を逃すと非常に不快なカクつきが発生する
新しいフレームは画面走査の途中で割り込めるためティアリングが発生するが、境界線より下にはより新しいピクセルが表示される。したがって、モニターの1フレームに複数のレンダリングフレームが混在し得て、高リフレッシュレートの可変リフレッシュレートディスプレイほどではないにせよ、遅延を減らしてくれる。動きの重要性が低いゲームでは、VSyncでフレームをリフレッシュレートに合わせてティアリングをなくすことがよくある
一部のゲームは一定のフレームレートのために解像度をリアルタイムで調整する。PCでは本来の想定目標よりはるかに低い性能でもゲームを動かせたし、低フレームレートは文化的により許容されており、嫌ならアップグレードもできた。コンソールにはアップグレードの道がなく、単一構成に最適化しなければならないため、性能が落ちすぎる前に解像度を下げる方式のほうが適していた
ゲームが入力イベントをより多く受け取るという意味ではないが、入力をより早く処理して反映できる。思い込みではないが逓減効果は大きく、フレームキュー・VSync・可変リフレッシュレート・CPUまたはGPUボトルネック・入力およびシミュレーションのループ構造によって効果は変わる
筆者は最初から思い込みを排除しようとしているが、遅延は結局のところ感覚や使い心地で評価するものではないかとも思う。個人的にはどう感じるかが最終試験であり、実際の遅延を診断して直すのにデータが有用だとしても、大半のUI/UXでは好みと体感に頼っても構わないと考える。
星評価のような、より非技術的な評価を併用すれば、試験やデータ収集が方法論に過度に埋没するのを防ぐこともできる。精密に構成した試験では、特定環境の日常使用で頻繁に現れる性能低下条件が抜け落ちる可能性がある