Your ai generated report forgot to include how the vram usage is looking like when it's running slow. It's probably severely oversubscribing vram.

Your ai generated report forgot to include how the vram usage is looking like when it's running slow. It's probably severely oversubscribing vram.

Well it's my first time with reporting. I just created the account to report the issues😅. I don't think it could be vram coz the game works fine on windows with my gtx 1650.

I've noticed this problem with only 2 games tlou2 and spiderman 2. Both sony games. Although uncharted 4 worked fine.

I was using gpt to fix it and says it's probably a vkd3d/dx12 issue.

Almost guaranteed to be a VRAM issue, this is expected to happen when the driver shuffles around large memory allocations between VRAM and system memory. Your GPU is barely above min spec for this game to begin with.

You guys maybe right about the vram issue. But i have a question. I've tried these games on windows with the same gpu and it works perfectly fine. With linux only on these games i get 1 fps. I expected some performance drop but not anything like this. Why does this happen and what do i need to do?

There isn't much you can do besides lowering settings and closing all background applications that potentially use vram, but even then windows will handle being vram constrained better on all gpu vendors. 4GB is most likely just not enough for that game on linux no matter what you do.

Nvidia does not support VRAM offload to system RAM on Linux. So getting 1 fps in this situation is kinda expected…

https://forums.developer.nvidia.com/t/non-existent-shared-vram-on-nvidia-linux-drivers/260304

If nvidia couldn't offload anything to system ram games would crash as soon as you run out of vram and not run slow. It's also not a nvidia exclusive problem, performance also collapses on AMD linux and never recovers as soon as anything important gets spilled to system ram.

If nvidia couldn't offload anything to system ram games would crash as soon as you run out of vram and not run slow. It's also not a nvidia exclusive problem, performance also collapses on AMD linux and never recovers as soon as anything important gets spilled to system ram.

There is "some" sort of offloading to host mem, but it does not work that well when running wine/proton... So, depending on app, you will not crash directly when out of vram like one expects. Another part is that even freeing up "real" vram does not seem to make the system recover from this slowdown.

If you compare it to windows there is 2 differences:

1. Windows handles shared mem quite differently and a lot better than the linux driver (on a OS level).
2. Remember you have some overhead from vkd3d/vulkan that you do NOT have when playing the same game in windows.

Linux also does not have any really good apps to show how much vram <-> host mem is actually used.. nvtop does not show this accurately, so it is not really to be trusted. The vram/hostmem i think is not "just" a nvidia issue, as it is more of a os level issue.

PS. Sure there might be some clever way to determine this by digging through /dev /proc /whatever.. but the facts are what they are: If you spend 101%+ of vram you are bound for trouble 😄

Following up on this: doitsujin got it right above — almost guaranteed to be a VRAM issue — and Kurobac pointed at the system-RAM angle. Below is the confirmation, the exact mechanism, and a workaround that works. Measurements are from a different card (RTX 2060, 6 GB, CachyOS, 615.71.09, Proton Experimental, same title), so treat the absolute numbers as card-specific.

The budget. With VKD3D_CONFIG=log_memory_budget:

Memory heap #0 [DEVICE_LOCAL] size 6144 MiB budget 5134 MiB usage 5133 MiB

Usable budget is 5134 MiB, not 6144 — the driver reserves about 1 GB — and the game sits at 5133 MiB, i.e. 1 MiB free, touching the ceiling several hundred times per session. This is why lowering settings doesn't help: it is pinned at the ceiling regardless of what the settings say.

The mechanism. Kurobac's point about system RAM is exactly what happens, and the kernel log shows where. It fills with:

ERROR [nvidia-drm] Failed to allocate NVKMS video memory for GEM object

sometimes preceded by trying to fall back to sysmem. nvidia-drm cannot allocate display memory for new surfaces, so frames get copied through the CPU. A tell-tale symptom is that audio plays at normal speed while video lags far behind — audio needs no VRAM, video does. Cinematics are worst because they ignore the user's quality settings and render at maximum, which is consistent with what faizzoy described.

Workaround on 6 GB: skip the descriptor heap, lower the internal resolution instead.

launch options: leave empty
Display resolution: 1600x900 (1280x720 also works)

That gives ~50 FPS in gameplay, 60+ in cinematics, ~690 MiB of VRAM headroom, no stalling, and no VKD3D_CONFIG at all.

Why not just enable the descriptor heap, since that is the natural fix for VRAM pressure on a small card? Because on 610/615 it corrupts geometry: skinned character hair and cloth render with vertices teleported to wrong positions (severe stretching and spikes). That is a separate, reproducible NVIDIA driver bug, detailed in #2914. So on 6 GB you currently have to choose between fitting in VRAM and rendering correctly.

Also matches doitsujin's expectation — this is not DXR-related either, VKD3D_CONFIG=dxr=none made no difference in my testing.

Happy to provide the nvidia-bug-report or full Proton log if that would help.