Linuxの入力遅延を徹底検証：X11 vs Wayland、VRR、そしてDXVKの実力を解剖

Linux環境における入力遅延の正体を明らかにします。X11とWaylandの比較をはじめ、VRR（可変リフレッシュレート）の有効性、そしてDXVK使用時のパフォーマンス影響まで、最新の検証結果を詳しく解説します。

筆者が最後に、なぜみんなWaylandをこんなに遅いと思っているのか不思議がっているけど、それってXWaylandの結果のせいじゃないかな？みんなWayland上でX11のゲームを動かして、その顕著なラグに気づいただけだと思うよ。まあ、ただの勘だけど。すごく良い記事だね。こういう測定を、いろんなことに対してもっと頻繁にやってくれる人が増えると嬉しいな。

素晴らしい記事だ。数ヶ月前にメインPC（兼ゲーム機）をFedoraに乗り換えたんだ。Windowsに比べて全部サクサク動いている気がするけど、気のせいかどうかわからなくて、ゲーミングの入力レイテンシについてずっと気になっていたんだ。これのおかげで疑問がいくつか解決したよ。最近hyprlandに変えたばかりだから、その結果がどうなるかすごく興味がある。hyprlandはWaylandを使ってるし、最近人気が出てきてるから、筆者がまた調べてくれるといいな。gamescopeを使ってこの辺の懸念を解消しようかとも思ったけど、自分はNVIDIAを使っているから、うまく動かないっていう話もあってね。それと、筆者の記事でゲーミング最適化カーネルの存在を知ったよ。そんなのがあるなんて知らなかった。格闘ゲームをガチでやってるから入力レイテンシは死活問題なんだ。同じような道を歩んできた人がいたらぜひ話を聞きたい。

「Waylandの入力レイテンシ」なんてものは存在しないよ。それは「HTTPのアニメーションのスムーズさ」みたいな、ただの言葉の羅列だ。この記事が測定しているのはXorg vs KWin（あとXWayland）であって、X11やWaylandの他の実装ならまた別の特徴が出るはず。それにしても、XWaylandで発生する追加のレイテンシはどこから来てるんだろうね。単なるオーバーヘッドとして片付けるには、怪しいくらい高すぎる気がするんだ。

Linuxの素晴らしいところは、こういう分析が可能であるだけでなく、それが意味を持つことだよね。この結果はグラフィックスソフトウェアの作者やディストリビューションのパッケージャーにフィードバックされて、エコシステム全体が改善されていく。Microsoftで同じような改善が期待できるなんて、これっぽっちも思えない。自分もWindowsデスクトップを何年も使った末に最近Linuxに乗り換えたんだけど、一番の理由はKDE PlasmaのほうがWindows 11よりサクサク動く感じがしたからかな。それに、もし何かがうまく動かなくても自分でいじって改善できるっていう感覚もいい。すごく快適だよ。もし最近Linuxデスクトップを触っていないなら、Bazziteを試してみてほしい。ゲーミング向けに調整されたFedoraなんだけど、ゲームをしない人にとっても、あっという間に超便利なLinux環境が手に入る良い手段だよ。

コンソール機とPCでは、ゲームの構成が少し違うね。コンソールはフレームレートを固定して、解像度を動的に変えることが多い。対照的にPCは解像度を固定して、フレームレートやフレームタイムの安定性を動的に調整する。このあたりってレイテンシの議論にどう関わってくるんだろう？特に競技性の高いゲームだと、ディスプレイのリフレッシュレートを遥かに超えるフレームレートを目指す人をよく見るけど、あれって本当に恩恵があるのか、それともプラセボ効果を追いかけているだけなのか確信が持てないんだよね。自分が時代遅れなのか、それともDRAMのスティックにLEDを光らせてる子供たちが間違っているのか。

これ500Hzのディスプレイを使っているから、低速なディスプレイだと出てくる問題の多くが隠れちゃってるね。XWaylandの結果が3ms遅いってのは、これだけのリフレッシュレートだと1フレーム遅れているだけじゃないかと思ってしまう。120Hzや60Hzでもテストしてみると面白いかもしれない。そうすれば、非常に小さなタイミングの差と、1フレーム丸ごと遅れることによる大きな影響を切り分けられるようになるからね。

Waylandにはあまり詳しくないけど、X11のコンポジットレンダリングの仕組みについて。フルスクリーンのウィンドウがある場合、コンポジターに「unredirect（リダイレクト解除）」ヒントを出せるんだ。そうすれば、画面を描画しているのが自分だけならコンポジットを止めて、アプリの入れ替えチェーン（swapchain）を直接画面に渡してくれる。これはほぼ理想的な状態で、これ以上を求めるのは難しい。でも、上に余計なウィンドウが出たり、コンポジットができないと判断されるような何かが起きると、アプリのウィンドウを他とまとめてテンポラリバッファに描き出すという中間のステップが発生してしまう。たまに何らかの理由でunredirectが壊れたり（画面より1px小さいウィンドウを作ってしまうような謎のケースを覚えてる）、XWaylandを使ったりすると、ひどいレイテンシが発生するんだ。これは根本的な制約だから、他のOSのコンポジターも同じような仕組みだろうし、同じ問題に直面するはずだよ。あと、Waylandは「ディスプレイプレーン」の露出を始めたはず。これはGPUのハードウェア機能で、複数のレイヤーを同時にコンポジットできるものだ。これを使えばゲームがフルFPSで描画されていても、上のウィンドウは別のプレーンに描画して合成できるから、悪影響はないはず。ただ、実際に現場で使われているのかはわからないな。

Breaka Clubでこの問題を少し扱っているよ。うちは改造した『Overcooked 2!』を使って子供たちにプログラミングを教えているんだ。modをプリインストールした状態でWebRTC経由で配信してるから、子供や学校側がmodをインストールする手間を省ける。学校の備品PCで動かすことを考えるとこれは特に重要なんだ。ゲームのインストールだけでも大変なのにmodまでとなるとね。さらに、iPadのMobile Safariから画面上のバーチャルゲームパッドで遊べるっていう利点もある。ゲームインスタンスはDockerコンテナで動かしていて、Kubernetes/k3s環境、しかもかなり古いnVidiaハードウェア上で動かしてる。インターネットを経由して学校のネットワークに繋ぐから、レイテンシの最適化には必死だよ。NVIDIA NVEncとDMABuf（ゼロコピー）なんかも使ってる。残念ながら今はXWaylandを使っているから、記録されているような入力オーバーヘッドは発生しているね。ただ、うちは入力が仮想デバイスだからオーバーヘッドの性質は少し違うかもしれない。エンドツーエンドでこれを最適化するのは本当に骨が折れる。現状のパフォーマンスは「許容範囲」かな。

10ms以下のレイテンシについて議論している人たちには、これらを見ることをおすすめするよ。（YouTubeリンク等への参照）

筆者が最初からプラセボを排除して効率化しようとしているのは興味深いね。でも、そもそもレイテンシっていうのは「プラセボ」や「雰囲気」、「感覚」そのものじゃないか？最終的なテストは、個人的に触ってみてどう感じるかだろう。もちろん、こうしたデータを集めるのは実際のレイテンシを診断・修正する上で役立つし、価値があるのはわかるよ。ただ、UI/UXのほとんどについては、レイテンシを含めて感覚や経験に頼ってもいいんじゃないかな。あともう一点。比較の結果を（5段階評価のような）あまり技術的ではない形でまとめれば、テスト中に「方法論に凝りすぎて現実とかけ離れる」のを防げるはず。この手法の欠点は、ある構成の日常的な利用でよくある退化的なケースが、セットアップされた正確なテストの中では発生しにくいことだね。