Natalie Vock、Valve 和 Linux 系统中的 8GB 显存革命

如果你在 Linux 电脑上玩游戏，并且显卡显存只有8GB 或更低，那么你很可能在玩最新游戏时遇到过卡顿、微卡顿和帧率下降的问题。令人惊讶的是，这种糟糕的游戏体验通常并非源于显卡本身的性能不足，而是系统在处理高负载任务时对显存的管理方式造成的。

这一切都因Valve图形驱动团队工程师Natalie Vock的工作而发生了重大转变。Vock专攻RADV（AMD GPU的Vulkan驱动程序）。她为Linux内核、KDE ​​Plasma和Gamescope生态系统开发了一系列补丁，彻底改变了系统在显存空间不足时决定哪些数据保留在显存中、哪些数据释放到系统内存的方式。

Linux 系统中配备 8GB 显存的 GPU 存在问题

近年来，显存容量已成为一个不容忽视的瓶颈。现代游戏加载海量纹理、复杂几何图形和高级特效，这些都会消耗大量的显存。对于中端显卡而言，8GB 或更低的显存容量非常常见，因此即使稍微提高游戏设置，也很容易导致显卡显存被占满。

在Linux系统中，当显存（VRAM）接近饱和时，图形转换表（GTT）就会发挥作用。简单来说，系统会将GPU的部分数据转移到计算机的内存（RAM）中，以防止系统崩溃。问题在于，尽管内存速度很快，但仍然远低于显存，这种延迟会导致画面卡顿、帧率波动，以及游戏体验不佳。

此前，Linux 内核缺乏一种真正完善的方法来判断哪些数据应该保留在显存 (VRAM) 中，哪些数据可以发送到内存 (RAM) 而不会引发严重问题。系统无法正确区分进程是全屏游戏还是后台运行的浏览器。在许多情况下，游戏本身最终会被部分从显存中释放出来，而不太重要的桌面应用程序却继续占用显存。

这一切导致玩家体验远非理想：即使配备 8GB 显存的显卡，在Steam Play上的《赛博朋克 2077》这类对显存要求较高的游戏中，系统也仅使用了不到 6GB 的显存，而超过 1,3GB 的显存却被分配给了内存中的 GTT（全局线程传输）——这完全不合理。简而言之：明明有充足的显存可用，游戏运行却依然卡顿。

对用户而言，实际后果显而易见：最低帧率不稳定，加载新区域时出现卡顿，转动镜头或进入不同区域时出现轻微冻结，以及一种“显卡勉强够用”的普遍感觉，而实际上瓶颈在于内存管理调校不佳。

Valve 和 Natalie Vock 的提议：优先使用显存运行游戏

为了从根本上解决这个问题，Vock 设计了一种结合内核修改和用户空间工具的方案。其核心思想虽然简单易懂，但背后却蕴含着大量的工程技术：明确地告诉 Linux哪个应用程序处于前台，应该在显存中拥有绝对优先级。

该提案的核心技术方面包括对设备内存管理 (DRM) cgroup 控制器的补丁，以及对内核转换表映射 (TTM) 内存管理子系统的一系列重大修改。TTM 负责确定图形设备中内存的分配和释放方式，因此是向系统传授新思维方式的理想场所。

这些补丁允许内核识别与前台游戏关联的内存池，并将其视为 VIP（显存优先级）。当显存已满需要释放时，系统会首先检查桌面进程、浏览器、媒体播放器或后台运行的实用程序，最后才考虑释放游戏的关键内容。

简单来说：从现在开始，如果您在玩游戏时打开了多个窗口，显存（VRAM）将优先分配给游戏。只有在绝对必要时，Linux 才会动用当前游戏的资源，从而大大降低因错误退出窗口而导致卡顿的可能性。

这一改变背后与 Linux 的cgroups功能紧密集成，systemd 已经利用 cgroups 机制来隔离和控制应用程序资源。Vock 利用该系统，创建了一种按进程组对 GPU 内存进行分类和保护的方法，使内核能够始终了解哪些资源需要保留，哪些资源可以牺牲。

dmemcg-booster：新型设备内存控制的核心

用户空间中的关键组件称为dmemcg-booster。它是一个 systemd 服务，负责协调如何将设备内存控制组 (DMEM cgroup) 的限制和优先级应用于使用 GPU 的应用程序。

它的主要功能是明确地告诉系统在任何给定时间应该保护哪个程序占用显存 (VRAM)。当您启动一个游戏并将其设为主窗口时，dmemcg-booster 会将其标记为 cgroup 中的优先进程，以便内核知道这部分显存不能被轻易访问。

如果没有这种机制，内核会将所有显存使用情况视为几乎相同，从而导致“盲目”的进程驱逐。运行 dmemcg-booster 后，如果内存已满需要释放空间，则首先被驱逐的进程将是辅助进程：桌面、浏览器或未处于活动状态的应用程序。

这种优先级设置并不会神奇地降低游戏对显存（VRAM）的使用量，但它确实能最大限度地利用每一兆字节的可用空间。这样一来，之前由于内存管理问题而性能不足的GPU，现在可以更接近其真正的潜力。

Vock 使用 Steam Play 在 8GB 显卡上运行《赛博朋克 2077》的测试结果显示，变化非常显著：在更新补丁之前，游戏仅使用了 6GB 的显存，约有 1,37GB 溢出到内存中的 GTT（全局线程传输）部分。启用新的内存架构后，游戏实际使用的显存约为 7,4GB，而 GTT 的使用量则降至约 650MB，这意味着 GTT 的使用量减少了一半以上。

等离子体前景增强器及与 KDE 等离子体的协调

要使整个优先级系统顺利运行，仅仅修改内核是不够的；桌面环境还需要告诉系统哪个窗口实际处于前台。这就是 Valve 开发的第二个组件plasma-foreground-booster 的作用所在。

该模块旨在与KDE Plasma集成，并充当桌面和设备内存 cgroups 机制之间的桥梁。它的任务简单却至关重要：实时报告哪个窗口处于活动状态（通常是您的全屏游戏），以便系统可以动态调整显存优先级。

当您切换应用程序或按下 Alt+Tab 切换到其他窗口时，plasma-foreground-booster 会更新发送给内核和 dmemcg-booster 的信息，因此您可以根据需要更改显存的优先级。这是桌面和内核之间以前从未实现过的协同工作。

除了 KDE Plasma 之外，Valve 也考虑到了其他桌面环境的用户。对于这些用户，解决方案是利用最新版本的 Gamescope，Gamescope 是 Valve 著名的微型编辑器，广泛应用于 Steam Deck 和游戏环境。Gamescope 可以执行与 Plasma 类似的功能：识别游戏窗口并为其分配资源优先级，或者在某些工作流程中使用Bottles等工具来管理兼容性会话。

其基本理念是构建一个从内核到桌面的协调生态系统，使整个系统与用户真正想要的东西保持一致：即使后台运行着其他程序，也要让用户面前的游戏尽可能流畅地运行。

在《赛博朋克2077》等游戏中取得的实际效果

抛开理论不谈，重要的是这一切如何转化为日常游戏体验。在Vock公开展示的案例中，最具代表性的例子之一是在8GB显卡上运行Steam Play上的《赛博朋克2077》 。

在补丁发布前的状态下，游戏运行的显存占用率从理论上看似乎可以接受，但实际上远未达到充分利用所有可用内存的水平：GPU 仅占用约 6GB，而 1,37GB 则“溢出”到图形线程终端 (GTT) 中。这种持续的溢出意味着相当一部分图形数据实际上存在于系统内存中，迫使 GPU 通过 GTT 访问这些数据，从而导致响应时间出现峰值。

随着新架构的实施，游戏格局发生了显著变化。《赛博朋克2077》现在几乎利用了所有可用的显存（约7,4GB），而全局线程（GTT）的使用量则降至约650MB。更少的内存释放意味着更少的低速内存访问，从而带来更加稳定的游戏体验。

需要强调的是，这些补丁并非着重于提升最高帧率（也就是你盯着墙看时看到的那个数字），而是致力于改善最低帧率和帧时间稳定性。换句话说，它们减少了卡顿，平滑了帧率波动，提升了整体流畅度，这才是玩家在夜之城或其他高负载开放世界中移动时真正能感受到的。

实际上，这种优势在显存已接近极限的系统中尤为明显：例如，使用8GB或更小显存的显卡运行现代3A游戏，同时运行多个程序。正是在这些“勉强运行”的情况下，合理管理显卡的弹出和优先级，可以延长显卡的使用寿命，使其再延长几代。

发行版、兼容性和当前补丁状态

在细节公布之时，测试这种新内存架构最简单的方法是使用CachyOS，该发行版走在了其他发行版的前面，并且默认情况下将这些补丁集成到内核和用户空间组件中。

对于其他发行版，虽然需要一定的专业知识，但也可以自行编译打过补丁的内核以及 dmemcg-booster 和 plasma-foreground-booster 软件包。Vock 及其生态系统的目标是，随着时间的推移，所有这些改进都将整合到上游的官方 Linux 内核以及 KDE 和 Valve 的正式软件仓库中，以便 Ubuntu、Fedora、Arch 和其他发行版的用户无需进行任何特殊修改即可受益。此外，对于需要兼容层的用户，还有Wine等其他选择。

这里有一个重要的区别：这些更改主要针对使用开源驱动程序和 RADV 协议栈的 AMD GPU。原因很简单：NVIDIA 的内存管理严重依赖于专有的闭源驱动程序，这极大地限制了内核和开放用户空间可以进行的操作。而对于 AMD 来说，使用开源驱动程序可以更好地调整内核、DRM、TTM 和图形驱动程序之间的交互。

关于时间表，一些发行版已经在着手在短期和中期内整合这些改进。随着支持DMEM cgroup 驱动程序和 TTM 补丁的内核在稳定版本中得到更广泛的应用，未来将会有更多发行版能够“开箱即用”地为游戏提供 VRAM 优先级设置。

对于使用 KDE Plasma 以外的桌面系统的用户来说，最合乎逻辑的做法是利用最新版本的Gamescope，因为 Valve 正在将其打造为管理游戏会话的标准工具，尤其是在 Steam Deck 等硬件或该公司未来可能推出的机器上。

对游戏体验和硬件寿命的影响

所有这些工作的直接成果是，数百万拥有 8GB 显存显卡的玩家无需大幅降低画面设置或立即升级硬件，就能继续挖掘显卡的潜力。Vock 和 Valve 的方法强调软件效率和智能资源分配，在一定程度上弥补了芯片及其显存的物理限制。

与其坐等显存被占满，系统随机决定释放哪些数据，现在有了明确的策略：前台游戏的数据最后才从显存中释放。这意味着即使纹理繁多、环境复杂，游戏引擎也更有可能将关键数据保存在GPU的高速内存中，从而最大限度地减少崩溃。

对于普通用户来说，这意味着非常实际的好处：您可以继续使用桌面电脑，打开浏览器并加载多个标签页，使用音乐播放器或聊天应用程序，因为您知道，当关键时刻到来时，首先被牺牲的是这些应用程序（而不是您的游戏）的显存。

从更广阔的视角来看，Vock 的工作也进一步印证了Valve 对 Linux 游戏领域的重视。这不仅仅体现在发布 Steam Deck 或配备 8GB GDDR6 共享显存的 Steam Machine 等游戏主机上；他们还投入资源来改进整个生态系统：内核、驱动程序、桌面环境以及 GameScope 等工具。

对于那些关注复杂游戏中延迟、帧时间和稳定性的用户来说，这些补丁恰好提供了他们所需要的：上下文感知踢出管理，它可以理解什么是全屏游戏，什么是桌面上的背景噪音。

简而言之，由 Natalie Vock 主导的全新基础设施代表着 Linux 在资源受限系统上处理显存方式的一次重大飞跃。通过结合设备内存 cgroup、TTM 子系统的补丁、dmemcg-booster 服务以及与 KDE Plasma 和 Gamescope 的集成，该系统终于真正为玩家服务，而非反之。对于任何在 Linux 系统上使用 8GB 或更低显存 GPU 玩游戏的用户来说，这是一项悄无声息的改进，一旦体验过，便会无比怀念。