Arch Linux＋niri＋NVIDIA 笔记本游戏性能排查：4K HDR 从约 45 FPS 提升到 75 FPS

最近， 空之轨迹2nd 发售了，我也第一时间在 steam 上购买下载了，开始游玩。我的主力笔记本是 Archlinux 2024款的翼龙15pro 4070版本, 现在用的 niri+dms+wayland.

听说 cachyOS 的 proton 支持走wayland 而不是 Xwayland 了，因此我也装了 proton-cachyos. 进入游戏之后发现游戏支持HDR, 又让 GPT6 帮我找了一个 niri 的分支，自行构建开启了HDR支持。

但是进入游戏之后，帧率很低，尤其我用4k 中画质的话，大约只有45帧，开启HDR会更低。听闻前段时间Linux上能用上 dlss5, 我也尝试了一下，于事无补，而且帧率进一步降低，可能我的显卡太差了（对应的资源也放在我的 openlist了）。

找AI帮我调了一些参数，也没有什么明显效果，所以在 Linux下我就先用着2k高画质玩着，差不多60FPS. 我又想要不回 Windows 得了，结果 windows下4k中画质有60fps, 但是没有HDR了（我的显示器是支持的）。所以我又回Linux了，想着怎么提升一下帧数。

排查过程

下面的排查过程是让 GPT帮我总结的，大致上没问题。

第一阶段有效的调整是：指定 niri 使用 NVIDIA 独显作为主渲染设备。 游戏本身一直运行在独显上，但 niri 原先使用的是另一块 GPU。后续为了解决日常应用占用独显显存、内外屏需要不同合成 GPU 的问题，又编译了配套修改的 niri 和 Smithay，启用 render-on-output-device，让每个输出在连接它的 GPU 上合成。这个最终方案放在文末的后记里。

记录一下 Windows/Linux 对照、排查过程和解决办法，供双显卡笔记本用户参考。

使用环境

• 系统：Arch Linux
• 桌面：niri＋DMS；最初使用自行编译的 HDR 分支，后续使用配套修改的 niri 和 Smithay
• niri 版本：这组帧率记录使用 26.04 (641335f)；后续检查时已更新为 26.04 (1568e42)
• 独显：RTX 4070 Laptop，8GB 显存，PCI 地址 0000:01:00.0
• 核显：AMD Radeon 780M，PCI 地址 0000:07:00.0
• NVIDIA 驱动：615.71.09
• Proton：proton-cachyos-slr 1:11.0.20260703-1
• 显示器：ASUS PG32UCDM3，通过 HDMI 连接
• 外屏输出：3840×2160，缩放 200%；配置曾请求 240Hz，但实际刷新率需要单独确认
• 内屏：2560×1600，240Hz，缩放 150%，接口连接 AMD 核显
• VRR：配置启用 VRR；没有按测试轮次完整记录其实际状态

配置中的刷新率不等于实际输出模式。 2026 年 9 月 28 日检查时，外屏实际为约 143.988Hz，DMS 的输出配置也设置为这个模式。之后的日志里既出现过成功选中 240Hz，也出现过请求 240Hz 不可用、回退到 60Hz，以及重新选中 144Hz 的记录。因此，不能把下面所有帧率观察都视为在固定 240Hz 输出下完成；当时没有给每一轮结果保存对应的输出模式。

实际模式可以用下面的命令检查；使用 DMS 时，还要核对 include 引入的输出配置：

niri msg outputs

当前配置中的 variable-refresh-rate 表示启用 VRR。按需模式则需要输出配置中的 variable-refresh-rate on-demand=true，并配合窗口规则中的 variable-refresh-rate true，两者不能混为一谈。具体见 niri 的 VRR 配置说明。

这里的 HDR 支持来自自行构建的分支，不能只凭 26.04 这个版本号判断其他构建是否具有相同功能。最终方案使用 sukanka/niri 的 feat/render-on-output-device 分支和配套的 sukanka/smithay 的 fix/multigpu-buffer-sync 分支。下面保留第一阶段测试的提交号，最终方案的构建版本另行记录。

后期 Linux 对照测试主要使用 4K 输出、中画质、DLSS Performance。这里的 4K 指输出分辨率，启用 DLSS 后并非原生 4K 渲染。

最初的疑问：为什么 Windows 能接近 4K 60 FPS，Linux 却不行？

在 Windows 11 下，使用 4K＋DLSS Performance，帧率能够勉强达到 60 FPS。

但 Windows 下还有一个 HDR 问题：

• Windows 系统设置中的 HDR 已开启。
• 游戏内 HDR 显示为 Off，而且不能调整。
• Linux 下使用支持 HDR 的 niri 分支后，游戏内 HDR 可以调整。

所以，Windows 的这个结果不能算作“游戏 HDR 开启时的 4K 60 FPS”。当时也没有把两边所有画质选项逐项记录下来，它主要是排查起点，并非严格控制全部变量的跨系统基准测试。

Linux 下做过的帧率对照

早期在 4K、中画质、DLSS Performance，HDR 关闭 的条件下：

运行方式	实测帧率
XWayland	约 60 FPS
Proton 原生 Wayland	43–49 FPS

这让我最初怀疑是 Proton 的原生 Wayland 路径存在明显性能损失，考虑过重新编译 Proton，或者添加环境变量。

之后另一次测试中，原生 Wayland 的表现是：

HDR 状态	实测帧率
开启	约 45 FPS
关闭	约 52 FPS 以上

这些是不同轮次的观察，因此没有把早期的 43–49 FPS 与后来的 52 FPS 以上当作完全相同条件下的重复测量。

中间排查了哪些方向？

1. 显卡功耗与 Dynamic Boost

   游戏时经常看到 GPU 只有约 105W，而 nvidia-smi 显示上限为 140W，因此怀疑没有释放全部功耗。

   检查发现：

   • Notebook Dynamic Boost 显示 Supported。
   • nvidia-powerd 已启动。
   • 一次详细采样中，平均功耗达到 139.59W。
   • 另一次连续采样虽然只有约 103–104W，但核心频率稳定在 2520MHz，SW Power Cap 为 Not Active。

   因此，不能因为某段游戏只有 105W，就判断显卡被锁在 115W，或者需要“解锁 140W”。

2. 关闭 Wine fullscreen hack

   测试了：

   PROTON_ENABLE_WAYLAND=1 WINE_DISABLE_FULLSCREEN_HACK=1 gamemoderun %command%

   帧率仍为 43–49 FPS，没有观察到改善。

3. HDR 分支的 scanout-post-blend-encode

   单独尝试了：

   debug {
       scanout-post-blend-encode
   }

   添加和移除都没有观察到帧率变化，因此它不是这次解决问题的关键。

真正的线索：niri 使用的渲染设备

检查 niri 日志：

journalctl -b _COMM=niri --no-pager |
  rg 'using as the render node'

原先显示：

using as the render node: "/dev/dri/renderD128"

随后确认 NVIDIA 独显对应的节点：

readlink -f /dev/dri/by-path/pci-0000:01:00.0-render

结果是：

/dev/dri/renderD129

也就是说，游戏使用 NVIDIA，但 niri 的主渲染设备并不是 NVIDIA。

之前在 nvidia-smi 的进程列表里也能看到 niri，但这不足以证明 niri 把 NVIDIA 作为主渲染设备。这里需要看 niri 启动日志。

第一阶段：让 niri 统一使用独显合成

在自己维护的 ~/.config/niri/config.kdl 中加入：

debug {
    render-drm-device "/dev/dri/by-path/pci-0000:01:00.0-render"
}

如果已经有 debug 配置块，就把这一项合并进去。

这里使用 PCI 对应的 by-path 路径，避免依赖可能随启动变化的 renderD128、renderD129 编号。其他机器需要先确认自己的独显 PCI 地址，不能直接照抄。

然后注销并重新进入 niri 会话。主渲染设备在启动时选择，仅重新加载配置不够。

重新检查日志，确认变成：

using as the render node: "/dev/dri/renderD129"

Steam 启动参数保持为：

PROTON_ENABLE_WAYLAND=1 gamemoderun %command%

这次调整没有重新编译 Proton；前面的 DLSS5 helper 尝试也未观察到改善。

第一阶段修改后的结果

继续使用 4K 输出、中画质、DLSS Performance：

原生 Wayland	修改前，后期测试	指定 niri 使用 NVIDIA 后
HDR 开启	约 45 FPS	约 75 FPS
HDR 关闭	约 52 FPS 以上	约 80 FPS

这是此次测试场景中的结果，不代表整个游戏所有场景都能维持同样帧率。不过，已经超过了我最初希望达到的 4K HDR 60 FPS。

这些数字是游戏场景中的帧率观察。本文没有提供完整的帧时间记录、平均 FPS 或 1% low，也没有逐轮列出同一存档位置、采样时长、内外屏启用状态、VSync、限帧和帧生成设置，以及实验性 DLSS5VKLayer 是否仍加载。因此，这里可以说明调整后观察到明显改善，但不能作为严格控制全部变量的基准测试，或据此确定某一段跨卡传输的耗时。

补充确认：HDMI 本来就是独显直出

我还怀疑过 HDMI 是否经过核显，以及换成 Type-C 连接是否能改善性能。

检查外接屏接口：

for p in /sys/class/drm/card*-HDMI-A-*; do
    [ "$(cat "$p/status")" = connected ] && readlink -f "$p"
done

返回路径中的关键部分是：

0000:01:00.0/drm/card0/card0-HDMI-A-1

这说明 HDMI 接口本来就属于 NVIDIA 独显。

内屏 eDP 则位于另一块 GPU：

0000:07:00.0/drm/card1/card1-eDP-1

所以这次修改改变的是 niri 使用哪块 GPU 渲染，并没有切换笔记本内屏的硬件 MUX。

修复之后，游戏、niri 主渲染设备和 HDMI 输出都落在 NVIDIA 上。没有必要仅为解决这次帧率问题而更换 Type-C 连接。

另一个问题：游戏失去焦点后最小化

游戏失去焦点后还会出现最小化。这需要分别考虑游戏或 Wine Wayland 对失焦的处理，以及合成器是否接受客户端的最小化请求，不能仅凭现象归因于某个 niri 设置。

这次采用的处理包括以下窗口规则：

window-rule {
    match app-id="^steam_app_4225980$"
    block-minimize true
}

block-minimize 是本文所用分支支持的扩展，不应当作普通上游 niri 的通用配置。相关实现用于忽略客户端的 xdg_toplevel.set_minimized 请求，不会禁止所有最小化操作，也不保证能阻止游戏自身因失焦隐藏窗口。参见 分支实现和相关讨论。

复制窗口规则前，应使用 niri msg windows 确认实际 app-id。这里的 steam_app_4225980 不能仅从 Steam 游戏编号推导，也不能假定不同 Proton 或显示后端都会报告同一个值。修改后可以运行 niri validate 检查当前构建是否接受该规则。

Proton 启动参数还加上了 WAYLANDDRV_FOCUS_LOSS=0。如果保留前文的 GameMode，完整写法是：

WAYLANDDRV_FOCUS_LOSS=0 PROTON_ENABLE_WAYLAND=1 gamemoderun %command%

该失焦变量是本文使用的 Proton-CachyOS 环境中采用的处理办法，不应泛化为所有 Wine/Proton 版本的通用选项。这里也没有分别记录只使用窗口规则、只使用变量时的效果，因此不能断言某一项单独就能解决问题。这个失焦处理与前面切换合成 GPU 的帧率改善分开看待。

后记与最终方案：按输出设备选择合成 GPU

普通应用也可能开始使用独显

第一阶段未启用按输出合成时，render-drm-device 选择的是 niri 统一合成使用的主 GPU，同时也会影响应用从 Wayland 获知的默认渲染设备。切到 NVIDIA 后，部分普通应用也会默认选择独显，与游戏共享显存；它并没有强制所有应用只能用独显。

2026 年 9 月 28 日的一次检查中，游戏未运行，RTX 4070 的显存占用已经约为 2917 MiB / 8188 MiB。nvidia-smi 中能看到这些进程：

进程	当次显存占用
niri	487 MiB
Zed	386 MiB
Chrome 的 GPU 进程	363 MiB
一个 Electron 应用的 GPU 进程	282 MiB
DMS / Quickshell	252 MiB
Thunderbird	178 MiB
Telegram	156 MiB
Tsukimi	108 MiB
Alacritty	45 MiB

这是当时应用使用状态下的一张快照。进程数值不一定能直接加总为显卡总占用，也没有核显合成时的同条件对照，所以不能说“这项调整额外消耗了 2.9 GiB”。但它确实说明，在 8GB 显存的机器上，日常应用的占用值得一起检查。独显承担桌面渲染也可能增加功耗，这次没有测量电池续航变化。

第二阶段：编译支持 render-on-output-device 的 niri 和 Smithay

统一让 NVIDIA 合成，外屏游戏的路径改善了，但内屏也要由 NVIDIA 渲染后交给 AMD 输出。为了同时保留内屏的核显合成和外屏的独显合成，最终从合成器本身入手：编译修改后的 niri 和 Smithay，加入并启用 render-on-output-device。

开启后，niri 优先在驱动该输出的 GPU 上合成；如果输出设备没有可用的 render node，才回退到主 GPU。本机的分工变成：

配置方式	内屏 eDP-1 的合成 GPU	外屏 HDMI-A-1 的合成 GPU
主设备为 AMD，未启用新参数	AMD	AMD
主设备为 NVIDIA，未启用新参数	NVIDIA	NVIDIA
主设备为 AMD，启用 render-on-output-device	AMD	NVIDIA

这样，使用核显的应用在内屏显示、使用独显的游戏在外屏显示时，应用渲染、合成和输出可以各自使用同一块 GPU。即使游戏没有进入 direct scanout、仍需桌面合成，也不必因为统一由核显合成外屏而绕经核显。

这项功能来自自定义分支，需要同时构建配套的 niri 和 Smithay。只在上游 niri 配置中添加同名参数，并不会自动获得这个行为。本次配套修改的源码为：

项目	仓库与分支	对应提交
niri	sukanka/niri，feat/render-on-output-device	1568e42
Smithay	sukanka/smithay，fix/multigpu-buffer-sync	7b776da

niri 的 Cargo.toml 使用本地路径 ../smithay 和 ../smithay/smithay-drm-extras 覆盖上游依赖，所以两个源码目录需要并排放置。Arch 上的打包配置也已经改为同时获取上述两个分支。

Smithay 的配套修改解决的是跨 GPU 缓冲区复用时的同步问题：目标 GPU 还在读取旧画面时，源 GPU 不能提前覆盖共享缓冲区。niri 也补充了客户端 DMA-BUF 的读取完成 fence，让客户端在合成器读完之前不会过早复用缓冲区。这些修改关系到画面正确性，不能把整个方案简化成只增加一个选卡参数。

已有的构建和回归测试记录中，AMD 780M → NVIDIA 4070 的双 GPU 缓冲区复用测试在 linear 和 native 两种布局下通过，测试报告的像素错误为 0；Smithay 的同步单元测试也通过。这些属于同步正确性验证，不等同于新方案的游戏帧率或长期稳定性测试。

最终配置与确认方式

最终配置保留 AMD 为主设备，并启用按输出设备合成：

debug {
    render-drm-device "/dev/dri/by-path/pci-0000:07:00.0-render"
    render-on-output-device
}

两个参数的作用不同：render-drm-device 选择主设备，作为全局默认的 DMA-BUF 反馈设备以及没有可用 render node 的输出的回退设备；render-on-output-device 决定每个输出实际使用哪块 GPU 合成。修改后需要注销并重新进入 niri 会话。

因此，新版本日志中的 using as the render node: "/dev/dri/renderD128" 只说明 AMD 是主设备，不能再据此判断 HDMI 外屏也在 AMD 上合成。还需要检查每个输出的合成设备：

journalctl -b _COMM=niri --no-pager |
  rg 'using as the render node|compositing each output|selected composition GPU for output'

实际会话日志中能看到以下关键信息：

using as the render node: "/dev/dri/renderD128"
compositing each output on its own GPU when available
selected composition GPU for output connector="eDP-1" render_node=renderD128 scanout_node=card1 primary_fallback=false
selected composition GPU for output connector="HDMI-A-1" render_node=renderD129 scanout_node=card0 primary_fallback=false

这才确认了内屏 AMD 合成、外屏 NVIDIA 合成。这里的日志还不能单独证明游戏是否进入 direct scanout。

应用选卡与仍然存在的跨 GPU 路径

render-on-output-device 控制合成器的渲染设备，不会强制所有日常应用永远使用核显，也不会强制应用随着窗口换屏切换 GPU。主设备为 AMD 时，全局默认反馈仍来自 AMD；分支还会给各输出上的窗口发送对应合成 GPU 的 DMA-BUF feedback，应用是否采用这份反馈、是否重新选择设备，取决于客户端实现。

游戏仍需单独确认使用 NVIDIA。需要通过 PRIME 启动时，可以在已有 Steam 启动参数中加入 prime-run，例如保留原生 Wayland、GameMode 和失焦处理的写法：

WAYLANDDRV_FOCUS_LOSS=0 PROTON_ENABLE_WAYLAND=1 prime-run gamemoderun %command%

这条命令用于指定游戏的 GPU，不是前面 45→75 FPS 对照中的新增测试条件。

应用和它所在输出使用同一块 GPU 时，可以避免因统一在主 GPU 合成而引入的跨卡显示路径。核显应用移到独显外屏、独显游戏移到核显内屏，或截图、录屏等场景，仍可能需要跨 GPU 访问或传输。因此，最终方案解决的是按输出分配合成工作，而不是消除所有跨 GPU 开销。

全屏满足条件时，仍可以通过 direct scanout 跳过合成；niri 默认启用主平面的直接扫描输出，但全屏并不保证生效。按输出设备合成的收益不要求游戏一定进入 direct scanout。

截至 2026 年 10 月 1 日，本机运行的 niri 已是 26.04 (1568e42)，上述配置和每输出设备的会话日志都已确认。前面约 45→75 FPS 的记录对应第一阶段统一使用独显合成；本文还没有补充最终配套版本在同条件下的平均 FPS、1% low 和显存占用对照，不把两阶段结果合并成同一组性能数据。

这次排查得到的结论

主渲染设备日志及调整后的帧率变化表明，niri 的 GPU 选择以及跨 GPU 显示路径是本例值得重点检查的因素，不能简单归因于“Proton 原生 Wayland 性能差”。

没有进行 GPU 跟踪，因此不能精确断言其中发生了几次复制、各自耗时多少；修复后也没有进一步确认外接屏是否进入直接扫描输出。接口属于独显，与合成器成功直接扫描输出，是两件不同的事。

对于双显卡笔记本，尤其是外接显示器接在独显上的情况，如果游戏已经使用独显，Wayland 性能却明显异常，值得同时检查：

• 游戏使用哪块 GPU。
• 合成器在这个输出上使用哪块 GPU；启用按输出合成时，不能只看主设备日志。
• 显示器接口实际属于哪块 GPU。

本例中，调整第二项后，在当时的 HDR 分支、游戏场景和 HDMI 外屏条件下，观察到帧率从约 45 FPS 提升到约 75 FPS。这支持合成器选卡及跨 GPU 显示路径是重要影响因素，但没有进一步测量具体传输开销。

统一由独显合成带来的显存和内屏跨卡问题，推动了后续的代码修改。最终编译了配套的 niri 和 Smithay，保持 AMD 为主设备并启用 render-on-output-device：内屏由 AMD 合成，HDMI 外屏由 NVIDIA 合成，游戏另行指定使用独显。每输出日志已经确认这一分工。

最新使用结果：采用这个最终方案后，RTX 4070 Laptop 在本游戏中使用 4K 输出、高画质，可以达到约 70 FPS。 这是后续实际游玩中的帧率观察，与前面中画质下约 45→75 FPS 的阶段性测试分开记录；最终方案的游戏帧时间与显存收益仍需补充同条件测量。

我也提供了自编译的 niri-hdr 下载，使用上述定制分支的最新提交构建，包含 render-on-output-device 及配套的 Smithay 修改。本文当前核对的 niri 提交为 1568e42；后续下载包更新后，可用 niri --version 确认所安装构建的实际提交。

参考：

• niri 的 render-drm-device 配置说明
• niri FAQ：双显卡笔记本外屏卡顿
• niri 的 overlay planes 与 direct scanout 说明
• 自定义 niri 的 render-on-output-device 说明
• 配套 Smithay 的多 GPU 缓冲区同步修复