protonscr

RDNA4: gfx ring timeout on zone load due to parallel shader compile burst

vkd3dclosed AI bullshit
HansKristian-Work/vkd3d-proton#2895 · opened 2026-03-21 by theta55 · updated 2026-03-21 · 3 comments · github
Ttheta55 2026-03-21 github

Summary

Diablo IV freezes on zone transitions (dungeon portals) with ring gfx_0.0.0 timeout on RDNA4 (Navi 48). Audio continues, display is frozen. The GPU recovers via ring reset but the game is unplayable past that point.

VKD3D_CONFIG=shader_cache resolves the issue, suggesting the default parallel pipeline compilation path overwhelms the gfx ring during bulk asset/shader loads on zone entry.

Environment

  • GPU: AMD RDNA4 Navi 48 (RX 9070 class) via eGPU (Thunderbolt)
  • Driver: RADV (vulkan-radeon) via Mesa 26.0.3-2
  • Kernel: 6.19.9-1-cachyos
  • Proton: Proton Experimental
  • Compositor: Gamescope (-W 3440 -H 1440 -r 240 -f --hdr-enabled)
  • OS: CachyOS (Arch-based)

Reproduction

  1. Launch Diablo IV via Steam with Proton Experimental + Gamescope
  2. Enter a specific dungeon (zone transition via portal)
  3. Screen freezes immediately on load, audio continues playing

Reproducible 100% of the time on the same zone. Different zones load fine.

Kernel log

amdgpu 0000:c3:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=9933218, emitted seq=9933220
amdgpu 0000:c3:00.0: amdgpu:  Process Diablo IV.exe pid 208431 thread vkd3d_queue pid 208608
amdgpu 0000:c3:00.0: amdgpu: Starting gfx_0.0.0 ring reset
amdgpu 0000:c3:00.0: amdgpu: Ring gfx_0.0.0 reset succeeded
amdgpu 0000:c3:00.0: [drm] device wedged, but recovered through reset

The vkd3d_queue thread is always the faulting process. Multiple occurrences show the same pattern — always on zone load, always gfx ring.

What was tried (did NOT help)

Attempt Result
Clear all shader caches (Mesa + Steam pipeline) Same freeze
RADV_DEBUG=nosched Same freeze
RADV_PERFTEST=nosam Same freeze
RADV_DEBUG=nodcc,nohiz Same freeze
RADV_DEBUG=llvm (LLVM backend) Instant crash
VKD3D_CONFIG=no_execute_indirect_drawing Instant crash
VKD3D_SHADER_THREADS=1 alone Same freeze

Fix

VKD3D_CONFIG=shader_cache

This completely resolves the freeze. The zone loads fine every time with this flag set.

Analysis

The default vkd3d pipeline compilation path appears to submit a burst of shader compile work to the gfx ring during zone transitions that exceeds what RDNA4/RADV can process within the kernel timeout window. shader_cache likely changes the submission pattern (serialized or batched differently), avoiding the burst.

This may be RDNA4-specific due to differences in how the hardware handles concurrent shader compilation, or it may be a latent issue that RDNA4's timing characteristics expose more readily.

Suggested improvement

vkd3d-proton could potentially:

  • Throttle parallel pipeline compilation during bulk loads
  • Detect and back off when approaching gfx ring saturation
  • Make shader_cache behavior the default, or enable it automatically for affected GPU families
Mmbriar 2026-03-21 github

VKD3D_CONFIG=shader_cache doesn't exist and doesn't do anything and is as nonsensical as the rest of the AI hallucinations you posted. Pipeline compilation also doesn't submit any work to the gfx ring at all because it happens exclusively on the cpu.

HHansKristian-Work maintainer 2026-03-21 github

via eGPU (Thunderbolt)

Most likely kernel related if anything.

Ttheta55 2026-03-21 github

Thanks for the quick response and clarification. Apologies for the noise — will investigate on the kernel/Thunderbolt side instead.

Proton versions

Launch options