MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Linux AMD RADV (RX 6650 XT, Mesa 26.2.6): GPU reset as soon as the world loads — comp_1.3.0 → gfx_0.0.0 timeout, MODE1 reset, Wayland session lost (same fingerprint as #2245) #2590

Closed

opened 2026-11-12 00:38:28 +00:00 by TuxArchi · 1 comment

TuxArchi commented

2026-11-12 00:38:28 +00:00

(Migrated from github.com)

Hookshot version

v2.1.0 (source e561602e), Linux AppImage

What kind of problem

Crash, freeze or black screen

What happened

Every session ends with a GPU hang the moment the world/map loads. The in-game
menu and the loading screens never crash: the reset arrives with the first frames
of the world, when the texture/shadow/pipeline burst happens.

The kernel performs a full MODE1 reset ("VRAM is lost due to GPU reset!") and the
Wayland session dies with it (Hyprland aborts in CHyprOpenGLImpl::begin right
after the VRAM loss). This is not the game window crashing: the GPU is reset.

This is the same defect already reported in #2245 (RX 6600 XT / RX 6800 / Steam
Deck). The log carries the identical fingerprint line:

[hos host] vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20

Same program hash, same stage, same binding address, same size, and the same
precursors (a capture's wait for write-back … timed out, ~250 ms memory sync
submits). New data point: Navi 23 / RX 6650 XT, Mesa 26.2.6, kernel 7.2.14.

Where in the game

Right after the world/map loads and gameplay starts. The in-game menu and the
loading screens are fine. Not tied to a cutscene (unlike #2245, which happened
before the Great Deku Tree appears).

How often

Every time — every single session, without exception.

Graphics card and driver version

AMD Radeon RX 6650 XT (RADV NAVI23), Vulkan 1.4, driver 0x6802006
mesa 1:26.2.6-1, vulkan-radeon 1:26.2.6-1, libdrm 2.4.134-1
amdgpu, linux 7.2.14-arch1-1, 8 GB VRAM (8176 MiB), ppfeaturemask 0xfff7bfff
stock clocks, no overclock/undervolt/power-limit change

CPU, RAM and operating system

AMD Ryzen 7 5800X (8C/16T), 32 GB RAM, Arch Linux, kernel 7.2.14-arch1-1
Wayland: Hyprland 0.57.2-1 + aquamarine 0.16.0-1

Changes from the defaults

The crashing runs were stock: no RX_VK_* variables, and mesh_shaders=0
(Automatic), which the log resolves to mesh shaders row: Automatic (native).

The session that works differs in exactly one line:

- mesh_shaders=0
+ mesh_shaders=2        # Compute, the workaround from #2245

Other relevant values, unchanged in both: quality_preset=0,
output_res=1920x1080, resolution=3, descriptor_reuse=1, sampler_cache=0,
robust_buffers=0, frame_generation=0, dlss=3.

Other software hooked into the game

No overlays (no MangoHud, no Gamescope, no vkBasalt), no wrappers. Launched from
the builder's desktop shortcut (AppImage --launch <game folder>).

hookshot_log.txt

Full log: linked at the end of this report (a gist with hookshot_log.txt,
256 KB, no game files). Note: it contains two boots of the game (the second boot: is
at line 844); the second one is the one that hung. The 55m44s of the systemd scope
is process lifetime — menu, shader preparation and two boots — not gameplay time.

Tail before the reset:

[hos Presentation Thread] vk: a frame's uploads took 50 ms: ASTC on the GPU 177 (153.7 MB, 48 ms); on the CPU 17 (7.7 MB, 3 ms); [3072x3072 x1 NVN 0x7b ASTC on the GPU 7.8 MB 10 ms]
[hos Presentation Thread] vk: 167 new ASTC textures left for a later frame (this frame's uploads took their budget; 512 so far)
[hos sead::MainThread] vk: a capture's wait for write-back 6035 timed out (done 6031)
[hos sead::MainThread] vk: slow submit: 257.5 ms: memory sync 257.4
[hos Presentation Thread] vk: a capture's wait for write-back 6035 timed out (done 6031)
[hos Presentation Thread] vk: slow submit: 253.6 ms: memory sync 253.4
[hos host] vk: a capture's wait for write-back 6035 timed out (done 6031)
[hos host] vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20
[hos host] vk: sampler 431 is nearest: min filter 0, mag filter 0, wrap 7/7/7, lod 0..0 bias 0, aniso 1, compare 0
[hos OptimizeChangeBanc] nvn: 13 copies of recordings whose control memory was reused let go (27514 live)
radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
[hos OptimizeChangeBanc] vk: batched submit 912 failed (-4)
[hos OptimizeChangeBanc] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)
[hos OptimizeChangeBanc] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more (on Linux, dmesg or journalctl -k around this time names the reset)

Last memory block reported before the hang:

[hos Presentation Thread] vk: memory: working set 5720 MB (peak 5875), private 2548 MB, staging 128 MB in 2 arenas
[hos Presentation Thread] vk: memory heaps: heap 0 (system): 9 blocks 229 MB, 35 allocations 199 MB; used 406 of 15868 MB; heap 1 (device): 60 blocks 896 MB, 190 allocations 715 MB; used 1283 of 7704 MB;
[hos Presentation Thread] vk: VRAM: 1283 MB used of 7704 MB allowed (180 MB of it free in the blocks); textures 112 MB (budget 3458 MB), 126 textures

Kernel side (journalctl -k), same second:

amdgpu 0000:09:00.0: ring comp_1.3.0 timeout, signaled seq=28121, emitted seq=28122
amdgpu 0000:09:00.0:  Process exe pid 346207 thread OptimizeChangeB pid 348201
amdgpu 0000:09:00.0: Starting comp_1.3.0 ring reset
amdgpu 0000:09:00.0: Ring comp_1.3.0 reset succeeded
amdgpu 0000:09:00.0: ring gfx_0.0.0 timeout, signaled seq=6976063, emitted seq=6976065
amdgpu 0000:09:00.0:  Process exe pid 346207 thread OptimizeChangeB pid 348201
amdgpu 0000:09:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:09:00.0: Ring gfx_0.0.0 reset failed
amdgpu 0000:09:00.0: GPU reset begin!. Source:  1
amdgpu 0000:09:00.0: MODE1 reset
amdgpu 0000:09:00.0: GPU reset succeeded, trying to resume
amdgpu 0000:09:00.0: VRAM is lost due to GPU reset!
amdgpu 0000:09:00.0: GPU reset(2) succeeded!
amdgpu 0000:09:00.0: [drm] device wedged, but no recovery needed

Note the shape: the compute ring times out first and its ring reset succeeds,
while the gfx ring reset fails and forces the MODE1 reset — the same
"gfx ring and RADV gang compute ring stuck waiting on each other" shape described
in #2245.

Workaround confirmed on this card: `mesh_shaders=2` (Compute)

With mesh_shaders=2 the log says, at start-up:

[hos host] vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback)
[hos host] vk: mesh shaders row: Compute (the compute path)

Result (same GPU, same driver, same build, map loaded and played):

49,584 frames presented, 57–60 fps
journalctl -k since start: 0 ring … timeout, 0 GPU reset begin,
0 VRAM is lost
VRAM at that point: 5416 MB used of 7395 allowed, 3069 MB of textures
(budget 3445 MB). The working session uses more VRAM than the crashing one
(1283 MB used, ~2.3 GB of textures), so this is not a VRAM-exhaustion bug.
Only cost: the first start after switching re-prepares more programs (task/mesh
are built as compute), so "preparing shaders" takes longer, and fps varies with
the scene.

Not a fix, and not my finding: this is DuxMuxxy's workaround from #2245,
confirmed upstream by Fortich on RX 6800 XT. I am adding the Navi 23 data point.

For diagnosis only, not part of the workaround: hookshot_env.txt with
RX_VK_CHECKPOINTS=1 (VK_AMD_buffer_marker before each draw and dispatch).

Ruled out

VRAM: see above; the passing session uses more VRAM than the crashing one,
there is no vkAllocateMemory failure anywhere, and the crashing log never
went past ~2.4 GB of textures on an 8 GB card.
Hardware / PSU / thermals: the same save runs ~56 minutes in Lichii
(Switch 2 emulator, Vulkan) on this same GPU with zero amdgpu faults. In the
same boot, SharpEmu (PS5, 22.4 GB peak) and local-LLM inference on the GPU also
ran without a single reset. Only Hookshot resets the GPU.
One specific shader: the compute ring and the gfx ring time out together,
and the compute ring reset succeeds while the gfx one fails.

Next steps I can provide

A native (mesh_shaders=0) run with RX_VK_CHECKPOINTS=1 to name the last
program/dispatch before the hang, plus the amdgpu devcoredump (waves stuck vs
VM page fault), if that helps PR #2362/#2311.

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

Full hookshot_log.txt (256 KB, no game files): https://gist.github.com/TuxArchi/dd6eec29b8212b500be0b9fcfc7bdf11

### Hookshot version v2.1.0 (source e561602e), Linux AppImage ### What kind of problem Crash, freeze or black screen ### What happened Every session ends with a GPU hang the moment the world/map loads. The in-game menu and the loading screens never crash: the reset arrives with the first frames of the world, when the texture/shadow/pipeline burst happens. The kernel performs a full MODE1 reset ("VRAM is lost due to GPU reset!") and the Wayland session dies with it (Hyprland aborts in `CHyprOpenGLImpl::begin` right after the VRAM loss). This is not the game window crashing: the GPU is reset. This is the same defect already reported in #2245 (RX 6600 XT / RX 6800 / Steam Deck). The log carries the identical fingerprint line: ``` [hos host] vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20 ``` Same program hash, same stage, same binding address, same size, and the same precursors (`a capture's wait for write-back … timed out`, ~250 ms `memory sync` submits). New data point: Navi 23 / RX 6650 XT, Mesa 26.2.6, kernel 7.2.14. ### Where in the game Right after the world/map loads and gameplay starts. The in-game menu and the loading screens are fine. Not tied to a cutscene (unlike #2245, which happened before the Great Deku Tree appears). ### How often Every time — every single session, without exception. ### Graphics card and driver version ``` AMD Radeon RX 6650 XT (RADV NAVI23), Vulkan 1.4, driver 0x6802006 mesa 1:26.2.6-1, vulkan-radeon 1:26.2.6-1, libdrm 2.4.134-1 amdgpu, linux 7.2.14-arch1-1, 8 GB VRAM (8176 MiB), ppfeaturemask 0xfff7bfff stock clocks, no overclock/undervolt/power-limit change ``` ### CPU, RAM and operating system ``` AMD Ryzen 7 5800X (8C/16T), 32 GB RAM, Arch Linux, kernel 7.2.14-arch1-1 Wayland: Hyprland 0.57.2-1 + aquamarine 0.16.0-1 ``` ### Changes from the defaults The crashing runs were stock: no `RX_VK_*` variables, and `mesh_shaders=0` (Automatic), which the log resolves to `mesh shaders row: Automatic (native)`. The session that works differs in exactly one line: ```diff - mesh_shaders=0 + mesh_shaders=2 # Compute, the workaround from #2245 ``` Other relevant values, unchanged in both: `quality_preset=0`, `output_res=1920x1080`, `resolution=3`, `descriptor_reuse=1`, `sampler_cache=0`, `robust_buffers=0`, `frame_generation=0`, `dlss=3`. ### Other software hooked into the game No overlays (no MangoHud, no Gamescope, no vkBasalt), no wrappers. Launched from the builder's desktop shortcut (AppImage `--launch <game folder>`). ### hookshot_log.txt Full log: linked at the end of this report (a gist with `hookshot_log.txt`, 256 KB, no game files). Note: it contains two boots of the game (the second `boot:` is at line 844); the second one is the one that hung. The 55m44s of the systemd scope is process lifetime — menu, shader preparation and two boots — not gameplay time. Tail before the reset: ``` [hos Presentation Thread] vk: a frame's uploads took 50 ms: ASTC on the GPU 177 (153.7 MB, 48 ms); on the CPU 17 (7.7 MB, 3 ms); [3072x3072 x1 NVN 0x7b ASTC on the GPU 7.8 MB 10 ms] [hos Presentation Thread] vk: 167 new ASTC textures left for a later frame (this frame's uploads took their budget; 512 so far) [hos sead::MainThread] vk: a capture's wait for write-back 6035 timed out (done 6031) [hos sead::MainThread] vk: slow submit: 257.5 ms: memory sync 257.4 [hos Presentation Thread] vk: a capture's wait for write-back 6035 timed out (done 6031) [hos Presentation Thread] vk: slow submit: 253.6 ms: memory sync 253.4 [hos host] vk: a capture's wait for write-back 6035 timed out (done 6031) [hos host] vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20 [hos host] vk: sampler 431 is nearest: min filter 0, mag filter 0, wrap 7/7/7, lod 0..0 bias 0, aniso 1, compare 0 [hos OptimizeChangeBanc] nvn: 13 copies of recordings whose control memory was reused let go (27514 live) radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent. [hos OptimizeChangeBanc] vk: batched submit 912 failed (-4) [hos OptimizeChangeBanc] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) [hos OptimizeChangeBanc] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more (on Linux, dmesg or journalctl -k around this time names the reset) ``` Last memory block reported before the hang: ``` [hos Presentation Thread] vk: memory: working set 5720 MB (peak 5875), private 2548 MB, staging 128 MB in 2 arenas [hos Presentation Thread] vk: memory heaps: heap 0 (system): 9 blocks 229 MB, 35 allocations 199 MB; used 406 of 15868 MB; heap 1 (device): 60 blocks 896 MB, 190 allocations 715 MB; used 1283 of 7704 MB; [hos Presentation Thread] vk: VRAM: 1283 MB used of 7704 MB allowed (180 MB of it free in the blocks); textures 112 MB (budget 3458 MB), 126 textures ``` Kernel side (`journalctl -k`), same second: ``` amdgpu 0000:09:00.0: ring comp_1.3.0 timeout, signaled seq=28121, emitted seq=28122 amdgpu 0000:09:00.0: Process exe pid 346207 thread OptimizeChangeB pid 348201 amdgpu 0000:09:00.0: Starting comp_1.3.0 ring reset amdgpu 0000:09:00.0: Ring comp_1.3.0 reset succeeded amdgpu 0000:09:00.0: ring gfx_0.0.0 timeout, signaled seq=6976063, emitted seq=6976065 amdgpu 0000:09:00.0: Process exe pid 346207 thread OptimizeChangeB pid 348201 amdgpu 0000:09:00.0: Starting gfx_0.0.0 ring reset amdgpu 0000:09:00.0: Ring gfx_0.0.0 reset failed amdgpu 0000:09:00.0: GPU reset begin!. Source: 1 amdgpu 0000:09:00.0: MODE1 reset amdgpu 0000:09:00.0: GPU reset succeeded, trying to resume amdgpu 0000:09:00.0: VRAM is lost due to GPU reset! amdgpu 0000:09:00.0: GPU reset(2) succeeded! amdgpu 0000:09:00.0: [drm] device wedged, but no recovery needed ``` Note the shape: the compute ring times out first and its ring reset succeeds, while the gfx ring reset fails and forces the MODE1 reset — the same "gfx ring and RADV gang compute ring stuck waiting on each other" shape described in #2245. ### Workaround confirmed on this card: `mesh_shaders=2` (Compute) With `mesh_shaders=2` the log says, at start-up: ``` [hos host] vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback) [hos host] vk: mesh shaders row: Compute (the compute path) ``` Result (same GPU, same driver, same build, map loaded and played): - 49,584 frames presented, 57–60 fps - `journalctl -k` since start: **0** `ring … timeout`, **0** `GPU reset begin`, **0** `VRAM is lost` - VRAM at that point: 5416 MB used of 7395 allowed, 3069 MB of textures (budget 3445 MB). The working session uses *more* VRAM than the crashing one (1283 MB used, ~2.3 GB of textures), so this is not a VRAM-exhaustion bug. - Only cost: the first start after switching re-prepares more programs (task/mesh are built as compute), so "preparing shaders" takes longer, and fps varies with the scene. Not a fix, and not my finding: this is DuxMuxxy's workaround from #2245, confirmed upstream by Fortich on RX 6800 XT. I am adding the Navi 23 data point. For diagnosis only, not part of the workaround: `hookshot_env.txt` with `RX_VK_CHECKPOINTS=1` (`VK_AMD_buffer_marker` before each draw and dispatch). ### Ruled out - **VRAM**: see above; the passing session uses more VRAM than the crashing one, there is no `vkAllocateMemory` failure anywhere, and the crashing log never went past ~2.4 GB of textures on an 8 GB card. - **Hardware / PSU / thermals**: the same save runs ~56 minutes in Lichii (Switch 2 emulator, Vulkan) on this same GPU with zero amdgpu faults. In the same boot, SharpEmu (PS5, 22.4 GB peak) and local-LLM inference on the GPU also ran without a single reset. Only Hookshot resets the GPU. - **One specific shader**: the compute ring and the gfx ring time out together, and the compute ring reset succeeds while the gfx one fails. ### Next steps I can provide - A `native` (`mesh_shaders=0`) run with `RX_VK_CHECKPOINTS=1` to name the last program/dispatch before the hang, plus the amdgpu devcoredump (waves stuck vs VM page fault), if that helps PR #2362/#2311. ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves. --- **Full `hookshot_log.txt` (256 KB, no game files):** https://gist.github.com/TuxArchi/dd6eec29b8212b500be0b9fcfc7bdf11

NotRexed commented

2026-11-12 03:08:16 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same kind are collected in #1000, which lists this one with your details and links back here, so one fix closes them together. Follow #1000 for the fix and add new details there (or here). If this turns out to be separate it will be reopened.