Linux 7.3: Optimizing Performance During VRAM Exhaustion

VRAM Management Part 2: Beyond the Limits of Physical VRAM Originally published by pixelcluster's GPU blog on August 17, 2026

Earlier this year, I detailed my efforts to refine how VRAM is managed during gaming. After several months of discussion and iteration across various mailing lists, those kernel patches have officially been merged and are slated for the Linux 7.3 release!

To mark this milestone, I want to expand upon a specific claim from my last entry:

"[Games] should perform much more stable - as long as the game itself doesn’t use more VRAM than you actually have."

This naturally leads to a critical question: What happens when a game actually exceeds your physical VRAM capacity?

The Common Misconception

Many users assume that hitting the VRAM ceiling means you are completely screwed. The typical expectation is a cascade of failures:

• Frequent application crashes.
• Performance dropping to unplayable levels.
• A total collapse of the gaming experience.

The real challenge is: How do we minimize the "suck" factor when this happens?

Establishing the Baseline

In a perfect world, exceeding VRAM should be a performance degradation issue, not a stability failure.

GPU drivers have long supported "overcommitting" VRAM. Essentially, if a driver allows overcommitment, you can request more memory than physically exists; the kernel driver simply fits as much as possible into the physical VRAM and handles the rest.

The Performance Bottleneck

The reason performance tanks during overcommitment is straightforward: when physical VRAM is full, the driver must evict some data to the system's CPU RAM.

For the GPU, accessing CPU RAM is significantly slower because:

1. CPU RAM is inherently slower than dedicated GDDR.
2. All data must travel across the PCIe bus.

The PCIe bus introduces latency and acts as the primary bandwidth bottleneck.

The Hard Math of Bandwidth

Let's look at the theoretical limits using $\LaTeX$ to calculate the impact. If we assume a GPU is utilizing a PCIe 4.0x16 connection:

$\text{Total Bandwidth} \approx 32 \text{ GiB/s}$ $\text{Data per millisecond} = \frac{32.2 \text{ MiB}}{1 \text{ ms}}$

To maintain a minimum of 30 FPS, a frame must be rendered every $33.3\text{ms}$. Therefore, the maximum amount of data the GPU can fetch from CPU RAM per frame is:

$32.2 \text{ MiB/ms} \times 33.3 \text{ ms} \approx 1,075.5 \text{ MiB}$

The Bottom Line: If the GPU needs to fetch more than $\approx 1\text{GiB}$ of evicted data in a single frame, hitting 30 FPS becomes mathematically impossible.

Why Some Accesses Are "Cheap"

Interestingly, not all CPU RAM access is catastrophic. Drivers often place command buffer data in CPU RAM even when VRAM is available, and games still run smoothly. Why the difference?

The Role of Caching

Caching is the great equalizer. If there is a cache hit, the latency is identical regardless of whether the backing store is CPU or GPU memory. The high cost of the initial PCIe fetch is "amortized" over subsequent hits.

To analyze this, I ran microbenchmarks on RDNA3 hardware using adversarial patterns to bypass caches.

// Conceptual microbenchmark for latency testing
for (int i = 0; i < buffer_size; i += stride) {
    float val = read_memory(buffer[i]); 
    // stride is chosen to maximize L2 cache misses
}

The results are summarized below:

Key Observation: On RDNA3, VRAM accesses utilize the Infinity Cache, but CPU RAM accesses bypass it entirely, hitting the PCIe bus directly upon an L2 miss.

Latency Multipliers

The penalty for missing the cache and going to CPU RAM is severe:

• PCIe fetch vs. Infinity Cache hit: $\approx 7.3\times$ latency.
• PCIe fetch vs. VRAM fetch: $\approx 4.6\times$ latency.

Conclusion: The Nuance of Eviction

Because of these factors, the impact of VRAM eviction is not uniform. Performance depends on:

• Cache Friendliness: Memory accessed in patterns that favor the cache feels less of a hit.
• Access Frequency: Rarely accessed memory can be evicted with minimal impact.
• Allocation vs. Usage: A game might allocate $2\text{GiB}$ but only actually read $100\text{MiB}$ per frame.

Consequently, predicting exactly how performance will behave when running out of VRAM is surprisingly complex.