显存用完时，很多玩家已经习惯了最坏结果：游戏崩溃、帧率骤降，甚至整个桌面都变得不稳定。但显存耗尽本身并不一定意味着系统只能“认输”。pixelcluster 的排查从一个简单问题开始：显存不足为什么会让应用承受如此剧烈的连锁反应？
几个月前，作者曾讨论过如何改进 Linux 上的游戏显存管理。如今，相关内核补丁已经合入 Linux 7.3。这个变化的价值不在于让有限的显存凭空变多，而在于让内核在资源耗尽时更有机会回收、等待和恢复，减少一次显存分配失败演变成游戏连续崩溃或内核死锁的概率。
显存耗尽为什么会变成系统级问题
从应用角度看，显存不足通常只是一次资源申请失败。游戏可能需要为纹理、着色器、帧缓冲或缓存分配 GPU 内存；当分配无法完成时，理想行为是返回错误，让应用降低画质、释放缓存，或者优雅地退出。
现实中的 GPU 内存管理往往更复杂。驱动和内核需要同时处理几类状态：
- GPU 内存中哪些对象仍在使用，哪些可以回收或迁移。
- CPU 与 GPU 之间是否还有未完成的工作。
- 某个内存对象是否正被另一个线程、进程或设备队列持有。
- 回收路径是否需要等待 GPU 完成，而等待过程又是否依赖新的内存分配。
最后一种情况尤其危险：内核为了释放显存而等待某个资源完成，但完成该资源所需的路径又被显存分配阻塞。这样的循环等待可能形成死锁。对游戏来说，表现出来的未必只是一个清晰的“显存不足”错误，而可能是卡死、窗口无响应、桌面卡顿，随后多个应用一起崩溃。
因此，这次修复的重点可以理解为改善资源耗尽状态下的内核控制流。它并不会改变显卡的物理容量，也不保证所有游戏都能在显存不足时继续运行；它解决的是“资源已经紧张时，内核是否还能保持可恢复性”这一层问题。
从一次失败分配追到内核死锁
排查这类问题不能只盯着游戏日志。应用日志往往只能告诉你某个纹理或缓冲区创建失败，而真正的阻塞点可能位于驱动、内核内存回收或 GPU fence 等待路径中。
一个实用的排查顺序是：
- 确认显存是否确实接近上限，而不是游戏自身的资源泄漏或 CPU 内存不足。
- 对照游戏卡死时间检查内核日志，寻找 GPU hang、allocation failure、lockdep 或 watchdog 相关信息。
- 观察问题是否只发生在高画质、高分辨率或大量切换场景时。
- 使用较新的内核和驱动复现，比较“游戏崩溃”和“系统整体失去响应”之间的差异。
- 检查是否存在多个进程同时使用 GPU，例如浏览器、录屏程序、桌面合成器和游戏启动器。
下面的脚本适合在 NVIDIA 环境中观察显存变化。它不会修复问题，但可以帮助把“感觉像显存不够”变成可比较的时间序列。运行前请确认系统安装了 nvidia-smi。
#!/usr/bin/env bash
interval="${1:-1}"
command -v nvidia-smi >/dev/null 2>&1 || {
printf 'nvidia-smi is required\n' >&2
exit 1
}
printf 'Watching GPU memory every %ss; press Ctrl-C to stop.\n' "$interval"
printf '%-8s %-12s %-12s %-12s\n' 'TIME' 'GPU' 'USED_MiB' 'TOTAL_MiB'
while :; do
nvidia-smi --query-gpu=index,memory.used,memory.total \
--format=csv,noheader,nounits | while IFS=',' read -r index used total; do
printf '%-8s %-12s %-12s %-12s\n' \
"$(date +%H:%M:%S)" \
"${index// /}" "${used// /}" "${total// /}"
done
sleep "$interval"
done
同时，可以在另一个终端记录内核消息：
sudo journalctl -kf -o short-precise | \
tee ~/gpu-kernel.log
复现问题后，重点对比显存达到上限的时间、游戏开始卡顿的时间，以及内核日志出现异常的时间。这个方法不能替代驱动级调试，但足以帮助区分“正常的应用级分配失败”和“内核回收路径被卡住”。
补丁的实际边界
Linux 7.3 中合入的改动，重要意义在于降低显存耗尽对系统稳定性的放大效应。对玩家来说，可能表现为以下几种变化：
- 某些场景下应用更可能收到资源不足错误，而不是长时间卡死。
- 内核有更好的机会完成内存回收或等待，避免进入死锁状态。
- 单个游戏的问题更不容易扩散为桌面环境或其他 GPU 应用一起失去响应。
但需要明确几个边界。
第一，补丁不会增加 VRAM 容量。如果游戏的最低资源需求超过显卡可用显存，降低纹理质量、分辨率、光照缓存或后台 GPU 应用仍然是有效手段。
第二，应用是否能优雅处理分配失败，取决于游戏引擎和图形 API 的错误处理。内核能够避免死锁，并不代表游戏一定会自动降级画质。
第三，驱动版本、GPU 厂商和图形栈都会影响结果。Linux 内核、Mesa、专有驱动、Wine、Proton 和游戏本身之间存在多个边界，单凭一次复现不能把问题全部归因于内核。
升级和验证时该看什么
如果你想验证这类改动是否改善了自己的环境，可以建立一个最小测试矩阵：
- 同一游戏、同一存档、同一画质设置。
- 使用旧内核与 Linux 7.3 或更高版本分别测试。
- 记录显存峰值、卡顿开始时间、应用退出方式和内核日志。
- 关闭浏览器硬件加速、录屏工具等额外 GPU 使用者，再重复一次。
升级内核前也要保留一个可启动的旧内核，并确认图形驱动与新内核兼容。测试时不要只看平均帧率；显存耗尽问题更应该关注是否出现无限卡顿、桌面无响应、GPU reset，以及应用能否恢复。
结语：把“显存不足”变成可处理的失败
显存耗尽无法被软件彻底消除，但可以被更好地管理。一个健壮的系统应该尽量把资源不足限制在一次可处理的分配失败中，而不是让它沿着回收、等待和锁依赖扩散成死锁。
这次内核补丁的价值，正是改善了这个最糟糕的边界状态。对开发者而言，仍应正确处理 GPU 内存分配失败；对用户而言，升级内核只是验证链路的一部分，驱动、游戏设置和后台 GPU 负载同样需要纳入排查。显存不够时游戏可能仍会降画质或退出，但系统至少更有机会保持可用，而不是一起被拖垮。