Reproduced it with this hardware / software combo:

Kernel: 6.19.10-1-cachyos-bore
CPU: AMD Ryzen 7 9800X3D @ 5.4 GHz
GPU: GeForce RTX 5090 - nvidia (open source) 595.58.03
Proton: proton-cachyos-10.0-20260321

Steam launch options:
=> LD_PRELOAD="" PROTON_VKD3D_HEAP=1 NVPRESENT_ENABLE_SMOOTH_MOTION=1 MANGOHUD=1 game-performance %command% => GAME LAUNCHES,
=> LD_PRELOAD="" PROTON_VKD3D_HEAP=1 MANGOHUD=1 game-performance %command% => GAME LAUNCHES,
=> LD_PRELOAD="" MANGOHUD=1 game-performance %command% => GAME DOES NOT LAUNCHES

I can provide logs if required.

Thanks, it resolved my Xid 109 CTX SWITCH TIMEOUT issue on The Last of Us part II as well

Operating System: Bazzite 43
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
Kernel Version: 6.17.7-ba29.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 32 Gio of RAM (31.3 Gio usable)
Graphics Processor: NVIDIA GeForce RTX 5060 Ti (nvidia 595.58.03)
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7B89
System Version: 1.0

Anecdotally, the descriptor-heap-test branch actually fixes many more games on the 595 drivers on Blackwell that hit the Xid 109 hard lockup: Ghost of Tsushima, AC Shadows, Elden Ring to name a few.

I've updated the OP with relevant updates:

EDIT: There are many reports below + on Reddit and on Discord that using the VK_EXT_descriptor_heap branch also fixes Xid 109 Hard Crashes. Since it has been massively reported to me by many people, I decided to incorporate this into this issue.

EDIT 2: Conversely, there is a minority of people that this workaround didn't work for them in Crimson Desert right away. I suspect that their game may be left in bad state after trying to run the game without this workaround first. All that I can suggest to people who have been struggling is to clean their steam cache and verify their game files. This shader cleanup has been reported to solve these issues with the workaround most of the time. However, If that still doesn't work, all I can think of is to backup their save and reinstall the game.

I deleted my Steam cache and the PROTON_VKD3D_HEAP=1 launch option still wasn't working, but when I uninstalled the game and reinstalled it, it finally worked!

Operating System: CachyOS
Kernel Version: 6.19.10-1
Graphics Platform: Wayland
Processors: Intel i9 14900KS
Memory: 64GB DDR5 Corsair Dominator Platinum
Graphics Processor: NVIDIA GeForce RTX 5090 -595.58.03 driver
Proton Version: Proton-CachyOS Latest (10.0-20260324 x86_64_v3)

Same Problem with Space Marine 2 but unfortunately, clearing the cache, reinstalling the game, and setting PROTON_VKD3D_HEAP=1 didn't help.
I was able to access the settings once after reinstalling the game, but when I tried to save, the game crashed and wouldn't start again.

Operating System: Arch Linux
Kernel Version: 6.19.10-zen1-1-zen
Graphics Platform: Wayland
Processors: AMD Ryzen 7 9800X3D
Memory: 32GB DDR5
Graphics Processor: NVIDIA GeForce RTX 5080 - 595.58.03 driver
Proton Version: GE-Proton10-34

@Helmchen-Lord

Operating System: Arch Linux Kernel Version: 6.19.10-zen1-1-zen Graphics Platform: Wayland Processors: AMD Ryzen 7 9800X3D Memory: 32GB DDR5 Graphics Processor: NVIDIA GeForce RTX 5080 - 595.58.03 driver Proton Version: GE-Proton10-34

I guess you are using the wrong proton version. As far as I tested the above solution only works with proton-cachyos versions: 10.0-20260321 x86_64 and 10.0-20260324 x86_64.

CachyOs devs baked the new heap testing branch into their proton.
Please correct me if iam wrong.

@xcsvxangelx You are correct. @Helmchen-Lord It requires Proton-CachyOS 10.0-20260321 or newer.

OS + DE: CachyOS, KDE Plasma v6.6.3, Frameworks v6.24.0, Qt v6.11.0
Kernel v6.19.10-1-cachyos (64-bit); Wayland
AMD Ryzen 7 5700X 8-Core Processor
Graphics Processor: NVIDIA GeForce RTX 5060 (nvidia 595.58.03)
RAM: 32Gib

I'm probably among the minority of the minority where almost nothing worked, but after days of tinkering I found a solution for the RTX 5060 (at least it works for me, hopefully it works for any other who's running into similar issues).

The main issue: when upgrading to nvidia driver 595.58.03, Crimson Desert would open normally but would freeze while on the loading screen even though the music kept playing.

Although I am unsure if this only happened to me or if other people are having this issue, after days of tinkering and going back and forth with the drivers, I finally found a solution, at least for my RTX 5060

Steps to fix:

1. Uninstalling the game and reinstalling (without opening)
2. Deleting all game and nvidia cache:

rm -rf ~/.cache/nvidia/GLCache/*
rm -rf ~/.steam/steam/steamapps/shadercache/3321460/
rm -rf ~/.local/share/Steam/steamapps/common/Crimson\ Desert/bin64/vkd3d-proton.cache
rm -rf ~/.local/share/Steam/steamapps/common/Crimson\ Desert/bin64/vkd3d-proton.cache.write

(make sure you know what your steam path is)
3. Upgrading system and drivers, then rebooting
4. Click on Crimson Desert > Properties > Compatibility > Choose either proton-cachyos-10.0-2026-0324-slr-x86_64 or the 0321 version
5. In launch options: PROTON_VKD3D_HEAP=1 VKD3D_CONFIG=no_upload_hvv DXVK_ASYNC=1 %command%

That one command worked for me the first time I opened the game, it had a tiny freeze at the end of the loading screen but it went through and now the game opens and runs normally.

@Blisto91 Believe it or not, my friend RitzelHax was still experiencing crashes. VKD3D_CONFIG=descriptor_heap solved it. But this was probably on the NVIDIA 610.57.04. (Happened on the September 10th)

Answering @Blisto91's question above — on 610/615 the heap path still fixes crashes, but on some titles it has a visual cost that doesn't seem to have been reported yet.

With VKD3D_CONFIG=descriptor_heap (the current flag name; the thread above uses the older PROTON_VKD3D_HEAP=1), The Last of Us Part II Remastered renders skinned character geometry — hair, jackets, cloth — with vertices teleported to wrong positions. Long stretched spikes, detached fragments floating off the mesh. Persistent and very visible, while the framerate itself is perfectly normal.

This is a direct counterpoint to @Alexandre-Tridon's report above: same title, same fix for the Xid 109 timeouts, but 595.58.03 there and 615.71.09 here. So the heap path solved the crash and introduced something else.

Turning the heap path off makes the corruption disappear completely, which points at the heap path rather than the base descriptor implementation. It matches two NVIDIA driver bugs reported with minimal reproducers, which I also reproduced on my RTX 2060 / 615.71.09:

• Fragment shader reads the wrong descriptor for any heap index other than 0 — https://forums.developer.nvidia.com/t/rtx-4060-fragment-shader-reads-the-wrong-descriptor-for-any-heap-index-other-than-0/383842
• Incorrect row-major MatrixStride handling for whole-matrix OpLoad through an untyped pointer — https://forums.developer.nvidia.com/t/vulkan-615-71-09-rtx-4050-descriptor-heap-incorrect-rowmajor-matrixstride-handling-for-whole-matrix-opload-through-an-untyped-uniform-pointer/383932

The second one is the likely cause of the geometry corruption: skinning reads a 4x4 bone matrix through a heap pointer, and MatrixStride is ignored, so the matrix comes back as garbage. That is exactly the "vertex teleported to a wrong position" signature.

The trade-off on a 6 GB card is that neither path is good. Without the heap, the legacy descriptor buffer exhausts VRAM and the game drops to 1-2 FPS (measurements here: #2518). With the heap, VRAM fits and geometry is corrupted. The only configuration I found that works on that card is to skip the heap and lower the internal resolution instead.

So I would not read this as an argument against the heap path in general — for the Xid 109 crashes it is clearly doing its job. Just worth knowing that "fixes the crash" and "renders correctly" can come apart on 610/615, and that the vertex stage does not appear to be covered by the existing repros, so there may be a third distinct issue behind the geometry.

One more data point that may be useful: @ThomasEricB mentioned above that VKD3D_CONFIG=descriptor_heap solved the crashes for @RitzelHax without any visible corruption being mentioned. I'm not sure whether that's because the corruption is title-dependent, generation-dependent, or simply went unnoticed — which GPU and which title was that on?

I'm asking because the underlying driver bugs do reproduce on Turing, Ada and Blackwell, but whether they manifest depends on how heavily a given title uses bindless descriptors for skinning. TLOU2 Remastered is on the heavy end of that. If the corruption is title-specific rather than universal, that's useful to know before treating the heap path as a default.

Mine: RTX 2060 (TU106), 615.71.09, CachyOS, Proton Experimental, TLOU2 Remastered (AppID 2531310).

How is this looking with the latest Nvidia driver?

@Blisto91

Funny you mention this, because after changing drivers to 610.xx, the game worked even without having to apply any launch options. It WAS working perfectly fine.

That is, until I updated from 610.xx to 615.xx. Then a plethora of issues started happening:

• Fast traveling to Howling Hill or anywhere near the area would simply crash and fully close the game.
• Heavy fps drops (about ~15 fps) on the same graphics settings I used on previous drivers (Cinematic + DLSS Performance + RR + FGx2).
• ~20 minutes of playtime would just crash the game without a warning, hang, or freeze.

Instead of troubleshooting for hours looking for launch options, I decided to simply downgrade back to 610.xx, and everything is back to normal. No launch options needed in my case, even after fully updating CachyOS to the latest kernel/OS version while excluding the NVIDIA drivers from the update.