Linux 延迟测量与合成器调优深度解读

背景

自作者从 Windows 迁移回 Linux 以来，一直对 Linux 平台上的游戏延迟（Latency）问题感到焦虑。环境的细微变化或设置的调整，都可能导致鼠标操作突然变得“漂浮”且缺乏跟手性。这并非个例，社区中对此话题的讨论屡见不鲜。

为了量化并解决这一问题，作者使用 Teensy 微控制器构建了一套自动化测试系统。该设备模拟 USB HID 鼠标，并配合紧贴屏幕的光传感器，通过修改开源 LDAT 草图（Sketch）来测量“点击到光子（Click-to-Photon）”的延迟。这套设置能够无人值守地将数百个样本记录到 CSV 文件中，为后续的严谨对比提供了数据基础。

核心内容

测试环境与配置

测试在两台硬件相似但形态不同的计算机上进行：一台台式机（Desktop）和一台笔记本电脑（Laptop）。两者均配备 Ada 架构的 RTX 显卡和 Zen 4 CPU，并运行几乎相同的 NixOS 配置。此外，每台机器上还安装了最新的 Windows 11 系统作为对照。

• 显示设备：大部分测试使用 LG C1 电视，通过 HDMI 以 120 Hz 刷新率输出。
• Linux 环境：使用 KDE Wayland 6.6.4、Proton-GE 10-33、MangoHud 0.8.2（用于限制 FPS，采用“晚期”方法）以及 Nvidia 595.58.03 驱动。原计划对比 X11 会话，但因 KDE 即将移除 X11 支持而放弃。
• Windows 环境：使用 Nvidia 控制面板或 RTSS（RivaTuner Statistics Server）进行帧率限制。
• 目标：避免硬件瓶颈，轻松达到 120 FPS 以匹配 120 Hz 输出，重点测试软件栈中的排队效应（Queueing effects）。

测试中的变量控制与干扰因素

尽管工具自动化程度高，但控制变量仍极具挑战。作者在测试过程中发现了一些导致数据无效或偏差的异常行为：

1. LG webOS 电视行为：当在同一端口连接不同电脑时，电视会自动切换“黑帧插入（Black Frame Insertion）”设置。
2. KDE Konsole 的影响：使用 Konsole 终端标记测试开始会生成巨大的 wl_shm 呈现表面，这些表面通过 PCIe 复制到 GPU 显存耗时较长，导致合成器对时序变得过度悲观。
3. 垂直同步（V-Sync）延迟：在某些游戏中切换 V-Sync 模式不会立即生效。

合成测试：发现 Zed 编辑器的隐藏延迟

为了快速验证显示设置，作者编写了一个简单的合成测试工具：一个点击后立即变白的黑色方块，并加入可配置的延迟以模拟输入处理。测试在纯净的 Chromium 配置文件下进行。

图表解读方法：

• Y 轴表示变化的参数。
• 底部 X 轴为毫秒级延迟，顶部 X 轴为 120 Hz 下的帧数。
• 图表包含多个分面（Facets），每个分面展示另一个变量的值。
• 每个 Y 值对应多个水平箱线图（Boxplots），代表不同可调参数的组合。
• 箱体显示四分位距（IQR），须线表示最小/最大值，垂直线为中位数。

意外发现： 在合成测试中，作者惊讶地发现台式机比笔记本慢。在排除软件版本和硬件差异后，通过创建新用户账户复测，发现台式机原有配置引入了至少 3ms 的额外延迟。经过排查，罪魁祸首是后台闲置的 Zed 编辑器。即使 Zed 窗口处于后台且空闲，其存在也会增加所有其他应用的延迟。不过，这一发现并未影响全屏游戏的测量结果，因为全屏游戏不受此影响。

LG 显示器设置影响

• PC 模式：将输入模式设为 PC（锁定部分图像设置）对延迟无影响。
• 黑帧插入（BFI）：似乎增加了整整一帧的延迟。尽管作者喜欢此功能，但其实现方式似乎增加了额外的缓冲，而非使用无延迟的滚动扫描。
• HDR：产生了微小但可测量的延迟影响。
• HDMI ALLM：作者计划测试自动低延迟模式（ALLM）。在 Windows 上使用 Radeon 显卡时，驱动会无条件应用 ALLM，作者甚至需要通过伪造 EDID 来阻止其生效。但在 Linux 上似乎不支持 ALLM，且 Nvidia Windows 驱动中也未找到相关选项。

游戏实测

作者选择了三款支持不同图形 API 的游戏进行测试，重点在于比较不同 API 下的可调参数，而非跨游戏比较（因动画时序不同）。

1. Doom Eternal (Vulkan)

• 设置：加载黑暗关卡，利用无限弹药观察重炮枪口闪光。
• 平台差异：Linux 下的分布尾部更宽（p75 处），表明延迟波动更大。
• 帧率限制：若 FPS 未限制在刷新率以下，启用 V-Sync 会导致帧缓冲，增加延迟。禁用 V-Sync 可恢复延迟，但由于游戏通过 XWayland 运行，并未出现画面撕裂。
• VRR 与 Nvidia 设置：可变刷新率（VRR）本身对延迟影响不显著；测试的 Nvidia Windows 独占设置也未见明显效果。

2. Borderlands 3 (DX11, DX12)

• 设置：修改存档移除武器弹匣附件，防止弹药消耗，便于连续测量 500 次枪口闪光。
• 平台对比：Windows 的延迟始终低于 Linux，在使用 V-Sync 时差异尤为显著。
• Proton Wayland：启用原生 Proton Wayland (PROTON_ENABLE_WAYLAND=1) 可以在一定程度上挽回延迟劣势。
• API 性能：DX12 在两个操作系统上均比 DX11 慢。作者未测试 Unreal Engine 的特定优化（如 OneFrameThreadLag CVar）。
• 关键调优参数：
  • Nvidia 超低延迟模式（Windows）。
  • VKD3D_SWAPCHAIN_LATENCY_FRAMES=1 和 VKD3D_SWAPCHAIN_IMAGES=2（针对 DX12）。
  • DXVK_CONFIG="d3d9.maxFrameLatency=1;dxgi.maxFrameLatency=1"（针对 DX11）。
  • 结果：仅有 VKD3D_SWAPCHAIN_LATENCY_FRAMES=1 产生了影响，但 DX12 仍显著滞后于 DX11。
• 帧率限制的重要性：将 FPS 限制在刷新率以下，防止帧在刷新率标记处排队，是降低延迟最有效的手段。

3. Hades 2 (DX12)

• 观察：动画启动时间较长，但表现一致。
• 有效设置：
  • 将 FPS 限制在刷新率及以下。
  • 使用 wine_wayland/ 或 PROTON_ENABLE_WAYLAND=1。
  • 这些设置的效果是独立的，不一定具有累积效应。

关键要点

• 后台应用影响显著：在 Linux (KDE Wayland) 环境下，即使是后台闲置的应用程序（如 Zed 编辑器）也可能引入额外的合成延迟（约 3ms+）。保持系统精简有助于降低基础延迟。
• 帧率限制是核心：无论使用何种 API 或平台，将 FPS 限制在显示器刷新率（如 120 FPS @ 120Hz）以下，防止帧队列堆积，是降低输入延迟最有效的方法。
• API 性能差异：在 Borderlands 3 中，DX11 的延迟表现优于 DX12。虽然 Proton Wayland 能改善部分情况，但 Windows 原生在低延迟方面仍具优势。
• 显示器设置陷阱