The Marvel Rivals issue is the same as the one tracked here https://github.com/HansKristian-Work/vkd3d-proton/issues/2266.

Do you have some more info about the other games? Proton logs and graphics settings from each game would be useful.

@runar-work, for other games I could not find a setting that will eliminate the issue just like in Marvel Rivals to set Effects to low. It happens after some time and the Proton log will be large if I run the game for 1 hour and wait to happen, the dmesg or journalctl system log is the same like this one I have posted it is either ring gfx timeout or ring comp_1.x.x timeout. I think it is more like kernel/driver issue, but I am not sure. CachyOS few months ago had 6.12 LTS kernel, and on that kernel I was not crashing in Witcher 3, Cyberpunk, Shadow of The Tomb Raider, only on Marvel Rivals I was having issue so it was more stable, but that kernel is history now and they use 6.18 LTS. I will do more testing and try to find out if any game setting, kernel flag or env variable can help with this.

I can confirm a very similar issue on RDNA4 with The Witcher 3 Next-Gen (DX12).

System:

• GPU: AMD Radeon RX 9070 XT
• OS: Bazzite
• Kernel: 6.19.14
• Proton: Proton GE (latest)
• Vulkan: RADV (Mesa version available if needed)

Symptoms:

• Random freezes while playing The Witcher 3 Next-Gen in DX12.
• Sometimes the image freezes while audio continues playing.
• In some cases the entire desktop becomes unresponsive after the GPU hang.
• The issue happens during normal gameplay without any obvious trigger.

The journal shows:

amdgpu: ring gfx_0.0.0 timeout
amdgpu: Process witcher3.exe pid XXXXX thread vkd3d_queue
amdgpu: Starting gfx_0.0.0 ring reset
amdgpu: Ring gfx_0.0.0 reset failed
amdgpu: GPU reset begin!
amdgpu: MES(1) failed to respond to msg=REMOVE_QUEUE
amdgpu: GPU reset succeeded
amdgpu: VRAM is lost due to GPU reset!
amdgpu: device wedged, but recovered through reset

I initially suspected OptiScaler, ray tracing, HairWorks, HDR, Gamescope or my undervolt configuration, but the issue still occurs after removing OptiScaler, disabling Ray Tracing and disabling HairWorks.

I use LACT with a very conservative -70 mV voltage offset and have been running this configuration for nearly a year without stability issues in other games. I have not experienced GPU hangs, resets or similar crashes outside of The Witcher 3.

An important detail is that this is currently the only game where I can reliably reproduce this problem. Other demanding titles run normally on the same system.

I also noticed that ProtonDB contains multiple reports from Linux users describing behavior, specifically on The Witcher 3, that appears very similar, especially on the DX12 renderer, including random freezes, lockups and cases where switching to DX11 improves stability.

The symptoms described in this issue are an almost perfect match for what I am experiencing, including the screen freeze followed by an AMDGPU timeout and GPU reset.

I am currently testing the DX11 renderer to determine whether the issue is specific to the DX12/VKD3D path.

The symptoms described in this issue are an almost perfect match for what I am experiencing, including the screen freeze followed by an AMDGPU timeout and GPU reset.

yes, you can probably find descriptions of this symptom for hundreds of games. A gpu hang and reset is a generic symptom that can have loads of different causes and most of them are completely unrelated.

@BlackomegaTM , in my case DXVK is rock stable in all games like God of War, Witcher 3, Shadow of the Tomb Raider, GTA V and so on. While VKD3D is pain in almost 80% of my games collection: Witcher 3, Cyberpunk 2077, Horizon Zero Dawn Remastered, Clair Obscur Expedition 33, Shadow of The Tomb Raider - all are triggering the ring gfx timeout sooner or later.

Try in your case to give more voltage for the GPU it might help. Transient power spikes, rapid fluctuations in voltage and frequency is 1 of the many problems why this ring gfx timeout happens. Windows drivers seems to handle it much better.
These are the kernel flags that might help and I am currently testing: amdgpu.gpu_recovery=1, amdgpu.ppfeaturemask=0xfffd7fff, pcie_aspm=off, amdgpu.runpm=0, amdgpu.noretry=0.

Also reproducing this on Navi10 (RX 5700 XT) with vkd3d-proton 3.1.0. In my case it happens with multiple DX12 titles (Ratchet & Clank: Rift Apart, Forza Horizon 6), and I've been able to rule out a few things that might help narrow this down:

Reproduces on a clean Arch install and a separate CachyOS install on the same hardware (not distro-specific)
Reproduces with VKD3D_CONFIG='' (default), and no ray tracing/DXR activity in the log — so likely not RT-specific in my case
Confirmed it's not related to MangoHud/mangoapp (reproduces with it fully uninstalled)

Full logs and system info below:

System Info

• GPU: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (rev c1), ASUS Device 0577
• Distro: Arch Linux
• Kernel: 7.1.3-2-cachyos-bore (linux-cachyos-bore)
• Mesa: 26.1.4-1
• vulkan-radeon (RADV): 26.1.4-1
• linux-firmware: 20260622-1
• Proton version: Proton-CachyOS Latest (cachyos-11.0-20260602-slr)
• vkd3d-proton: 3.1.0, build 3dfc6f07d0953b1
• Desktop/Session: gamescope-session (GNOME/GDM host)
• Display server: Wayland (Xwayland for the game)

Description

GPU reset / ring gfx timeout reproducing with multiple DX12 titles via vkd3d-proton:

• Ratchet & Clank: Rift Apart
• Forza Horizon 6

Symptom: mid-session, the GFX ring hangs, amdgpu attempts a ring reset which fails, escalates to a full GPU reset (BACO), VRAM is lost, and the desktop/gamescope session crashes, forcing a logout/relogin. Reproduces across a clean Arch install and a separate CachyOS install (same hardware), ruling out a distro-specific misconfiguration. Also reproduces with mangohud/mangoapp completely uninstalled, ruling out the overlay as the trigger — it was previously suspected only because it was the process nearest the ring at fault time.

Kernel log — Ratchet & Clank: Rift Apart crash

amdgpu 0000:03:00.0: Dumping IP State
amdgpu 0000:03:00.0: Dumping IP State Completed
amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created
amdgpu 0000:03:00.0: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=1090274, emitted seq=1090275
amdgpu 0000:03:00.0:  Process RiftApart.exe pid 35922 thread vkd3d_queue pid 36054
amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
amdgpu 0000:03:00.0: GPU reset begin!. Source:  1
amdgpu 0000:03:00.0: [drm] *ERROR* Failed to initialize parser -125!
amdgpu 0000:03:00.0: BACO reset
amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
amdgpu 0000:03:00.0: [drm] PCIE GART of 512M enabled (table at 0x00000081FEE00000).
amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
amdgpu 0000:03:00.0: PSP is resuming...
amdgpu 0000:03:00.0: SMU is resumed successfully!
amdgpu 0000:03:00.0: GPU reset(2) succeeded!
amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed

Kernel log — earlier crash on same hardware (different session, same GPU ring fault pattern)

amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:4 pasid:766)
amdgpu 0000:03:00.0:  Process mangoapp pid 17966 thread mangoapp:cs0 pid 17977
amdgpu 0000:03:00.0:   in page starting at address 0x000080000823e000 from client 0x1b (UTCL2)
amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00400C30
amdgpu 0000:03:00.0:          Faulty UTCL2 client ID: CPG (0x6)
amdgpu 0000:03:00.0:          PERMISSION_FAULTS: 0x3
amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=553932, emitted seq=553934
amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
amdgpu 0000:03:00.0: GPU reset begin!. Source:  1
amdgpu 0000:03:00.0: BACO reset
amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
amdgpu 0000:03:00.0: [drm] *ERROR* Failed to initialize parser -125!
amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed

Note: mangoapp is flagged here only because it happened to be the next process queued on the ring when the fault landed — not because it caused the fault. Confirmed by reproducing the same crash pattern with mangohud/mangoapp fully uninstalled.

vkd3d-proton log — device lost cascade (steam-1895880.log)

VKD3D_CONFIG='' — this crash happened with default config, no flags set. No ray tracing / DXR strings appear anywhere in the log, so this instance does not appear to involve ray tracing.

8225.613:0140:0144:info:vkd3d-proton:vkd3d_config_flags_init_once: VKD3D_CONFIG=''.
8225.615:0140:0144:info:vkd3d-proton:vkd3d_get_vk_version: vkd3d-proton - applicationVersion: 3.1.0.
8225.615:0140:0144:info:vkd3d-proton:vkd3d_instance_init: vkd3d-proton - build: 3dfc6f07d0953b1.
...
8228.657:0140:027c:warn:vkd3d-proton:d3d12_device_mark_as_removed: Device 0000000056820080 is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").
8228.657:0140:027c:warn:vkd3d-proton:d3d12_device_mark_as_removed: Device 0000000056820080 is lost (reason 0x80004005, "Failed to execute pending memory clears.")

(repeats across dozens of threads over ~4ms as every in-flight command list reports the device loss)

Followed immediately by the Xwayland/X11 connection dying as the compositor itself went down with the GPU reset:

XIO:  fatal IO error 110 (Connection timed out) on X server ":1"

coredumpctl (relevant entries)

TIME                          PID    SIG     EXE
2026-07-15 19:06:26 AST       17496  SIGABRT /usr/bin/gamescope
2026-07-15 19:06:48 AST       24189  SIGQUIT Proton-CachyOS wine-preloader
2026-07-15 19:32:26 AST       33617  SIGABRT /usr/bin/gamescope
2026-07-15 19:32:26 AST       33671  SIGABRT /usr/bin/Xwayland
2026-07-15 19:32:26 AST       33672  SIGABRT /usr/bin/Xwayland
2026-07-15 19:32:55 AST       41989  SIGQUIT cachyos-11.0-20260602-slr wine-preloader

What I've tried

• Reproduces on both a clean Arch Linux install and a separate CachyOS install on the same hardware (ruling out distro-specific config)
• Reproduces with mangohud/mangoapp completely uninstalled (ruling out the overlay)
• Reproduces across different Mesa versions up to current 26.1.4
• Confirmed via Steam log that this crash occurred with default VKD3D_CONFIG='' and no ray tracing/DXR activity logged — so the crash is not RT-specific, at least in this instance
• Have not yet tried VKD3D_CONFIG=nodxr — will update with results

Steps to reproduce

1. Launch [Ratchet & Clank: Rift Apart / Forza Horizon 6] via Proton-CachyOS or Proton Experimental
2. Play normally; GPU reset occurs after a variable amount of time (has not been narrowed to a specific in-game trigger yet)
3. Session crashes / desktop restarts due to the GPU reset taking down the compositor

I am currently testing the DX11 renderer to determine whether the issue is specific to the DX12/VKD3D path.

From what I could test, DX11 wont have any problem like this kind of GPU hang

@runar-work, for other games I could not find a setting that will eliminate the issue just like in Marvel Rivals to set Effects to low. It happens after some time and the Proton log will be large if I run the game for 1 hour and wait to happen, the dmesg or journalctl system log is the same like this one I have posted it is either ring gfx timeout or ring comp_1.x.x timeout. I think it is more like kernel/driver issue, but I am not sure. CachyOS few months ago had 6.12 LTS kernel, and on that kernel I was not crashing in Witcher 3, Cyberpunk, Shadow of The Tomb Raider, only on Marvel Rivals I was having issue so it was more stable, but that kernel is history now and they use 6.18 LTS. I will do more testing and try to find out if any game setting, kernel flag or env variable can help with this.

Hi @runar-work,

I havent tried latest 6.12.95 because it lacks of modules for LACT fan control to work, have in mind that the crash might ocurr after several hours, its damn strange random and I tend to think its not VKD3D problem but amdgpu https://gitlab.freedesktop.org/drm/amd/-/work_items/3067 here a developer suggest trying RADV_DEBUG=nocompute

I've experienced a similar issue that I can provide some notes on.

My setup is as follows:

• 5700 XT on eGPU dock - connection is Dock > Oculink > PCie adapter > Lenovo p3 Tiny ThinkStation Gen 1
• i5-13500T 32GB DDR5
• Arch Linux, Wayland / Niri
• Cyberpunk 2077 via Steam+Proton Experimental

So I'm on a low TDP machine, using the 5700 XT as an eGPU with its own power supply.

Game Settings are:

• 1440p High, FSR 3.0 Quality (0.50)
• VSync ON - 60hz
• my monitor is Dell U4320q and 3840x2160 max 60hz
• I use the full screen feature provided by the compositor (Niri)

Admittedly I am not as savvy when it comes to gaming + GPU configuration, so through AI I have gone through a number of gameplay sessions where it logged what what was happening to help me understand what was going on. A lot of how my system is configured now is from information it found in this specific issue, so thank you, i hope this information is helpful:

AI DISCLAIMER

The output below is an AI generated summary.

Additional report (eGPU + OCuLink variant)

Same signature as the OP: [gfxhub] page faults → gfx_0.0.0 ring timeout
→ ring reset failed → GPU reset, in Cyberpunk 2077 (DX12/vkd3d). Faulting
process is inconsistent (qs:cs0, Xwayland:cs0) — supports "next-on-ring"
attribution.

System

• GPU: RX 5700 XT via OCuLink eGPU dock → Navi 10 XL PCIe switch
  (02:00.0 upstream / 03:00.0 downstream) → Gen4 x4 link. Card is NOT in
  a direct PCIe slot.
• Kernel: 7.1.5-arch1-1; Mesa 26.1.5; vulkan-radeon/lib32 26.1.5;
  Proton Experimental. Wayland/niri + Xwayland.
• Kernel params: pcie_aspm=off amdgpu.runpm=0 amdgpu.noretry=1

Trigger pattern (differs from OP)

• ~1.5 h of sustained combat at 1440p/60 vsync-on: zero faults, temps
  normal (junc ~84°C, ~195W), fans quiet.
• Crash occurs specifically on scene/zone transition (entering a newly
  bought apartment = bulk asset + shader load). At crash moment: pkg 67°C,
  junc 79°C, 174W — not heat or sustained power.

Data points

• Matches OP: power/heat unrelated (crashes at normal temps and modest
  load); kernel flags reduce frequency, don't eliminate.
• Vsynced sustained load is stable; load bursts trip it — consistent
  with the parallel shader-compile theory on zone load (cf. #2895).
• Link is behind a PCIe switch at Gen4 x4; BIOS Gen3 downgrade does not
  affect the OCuLink/switch path.

/END AI SUMMARY

The most notable changes that really improved my most recent gameplay experience:

• Change GPU mode from manual to COMPUTE: i think this was a lingering setting from my previous dGPU
• ^ this i believe gives me access to Zero RPM feature
• PCie speed from Gen 4 to Gen 3
• CPU cooling profile from Performance to Balanced

And so with these changes basically I had a very quiet almost 2 hours of gameplay (fans barely audible) but most importantly I only encountered the crash when I got to an area of the game that I had not yet visited. I don't know if that's helpful but felt I should include it. Previously, the fans were loud because of mis-configured power profile; I would anticipate a crash in the tail end of a long gun battle, or in the subsequent looting.

I may try installing the LTS to see if that reduces the chances of crash even more, but at the moment I'll just play a bit more and gather more data. Cheers, thank you all.

Another data point for this issue, with kernel-level evidence from an AMDGPU device coredump.

Same hardware (Navi 10 / RX 5700 XT) and the exact symptom described in the OP — picture freezes while audio keeps playing and input still works — but on a different distro, different Mesa version, different Proton build and a different game. That combination suggests this is not specific to a single Mesa release.

Environment

Kernel evidence: GPU page fault at address 0x0

This is the part I have not seen posted in this issue yet. The devcoredump identifies the hang as a page fault on a NULL address, not a generic timeout:

**** AMDGPU Device Coredump ****
version: 1
kernel: 6.17.7-ba29.fc43.x86_64
module: amdgpu
time: 4613.177080372
process_name: ForzaHorizon5.e PID: 10960

Ring timed out details
IP Type: 0 Ring Name: gfx_0.0.0

[gfxhub] Page fault observed
Faulty page starting at address: 0x0000000000000000
Protection fault status register: 0x0

Relevant registers:

mmGRBM_STATUS                       0x00003028
mmGRBM_STATUS2                      0x00100008
mmCP_STALLED_STAT1                  0x00000c00
mmGCVM_L2_PROTECTION_FAULT_CNTL     0x3ffffffc
mmGCVM_L2_PROTECTION_FAULT_STATUS   0x00501011

Decoding GCVM_L2_PROTECTION_FAULT_STATUS = 0x00501011:

• MORE_FAULTS = 1
• WALKER_ERROR = 0
• PERMISSION_FAULTS = 1
• MAPPING_ERROR = 0

So the page-table walker itself is healthy — this is a read of an unmapped NULL address, which looks like a null-descriptor / dangling-descriptor problem rather than page-table or memory-management corruption.

The hung ring at the time of the dump:

ring name: gfx_0.0.0
Rptr: 0x100 Wptr: 0x170100 RB mask: 7ff
Ring size in dwords: 2048

Timeline

Two independent occurrences in a single boot, 28 minutes apart, 19 ring gfx_0.0.0 timeout events total. Both follow an identical pattern — the driver resets the ring successfully every time, but the same faulting submission is retried ~10 s later, until the compositor is dragged down with it:

12:04:45 amdgpu: ring gfx_0.0.0 timeout, signaled seq=866078, emitted seq=866080
12:04:45 amdgpu:  Process ForzaHorizon5.e pid 4056 thread vkd3d_queue pid 4147
12:04:45 amdgpu: Ring gfx_0.0.0 reset succeeded
12:04:45 [drm] device wedged, but recovered through reset
         ... repeats every ~10s, always blaming vkd3d_queue ...
12:05:12 steam: CSteamEngine::BMainLoop appears to have stalled > 15 seconds
12:05:28 steam: killing all Forza Horizon 5 processes
12:05:36 amdgpu: ring gfx_0.0.0 timeout ... Process Xwayland pid 2184 thread Xwayland:cs0
12:05:37 Xwayland + mangoapp both SIGABRT -> gamescope session dies and auto-restarts

The kernel never panics and the ring reset always reports success — the session collapse is collateral damage once Xwayland's own submissions start faulting.

Ruled out

• Not thermal / power / clocks. Junction temp 57 °C, stock 190 W cap, power_dpm_force_performance_level=auto, no over/underclocking. (Consistent with the OP, where dropping to 300 MHz / 40 W did not help.)
• Not VRAM or system memory pressure. 840 MB of 8 GB VRAM in use, 11 GB of 16 GB system RAM free, no OOM events.
• Not a kernel panic or a driver-level GPU reset. Guest kernel uptime is continuous across both incidents; only the userspace session restarts.

Full coredump

I still have the complete 5.9 MB devcoredump (105 KB compressed) and can attach it or pull any specific section out of it on request — the ring contents are 2054 lines and I left them out here for length. Happy to run further diagnostics on this machine; the hang reproduces reliably enough to test candidate fixes.

System

• GPU: PowerColor Red Devil RX 5700 XT 8GB
• Driver: amdgpu / Mesa RADV
• Mesa: 26.2.1
• OS: Bazzite 44
• Kernel: 7.2.0-ogc6.1.fc44
• Proton: reproduced with multiple Proton versions, including Proton Experimental
• Both DX11/DXVK and DX12/VKD3D have triggered the problem

I’m seeing very similar behaviour with Control on a PowerColor Red Devil RX 5700 XT (Navi10), using RADV/AMDGPU on Bazzite.

Control under DX12/VKD3D can randomly hard-lock the GPU. It does not appear to be tied to sustained GPU load; one crash happened simply turning a corner / entering another area, possibly during asset, shader or resource streaming.

Findings so far:

• DX12/VKD3D is noticeably less stable than DX11/DXVK.
• Control can crash even with the GPU using its default profile.
• Other games and Superposition remain stable, including with a 220 W power limit and OC/UV profile.
• Control is currently the only game reproducing these GPU lockups.
• A 150 W power-capped profile appears to prevent the crashes so far.
• Higher power/boost operation seems to make the issue easier to trigger, but it does not look like straightforward OC instability because the issue also occurs at default settings.
• DX11/DXVK has also caused a GPU ring timeout on this system, but is substantially more stable than DX12/VKD3D.

My current suspicion is a Control/VKD3D/RADV/AMDGPU issue on Navi10 that may be sensitive to GPU power/clock-state transitions. The 150 W cap may be masking the underlying problem rather than fixing it.

I have a detailed AMDGPU log from a DX11/DXVK occurrence showing a gfx ring timeout and full GPU reset, but I have not yet captured the equivalent kernel trace from a DX12/VKD3D crash.

I can provide additional AMDGPU logs/devcoredumps from the next DX12 occurrence if useful.

Running 550W gold PSU, same issue from an older bronze 550W bronze PSU, getting a 1000W gold PSU.

Settings/effects/resolution makes no difference. Only experiencing with AMD, not Nvidia.

Latest crash

ring gfx_0.0.0 timeout
Process Control_DX12.ex
thread vkd3d_queue
Starting gfx_0.0.0 ring reset
Ring gfx_0.0.0 reset failed
GPU reset begin!
BACO reset

GPU reset succeeded, trying to resume
VRAM is lost due to GPU reset!

Pasted markdown(4).md

Update Sept 2nd 2026
Added RADV dump

The issue is highly reproducible in Control, particularly when moving into another area / during level or area transitions. It has occurred at low graphics settings as well as normal settings, so it does not appear to require high sustained GPU load.

The initial kernel failure is:

amdgpu: ring gfx_0.0.0 timeout
Process Control_DX12.ex
thread vkd3d_queue
Starting gfx_0.0.0 ring reset
Ring gfx_0.0.0 reset failed
GPU reset begin!
BACO reset
GPU reset succeeded, trying to resume
VRAM is lost due to GPU reset!

The later KWin/Plasma/other process faults happen after VRAM is lost and appear to be fallout from the initial Control/VKD3D GPU hang.

RADV hang dump

I reproduced the issue with:

RADV_DEBUG=hang,pso_history

RADV successfully captured the hang:

radv_dumps_5311_2026.09.02_17.15.58

The command trace is particularly useful.

Trace point 19 is reported as:

This is the last trace point that was reached by the CP

Immediately after trace point 19 is:

DISPATCH_DIRECT(shader_type=compute):
    DIM_X = 8100
    DIM_Y = 1
    DIM_Z = 1

The compute workgroup size is:

64 x 1 x 1

After the dispatch, the command stream issues a CS_PARTIAL_FLUSH.

Trace point 20 immediately following this was NOT reached by the command processor.

So the captured sequence is effectively:

trace point 19 reached
    -> compute dispatch 8100 x 1 x 1
    -> CS_PARTIAL_FLUSH
    -> trace point 20 never reached

Pipeline at the hang

RADV identified:

Pipeline hash: d6797a281861a397

Compute shader details:

Workgroup size: 64 x 1 x 1
SGPRs: 108
VGPRs: 84
Spilled SGPRs: 0
Spilled VGPRs: 0
LDS size: 512 bytes
Scratch size: 0
Instructions: 2043
Code size: 10812 bytes

Dumped SPIR-V:

c0505b5abfa3272b5f0adc13b560936ddde8aa25f12a885088b905084c4ec5e6.spv

The SPIR-V contains the source DXIL identifier:

b49041fd93bef430.dxil

The shader uses 2D textures, a 3D texture, SSBOs and a write-only 2D image.

vm_fault.log in the RADV report is empty, so there was no GPU VM fault captured as the initiating event.

bo_ranges.log says BO VA ranges were unavailable because RADV_DEBUG=allbos was not enabled.

UMR ring/wave information was also unavailable because umr is not installed.

Activity immediately before the hang

The VKD3D log shows a burst of shader/PSO activity immediately before RADV detects the hang.

At ~820.08 s VKD3D begins parsing/creating another group of DXBC/PSO state. At 821.108 s it reports:

Flushing disk cache (wakeup counter since last flush = 30).
It seems like application has stopped creating new PSOs for the time being.

Immediately afterwards:

radv: GPU hang detected...
radv: GPU hang report will be saved to
'/home/.../radv_dumps_5311_2026.09.02_17.15.58'

Larger PSO batches occurred earlier in the same run without crashing, so the number of PSOs alone does not seem to be the cause.

The same shader/hash groups also occur earlier without immediately causing a hang, suggesting it may depend on the resource/state combination rather than simply one shader always being invalid.

radv_dumps_5311_2026.09.02_17.15.58.tar.gz

Just experienced this problem on Witcher 3

System Info

• Operating System: Arch Linux
• Kernel Version: 7.1.9-arch1-2 (64-bit)
• Graphics Platform: Wayland
• Processors: 12 × AMD Ryzen 5 9600X 6-Core Processor
• Memory: 48 GiB of RAM (46.2 GiB usable)
• Graphics Processor 1: AMD Radeon RX 9070 XT
• Graphics Processor 2: AMD Ryzen 5 9600X 6-Core Processor
• Manufacturer: Gigabyte Technology Co., Ltd.
• Product Name: B850 GAMING X WIFI6E
• System Version: Default string-WCP-ADO
• Mesa: 1:26.2.1-1
• Running Steam version 1785799196 with Proton Experimental

Only experienced it once so far, with DX12.

Kernel log:

[  +9.119278] amdgpu 0000:03:00.0: Dumping IP State
[  +0.000942] amdgpu 0000:03:00.0: Dumping IP State Completed
[  +0.000012] amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created
[  +0.000001] amdgpu 0000:03:00.0: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
[  +0.000001] amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=13147780, emitted seq=13147783
[  +0.000002] amdgpu 0000:03:00.0:  Process witcher3.exe pid 1344338 thread vkd3d_queue pid 1344534
[  +0.000001] amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
[  +2.210462] amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
[  +0.000006] amdgpu 0000:03:00.0: GPU reset begin!. Source:  1
[  +2.225264] amdgpu 0000:03:00.0: MES(1) failed to respond to msg=REMOVE_QUEUE
[  +0.000006] amdgpu 0000:03:00.0: failed to unmap legacy queue
[  +0.211373] [drm:gfx_v12_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
[  +0.027562] amdgpu 0000:03:00.0: MODE1 reset
[  +0.000004] amdgpu 0000:03:00.0: GPU mode1 reset
[  +0.000042] amdgpu 0000:03:00.0: GPU smu mode1 reset
[  +1.020223] amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
[  +0.000082] amdgpu 0000:03:00.0: [drm] PCIE GART of 512M enabled (table at 0x00000083DAB00000).
[  +0.000047] amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
[  +0.000001] amdgpu 0000:03:00.0: PSP is resuming...
[  +0.239453] amdgpu 0000:03:00.0: RAP: optional rap ta ucode is not available
[  +0.000004] amdgpu 0000:03:00.0: SECUREDISPLAY: optional securedisplay ta ucode is not available
[  +0.000002] amdgpu 0000:03:00.0: SMU is resuming...
[  +0.067548] amdgpu 0000:03:00.0: SMU is resumed successfully!
[  +0.000187] amdgpu 0000:03:00.0: program CP_MES_CNTL : 0x4000000
[  +0.000003] amdgpu 0000:03:00.0: program CP_MES_CNTL : 0xc000000
[  +0.013574] amdgpu 0000:03:00.0: [drm] DMUB hardware initialized: version=0x0A000C00
[  +0.317234] amdgpu 0000:03:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[  +0.000005] amdgpu 0000:03:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[  +0.000001] amdgpu 0000:03:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[  +0.000001] amdgpu 0000:03:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
[  +0.000000] amdgpu 0000:03:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
[  +0.000001] amdgpu 0000:03:00.0: ring sdma0 uses VM inv eng 9 on hub 0
[  +0.000001] amdgpu 0000:03:00.0: ring sdma1 uses VM inv eng 10 on hub 0
[  +0.000001] amdgpu 0000:03:00.0: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[  +0.000000] amdgpu 0000:03:00.0: ring jpeg_dec uses VM inv eng 1 on hub 8
[  +0.004599] amdgpu 0000:03:00.0: GPU reset(1) succeeded!
[  +0.001475] amdgpu 0000:03:00.0: [drm] *ERROR* Failed to initialize parser -125!
[  +0.011931] amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed

Several processes crashed, presumably they were using the GPU and didn't know how to recover (e.g. 1Password, Ghostty, Steam).

The coredump from the GPU: gpu-coredump.gz

Hi mates,

In my case, I tried lot of stuff and lately (about a month I think) havent got any problem with any other DX12 game. What I tend to think is some kind of wrong max mV power/clocks speed informed by kernel (firmware?), so setting everything MANUALY to these limits (sapphire stock card limits) worked fine for me (dont call the devil please!)

I.E. what I notice is a default of 2900 gpu max clock informed, but my card is 2680. So, if I leave settings default fresh as new installation, max clock is wrong.

I spent probably 8 hours debugging this issue. Let me know what info would actually be helpful if more is needed. I am running Horizon Zero Dawn Remaster through steam on Proton 11.0-2.

• AMD Ryzen 9 7950X (32) @ 5.88 GHz
• AMD Radeon RX 7900 XTX [Discrete]
• 32GB DDR5 RAM
• Archlinux
• Kernel 7.2.7-zen1-1-zen
• Wayland
• GPU0:
  apiVersion = 1.4.354
  driverVersion = 26.2.3
  vendorID = 0x1002
  deviceID = 0x744c
  deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
  deviceName = AMD Radeon RX 7900 XTX (RADV NAVI31)
  driverID = DRIVER_ID_MESA_RADV
  driverName = radv
  driverInfo = Mesa 26.2.3-arch1.1
  conformanceVersion = 1.4.5.3

Another Navi10 data point, this time with Path of Exile 2 (Steam appid 2694490). The distinguishing detail in my case is that amdgpu directly attributed one of the ring timeouts to the game's vkd3d queue thread, and all three faults I captured landed on the compute client (CPG) rather than the graphics client.

Reproduces reliably — 3 GPU hangs / resets in roughly 1.5 hours of play. Symptoms differ slightly from the OP: the screen freezes, and then Hyprland itself aborts rather than just hanging, because the compositor's GL context is dead after the BACO reset and hits an unrecoverable assert. Steam and the game die with it.

Environment

Kernel log

All three events show the same fault signature, on the compute client:

amdgpu 0000:28:00.0: gfxhub page fault (src_id:0 ring:24 vmid:6 pasid:316)
amdgpu 0000:28:00.0: in page starting at address 0x000080000f065000 from client 0x1b (UTCL2)
amdgpu 0000:28:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00600C31
amdgpu 0000:28:00.0: Faulty UTCL2 client ID: CPG (0x6)
amdgpu 0000:28:00.0: MORE_FAULTS: 0x1
amdgpu 0000:28:00.0: PERMISSION_FAULTS: 0x3
amdgpu 0000:28:00.0: MAPPING_ERROR: 0x0
amdgpu 0000:28:00.0: ring gfx0.0.0 timeout, signaled seq=4283982, emitted seq=4283985
amdgpu 0000:28:00.0: Ring gfx0.0.0 reset failed
amdgpu 0000:28:00.0: GPU reset begin!. Source: 1
amdgpu 0000:28:00.0: BACO reset
amdgpu 0000:28:00.0: VRAM is lost due to GPU reset!
amdgpu 0000:28:00.0: drm device wedged, but no recovery needed

The third event is the one that names the game, on the compute ring:

amdgpu 0000:28:00.0: ring comp_1.3.1 timeout, signaled seq=379146, emitted seq=379149
amdgpu 0000:28:00.0: Process Main pid 30267 thread vkd3d_queue pid 30417

pid 30267 is the Path of Exile 2 process (thread vkd3d_queue), so this is a direct attribution of a compute ring timeout to VKD3D.

Do it https://github.com/HansKristian-Work/vkd3d-proton/issues/3336

I spent probably 8 hours debugging this issue. Let me know what info would actually be helpful if more is needed. I am running Horizon Zero Dawn Remaster through steam on Proton 11.0-2.

Hi, just for my curiosity... have you tried manually setting GPU Max clock to your card factory specs? and no automatic default management?