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

# 在 Linux 上测量输入延迟：X11 vs Wayland、VRR 与 DXVK 来源：https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/ 2026\-07\-13 两年前，我把游戏 PC 切换到了 Linux。人们一直告诉我，在帧率、帧生成节奏和输入延迟方面，Linux 可以比 Windows 表现好得多，当我实际尝试时，感觉确实好了很多。 网上关于优化 Linux 游戏体验的建议铺天盖地： - Wayland 输入延迟高，用 X11 - 关闭合成（“使用翻转模式”） - 使用延迟优化的 DXVK 分支 (https://github.com/netborg-afps/dxvk-low-latency) - 使用游戏专用内核调度器 (https://www.phoronix.com/review/cachyos-bore) - 等等。 我玩竞技性 FPS 游戏，所以低延迟、一致的帧时间以及高帧率对我来说很重要。在 Linux 上，有无数设置可以为此进行调优（魔法环境变量、gamescope、gamemode、甚至更多的 DXVK 分支 (https://gitlab.com/Ph42oN/dxvk-gplasync)，等等）。 但一直以来困扰我的是，我没有可靠的方法来验证某项设置是否真的降低了系统延迟，还是只是“蛇油”、安慰剂效应，甚至在没有察觉的情况下变得更差。 --- ## 设备 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#the-device) 想法很简单：将某种带有光传感器的设备绑在显示器上，并通过 USB 连接到 PC 模拟鼠标点击。点击时，测量从点击到光传感器检测到屏幕变化之间的时间。 这样，你就测量了端到端的系统延迟。 延迟流水线图：从鼠标输入经过 CPU、渲染队列、GPU、合成和扫描输出到显示器的各个阶段，分为外设、PC 和显示器延迟；共同构成端到端系统延迟。© NVIDIA 有一张很好地总结这一点的图片。虽然现在有一些类似的开源设备可用，比如 m2p\-latency (https://github.com/davidramiro/m2p-latency) 或 Open\-Source\-LDAT (https://github.com/S4N-T0S/Open-Source-LDAT)，但当我开始这个副项目时，只有 OSLTT (https://github.com/OSRTT/OSLTT)，而且对硬件一无所知，我很高兴研究了它的原理图，并大致基于它的设计。 但就在本月完成我的项目时，我最终也整合了另外两个项目的很多想法。 长话短说，我学到了很多关于微控制器、焊接、Arduino 固件开发、积分时间、跨阻放大器、KiCad（一点点）和外壳设计的知识。 以下是我最终的方案： - 一块 Adafruit QT Py RP2040 充当 USB HID 鼠标，轮询率 1000 Hz，并触发点击。 - 在发送点击的瞬间，它开始从光电二极管采集样本（每约 24 μs）。 - 每次点击采集 12,000 个样本，通过串口流式传输到主机并记录到 CSV。 - 基于这些样本，主机上的工具为每次点击建立基准线，然后找到第一个偏离基准线一定幅度的样本。 - 由于采集 12,000 个样本所需的时间是固定的，现在可以计算从发送点击到检测到屏幕亮度变化之间的时间。 --- ## 测试场景 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#test-scenarios) 我想测试三个不同的方面。 ### 显示服务器（X11 vs 原生 Wayland） 很多人仍然使用 X11 而不是 Wayland，因为据说 Wayland 的输入延迟差得多。只要搜索一下 (https://www.google.com/search?q=x11+wayland+latency)，就会发现很多人在抱怨 Wayland“感觉不对劲”。 ### VRR（开 vs 关） 可变刷新率 / G-Sync / FreeSync / 随便你怎么叫。这也是一个争论激烈的话题。 ### DXVK 低延迟分支（开 vs 关） *此后称为 `dxvk-low-latency` 或 `low-latency`。* 该分支 (https://github.com/netborg-afps/dxvk-low-latency) 的维护者 netborg 为开发这个帧调速器付出了很多努力，最近它被整合到了官方的 **proton-cachyos** 包中，通过环境变量 `PROTON_DXVK_LOWLATENCY=1` 启用。这个分支所承诺的效果是我再次尝试桌面 Linux 的决定性因素之一。 ### 额外：dxvk-low-latency vs 默认 dxvk 无上限 像 dxvk-low-latency 这样的帧调速器最大的优势是吸收帧时间波动并防止渲染队列堆积。使用我采用的测试方法（静态游戏内场景，详见下文），无法观察到帧时间波动，因为所有测试都产生了纯 CPU 绑定的场景。但这基本上不能反映真实的游戏会话，因为在游戏内部或外部（例如其他进程使用资源）帧时间可能波动。 因此，为了展示调速器的工作效果，我增加了两个无上限的测试用例。 ### 额外：原生 Wayland vs XWayland 我通过原生 Wayland（`PROTON_ENABLE_WAYLAND=1`）运行了所有 Wayland 测试用例，因为我已经知道 XWayland 会引入延迟。但为了比较，我增加了两个 XWayland 测试用例（仅关闭 VRR）。 --- ## 测试条件 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#test-conditions) 硬件 AMD Ryzen 7 5800X3D NVIDIA GeForce RTX 4070 SUPER 2×8 GB DDR4 3200 MHz MSI MAG 272QP QD-OLED X50 2560×1440 / 500 Hz MSI B450 GAMING PRO CARBON AC 测试期间仅连接了一台显示器。 软件 版本 CachyOS-Kernel 7.1.3-2-cachyos NVIDIA 驱动 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 设置菜单启用（无需重启） *翻转模式（或“直接扫描输出”）vs Blit 模式（合成）在 Wayland 上：* 没有专门的设置项。合成器自行决定是对帧进行合成还是使用直接扫描输出。要确保游戏以翻转模式运行：打开“KWin 调试控制台”（一个 GUI 工具），在“效果”选项卡中启用 `showcompositing`。然后确保游戏完全聚焦并以全屏模式独占屏幕。如果游戏边缘没有可见的红色边框，则处于翻转模式。 ### dxvk 为了使比较公平，根据场景使用了优化的 `dxvk.conf`： - 如果 VRR 禁用，则设置 `dxgi.maxFrameRate = 500`（帧率锁定在屏幕刷新率） - 如果 VRR 启用且 dxvk-low-latency 禁用，则设置 `dxgi.maxFrameRate = 497`（帧率锁定略低于屏幕刷新率） - 如果 VRR 启用且 dxvk-low-latency 启用，则使用以下配置以利用低延迟 VRR 帧调速： `` dxgi.maxFrameRate = 480 dxvk.lowLatencyOffset = 70 dxvk.framePace = "low-latency-vrr-500" dxvk.lowLatencyAllowCpuFramesOverlap = False `` 在所有情况下，都设置了 `d3d11.cachedDynamicResources = "c"`。 --- ## 游戏与方法论 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#game-and-methodology) 我使用的游戏是 Diabotical (https://store.epicgames.com/en-US/p/diabotical)，一款 **DirectX 11** 游戏，通过 Heroic 和 Proton 启动。 ### 游戏设置 - 原生屏幕分辨率 - 100% 渲染比例 - 垂直同步关闭 - 其他所有视频设置尽量低 有一个隐藏命令可以短时间内隐藏界面。将该命令绑定到左键点击（`/bind mouse_left testlatency`），并设置一个会显示大型白色方块的 HUD，我就能在点击时产生较大的亮度差异。 设备在 Diabotical 中的工作情况。 ### 方法论 - 关闭不必要的软件。 - 启动游戏。 - 启动本地比赛服务器（每次相同的模式和地图）。 - 移动到特定位置，将鼠标放在特定参照物上。 - 运行测试用例迭代（100 次点击，大约运行 2 分钟）。 - 测试完成后，开始下一个测试用例迭代（总共 3 次）。 - 游戏内条件：无机器人、无其他玩家、无移动、无回合重启。基本上就是静态场景，会一直保持下去。 - 系统条件：测试期间，系统上不应运行其他重要进程。 - 测量设备在所有测试中保持相同位置（见视频）。 --- ## 结果 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#results) **click2photon 延迟：X11 / Wayland、VRR、low-latency** Diabotical，500 Hz QD-OLED，RTX 4070 SUPER，每种情况 300 次点击。 每个锁帧测试用例在测试期间都保持了稳定的帧率上限，并且游戏全程保持 CPU 绑定。 数据看起来很干净：没有测试用例产生极端异常值，每个用例都呈现钟形分布，p5 到 p95 之间大约 **2 到 3 ms** 宽。 有三点很突出： - 8 个主要用例彼此相差在 **0.72 ms** 以内（**中位数从 4.21 ms 到 4.93 ms**）。 - XWayland 比其原生 Wayland 对应版本增加了 **3.13 ms**（**中位数 8.06 ms vs 4.93 ms**）。 - 在无上限的用例中，dxvk 分支成功将延迟降低了 **0.84 ms**。 以下是最快的用例： **延迟分布：最快用例（X11、VRR、low-latency）** --- ## X11 vs Wayland (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#x11-vs-wayland) 那么，X11 的延迟是否比 Wayland 低？是的，但远不足以解释为什么 Wayland 普遍被认为比 X11 差得多。 | 配置 | X11 | Wayland | 差异 | |------|-----|---------|------| | low-latency + VRR | 4.21 ms | 4.38 ms | +0.17 ms | | low-latency | 4.64 ms | 4.83 ms | +0.19 ms | | VRR | 4.45 ms | 4.67 ms | +0.22 ms | | plain | 4.79 ms | 4.93 ms | +0.14 ms | X11 在每个场景中都胜出，但仅仅 **0.14 到 0.22 ms** 的差异。分布非常相似： **延迟分布：plain X11 vs plain Wayland**\-\-\-https://news.ycombinator.com/ ## VRR：开还是关？(https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#vrr-on-or-off) VRR 在配对中的影响最大：启用它比禁用快 **0.26 到 0.45 ms**。 | 配置 | VRR 关闭 | VRR 开启 | 差异 | |------|---------|---------|------| | X11, low-latency | 4.64 ms | 4.21 ms | -0.43 ms | | X11 | 4.79 ms | 4.45 ms | -0.34 ms | | Wayland, low-latency | 4.83 ms | 4.38 ms | -0.45 ms | | Wayland | 4.93 ms | 4.67 ms | -0.26 ms | 它也使分布更平坦：VRR 用例中 p95-p5 的跨度是 **2.1 到 2.2 ms**，而没有 VRR 时是 **2.6 到 3.0 ms**。 **延迟分布：VRR 开 vs VRR 关（Wayland、low-latency）** 这与 VRR 的工作原理一致：帧在准备就绪时即扫描输出，而不是等待下一个扫描输出槽。 --- ## dxvk-low-latency 不错 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#dxvk-low-latency-is-good) 在锁帧的测试用例中，差异虽小但一致，与 X11 vs Wayland 的幅度大致相同。Wayland 和 X11 之间的平均差异为 **0.18 ms**，而使用 dxvk-low-latency 平均快 **0.20 ms**。 | 配置 | low-latency 关闭 | low-latency 开启 | 差异 | |------|----------------|-----------------|------| | X11, VRR | 4.45 ms | 4.21 ms | -0.24 ms | | X11 | 4.79 ms | 4.64 ms | -0.15 ms | | Wayland, VRR | 4.67 ms | 4.38 ms | -0.29 ms | | Wayland | 4.93 ms | 4.83 ms | -0.10 ms | 在无上限的测试用例中，我们可以看出 dxvk-low-latency 的真正优势所在：平滑不均匀的帧节奏并防止渲染队列堆积。调速器通过确保 GPU 永远不会完全满载来实现这一点，因此游戏始终接近 GPU 绑定，但从未完全绑定。这在测试运行中可以观察到：使用 dxvk-low-latency 时 GPU 利用率为 **95-97%**，而不使用时为 **100%**。这以帧率为代价换取了一点性能。 | 维度 | low-latency 关闭 | low-latency 开启 | 差异 | |------|----------------|-----------------|------| | 延迟 | 5.27 ms | 4.43 ms | -0.84 ms | | FPS | 715 | 670 | -45 | **延迟分布：无上限，DXVK low-latency 开 vs 关（X11）** --- ## XWayland 很糟糕 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#xwayland-is-bad) 到目前为止，所有 Wayland 测试都通过 `PROTON_ENABLE_WAYLAND=1`（或 Heroic Launcher 中的“启用 Wine-Wayland（实验性）”开关）原生运行游戏。关闭该选项会使游戏改为通过 XWayland 运行，这就是问题所在。 | 配置 | 原生 Wayland | XWayland | 差异 | |------|-------------|---------|------| | low-latency | 4.83 ms | 5.95 ms | +1.12 ms | | plain | 4.93 ms | 8.06 ms | +3.13 ms | 在没有 dxvk-low-latency 的情况下，XWayland 给测量增加了 **3.13 ms** 的延迟。这比我测量的所有其他影响的总和还要多。而且并非偶尔的坏帧拉高了平均值；整个分布都发生了偏移： **延迟分布：原生 Wayland vs XWayland** 值得注意的是，在 XWayland 测试中加入 dxvk-low-latency 将延迟降低了 **2.11 ms**，这是所有场景中最大的收益。 --- ## 总结 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#summary) 这些结果是在最佳条件下（帧率稳定达到上限、CPU 绑定）产生的，当然也特定于我的硬件和所选软件栈。 绝对值在其他配置上会有所不同，但每个测试用例的得失应该大致能够迁移。在更低刷新率的显示器上，VRR 和低延迟调速器带来的收益可能会更大。 ### 避免使用 XWayland 它增加了 **3.13 ms** 的延迟，超过了所有其他影响的总和。 ### Wayland 很接近，但 X11 仍然胜出 尽管只差 **0.14 到 0.22 ms**。鉴于有优化 KWin 的努力 (https://farnoy.dev/posts/linux-latency#future-work)，这个差距很可能很快就会缩小。谁知道呢，其他 Wayland 合成器可能已经更好了。 ### VRR 效果最显著 VRR 在每个配对中都更快（**0.26 到 0.45 ms**），并且也使延迟分布更平坦。 ### dxvk-low-latency 全面获益 在锁帧场景中 **0.10 到 0.29 ms** 是不错的提升，但该分支的真正实力体现在无上限测试用例中，它比默认 dxvk 获得了 **0.84 ms** 的收益。此外，在无法避免 XWayland 的场景中，它完全恢复了 **2.1 ms**。 ### 结论 如果不考虑 XWayland，应用所有优化（**X11、VRR、low-latency**）与默认设置（在现代 Linux 系统上，我假设是原生 Wayland）相比，中位数降低了 **0.72 ms**。这听起来不多，但原始延迟并不能说明全部问题，因为 VRR 还减少了延迟抖动，而 dxvk-low-latency 的调速器在平滑现实场景（帧时间下降和 GPU 绑定情况发生）方面非常出色。 --- ## 类似工作 (https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/#similar-efforts) David Ramiro 构建了他的 m2p\-latency (https://davidjusto.com/articles/m2p-latency/)，并在他的文章《构建输入延迟计（因为“Wayland 感觉不对劲”不是一种度量）》 (https://davidjusto.com/articles/m2p-latency/#results) 中比较了 X11 和 Wayland，得出了类似的结论：原生 Wayland 与原生 X11 相当（都约 7 ms），而 XWayland 在他的测试中大约使延迟翻倍。 farnoy 在他的文章《Linux 延迟测量与合成器调优》中使用 Open\-Source\-LDAT (https://github.com/S4N-T0S/Open-Source-LDAT) 进行了广泛测试 (https://farnoy.dev/posts/linux-latency)，同样得出结论：应该避免使用 XWayland。 我的副线任务：使用 VK\_EXT\_present\_timing 测量输入延迟 (https://themaister.net/blog/2026/07/02/my-side-quest-meas