Crimson Desert: reproducible GPUVM fault on RDNA4 async compute queue; RADV_DEBUG=nocompute is a workaround

vkd3dclosed

HansKristian-Work/vkd3d-proton#3058 · opened 2026-05-25 by rykugur · updated 2026-05-29 · 6 comments · github

Rrykugur 2026-05-25 github

Summary

Reproducible GPUVM page fault on the async compute queue (comp_1.1.1) in
Crimson Desert (Steam appid 3321460) at a fixed in-game location on RDNA4
(RX 9070 XT). Faulting thread is vkd3d_queue. Setting
RADV_DEBUG=nocompute in launch options reliably prevents the crash,
isolating the bug to the async-compute submission path.

Likely related to #3056 — same renderer, same fault family
(GPUVM + VK_ERROR_DEVICE_LOST + enhanced-barrier spam), but different GPU
generation (RDNA4 here vs RDNA3 there), different trigger (specific
in-game location here vs menu→game transition there), and different
working mitigation (RADV_DEBUG=nocompute here vs descriptor-buffer
toggle there). Filing separately so the RDNA4-specific evidence isn't
lost; feel free to merge if they share a root cause.

Software

vkd3d-proton: bundled with Proton Experimental experimental-11.0-20260518b
(d3d12.dll built 2026-05-22, post-3.0.1)
Game: Crimson Desert (3321460), current Steam build as of 2026-05-24
Mesa / RADV: 26.1.1
Kernel: 7.0.9-zen2 (NixOS)
Vulkan API: 1.4.348
MES firmware: 0x0000008b

Hardware

GPU: AMD Radeon RX 9070 XT (gfx1201, RDNA4)
CPU: AMD Ryzen 9 5900X
RAM: 64 GB

Reproducer

Launch Crimson Desert via Proton Experimental
Load any save and proceed via normal story progression toward the
location that triggers the fault (same spot every run)
GPU page-faults as the area streams in; game dies with cascading
VK_ERROR_DEVICE_LOST

Adding RADV_DEBUG=nocompute to the launch options reliably prevents the
fault. Without it, crash is 100% reproducible at the same location.

Notes on prior workaround (Proton#9595)

The widely-cited Proton#9595 AMD workaround ("disable ray tracing") does
NOT prevent the underlying GPU fault on this hardware — same fault address,
same ring, same client whether RT is on or off. What RT-off does change is
the consequences: with RT off, MES is able to soft-recover via ring
reset; with RT on, MES wedges and the kernel escalates to MODE1 reset
(VRAM lost, display engine stuck, hard power-cycle required).

Not yet tested on this setup

VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_buffer (the angle from #3056) —
happy to test on request

Kernel log — clean ring-reset case (RT off)

amdgpu 0000:2f:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:7 pasid:368)
amdgpu 0000:2f:00.0:  Process CrimsonDesert.e pid 26551 thread vkd3d_queue pid 26749
amdgpu 0000:2f:00.0:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:2f:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00701431
amdgpu 0000:2f:00.0:          Faulty UTCL2 client ID: SQC (data) (0xa)
amdgpu 0000:2f:00.0:          MORE_FAULTS: 0x1
amdgpu 0000:2f:00.0:          WALKER_ERROR: 0x0
amdgpu 0000:2f:00.0:          PERMISSION_FAULTS: 0x3
amdgpu 0000:2f:00.0:          MAPPING_ERROR: 0x0
amdgpu 0000:2f:00.0:          RW: 0x0
[ ...fault repeats... ]
amdgpu 0000:2f:00.0: Dumping IP State
amdgpu 0000:2f:00.0: [drm] AMDGPU device coredump file has been created
amdgpu 0000:2f:00.0: ring gfx_0.0.0 timeout, signaled seq=1146361, emitted seq=1146363
amdgpu 0000:2f:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:2f:00.0: Ring gfx_0.0.0 reset succeeded
amdgpu 0000:2f:00.0: [drm] device wedged, but recovered through reset

Kernel log — MES-wedge case (RT on)

amdgpu 0000:2f:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:7842)
amdgpu 0000:2f:00.0:  Process CrimsonDesert.e pid 428293 thread vkd3d_queue pid 428583
amdgpu 0000:2f:00.0:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:2f:00.0:          Faulty UTCL2 client ID: SQC (data) (0xa)
[ ...same fault details... ]
amdgpu 0000:2f:00.0: ring comp_1.1.1 timeout, signaled seq=127582, emitted seq=127583
amdgpu 0000:2f:00.0: Starting comp_1.1.1 ring reset
amdgpu 0000:2f:00.0: reset compute queue (1:1:1)
amdgpu 0000:2f:00.0: MES(1) failed to respond to msg=ADD_QUEUE
amdgpu 0000:2f:00.0: failed to map legacy queue
amdgpu 0000:2f:00.0: failed to remap kcq
amdgpu 0000:2f:00.0: Ring comp_1.1.1 reset failed
amdgpu 0000:2f:00.0: GPU reset begin!. Source:  1
[ ...repeated MES REMOVE_QUEUE failures... ]
[drm:gfx_v12_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
amdgpu 0000:2f:00.0: MODE1 reset
amdgpu 0000:2f:00.0: VRAM is lost due to GPU reset!
amdgpu 0000:2f:00.0: [drm] device wedged, but recovered through reset
amdgpu 0000:2f:00.0: [drm] *ERROR* [CRTC:420:crtc-1] flip_done timed out

Available on request

Full Proton log (~130 MB) from a faulting run
A fresh GPU coredump (/sys/class/drm/card1/device/devcoredump/data) on
the next reproducer run — auto-expires, would need to capture quickly
Test results for VKD3D_DISABLE_EXTENSIONS=VK_EXT_descriptor_buffer if
useful

Rrykugur 2026-05-26 github

Update: the RADV_DEBUG=nocompute workaround turned out to be unreliable. After a clean run yesterday, the crash recurred today at the exact same in-game spot — same save, same path, no reboot, no Steam updates, env var verified still in launch options.

The fault signature is identical:

amdgpu 0000:2f:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:1022)
amdgpu 0000:2f:00.0:  Process CrimsonDesert.e pid 72484 thread vkd3d_queue pid 72678
amdgpu 0000:2f:00.0:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:2f:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00501431
amdgpu 0000:2f:00.0:          Faulty UTCL2 client ID: SQC (data) (0xa)
amdgpu 0000:2f:00.0:          MORE_FAULTS: 0x1
amdgpu 0000:2f:00.0:          PERMISSION_FAULTS: 0x3
[...]
amdgpu 0000:2f:00.0: ring gfx_0.0.0 timeout, signaled seq=9324618, emitted seq=9324620
amdgpu 0000:2f:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:2f:00.0: Ring gfx_0.0.0 reset succeeded
amdgpu 0000:2f:00.0: [drm] device wedged, but recovered through reset

Crucially, the fault is still on hardware ring comp_1.1.1 (ring 24) even though RADV_DEBUG=nocompute removes the async-compute queue family from the Vulkan view of the device. Confirmed via vulkaninfo:

Without nocompute:

queueFamily[0]: GRAPHICS | COMPUTE | TRANSFER | SPARSE_BINDING (count 1)
queueFamily[1]: COMPUTE | TRANSFER | SPARSE_BINDING (count 4) ← async compute
queueFamily[2]: VIDEO_DECODE (1)
queueFamily[3]: VIDEO_ENCODE (1)
queueFamily[4]: SPARSE_BINDING (1)

With RADV_DEBUG=nocompute:

queueFamily[0]: GRAPHICS | COMPUTE | TRANSFER | SPARSE_BINDING (count 1)
❌ async-compute family is gone
(other families unchanged)

Since vkd3d-proton cannot allocate from a queue family that doesn't exist, the fault on comp_1.1.1 must originate from radv's internal use of compute hardware rings (CP DMA, internal image init, etc.), not from vkd3d-proton's explicit submissions. That points upstream at mesa/radv rather than at vkd3d-proton's submission logic.

Yesterday's apparent success was likely just non-deterministic timing — same system state, different outcome on different runs.

Next test on my end: RADV_DEBUG=nocompute,nodma to see whether disabling CP DMA suppresses the fault. Will report back.

Rrunar-work 2026-05-26 github

Can you share the save file from the location where you have this problem?

Rrykugur 2026-05-28 github

Can you share the save file from the location where you have this problem?

crimson-desert-save-backup-20260524.tar.gz

To reproduce: solve the initial puzzle cube to get past the doorway, step on on the plate and drop through the now open floor. Walk under the laser - this is where I experience the crash.

As a note, I uninstalled/reinstalled just tonight but haven't tested post-reinstall yet.

EDIT: tested, still crashing. Also, you can just run straight after solving the initial puzzle to get past the doorway to reproduce the crash.

Rrunar-work 2026-05-28 github

Thanks, that was indeed a reliable hang. I reported the issue on the Mesa tracker here: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15563

Rrykugur 2026-05-28 github

Thanks, that was indeed a reliable hang. I reported the issue on the Mesa tracker here: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15563

You're the best, thanks!

HHansKristian-Work maintainer 2026-05-29 github

Resolved as game bug workaround in Mesa.