Linux 7.3要合并一批显存管理补丁的消息传出后,不少AMD+Linux玩家松了口气——这批补丁在邮件列表里飘了大半年,总算要落地。写补丁的博主趁热打铁,发了一篇长文解释显存溢出到底为什么这么伤性能,细到PCIe带宽和缓存命中率的物理账。
但认真拆开看会发现,这次真正合并、真正见效的东西,和大多数玩家以为被修好的问题,不是同一件事。
修的是"抢座位",不是"床位不够"
显存不够用,其实有两种完全不同的情形。一种是前台游戏和后台程序抢显存:浏览器、Discord、桌面合成器占着一块显存不放,游戏被挤到系统内存里去。另一种是游戏本身的工作集就超过了物理显存,不管有没有别的程序抢,该显示的东西本身就装不下。
7.3合并的dmem cgroup方案,解决的是第一种。它给前台游戏更高的显存优先级,让内核在分配时先照顾正在玩的那个进程。此前在8GB显卡上用《赛博朋克2077》做的实测里,游戏被挤到系统内存(GTT)的占用量,从大约1.6GB降到了游戏本身预期的650MB左右——基本把"误伤"式驱逐消除掉了。
这是一次扎实的改进,但它治的是排队秩序,不是床位数量。真正的物理天花板还在那儿:PCIe 4.0 x16大约32GiB/s的带宽,换算到30帧的帧预算里,单帧能从系统内存里多读的数据上限也就1GiB左右。缓存命中率好不好、访问模式聪不聪明,决定了溢出显存到底有多痛,但决定不了显存到底够不够用。
真正的超载,还在拿命填坑
床位不够那件事,现在什么状态?原文里那个"命令提交时报-ENOMEM"的崩溃,根源在内核的TTM显存管理层没接入一套叫drm_exec的死锁重试机制。显存压力大到极限时,驱逐操作互相死锁,内核选择直接报错退出,而不是像其他子系统那样自动重试。
修这个的补丁2024年就发过,一直没进主线。作者重新提交了带修复的版本,但按其说法,离合并还需要更多工作。就算解决了崩溃,性能测出来的结果也不体面:前台游戏和后台程序会不停把同一块内存来回搬,evict了又立刻搬回来,再被踢出去——这种来回搬运造成的开销,比干脆不驱逐还要慢。
更现实的问题是,dmem cgroup这套优先级方案只在AMDGPU内核里实现,NVIDIA的专有驱动和开源内核模块都没接入对应机制。而NVIDIA Linux恰恰是社区里报告显存问题最狼狈的一群:有玩家在高分辨率下反映12GB显存很快占满,出现严重卡顿甚至分配失败,同一块显卡换到Windows虚拟机、或者换成性能更弱的AMD显卡都没复现这个问题。NVIDIA论坛上也长期有关于某几个驱动版本区间可能存在显存分配回归的讨论,官方在自己的测试机上没能复现,说明这更像是游戏、合成器、分辨率、驱动分支叠加出来的特定组合,不是一个普适bug——但对当事玩家来说,这依然是玩不下去。
Windows早就交了这份作业
Windows的WDDM显存管理器,长期在操作系统层面做显存预算、驱逐、恢复的整套机制。超预算时,Windows的典型表现是掉帧,不是崩溃或黑屏。微软和NVIDIA自己的官方文档都承认过,Linux缺一个对等的系统级显存换页机制。
补的是排队规则,不是床位不够这件事本身
7.3这次合并,更像是Linux在补一门Windows十几年前就交了的作业,而不是反超。DXVK 2.7新增了更激进的显存预算强制和驱逐机制,本该帮到显存吃紧的Unity游戏,但在AMD上因为内核驱动那套还没接好的死锁/驱逐问题,没能按预期跑起来——这两件事其实是同一根链条上的两个环节。
- 风险.如果你在AMD+Linux上等着靠这次合并"治好"真正的超载卡顿,等来的只会是排队更公平,不是显卡装得下更多东西。
卡顿不一定是显存的锅
玩家碰到疑似显存溢出的卡顿,不一定真是显存不够。此前一个案例是Linux 7.2预发布版本里的一次AMDGPU回归:RX 7900 XTX上移动镜头时帧率从约90帧掉到3-4帧,最后定位到虚拟内存状态变更让每次稀疏绑定要处理的SDMA任务数从大约2个暴增到275个,跟显存耗尽完全无关,但症状和真超载几乎一模一样。
碰到类似卡顿,先看是不是刚更新过内核、驱动或DXVK之后才出现,再看显存占用是不是真的顶格,别急着怪显存不够就去换显卡。
- 建议.8-12GB档AMD显卡+新内核的组合,值得关注前台优先级修复带来的实际改善;NVIDIA Linux用户目前只能靠预留更大显存余量或用Gamescope之类工具间接缓解,短期看不到对等修复的路线图。
这次合并值得记一笔,但别把它读成"显存溢出问题解决了"。真正让人为难的超载场景,作者自己都还在跟内核死锁死磕,而NVIDIA Linux玩家这一轮压根没上车。