在 Linux 上测量输入延迟：X11 与 Wayland、VRR 与 DXVK 低延迟

在 Linux 上测量输入延迟：X11 与 Wayland、VRR 与 DXVK 低延迟

TL;DR – 数字含义

  • X11 vs. Wayland： X11 略快（0.14–0.22 ms），不足以解释人们普遍觉得 Wayland 更慢的感受。
  • 可变刷新率（VRR）： 开启 VRR 能持续降低 0.26–0.45 ms 的延迟，并收紧延迟分布。
  • DXVK 低延迟分支： 在限帧场景下削减 0.10–0.29 ms；在未限帧、GPU 受限的运行中削减 0.84 ms 并平滑帧时间尖峰。
  • XWayland： 增加巨大的 3.13 ms 惩罚，远超其他所有因素。
  • 总体收益： 采用全部优化（X11 + VRR + DXVK 低延迟）相较于默认的纯 Wayland 设置，可将中位端到端延迟降低约 0.72 ms。

测量原理

作者使用 Adafruit QT Py RP2040 搭建了一个 click‑to‑photon 装置，其工作方式如下：

  1. 以 1000 Hz 的轮询率发送 USB HID 鼠标点击。
  2. 立即开始采样安装在显示器上的光电二极管（≈24 µs/样本，每次点击采集 12 k 样本）。
  3. 将采样数据流式传输到主机，脚本在每次点击的基线中寻找第一次亮度偏离。
  4. 由于采样窗口长度固定，脚本计算点击发出到屏幕亮度变化之间的精确时间——即 端到端系统延迟（鼠标 → CPU → GPU → 合成器 → 扫描输出 → 显示器）。

该方法捕获了完整的流水线，区别于仅测 GPU 的计时器——后者会忽略 USB 与显示延迟。

测试矩阵

变量 选项
显示服务器 X11（原生），Wayland（原生），XWayland
VRR 关闭，开启
DXVK 低延迟 关闭，开启
限帧模式 以刷新率限帧（500 Hz）或不限帧（GPU 受限）

所有测试使用相同的硬件和软件栈：

  • CPU： AMD Ryzen 7 5800X3D
  • GPU： NVIDIA RTX 4070 SUPER，驱动 610.43.03
  • 显示器： MSI MAG 272QP QD‑OLED，2560×1440 @ 500 Hz
  • 操作系统： CachyOS kernel 7.1.3‑2，KDE Plasma 6.7.2，Xorg 21.1.24
  • 游戏： Diabotical（DirectX 11）via Heroic + Proton‑cachyos 11.0，DXVK 3.0
  • 设置： 原生分辨率，100 % 渲染比例，关闭 V‑sync，其他图形均设为低。

每种情形运行 300 次点击（约 2 分钟），在静态游戏场景下保持帧率稳定且 CPU 受限。

核心结果（中位延迟，ms）

配置 X11 Wayland XWayland
低延迟 + VRR 4.21 4.38（+0.17） –
低延迟 4.64 4.83（+0.19） 5.95（+1.12）
仅 VRR 4.45 4.67（+0.22） –
纯净 4.79 4.93（+0.14） 8.06（+3.13）

未限帧（GPU 受限）对比

  • 关闭低延迟：5.27 ms，715 FPS
  • 开启低延迟：4.43 ms，670 FPS（‑0.84 ms 延迟，‑45 FPS）

观察

  1. X11 仅比 Wayland 快约 0.2 ms——远小于“Wayland 感觉更慢”的流行说法。
  2. VRR 持续提升延迟（0.26–0.45 ms）并缩小分布（p95‑p5 范围从约 3 ms 降至约 2 ms）。
  3. DXVK 低延迟在限帧模式下收益有限（≈0.2 ms），但在未限帧时表现突出，削减 0.84 ms 并防止 GPU 饱和。
  4. XWayland 是最大延迟罪魁——增加超过 3 ms，超过所有其他因素之和。

为什么 XWayland 如此昂贵

作者指出，XWayland 会在游戏到达 Wayland 合成器之前强制经过额外的 X 服务器层，导致额外的拷贝与合成步骤。原生 Wayland 下，合成器可以使用 direct scan‑out（翻转模式），对全屏窗口完全绕过合成。这一架构开销解释了约 3 ms 的惩罚，远大于 X11 与 Wayland 之间的细微差距。

社区验证

  • David Ramiro 的 m2p‑latency 研究发现原生 Wayland 与原生 X11 延迟相当（约 7 ms），而 XWayland 延迟约为其两倍——与本报告的结果相吻合。
  • farnoy 的 Open‑Source‑LDAT 工作同样得出应避免使用 XWayland 的结论。
  • Themaister 的 VK_EXT_present_timing 方法仅测量 PC 延迟（不包括 USB/显示），与这里的端到端方法形成互补。

对 Linux 玩家实用的建议

  1. 尽量避免 XWayland——它会额外增加 >3 ms 的延迟。
  2. 优先使用原生 Wayland；与 X11 的差距可以忽略不计，未来合成器的优化（如 KWin 调优）可能进一步缩小。
  3. 在高刷新率显示器上开启 VRR；它带来最大的延迟下降并稳定帧时序。
  4. 在未限帧、GPU 受限的场景下使用 DXVK 低延迟，可平滑帧间隔并削减约 0.8 ms。
  5. 保持显示器处于翻转模式（direct scan‑out），无论是 X11 还是 Wayland，都能确保合成器不回退到 blit/composite 路径。

局限性与范围

  • 结果基于单一硬件配置（500 Hz OLED、RTX 4070 SUPER、Linux kernel 7.1.3），绝对数值在其他配置上会不同，但相对收益应具有可迁移性。
  • 测试在 CPU 受限且场景静止的情况下进行；实际游戏的动态负载可能会让 VRR 与 DXVK 低延迟的收益更为显著。
  • 仅使用了一款游戏（DirectX 11 Diabotical），Vulkan 或 OpenGL 游戏的表现可能不同。

结语

在理想的 CPU 受限条件下，综合所有优化（X11 + VRR + DXVK 低延迟）相较于纯 Wayland 设置可将中位端到端输入延迟削减 约 0.72 ms。虽然绝对提升看似 modest，但通过 VRR 降低的抖动以及 DXVK 低延迟平滑的帧时间尖峰，在快节奏的竞技游戏中是可以感知到的。最大收益仍然是 避免 XWayland——它带来的延迟惩罚超过了所有其他因素的总和。

“Linux 的美妙之处在于，这类分析不仅可行，而且意义重大。这些结果会反馈给图形软件作者和发行版维护者，整个生态将随之改进。” – NelsonMinar，HN 评论

“根本不存在‘Wayland 输入延迟’这种说法。本文测量的是 Xorg 与 KWin（以及 XWayland）的差异，其他实现会有不同特性。” – seba_dos1，HN 评论

“最近让我抓狂的输入延迟是屏幕解除黑屏的延迟……我怀念旧 X 服务器的行为——在 DPMS 节能时输入仍保持活跃。” – saltcured，HN 评论

这些社区反馈凸显了精准硬件层面延迟测量对于指导 Linux 图形栈未来发展的重要性。

Sources