protonscr

Crimson Desert regression on Linux (RDNA3/RADV) – VK_ERROR_DEVICE_LOST + enhanced barrier spam

vkd3dopen
HansKristian-Work/vkd3d-proton#3056 · opened 2026-05-21 by mhakkuh · updated 2026-09-15 · 9 comments · github
Mmhakkuh 2026-05-21 github

steam-3321460.txt

Crimson Desert regression on Linux/Proton (RDNA3/RADV) – VK_ERROR_DEVICE_LOST + enhanced barrier spam

Crimson Desert previously worked perfectly on Linux/Proton for me. After a recent update, the game now frequently hangs after clicking "Start Game".

Symptoms

  • Main menu works normally

  • Clicking "Start Game" causes:

    • black screen or loading screen
    • loading music/orchestra continues indefinitely
    • gameplay never initializes

Additional observations:

  • Steam itself sometimes freezes while the game is hung

  • Steam immediately unfreezes once the game process is killed

  • Rarely, the game does successfully enter gameplay

  • Behavior appears timing-sensitive:

    • PROTON_LOG=1 changes startup behavior
    • disabling certain VKD3D extensions changes shader compilation behavior

System

GPU

  • AMD Radeon RX 7900 XTX

Driver

  • RADV 26.1.1

Kernel / Distro

  • CachyOS

Renderer stack

  • Vulkan + VKD3D-Proton

Proton versions tested

  • Proton Hotfix
  • Proton Experimental
  • CachyOS Proton

Confirmed behavior

The following mitigations were tested:

  • fresh compatdata
  • deleting shadercache
  • Proton Hotfix
  • Proton Experimental
  • CachyOS Proton
  • Steam Overlay OFF
  • DXVK_HDR=0
  • RADV_DEBUG=nogpl
  • VKD3D_CONFIG=disable_pipeline_library

Mitigation that changed behavior significantly

VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_buffer DXVK_HDR=0 %command%

With descriptor buffers disabled:

  • the game visibly started building shaders inside the menu
  • startup/render initialization behavior changed noticeably
  • eventual hangs/device-loss still still occurred

This strongly suggests the descriptor-buffer path affects the regression.

Relevant VKD3D warnings

Repeated continuously during startup:

warn:vkd3d-proton:d3d12_command_list_process_enhanced_barrier_texture:
NumPlanes == 0 promotes to 1 plane.

Also observed:

fixme:vkd3d-proton:d3d12_command_list_process_enhanced_barrier_texture:
Transitioning away from UNDEFINED, but there is no DISCARD flag.
Uncertain what is expected here. vkd3d-proton will force a discard.

GPU fault / device loss

Eventually the renderer hits GPUVM faults and Vulkan device loss:

radv/amdgpu: The CS has been cancelled because the context is lost.
radv: GPUVM fault detected at address ...
VK_ERROR_DEVICE_LOST

Relevant log lines:

err:vkd3d-proton:d3d12_command_queue_execute:
Failed to submit queue(s), vr -4.

err:vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore:
Failed to wait for Vulkan timeline semaphore, vr -4.

warn:vkd3d-proton:d3d12_device_mark_as_removed:
Device lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST")

Notes

This appears to be:

  • renderer-related
  • DX12 barrier/resource-management related
  • timing-sensitive
  • likely introduced by a recent game update

The game previously worked flawlessly on this same hardware/software stack.

The combination of:

  • enhanced barrier spam
  • descriptor-buffer sensitivity
  • intermittent successful launches
  • GPUVM faults
  • VK_ERROR_DEVICE_LOST

makes this look like a VKD3D/RADV synchronization or resource-management regression triggered by the updated renderer path.

Logs

Shortened logs attached below, as the warnings/errors repeat continuously.

Rrunar-work 2026-05-22 github

Which graphics settings are you using? I haven't run into any issues so far with RX 7600, 26.1.1, Proton Experimental, 7.0.9-arch1-1, and various graphics presets ranging from minimum to cinematic.

Mmhakkuh 2026-05-22 github

@runar-work heya! i've tested with almost every possible combination, even my own custom potato-mode.
Raytracing has never even been turned on for obvious reasons.
there seems to be no difference in outcome.

Tweaking INI files have the same effect: Nothing.
there's lots of reports of this happening over at protondb, so i don't think we should classify it as an isolated case.

I could run more logging, but i'm pretty sure they will just print out the same junk in an endless loop without really clarifying what is happening.

let me know if there is anything i can provide you with that would be of help.

Rrunar-work 2026-05-22 github

Which ProtonDB reports are you referring to? Keep in mind that older reports may refer to issues that have since been fixed or worked around in Mesa or vkd3d-proton. I've been able to reproduce GPU hangs in this game on this GPU in the past, but those were ray tracing related and have since been resolved, so I don't know what this could be.

I also tested 7.1.0-rc4-1-cachyos-rc (though still on Arch Linux) in case it could be something kernel-related, but I still have no issues on my system.

Nnicmullin 2026-05-29 github

I'm also on a system with a 7900XTX running CachyOS, the same GPU crash behaviour occurs when the game attempts to load past the menu on most attempts. Sometimes the game successfully loads, after which the game is playable and stable ( 5+ hour sessions without issues). I'm fairly certain the problem appeared after game version 1.06 if that is of any help.

Nnicmullin 2026-05-29 github

Applying the variable RADV_DEBUG=nocompute appears to alleviate the problem, but it also breaks the rendering of foliage and possibly other objects in the game.

Mmhakkuh 2026-05-29 github

Ive experimented a lot. Banging my head against the wall in the process.
The latest proton experimental by Valve lets me load the game successfully if I delete the shadercache from steam/steamapps/shadercache

Seems that if it gets to compile shaders client-side (game itself, not steam) and then load the game straight away, it works way more often.
I'm having a 75% success rate with this.

Wanna give it a go? Would be cool if we could reproduce this

Nnicmullin 2026-05-29 github

Ive experimented a lot. Banging my head against the wall in the process. The latest proton experimental by Valve lets me load the game successfully if I delete the shadercache from steam/steamapps/shadercache

Seems that if it gets to compile shaders client-side (game itself, not steam) and then load the game straight away, it works way more often. I'm having a 75% success rate with this.

Wanna give it a go? Would be cool if we could reproduce this

Sure, and good to hear you had some results. I deleted the Steam shader cache, and disabled shader pre-caching in steam under options>downloads. Regardless of proton version (most of the time I used CachyOS latest build, but Valve experimental seems to have the same result) the game now loads more often than not it seems. I will keep using these settings and see if this pattern holds over time.

Nnicmullin 2026-05-31 github

https://github.com/ValveSoftware/Proton/wiki/Changelog

According to the changelog for Proton Experimental:

"Fixed Crimson Desert not being playable after a recent game update."

I haven't had time to test this thoroughly, does the latest Proton Experimental fix this issue for you?

Edit: Seemingly no change for me, still crashes with the same string of errors on the Proton Experimental branch.

Jjeremonienmaster 2026-09-15 github

Another RX 7900 XTX / RADV data point here.

First, a disclaimer: I'm not a developer or Linux graphics expert. I troubleshot this together with ChatGPT, testing different configurations and comparing AMDGPU/kernel logs, so please treat this as a user observation rather than a technical diagnosis.

System

  • GPU: Sapphire PULSE Radeon RX 7900 XTX (Navi 31 / RDNA3)
  • Driver: RADV / Mesa 26.2.2-3.fc44
  • Kernel: 7.2.4-ogc3.1.fc44.x86_64
  • OS: Bazzite 44.20260914 (Fedora 44)
  • KDE Plasma / Wayland
  • Proton Experimental
  • Crimson Desert (Steam AppID 3321460)

Previous behavior

The game would run normally, sometimes for quite a while, and then eventually hang/crash.

Previous crash logs showed AMDGPU/gfx ring timeout behavior while Crimson Desert was running through the D3D12 → VKD3D-Proton → Vulkan/RADV path.

At first I suspected my multi-monitor setup. I tested fewer monitors, a single monitor and different refresh rates. Reducing my main 2560x1440 display from ~165/170 Hz to ~120 Hz seemed to improve stability, but did not eliminate the crashes. I eventually had a crash even during a single-monitor test.

What changed the behavior significantly

I'm currently using Proton Experimental with:

WINEDLLOVERRIDES="version=n,b" VKD3D_CONFIG=enable_experimental_features %command%

Since adding VKD3D_CONFIG=enable_experimental_features, I've accumulated approximately 6 hours of gameplay without a single GPU hang/crash.

Before this, crashes occurred repeatedly during normal gameplay.

I'm now back on all three monitors:

  • Main: 2560x1440 @ 119.88 Hz
  • Secondary: 1920x1080 @ 60 Hz
  • Portrait: 1680x1050 @ 59.95 Hz
  • VRR disabled

The current boot's kernel log contains no gfx ring timeout, GPU reset, VM fault or GPU hang.

I don't want to claim this proves that enable_experimental_features is the fix. Bazzite/kernel/Mesa were also updated during the testing period, so there are other variables.

However, the stability difference has been large enough that I thought this might be useful to the developers, especially given the other RDNA3/RADV reports here.

I'll keep playing with the same configuration. If the GPU hang returns, I can provide the AMDGPU/kernel logs from immediately after the crash and compare them with my previous crash logs.

Again, I'm not an expert — this was found through troubleshooting and testing with ChatGPT — but I'm happy to collect any specific logs or run tests if that would help.

Related threads

Proton versions

Launch options

Launch lines

Error codes