Linux VRAM Fix Triples FPS on 4GB AMD GPUs — Here's What Changed

A Problem That's Been Bugging Linux Gamers Forever

If you've ever gamed on Linux with a budget GPU, you probably know the feeling. Everything's running fine, and then — out of nowhere — the framerates tank. Stuttering kicks in. The game becomes unplayable. And the frustrating part? Your hardware didn't change. Your settings didn't change. Something just decided to swap your game's data out of fast video memory and into slower system RAM, and your experience paid the price.

That's not a bug in your specific setup. That's been a fundamental flaw in how Linux handles VRAM under memory pressure — and for years, nobody had a clean fix for it.

Until now.

The Root Cause: Linux Couldn't Tell Your Game Apart From a Browser Tab

Here's what's actually been going on under the hood. When a GPU's dedicated video memory fills up, the Linux kernel has to make a decision: what do I move out of VRAM? And the problem is, it has no way to prioritize. A running game, a browser tab, a desktop compositor — to the kernel, they all look the same. So it just starts evicting whatever it wants into slower system RAM, accessed over PCIe. The result is those nasty frame-time spikes and stuttering that feel completely random.

The fix, developed by a 21-year-old independent contractor on Valve's Linux graphics driver team, targets exactly this. The solution uses something called the dmem cgroup controller — co-developed with engineers from Intel and Red Hat — to give the system a way to label the foreground game as the highest-priority process for VRAM access.

Two companion utilities make this actually work in practice:

• dmemcg-booster — runs as a systemd service and enforces those VRAM priorities at the system level
• plasma-foreground-booster — integrates directly with KDE Plasma to automatically detect which window is in focus and adjust priorities on the fly

The goal, as described in the developer's own blog post, is that "instead of performance slowly degrading over time, games should perform much more stable — as long as the game itself doesn't use more VRAM than you actually have."

That last part matters. This isn't magic. It's smart prioritization.

The Real-World Numbers: A 4GB GPU Put to the Test

Testing was done on a Radeon RX 6500 XT — a 4GB card, which is exactly the kind of hardware that gets hurt most when VRAM management goes wrong — running CachyOS with the patches enabled.

The headline result came from Alan Wake II at 1080p, low settings, with FSR 2 set to Quality:

Going from 14 FPS to 41 FPS isn't a tweak. That's the difference between a slideshow and something actually playable. And that 192% jump is where the "nearly triples FPS" story comes from — it's not hype, it's just the math.

Resident Evil: Requiem showed a 16% boost in average FPS (67 to 78), with 1% lows jumping from 36 to 56 — which honestly might matter even more for feel, since low-1% stutters are what break immersion.

Silent Hill f was more modest, going from 47 to 50 FPS average. Not every game stresses VRAM the same way, so results will vary depending on how aggressively a title is trying to use that memory.

Who Benefits — and Who Doesn't (Yet)

Right now, the optimization is available on CachyOS using kernel version 7.0rc7-2 and above. Both utilities can be installed directly from CachyOS's package repositories, so if you're already on that distro, the barrier to trying this is pretty low.

The kernel patches have been submitted upstream for inclusion in the mainline Linux kernel, which means wider distribution is coming — it just takes time to work through the process.

A few important limitations to keep in mind:

• Discrete GPUs only. If you're on an APU — where the CPU and GPU share a unified memory pool — this fix doesn't apply to you. The whole approach depends on there being a separate VRAM pool to prioritize.
• AMD + RADV only, for now. The fix targets AMD GPUs running the open-source RADV Vulkan driver. Nvidia users on the proprietary driver are still waiting for support.

So if you're running a mid-range or budget AMD dGPU on Linux and you've been blaming yourself (or your hardware) for mysterious performance drops — it probably wasn't you.