Non-existent shared VRAM on NVIDIA Linux drivers

Wait, wait… So, is this the reason why, when I play Split Fiction with a friend, it starts to stutter after about an hour!? The game initially uses 6-6.5 GB of VRAM, but after an hour, it maxes out my 8 GB, causing stuttering. The only way to fix it is by restarting the game…

My friend, who uses a Windows on a laptop and (I’m pretty sure) has no more than 8 GB of VRAM, doesn’t have this issue.
Ohh, I’m so happy that it’s finally time to upgrade my GPU - now I can happily switch to the red team! :P

It seems like memory allocations over the VRAM limit simply fail. This is a real problem because applications and games don’t expect it. Any other operating system (and literally any other GPU vendor) will start swapping to system memory.

The problem got even worse with Wayland becoming widely adopted in 2024. Now, even the desktop itself is kept in video memory. If VRAM allocations fail, the entire desktop becomes unresponsive or straight up crashes.

Please prioritise this.

VRAM allocations also seem to stutter the whole system: Allocating GPU memory seems to be a system-wide blocking operation · Issue #164 · NVIDIA/egl-wayland · GitHub. This may explain why games become unresponsive when GPU is out of VRAM.

So, it’s Nvidia that sell us GPUs with very limited VRAM, sometimes isn’t even enough to run their own programs, such as G-Assist where it requires at least 12GB but they still sell 8GB GPUs still in their last generation. Then it is NVIDIA again that doesn’t implement a good VRAM management in their drivers, for like, 2-3 years?

There are workarounds I can see, they limit DXVK’s VRAM, but games are slowly dropping DirectX 11 and moving to DirectX 12 and Vulkan. So we are going to use either VKD3D or native Vulkan, which doesn’t have such a custom VRAM option, and the fix must come from NVIDIA now.

absolutely wild that it’s been two years without a whisper from nvidia about this

2 years and this is still an issue even with 50* series. It is worse on wayland - because it’s VRAM-hungry

I forced to use iGPU from amd for desktop environment like KDE and my dGPU 5070 for games and workload. For 4k 12 gigs of vram is not enought, but without shared vram is literally unusable.

This is really a shame, you know.

This really does need fixing now, as workarounds are rapidly becoming impractical.

Utilising an iGPU for the main desktop and offloading only heavy rendering tasks to an NVIDIA GPU only works around this problem if the monitors in use aren’t sporting modern, UHD, VRR-capable panels benefiting from 10bpc color. Such screens are now a cheap commodity as of mid-2025 and businesses are already buying them in.

A modern dual-screen configuration will happily consume 2GB or more VRAM with just a desktop environment, web browser, office suite and instant messenger loaded.

Without shared VRAM support, NVIDIA cards will always be at a severe disadvantage when used on Linux, irrespective of whether the GPU is used for scientific workloads, professional 3D rendering or gaming. Given how rapidly Vulkan is catching up to CUDA for inferencing, and how rapidly rival companies are seizing the opportunity to deliver decent, responsive customer service, NVIDIA really should be prioritising this.

Absolutely, I reckon driver feature parity with Windows is a must, specially when something like this can bring forth a very noticeable usability decrease.

Shared VRAM is a fundamental feature for the performance and stability of the desktop experience on any computer.

I also posted about this problem here and got absolutely no response Driver support level for VRAM offload to system RAM.
I really don’t care about how this works with games or other Windows software since my problem is with AI applications that use torch, which in turn uses CUDA. But then any Windows emulation support is also probably going to run using CUDA.
So I think if you fix the CUDA problem, you fix anything.
This is a serious problem with AI software where you cannot run the larger AI models at all on consumer level GPU, even with two GPU, which is the practical limit for most consumer PCs.
If this can be solved for Windows then it seems to be solvable for Linux, and this has been a problem for over 2 years..
I look at this as a virtual storage management problem, i.e. on CPU, if you don’t have enough RAM the OS starts swapping to a swap file on disk. So here, you run out of VRAM you ‘swap’ to system RAM.
Even consumer level GPU has some level of support for this since if I write a CUDA program which has a bug with an out of range subscript, I get a crash because the card recognizes the address is not backed by VRAM.
With Linux, the OS catches a non-backed storage reference, realizes it needs to page swap and loads the missing memory page.
The GPU has the framework for this, it works on Windows, and should be able to work on Linux. It will slow down the application since memory traffic has to go across a slow PCI bus, but usually slow is better than crash.
It’s really irritating that this has not been fixed in 2 years. Part of the price of a card costing hundreds of dollars is to fund tech support. So it’s really annoying to pay for tech support and get nothing.
And no, AMD is not an option for me. AMD’s support for software development (ROCM, etc) has been abysmal, which is why I chose NVidia in the first place.

I’ve sent the information about the problem directly to: driverfeedback@nvidia.com and I’ve received following reply back:

|### NVIDIA Display Driver Feedback|00:50]

Thank you for your feedback. I have reached out to our Linux resource management team and shared your email with them.

I believe the more people sends their feedback directly to the aforementioned email - the higher is the chance that they will do something about it.

Send them your feedback, send them the links to this thread and other threads on the internet in which people have mentioned the same issue - so they know it’s a real problem for most of us.

Diablo IV out of memory issue got me here, even saw a post with someone having the same error with 128GB system ram and GTX 4090.

Talk about a rabbit hole. I’ve been reading up for a month now about this issue, changed all types of settings, opened up compiled files with Ghidra, USEFI (iommu) settings. Also found my way into amazing programmers website About Eric Lippert | Fabulous adventures in coding He had an article about memory.

Anyway — HEAP, memory eviction, resident memory, decommit heaps, soo many settings.

Reminds me of messing with hard drive format types again…“EF MAN, this was a 128 GB IDE HARD DRIVE! Why is it smaller!!!” Seems like, it’s using small sized 4KB heaps (textures etc?) for large VRAM sizes.
“0 means that the heap manager de-commits each 4 kilobytes (KB) page”

“A heap is the lowest level unit to manage physical memory”

It’s like the default? heap setting never (proportionally) grew with how much VRAM we have now … 5090 has 32 GB DDR7 “DISGUSTING … where do I sign up?” *as I hear a Bloomberg newcaster bring up Jensen - H20 export price change" lol.

Playing the game, there’s no way it’s using this much vram when I have it on super low settings…gotta be other noise hammering the memory?!? On Win10ltsc I could crank it up with no issues and multi stream. Must be some settings to optimize. Remember Unreal Tournament 3 ? The gfx looked amazing for running it on 9800gt I had at the time. It was optimized.

Got me to thinking about allocation (remember HD formatting?), incorrect ratio of data to reserved space. Think of boxes that waste some space filling a shelf, you can use smaller boxes to fill it more however it takes more time to stock it. VRAM = Operating Warehouse SystemRAM = storage warehouse next door, Data = box, Shelf = memory size/hard drive formatting. Sooo, use double the shelf size and use bigger boxes since you don’t need that small of granularity?

Also, it’s not cleaning up the VRAM? Big jumps every time I TP into town in the game.

Direct X, Vulkan, Open GL … I was reading all of them and looking for equivalent settings. I’m on Nobara using Lutris/WineGE.

I did made a dxvk.conf file and put it in the D4 exe folder and Battlenet.exe folder (throwing stuff anywhere at this point). I’m on GTX 1080, hence 8192.

dxgi.maxDeviceMemory=8192
dxgi.maxSharedMemory=8192

save that in the dxvk.conf.

GL Shader settings, added these arguments to lutris environment variables
DXVK_HUD: compiler
DXVK_STATE_CACHE_PATH: $GAMEDIR
STAGING_SHARED_MEMORY: 1
__GL_SHADER_DISK_CACHE: 1
__GL_SHADER_DISK_CACHE_PATH: $GAMEDIR
__GL_SHADER_DISK_CACHE_SKIP_CLEANUP: 1

For windows, There’s a shader cache setting (can’t remember where) that have helped some people according to forums. Also try deepseek, seriously helpful as an assistant like locating settings files.

(Bear with me, I have a folder with so many saved pages and notes all over the place, trying to find what to add next.)

Nvidia profile setting - HEAP REUSE RATIO is the key here. I don’t know the equivalent setting for DX but it should be similar…heaps man. I can lower 90% more if I still get OOM according to a forum, forgot its name.

{
“rules”: [
{
“pattern”: {
“feature”: “true”,
“matches”: “Diablo IV”
},
“profile”: “profile_d4”
}
],
“profiles”: [
{
“name”: “profile_d4”,
“settings”: [
{
“key”: “GLShowGraphicsOSD”,
“value”: true
},
{
“key”: “GLShaderDiskCache”,
“value”: true
},
{
“key”: “GLVidHeapReuseRatio”,
“value”: 90
},
{
“key”: “GLThreadedOptimizations”,
“value”: false
}]}]}

Pagefile settings (can modify it through wine settings).
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Video\ 0000 Which is the video card, hardwareinformation_memorysize … qwmemorysize is QuadWord for 64 bit. I modified the non qw (quadwordmemory) size larger, trying all types of settings at this point lol.

One section up, \Control\Session Manager

Here’s the decommit on Heaps HeapDeCommitFreeBlockThreshold I set (1024) 0x00000400
Heapsegmentcommit, totalfreethreshold all those might be settings that help.

Subsystems under Session Manager - a suggestion from a forum

"For 64-bit operating systems, increase the yyyy value to “20480”;
Increase the zzzz value to “1024”.
"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems registry subkey. The SharedSection parameter string is located in the Windows registry value and uses the following format to specify heap size:
SharedSection=xxxx,yyyy,zzzz
Where:
xxxx specifies the maximum size of the system-wide heap (in kilobytes)
yyyy specifies the size of each desktop heap
zzzz specifies the size of the desktop heap that is associated with a noninteractive Windows instance

"By default, the HeapDeCommitFreeBlockThreshold registry key value is 0. A value of 0 means that the heap manager de-commits each 4 kilobytes (KB) page that becomes available. De-commit operations can cause virtual memory fragmentation. "
Under Session Manager again headdecommitfreeblockthreshold. Article is about biztalk but it’s a system setting they change.

“To help reduce virtual memory fragmentation, you can increase the size of the HeapDeCommitFreeBlockThreshold setting in the heap manager by changing the value of the following registry key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager:
Value name: HeapDeCommitFreeBlockThreshold
Value type: REG_DWORD
Value data: 0x00040000 (It is the recommended starting value.)
Value default: not present”

Info: D3D12 Residency

“GPUs do not yet support page-faulting, so applications must commit data into physical memory while the GPU could access it. This process is known as “making something resident”, and must be done for both physical system memory and physical discrete video memory.”

“While it is true that kernel can shift some heaps on discrete adapters from video memory to system memory, it does so only as an extreme last resort.”

GSP firmware (GPU System Processor - takes some of the cpu work for itsself. Disabling helped some

nvreg_enablegpufirmware=0

Those microsoft links have Direct X information. I have more to post but I’ll get a brew for now, I’ll post the rest of settings I changed. I had a previous draft, I ended up rage quitting not getting anywhere and discarded it lol

Critical Section Timeout is a really good read, hopefully it might lead someone to the fix. His change made a significant improvement.

You can find it in localmachine/system/currentcontrolset/sessionmanager CriticalSectionTimeout

"Also, creating/destroying such critical sections is not zero time-consuming. Allocating/freeing memory on the heap takes some time, plus it needs additional synchronization.

This impact is insignificant for applications that work with some constant set of critical sections, but in some cases, you need to create/destroy them on-the-fly. That’s where we have a performance hit."

This happens to me when playing Stellar Blade, I don’t have any crashing but under Wayland I will have various background windows stop repainting, forcing me to restart them.

It’s now been several months since I can’t play many games on Linux because of VRAM exhaustion. The symptom is always the same: Start a game witn Mangohud open, watch it play perfectly until VRAM reaches the total amount, and once it does, frame rates go into single digits and never recover. In Mangohud, the render time graph goes from a flat line at the bottom to a spiky mess. Even freeing up VRAM by closing other applications does little to restore the game back to the normal graph once this happens. No amount of fiddling with settings mentioned in this thread have any effect.

I can’t recall the exact driver version where this all started, but it’s around 560 or so.

Can this PLEASE get some attention or acknowledgement?

Thanks

I’ve been able to play via setting my default GPU to the iGPU in plasma.

~/.config/plasma-workspace/env/auto_kwin_drm.sh

#!/bin/bash

nvidia_has_outputs=$(grep -l "^connected" /sys/class/drm/card?-*/status)

if [[ "$nvidia_has_outputs" == *"card1"* ]]; then
# Set igpu as primary renderer when it has at least one output connected
    export KWIN_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0
else
# otherwise, set dgpu as primary renderer
    export KWIN_DRM_DEVICES=/dev/dri/card0:/dev/dri/card1
fi

Courtesy of someone on reddit (made changes to match my card and not disable the dGPU since it seems their use case was for a laptop).

Now everything except games run on the iGPU for me, allowing me to not cap out my VRAM, I allocated 8GB of RAM to the iGPU in bios which isn’t a problem for me but I could see it being an issue for others. This is a very serious problem with games pushing VRAM more and more. When playing Stellar Blade I’m sitting at 13GiB utilization, and that’s only the game.

Don’t hold your breath. They just don’t care. I moved back to Windows for this reason.

I DID

I should mention that this is a very poor solution because it seems this causes significant latency due to copying the frame from the dGPU to the iGPU and then back to the dGPU before it’s displayed to you, unless you plug all your monitors into the iGPU that is.

Having the same issue with drivers 575.64 and a RTX 3070

[nix-shell:~]$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 8192 MB
    Currently available dedicated video memory: 6898 MB

Any wayland based DE or WM crashes when VRAM is exhausted. Games run poorly and LLM models crash.

Adding myself to the pile.
Hopefully they’ll fix it before the RTX2000 series starts getting deprecated. Please let us know if this issue has been acknowledged, is being worked on, etc… Anything… It’s been two years since OP original post… Let me know if there’s some useful information I can share, need some guinea pig to run test, etc.

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 8192 MB
    Currently available dedicated video memory: 7082 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 575.64.03
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

Bumping this thread yet again after following it for about a month.

Why is there no official response on when this is getting fixed after being an issue for so long? Is this being fixed?

Luckily I’m using a RTX 4070 12GB card, so gaming has only rarely brought about stuttering for poorly optimized games that was fixed with a restart - however as other people have mentioned this introduces some really unacceptable issues when running LLMs or image generation models, and if not careful can freeze distributions using Wayland.

It’s really looking like NVIDIA has no intention of fixing this. If that’s true, I’m sure AMD cards will prove more use for any of my future purchases, at least their cards from what I’ve read support the feature perfectly fine in linux…

Can we please get some real progress soon? even some indication that this may be fixed some point sooner rather than later?