Linux 7.3 improves performance when running out of vRAM
Linux kernel 7.3 introduces new VRAM management that greatly improves performance when GPUs run out of video memory, particularly for games and graphics-heavy workloads. Commenters contrast this with Windows and macOS behavior under memory pressure, debating overcommit, swap, and OOM killing, and noting that Linux often still freezes or randomly kills applications unless tuned with tools like earlyoom or systemd-oomd. The thread also highlights long‑standing issues with Nvidia’s Linux drivers versus AMD’s more seamless VRAM–system RAM fallback, as well as broader concerns about memory leaks, desktop responsiveness, and how different platforms prioritize stability versus flexibility.
Overall Reaction to the Kernel Work
- Article is praised as clear, detailed kernel engineering with useful tracing tools (e.g., gpuvis, DRM tracepoints).
- Many express excitement about Linux 7.2/7.3’s focus on gaming and GPU performance.
- Some highlight that good VRAM behavior is ultimately limited by hardware design (e.g., scanout using physical addresses only).
Gaming, VRAM Overcommit, and Asset Waste
- Big interest in how VRAM overcommit improvements help games that have many textures and often waste VRAM with oversize or unused assets.
- Commenters note real‑world examples of huge, unnecessary textures and games shipping with massive memory waste.
- Some wonder if the kernel could always reserve contiguous scanout regions or physically “defragment” VRAM by moving pages and updating page tables; feasibility remains unclear.
Compute / LLM and VRAM–Disk Ideas
- For LLM inference, most expect little benefit: workloads are more predictable and can manually manage GPU memory.
- Moving GPU data to NVMe as “VRAM swap” is discussed; best‑case is ~4× slower due to PCIe lane limits, so only niche use cases are plausible.
Linux vs Windows/macOS GPU and Desktop Experience
- Many celebrate rapid Linux kernel improvements; others point out regressions (e.g., reverted GPU scheduler) and distro‑specific breakage, especially on rolling distros.
- Windows is credited with more mature HDR/VRR and eGPU support; Linux is seen as catching up but not universally superior.
- Apple Silicon/macOS gets mixed reviews: good OOM UI and unified memory behavior for some, but others report persistent slowdowns after heavy ML/GPU usage.
VRAM Handling: NVIDIA vs AMD and Wayland
- Multiple reports that AMD GPUs on Linux seamlessly spill into system RAM when VRAM is full, while NVIDIA under Linux+Wayland historically crashed or refused allocations when VRAM exhausted.
- Long‑standing NVIDIA driver bugs on Wayland (e.g., memory leaks with KWin, lack of “shared VRAM”) are linked; many conclude AMD is currently the safer Linux choice, especially for Wayland and games.
OOM Behavior, Swap, and Tuning
- Large subthread on Linux freezing under RAM pressure vs Windows/macOS remaining sluggish but alive.
- Explanations center on Linux overcommit and heuristic OOM killing vs Windows’ stricter allocation model.
- Mitigations mentioned: swap/zswap/zram, MGLRU tuning, earlyoom/systemd‑oomd/nohang, overcommit settings.
- Opinions diverge sharply: some say “configured right, Linux is fine,” others call the default desktop OOM behavior a long‑standing, user‑hostile problem.
Miscellaneous
- Clarification that “VRAM” (not “vRAM”) is standard usage; “vRAM” suggests “virtual RAM.”
- Brief note appreciating contributions from underrepresented groups in low‑level performance engineering.