protonscr

Marvel Rivals: reproducible GPU page fault (SQC data) on RX 9070 XT / RDNA4, preceded by FSR_API_DEBUG_ERROR

vkd3dopen
HansKristian-Work/vkd3d-proton#3221 · opened 2026-08-19 by binido · updated 2026-08-20 · 2 comments · github
Bbinido 2026-08-19 github

System info

  • GPU: AMD Radeon 9070 XT (Navi 48, RDNA4, gfx1201)
  • Kernel: 7.1.8-1-cachyos
  • Mesa / RADV: 26.1.6
  • vkd3d-proton: commit 3dfc6f07d0953b1e8b41705275c2c59cc7374fc5 (2026-07-10), bundled via Proton-CachyOS cachyos-11.0-20260703-slr
  • Game: Marvel Rivals (Steam AppID 2767030), native FSR 3.1 (amd_fidelityfx_dx12.dll) shipped by the game
  • Launch options tested: Steamdeck=1 PROTON_LOG=1 VKD3D_DEBUG=err ...

Summary

Marvel Rivals reliably GPU-hangs after 20-70 min of play on RX 9070 XT. Every single hang (4/4 so far) is immediately preceded in the Proton log by the same FSR SDK warning, followed by a GPUVM fault at an SQC (data) client, then a ring gfx_0.0.0 timeout/reset:

warn:seh:OutputDebugStringA "FSR_API_DEBUG_ERROR: An instance of ffxCreateContextDescUpscaleVersion must be
attached to ffxCreateContextDescUpscale and specify a valid version to access new API functions.\n"
...
radv: GPUVM fault detected at address 0x8000<...>.
GCVM_L2_PROTECTION_FAULT_STATUS: 0x00601430 / 0x00701430 / 0x00501430 (varies)
	 Faulty UTCL2 client ID: SQC (data) (0xa)

Matching dmesg for one occurrence:

amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:7 pasid:203)
amdgpu 0000:03:00.0:  Process GameThread pid 8679 thread vkd3d_queue pid 8895
amdgpu 0000:03:00.0:   in page starting at address 0x000080004048a000 from client 10
amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00701431
amdgpu 0000:03:00.0:          Faulty UTCL2 client ID: SQC (data) (0xa)
amdgpu 0000:03:00.0:          MORE_FAULTS: 0x1
amdgpu 0000:03:00.0:          PERMISSION_FAULTS: 0x3
amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=28253032, emitted seq=28253035
amdgpu 0000:03:00.0:  Process GameThread pid 8679 thread vkd3d_queue pid 8895
amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset succeeded
amdgpu 0000:03:00.0: [drm] device wedged, but no recovery needed

What I've tried

  1. Blocking the CachyOS-injected amdxcffx64.dll (driver-side FSR4 upgrade) via WINEDLLOVERRIDES="amdxcffx64=". Confirmed in the Proton log that the DLL failed to load (err:amdxc:AMDFSR4FFX_UpdateFfxApiProvider Failed to load FSR4 dll (amdxcffx64)!), so the game was running on its native FSR 3.1 path only — hang still occurred with the identical SQC (data) signature. Rules out the FSR4 driver shim as the cause.
  2. VKD3D_CONFIG=retain_descriptor_heaps (per #3034/#3047) — hang still occurred, same SQC (data) client, same FSR_API_DEBUG_ERROR immediately before it.
  3. Checked whether the fix from #3034/#3047 (PR #3074, "Rewrite how resources get retained for workaround purposes", merged into master 2026-06-10) is already present in the vkd3d-proton commit I'm running (2026-07-10, 65 commits ahead of the fix commit, 0 behind) — it is. So this does not look like the same bug that was fixed there.

Related issues

  • #2933 — another RDNA4 user (RX 9060 XT) hitting page faults in this same game, also from GameThread/vkd3d_queue, still open, no resolution posted.
  • #3034 / #3047 — Borderlands 4, same SQC (data) fault signature and FSR involvement, but that specific bug is already fixed in the vkd3d-proton commit I'm using.

Question

Is the recurring FSR_API_DEBUG_ERROR: An instance of ffxCreateContextDescUpscaleVersion must be attached... warning expected/benign, or is it a sign of a genuine bug in how Marvel Rivals's FSR 3.1 integration interacts with vkd3d-proton's descriptor/resource handling on RDNA4? Happy to capture RADV_DEBUG=bo_history or VKD3D_CONFIG=fault output on my next repro if that would help narrow it down.

Workaround

Disabling the in-game Upscaling option (switching away from FSR) appears to avoid the hang entirely (not yet tested to full completion on my end, but this matched what fixed the equivalent bug for other users in #3047).

Bbinido 2026-08-19 github

Got a fresh repro with RADV_DEBUG=bo_history VKD3D_CONFIG=retain_descriptor_heaps,fault set.

dmesg:

amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:5 pasid:128)
amdgpu 0000:03:00.0:  Process GameThread pid 20834 thread vkd3d_queue pid 21029
amdgpu 0000:03:00.0:   in page starting at address 0x000080004083e000 from client 10
amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00501430
amdgpu 0000:03:00.0:          Faulty UTCL2 client ID: SQC (data) (0xa)
amdgpu 0000:03:00.0:          PERMISSION_FAULTS: 0x3
amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=37913646, emitted seq=37913649
amdgpu 0000:03:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset succeeded

vkd3d-proton's own address binding tracker on the same fault:

err:vkd3d-proton:d3d12_device_report_fault: Desc: A GPUVM fault has been detected
err:vkd3d-proton:vkd3d_address_binding_tracker_check_va: Received fault in address ffff80004083e000 @ 5098.294617 s. Scanning through address log ...
err:vkd3d-proton:vkd3d_address_binding_tracker_check_va: Found no candidate VA entries. Page fault was likely caused by accessing never used memory or out of bounds access. Scanning for nearby allocations ...

I also grepped the full radv_bo_history.log (68432 entries) for any BO whose VA range ever covered 0x80004083e000 at any point in the session, retain_descriptor_heaps included — zero matches. So this doesn't look like the Borderlands 4 use-after-free (#3034/#3047): there's no BO that was bound there and later destroyed, the address was never allocated through vkd3d-proton's tracked paths at all. Lines up with the tracker's own "out of bounds access" verdict rather than a stale/freed pointer.

The same FSR_API_DEBUG_ERROR: ffxCreateContextDescUpscaleVersion must be attached... warning shows up in the log a few seconds before this fault too, same as every previous occurrence, for what it's worth — but given the OOB verdict above, I'm not sure the FSR warning and the fault are the same bug rather than two symptoms of the same underlying shader/resource issue.

Happy to grab a d3d12_command_queue_execute capture or anything else that would help narrow down which draw/dispatch is doing the out-of-bounds access if there's a config for that.

Bbinido 2026-08-20 github

Correction to my previous comment, and I think this issue can probably be closed as misfiled.

Two things I got wrong above:

1. The FSR warning is not temporally adjacent to the fault. I said it appears "a few seconds before" — that was sloppy on my part. Actual timestamps from the runs:

Run FSR_API_DEBUG_ERROR at GPUVM fault at Gap
A 4623.75 s 5098.29 s ~8 min
B 958.85 s, 1386.97 s 1634.53 s ~4 min

It only fires 2-3 times per session (looks like FSR context creation), and never close to the fault. There is no causal link visible in the logs — I pattern-matched two unrelated log entries.

2. The game is not shipping an outdated FSR runtime. I tested swapping in the curated FSR 3.1 DLL (Proton-CachyOS ffx3 upgrade path, v1.0.1.41314). The downloaded DLL is byte-identical to the one the game ships — same MD5 49230ad94ed6169933cd0457501d9cb4. No-op, and the fault reproduced unchanged.

What this actually looks like: https://gitlab.freedesktop.org/mesa/mesa/-/issues/16120 — RX 9070 XT / gfx1201, SQC (data) (0xa), PERMISSION_FAULTS: 0x3, ring gfx_0.0.0 timeout, device wedged, but no recovery needed, hanging after 20-30 min. Identical signature to mine, but reproducing across The Witcher 3, Hogwarts Legacy and Jurassic Park Evolution, and — importantly — on both RADV and radeonsi. There's an OpenGL-only variant of the same fault class on the same GPU in https://gitlab.freedesktop.org/mesa/mesa/-/issues/15812 (Minecraft + Iris shaderpacks, no D3D12 involved at all).

So this is very unlikely to be a vkd3d-proton bug — nothing in my data points at the D3D12 layer specifically, and the same fault happens on paths that never touch it. Sorry for the noise. Happy for this to be closed; I'll take the data over to the Mesa issue.

Launch options

DLLs