Linux 7.3 Lands amdgpu Fixes to Keep Games Alive When VRAM Runs Out

A developer’s patches to improve VRAM management for the AMD graphics stack have been merged upstream and are queued for Linux 7.3. The work targets what happens when a game requests more video memory than the GPU physically has. In principle, overcommitting VRAM should only cost performance, not stability: when demand exceeds capacity, the driver evicts some allocations to system RAM, which the GPU then reaches over the PCIe bus. That path is far slower and higher-latency than local VRAM, and bandwidth sets a hard ceiling — a PCIe 4.0 x16 link moves under 32 GiB/s, so a GPU can pull at most about 1 GiB of evicted data per frame while still holding 30 FPS.

The nuance is that not all evicted memory hurts equally. Cache hits carry the same latency whether the underlying data lives in VRAM or system RAM, so allocations that are accessed in cache-friendly patterns, touched rarely, or only partially read can be pushed out to CPU memory with little visible impact. That makes real-world performance under overcommit hard to predict but often better than the conventional wisdom that running out of VRAM means guaranteed crashes and unplayable frame rates.

In practice, though, the bigger problem turned out to be stability rather than raw speed. Under memory pressure, RADV would fail with ‘Not enough memory for command submission,’ with the kernel returning -ENOMEM at submit time even though every buffer had already been allocated successfully. The root cause is on the kernel side: before each submission, amdgpu must ensure all memory the GPU might reference is accessible — a requirement made stricter by bindless APIs, where any allocation could be touched — and that validation logic broke down when VRAM was exhausted. The merged changes fix that failure path so overcommitting VRAM degrades gracefully instead of throwing hard errors.