世界を動かす技術を、日本語で。

Linuxにおける入力遅延の測定:X11とWayland、VRR、DXVKの比較

2026年7月15日原文(marco-nett.de)

概要

  • Linuxでの ゲーミング最適化 を検証するため、独自に システム遅延測定デバイス を開発。
  • WaylandとX11、VRR、dxvk-low-latency など各種設定の影響を詳細に比較。
  • XWayland は大幅な遅延増加、 VRRとdxvk-low-latency は遅延短縮。
  • X11はWaylandより 僅かに低遅延 だが、その差は小さい。
  • 検証結果は 特定の環境依存 だが、傾向は他の構成にも適用可能。

Linuxゲーミング遅延徹底検証:X11・Wayland・VRR・dxvk-low-latency比較

  • 2年前からLinuxでFPSゲーム をプレイ。低遅延・高FPS・安定したフレームタイム重視。

  • 最適化手法 が多岐にわたり、実際の効果検証が困難だったため 自作デバイス を開発。

  • デバイス構成

    • Adafruit QT Py RP2040による USB HIDマウス 機能(1000Hzポーリング)。
    • クリック時に フォトダイオード で画面の明るさ変化を検出、 クリックから反応までの時間 を計測。
    • 1クリックごとに 約12,000サンプル 取得、ホストPCへシリアル送信しCSVで記録。
    • サンプルから ベースライン算出→変化点検出→遅延計算
  • テスト対象と目的

    • ディスプレイサーバー :X11 vs ネイティブWayland
    • VRR(可変リフレッシュレート) :オン/オフ
    • dxvk-low-latency fork :有効/無効
    • ボーナス :dxvk uncapped、XWayland比較
  • テスト環境

    • ハードウェア
      • AMD Ryzen 7 5800X3D、NVIDIA GeForce RTX 4070 SUPER、500Hz QD-OLEDディスプレイ
    • ソフトウェア
      • CachyOS、NVIDIAドライバ、KDE Plasma、xorg-server、proton-cachyos、dxvk
    • 設定
      • 500Hzリフレッシュレート、Flip mode有効、VRR切替、dxvk.conf最適化
      • ゲーム:Diabotical(DirectX 11、Proton経由)、静的シーンで条件統一
  • 計測方法

    • 各ケースで 100クリック×3セット、合計300回データ取得
    • 不要なプロセス停止・同一条件維持 で外乱を排除

詳細結果と考察

  • X11 vs Wayland

    • X11が 常に0.14~0.22ms低遅延 だが、体感差を説明するほど大きくない
    • 分布もほぼ同一、XWaylandのみ大幅遅延
  • VRR(可変リフレッシュレート)

    • 全ケースで0.26~0.45msの遅延短縮
    • p95-p5幅も縮小 し、フレームタイミング安定化
  • dxvk-low-latency fork

    • 全てのテストで0.10~0.29ms短縮
    • uncapped時は 0.84ms短縮、特に フレームパシング安定化 に効果大
    • GPU使用率95-97% でレンダーキュー蓄積抑制、FPSはやや低下
  • XWayland

    • ネイティブWayland比で3.13ms増加
    • 全効果の中で最も悪影響、分布全体が右へシフト
  • まとめ

    • XWayland回避が最重要 (遅延増大)
    • WaylandはX11に僅差 (最適化進めば差は縮小見込み)
    • VRRが最も効果大 (遅延短縮・分布安定化)
    • dxvk-low-latencyは全体的に有効 (特にuncapped時やXWayland時)

実用的なアドバイス

  • 競技性重視ならX11が現状ベスト だが、Waylandも十分実用範囲
  • VRRとdxvk-low-latencyは必ず有効化推奨
  • XWaylandは極力避ける
  • 自分の環境で実測することが最重要。今回の手法は他の構成でも応用可能

Linuxゲーミングの遅延最適化 には多くの選択肢が存在するが、 科学的な検証と実測 が最も信頼できるアプローチである。

Hackerたちの意見

彼は最後に、なぜみんながWaylandは遅いと思っているのか混乱しているみたいだけど、彼のXWaylandの結果が原因じゃないかな?多分、みんなWaylandでX11ゲームをやってて、かなりの遅延に気づいたんだと思う。あくまで推測だけどね。すごくいい記事だと思う。こういう実測をもっと頻繁にやってほしいな、いろんなことについて。

1つのWaylandコンポジタだけをテストして、すべてのWaylandコンポジタのパフォーマンスについて語るのは無理だよ。かなり違うからね、特に入力デバイスを扱うために必要なWaylandの拡張に関しては(参考:https://wayland.app/protocols/)。XorgがX11の標準的な強力なリファレンス実装で、どこでも同じように動くのとは違うんだ。多分、他のWaylandコンポジタは彼がテストしたKDE Plasma Waylandより遅いんだろうね。で、みんなその体験を報告してる。中にはPlasmaより速いWaylandコンポジタもあるかもしれないけど、確かなのは、すべてのWaylandは他のWaylandとは全然違うってことだよ。

1990年代中頃からLinuxを使ってるから、これには全然初心者じゃないよ。X11とWaylandの違いなんて、使ってても全くわからないし、議論には興味がないんだ。これってVim対EmacsやGnome対KDEの話と同じだよね。今は、みんなが文句言ってるのを見ると、ページを閉じちゃう。全部バカらしくて無意味だと思う。

WaylandはXorgに比べて常に1フレーム遅れているんじゃなかったっけ?それを避けるために。もしそうなら、非常に高いリフレッシュレートがその影響を最小限に抑えることになるね。

そして、顕著な遅延を感じたのは、XWaylandだけがその結果を示した。違いは数ミリ秒だけだった。これは、遅延の違いを感じている人がいるか疑問に思う範囲だね。10-20msなら信じられるけど、数ミリ秒では無理だよ。この投稿の著者は、他の混乱する設定をうまく排除していた。Waylandが遅いと文句を言っていた人たちは、最適化されていない状況から始めていて、低遅延のバリアントに切り替える際に正しい設定をすべて整えた可能性があるね。

すごくいい記事だね。数ヶ月前に日常使いのPCとゲーミング rig をFedoraに切り替えたんだけど、Windowsと比べて全体的にキビキビしてる気がする。でもそれが本当にそうなのか、ただの気のせいかはわからないし、ゲームの入力遅延についてもすごく興味があるんだ。これでいくつかの疑問が解決したよ。最近Hyprlandに切り替えたんだけど、これが結果にどう影響するのかすごく興味ある。HyprlandはWaylandを使ってるから、著者がHyprlandの人気が上がってる今、再度取り上げてくれるといいな。ゲームスコープを使って、これらの懸念に対処できるかもと思ったけど、NVIDIAを使ってるから、うまくいかないって話もあるんだ。今、著者のせいでゲーム最適化カーネルについて考えさせられてる。そんなのがあるなんて知らなかったよ。競技用の格闘ゲームをやってるから、入力遅延は大きな問題なんだ。これに関して経験がある人の話も聞きたいな。

OpenSuseに移行して、同じ体験・意見を持ってるよ。Waylandで唯一気になるのはゲームストリーミングかな。Sunshine/Moonlightは動くけど、入力遅延が目立つし、ゲームにアーティファクトが出るんだ。X11とWaylandを行ったり来たりしてるけど、X11の方がゲームストリーミングには向いてるから。でも、いずれWaylandに完全に移行すると思うよ。

僕の知る限り、カーネルを切り替えることで微妙にFPSが上がるよ。少しは助けになる。ただ、その努力が自分にとって価値があるかどうかの問題だね。主な変更点はスケジューラーで、プロセスにCPU時間を均等に分配するのではなく、バースト処理を優先するようになってる。今のところ、ゲーム用にはHyprlandが気に入ってる。VRRやティアリング、他の細かい調整がGamescopeを通じてかなり設定しやすくなったし、AwesomeWMとX11の時よりもずっと良い感じ。Luaでの設定が特に良くて、AwesomeWMの頃の感覚が戻ってきた感じだよ。

XWaylandを除けば、すべてのテストで入力遅延は非常に小さい範囲内だった。人間にはその遅延の違いだけで区別することはできないと思う。3msの違いでXWaylandに気づく人がいるとは驚きだね。遅いモニターではもっと大きな違いが出るかもしれないけど。WaylandとX11のプロトコル間の違いはほとんど無視できるレベルだよ。XWaylandの実装には制限があるみたい。

「Wayland入力遅延」なんてものは存在しないよ。ただの言葉の寄せ集めで、「HTTPアニメーションの滑らかさ」と同じようなもの。この記事はXorgとKWin(そしてXWayland)を測定してるけど、他のX11やWaylandの実装はそれぞれ異なる特性を持ってる。XWaylandの追加遅延がどこから来てるのか気になるけど、ただのオーバーヘッドとして簡単に片付けられるには高すぎる気がする。

そうだね、OPは確かにGnomeで再テストすべきだよ。僕は詳しくないけど、GnomeのWaylandコンポジタはKWinよりも少し速くて、慎重に設計されてる気がする。少なくとも、pgtkモードのEmacsはGnomeの下でかなり良く動くけど、KWinだとスクロール時にCPUをかなり使って、特に高解像度ではちょっと遅れるんだよね。

これはWaylandファンの面倒な議論スタイルだね。Waylandファン: 「Waylandに切り替える必要がある。Xは廃止されて何年も経ってる!Waylandが未来だ。」ユーザー: 「分かった、試してみたけど、壊れてる/悪化してる。」Waylandファン: 「いや、君は理解してない。Waylandはただのプロトコルだ。君のWaylandの実装に問題があるんだ、Wayland自体は悪くない!Waylandはまだ素晴らしい!」ユーザー: 「でもXはちゃんと動いてたのに…」

Hacker Newsで議論の続きを見る