[Tracking] Linux and Steam Deck: GPU hangs, crashes, low FPS and build failures #1000
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#1000
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue collects every open report of Linux / Steam Deck GPU hangs, crashes, low fps and build failures, so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.
Summary
Linux reports that are still open after v2.0.6:
Two Linux problems are fixed in v2.0.6:
Affected GPUs and versions
Evidence from the logs
RADV GPU hangs
RADV low fps
RX_VK_BATCH_POLL_US=2000restores the fps (+65% on a 7900 XTX);RX_VK_PARALLEL=4withHOS_FPS_TARGET=60reached 55 fps.RADV rendering
NVIDIA on Linux
dma-buf not imported (-2)).Start-up
Builder
link FAILEDwith undefined f_8xxxxxxx symbols. Deletingsa/gen/.lift_keyis the workaround in #890; open PR #918 stops reusing an incomplete lift.hos_main.c:14: fatal error: '../gpu/vk/oot_cheat_items.h' file not found. A commenter copiedgpu/vk/oot_cheat_items.hfrom main into~/.local/share/hookshot/builder/versions/v2.0.6/usr/share/hookshot/gpu/vk/and the build finished.Wayland
nvn: window of 3 texturesand never reaches vkCreateInstance. It runs withSDL_VIDEODRIVER=x11plusVK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json.Workarounds
RX_VK_NO_MESH=1avoided it on v2.0.4 / v2.0.5.RX_VK_SKIP_CODE=2c56dc1006942f74needs hardicd's patch and is not in a release.RX_VK_BATCH_POLL_US=2000,RX_VK_PARALLEL=4.link FAILED: deletesa/gen/.lift_keyand build again.SDL_VIDEODRIVER=x11(#992).Reports merged here (25 issues, about 53 people)
97e7c55a598b9f58af2c0/15ec28d58af2c0+ ms-eviction patch; vanilla15ec28dsegfaults write 0x40 in libvulkan_radeon.so durin…a598b9fAdding a report
Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: distro, kernel, Mesa or NVIDIA driver version, GPU, version,
hookshot_log.txt, and for hangs thedmesglines around the reset.All tracking issues
Update from the #817 Deck (CachyOS, RADV VANGOGH, Mesa 26.2.6):
RX_VK_NO_MESH=1makes the game playable — confirmed tonight on v2.0.7-rc.1.Setup: Steam Deck (CachyOS Deckify), launch env
HOS_HANDHELD=1 RX_VK_CHECKPOINTS=1 RX_VK_NO_MESH=1, game at v2.0.7-rc.1.Results:
RX_VK_NO_MESH=1: ran straight past the Deku Tree, through the intro, into player control. Stable in gameplay; was able to create a save (so the long intro never has to be re-run to test). Base framerate ~12–20 fps with frame generation off; choppy in places, and some shader-compile stutter in new areas, but no hang.So the workaround does hold on the newest build, and the elimination is clean: mesh/task shaders on = hang at the Tree on every version tested (v2.0.3 → v2.0.7-rc.1); off = playable. That keeps the focus on the core issue — the task shader traced in this thread (2c56dc1006942f74, the nested 2D culling loop) and why it runs long enough on RDNA2/RADV to trip the GPU watchdog, while a desktop RDNA4 card finishes it in time.
Next test on this Deck (single change, will report back): re-enabling LSFG frame generation on top of NO_MESH to see if it stays stable.
Follow-up from the same Deck: LSFG test + overall verdict on the NO_MESH workaround.
Ran the promised single change: LSFG (lossless scaling frame generation) enabled on top of
RX_VK_NO_MESH=1, loading from the save created in the previous test (save/load works fine, no intro re-run needed).Results:
Verdict from this Deck: the NO_MESH workaround makes the game technically playable and is excellent as a diagnostic — it isolates the hang to the mesh/task shader path beyond reasonable doubt. But the resulting experience is workable-but-broken, not a viable way to play. The real fix has to be in that shader path itself (or in how long it is allowed to run on RADV/RDNA2), not in workarounds layered on top.
Saves from the stable run are backed up on this end, so this Deck is ready to re-test the moment a build touches the mesh path.
One more data point from the #817 Deck — tested whether submit settings can save the mesh path. They can't.
After the NO_MESH results above, I tried the "best of both worlds" experiment on v2.0.7-rc.1: mesh shaders back on, with
RX_VK_PARALLEL=4+RX_VK_BATCH_POLL_US=2000(the RADV submit settings from #528), LSFG on top.Result: hung at the Deku Tree again. The Deck's kernel log shows the same signature at 23:37 PT: GPU reset begin → MODE2 reset → reset succeeded — the game died in the reset, identical to the v2.0.3–v2.0.7-rc.1 no-workaround runs.
So on this hardware the elimination is now complete:
RX_VK_NO_MESH=1) → playable (with the flicker / missing-geometry costs already reported).That points squarely at the RDNA2 (Van Gogh) + RADV side of the mesh/task shader path itself — the nested culling task shader (2c56dc1006942f74) simply runs longer than the GPU watchdog allows on this chip, while RDNA4 desktop cards finish it in time. Nothing on the launch-settings side changes that; the fix has to come from the shader's compiled form or how it's dispatched.
This Deck is back on the stable NO_MESH + LSFG configuration, saves backed up, ready to re-test any build that touches the mesh path.
With RX_VK_NO_MESH=1, it now passes the intro cutscene and gets into gameplay on the RX 6600, but there is a lot of missing geometry (e.g., foliage in the intro scene, invisible doors, etc.).
Tested on v2.0.6
v2.0.7 works on NVIDIA here, for the tracker's "works" column: RTX 3060 12 GB, NVIDIA 615.78 (log:
vk: NVIDIA GeForce RTX 3060, Vulkan 1.4, driver 0x99d38200; mesh shaders yes, host memory import yes, pipeline libraries yes), Bazzite 45 (Fedora KDE Plasma, Wayland), Ryzen 12 threads, 15 GB RAM.oot_cheat_items.herror), then--prepare-shadersran in 9.8 s.RX_VK_NO_MESH, no crash or GPU hang, and no error or warning lines inhookshot_log.txt. The title movie ran at 60.0 fps (vk: ... presents, 60.0 fps) from about 360 presents on; the first 120 presents are slow (4-6 fps) while it starts up.Update, v2.0.10 (same machine, title screen only)
hookshot v2.0.10, same RTX 3060 / Vulkan 1.4 / mesh shaders yes line, no error or warning lines. The compile step took 1013 s this time (about 19 min in all), against about 2 min for v2.0.8 on the same box, so a first build here is slow even though the result is fine../bin/hookshot --prepare-shaders, the start-up precompile in the game takes 9-10 s (about 10,330 compute pipelines) and the title movie (AV1) reaches 60.0 fps; the first 120 presents run at about 7 fps and the next 120 at about 42 fps while the movie decoder starts, then it holds 59-60 fps (about 5,000 presents measured over two runs, one of them held 60 s at the title). SIGTERM exits cleanly (exit code 0), no.runningfile is left../bin/hookshotand./hookshotstop at a zenity "Update now / Not now / Skip this version" dialog before anything starts; started from a script with nobody at the screen it just sits there.HOOKSHOT_NO_UPDATE_CHECK=1skips the check.AI-assisted: run and collected by Claude Code on my behalf.
Adding a Linux/RADV data point on hardware that is not in the table yet: ROG Ally X (Z1 Extreme, RADV PHOENIX). Mostly good news, with three concrete problems and their log lines.
Setup
0x6802006(Mesa 26.2.6)a2043637)What works, against what the trackers describe
Built headless, which may be worth a line in the README:
Hookshot.AppImage --cli --nup ... --out ... --work ...works fine and is only documented in a comment insideAppRun. Build took 24 min 26 s (21 min 41 s compiling), 0 failed.1. Multi-second stalls around the Deku Tree scene
This is the most visible problem in play: the picture freezes for one to two seconds. The log attributes it to single uploads and submits, not to a steady load:
1256 ms to upload 408 KB stands out: that is 0.3 MB/s, so it reads like a stall rather than a bandwidth limit. Cumulative pipeline building over the session:
367 pipelines (17617 ms).2. Flicker: shadows, foliage, and occasional white flashes
In and around the Deku Tree scene the picture flickers, and it moves between targets: sometimes the shadows shimmer, sometimes the leaves / foliage, and every so often there is a whole-screen white flash.
The white flashes look like the same family as #1186 (AMD 8060S / Strix Halo, Linux RADV) and #1126 (Legion Go S, SteamOS), so this is probably a confirmation of those on another AMD iGPU — a Z1 Extreme on v2.0.10 — rather than something new. The shadow and foliage shimmer may be the same cause or a separate one; I cannot tell from the outside. Tracker is presumably #1005.
Textures themselves look correct between flashes. Happy to film it if a video helps tell these apart.
3. Frame rate
The 60 fps on the light scenes suggests the batched-submit work (PR #689) is doing its job here — I am not hitting the ~42 fps submit cap described in #789. I have not tried
RX_VK_BATCH_POLL_US=2000orRX_VK_PARALLEL=4from #528; tell me if a before/after on this APU is useful.4. Failed shader programs
151 at startup, 162 after a while in play. I do not know whether that count is expected; say the word and I will pull the list.
Also present, informational:
[a64] unimplemented importfor threenn::audiodevice-notification / auto-tune-volume symbols. Audio works.Not tested
I can test
I am a developer and the device is free for debugging. I can build from source with patches, run with any
RX_*/HOS_*variables, bisect versions, or capture logs and video for any of the three points above. Just say which would help most.Steam Deck LCD / SteamOS / RADV VANGOGH — Hookshot v2.0.10: reproducible GPU ring timeouts, MODE2 resets, desktop session disruption and 5.8 FPS in Kokiri
Hi NotRexed and contributors,
I'm following up with a detailed report from my Steam Deck LCD running SteamOS, after testing multiple Hookshot builds, most recently v2.0.10.
I managed to compile and launch the native Linux build, including shader preparation. However, loading Kokiri Forest remains unreliable, with severe rendering problems, extremely low FPS, Vulkan device loss, and, in some runs, GPU resets affecting the entire desktop session.
1. System information
Exact Mesa, Vulkan, kernel and SteamOS build numbers were not captured in this particular report.
2. Observed behavior
The game successfully launches and completes shader preparation. On v2.0.10, the preparation screen reported approximately 38,809 shaders.
However, loading Kokiri Forest frequently results in:
VK_ERROR_DEVICE_LOST.Earlier builds sometimes allowed limited movement and interaction in Kokiri Forest, but with significant graphical corruption and instability.
3. Launch configurations tested
Baseline workaround:
RX_VK_NO_FOLLOW=1 ./hookshotThis previously allowed the game to progress beyond an immediate Vulkan crash, but did not resolve the Kokiri GPU hang.
RADV submission polling adjustment:
RX_VK_NO_FOLLOW=1 RX_VK_BATCH_POLL_US=2000 ./hookshotThis did not produce a stable gameplay experience.
Experimental shader skip:
RX_VK_NO_FOLLOW=1 RX_VK_SKIP_CODE=2c56dc1006942f74 ./hookshotThe introduction appeared to stutter less, but the game still entered a black, flickering state at approximately 1 FPS before closing.
I cannot confirm from the logs whether this experimental skip was actually applied by the v2.0.10 executable.
Earlier experiment:
RX_VK_NO_FOLLOW=1 RX_VK_NO_MESH=1 ./hookshotThis previously allowed further progress into gameplay and cutscenes, but produced substantially worse rendering, including invisible doors and missing vegetation.
None of these configurations provided stable gameplay.
4. Hookshot Vulkan device-loss errors
Captured output:
VkResult -4corresponds toVK_ERROR_DEVICE_LOST.5. Confirmed AMDGPU timeout directly associated with Hookshot
On November 9, 2026, at 16:11:31, the SteamOS kernel recorded:
This confirms a graphics ring timeout with the Hookshot process explicitly identified by the kernel, followed by a failed ring-level recovery and successful full GPU reset.
6. Second GPU timeout involving the Wayland compositor
At 16:17:20, another GPU timeout occurred:
The second timeout identifies
kwin_waylandrather than Hookshot.This is consistent with the observed disruption of the KDE desktop session, although the logs alone do not establish whether the second timeout was a direct consequence of the first.
7. Severe performance degradation before Wayland disconnect
Another captured Hookshot log contained:
Important observations:
The large difference between GPU execution time and overall frame/replay time suggests substantial overhead or waiting outside the measured GPU work.
This appears potentially related to the Linux/RADV submission overhead investigated in #312 and #528, but I cannot establish that it has the same underlying cause.
8. Possible connection to existing reports
The symptoms resemble several existing reports:
I understand that some device-loss cases were addressed by commit
9bb52a9, but the problem remains reproducible in my v2.0.10 testing.I have not yet confirmed the exact source commit corresponding to my v2.0.10 executable.
9. Questions for the developers
9bb52a9?RX_VK_SKIP_CODE=2c56dc1006942f74workaround supported in the current public Linux release, or does it require a patched build?hookshot_log.txtbe sufficient, or would an AMDGPU device coredump be helpful?The kernel reported creating an AMDGPU device coredump, but the previously reported sysfs path was not available when I attempted to inspect it.
10. Current status
Hookshot v2.0.10 is not currently playable reliably on my Steam Deck LCD.
The game builds and starts successfully, but Kokiri Forest loading can cause severe performance degradation, Vulkan device loss, graphics ring timeouts, GPU resets and desktop session disruption.
I have paused further execution tests to avoid repeated GPU resets and loss of other open applications.
I can provide the saved kernel logs and additional Hookshot logs if needed.
Thank you for your work on this project and for continuing to investigate Linux/AMD compatibility.
hookshot_log.txt
Hi all,
Sorry if I don't get the way this Megaissue works, willing to change this comment if needed:
v2.0.11
Arch / RADV 26.2.6 / 7900XTX
Is this:
How it's supposed to look? It's a bit... desaturated?
A driver bug in the same area as this hang. I checked whether it explains #817, and our data says it probably does
not. It is still worth knowing about, because Hookshot's mesh shaders can reach it, and a small change on Hookshot's
side avoids it on every driver.
Context. I'm porting Hookshot (v2.0.7,
8b2e1d3) to my own jailbroken PS5, for personal use. The driver ismihawk-99's PS5_Mesa, RADV with a PS5 winsys. The bug below is in code that
upstream Mesa shares, unchanged from 24.3 to current main, so it includes the 26.2 builds reported in this thread.
The bug
src/amd/common/nir/ac_nir_lower_ngg_mesh.c) keeps the vertex and primitive counts in twovariables that start undefined. Only
OpSetMeshOutputsEXTsets them, and the end of the shader always reads them forGS_ALLOC_REQ.OpSetMeshOutputsEXTtherefore asks the hardware for a garbage number ofprimitives. In our case that was about a million, with none exported, and the GPU waits for them forever.
entries, the translator emits
OpUnreachable(
structured_control_flow.cpp:459,emit_spirv.cpp:219-221).Mesa compiles
OpUnreachableas a plain return.Evidence
draw lost the device.
GS_ALLOC_REQ.RADV_FORCE_FAMILY=vangoghshows the same undefined values reachingGS_ALLOC_REQin a small valid shader that returns early. I'm reporting it to Mesa (link to follow).Why it is probably not this hang
Different programs. An offline census of the game's shaders finds 1,312 task/mesh programs. We translated 1,300
of them with our build, including every program that uses
2c56dc1006942f74.OpUnreachablein their mesh shader. None of them uses task shader2c56dc1006942f74: 51 aremesh-only, and 51 use six other task shaders.
2c56dc1006942f74have noOpUnreachablein their mesh shader. Neither does2c56dc1006942f74itself.6f9142def3b6a978(mesh code4797e4cd2b870a69) and636eed4d5000d1c0.155b02322a3ee490and38cdd9d8563b16eb: their keys depend on state our offline census doesn'thave.
The path probably never runs with real data. In 878 of the 882
OpUnreachablesites:Hookshot binds those same constants at draw time, so the loaded target always matches. We only reached the path
because our harness binds null descriptors. We didn't classify the remaining 4 sites.
The timing doesn't match. A
GS_ALLOC_REQdeadlock never ends. hardicd saw a draw of155b02322a3ee490run for9 s and then finish.
The workaround doesn't touch these programs.
RX_VK_SKIP_CODE=2c56dc1006942f74fixes the Deck without skippingany of the 102 programs.
Suggested change in Hookshot (defensive)
In mesh shaders, leave with no outputs instead of
OpUnreachable: emitOpSetMeshOutputsEXT 0 0, thenOpReturn.OpUnreachableis undefined in SPIR-V anyway.Outputvariable yet: Hookshot's mesh epilogue does those writes.Where:
emit_spirv.cppTraverse(), lines 219-221emits the
OpUnreachable.PatchMeshInstructions(), lines 615-658already turns a marker
OpStoreintoOpSetMeshOutputsEXT, which Sirit cannot emit(
MeshEpilogue(),emit_spirv_mesh.cpp:330-342).Here is an untested sketch. What we ran on the console was the same SPIR-V produced by patching the binary.
The sketch also needs
bool mesh_zero_outputs_marker{};inspirv_emit_context.h, next tomesh_outputs_marker.A test for Deck users, if someone wants to settle it
Hookshot-side change. Build with the change above and load the Deku Tree save without
RX_VK_SKIP_CODE. If itstill hangs, which is what we expect, this bug is ruled out for #817. If it stops hanging, it's back in play.
Driver-side change. If you rebuild Mesa yourself, for example from CachyOS's PKGBUILD, this two-line RADV patch
gives the same answer without touching Hookshot. It goes in
ac_nir_lower_ngg_mesh(), right after the builder is placed at thestart of the shader and before the API shader is wrapped:
A hang outside
2c56dc1006942f74. If a hang remains withRX_VK_SKIP_CODE=2c56dc1006942f74set, theits code:line of the stuck draw tells whether its mesh shader is one of the programs withOpUnreachable. We cancheck it against our list.
What is and isn't confirmed
2c56dc1006942f74have noOpUnreachablein our build.The analysis and this write-up were done with the help of an AI assistant (Claude). The driver fix and the Hookshot-side variant were tested on my own PS5.
Im sorry I dont know if I need the format but Ive been told to drop my hookshot_log.txt here. Game runs at 25-30 now (before 5-10) but looks awful, very and I mean very white.
some generic system info:
v2.0.11
7.3.1-1-cashyos (64-bit) / RADV 3:26.2.6-1 / RX 9070 XT / KDE Plasma 6.8.2 / Wayland / 16 × AMD Ryzen 7 5800X 8-Core Processor / 64 GiB of RAM
Also the hookshot_log u asked for
hookshot_log.txt
Per-draw program lookup gets slower after each area change; only a restart brings fps back (v2.0.11, Linux, NVIDIA)
Setup
--cli), game log header:hookshot v2.0.11 (source 10f983ad)What happens
After starting the game, a new area runs at 50-60 fps. After the next area change, fps drops to 20-30 and stays there. Restarting the game in that same area brings it back to 50-60 fps until the next area change.
What the log shows
The
programsphase ofa frame's replay timejumps after an area change and does not come back down; the GPU is not the limit:slow submitlines after the change are dominated by programs, e.g.slow submit: 34.4 ms: draw 35.1 ... programs 26.7.program picksrates do not change: about 55k-90k of every 200k picks miss the fast path, both before and after. So the number of slow-path picks stays the same, but each one gets more expensive as the session goes on.My guess, unverified: something
program_for->still_valid/program_pickwalks (variants, codes or answers per program, orshader_mucontention) grows with every area visited and is never trimmed. I can attach full logs and test switches if that helps.hookshot_log.3.txt
hookshot_log.2.txt
hookshot_log.1.txt
Colors look all washed out and brightened on my rx 9070 archlinux build 2.0.11
Game under Lichii
Game under hookshot
Two findings from a Steam Deck (RADV VANGOGH), v2.0.11 built from the official Linux AppImage. Both are reproducible; logs below are verbatim. Posting here per the routing in #1318.
Device: SteamOS 3.8.28, kernel
6.18.50-valve2-1-neptune, AMD Custom GPU 0405 (RADV VANGOGH), Mesa26.2.0-devel, Vulkan 1.4.350, 3 GiB device-local + 6 GiB shared VRAM, 14 GiB RAM.1.
RX_VK_SKIP_CODE=2c56dc1006942f74did not prevent the reset at the Deku TreeThe skip does engage — 10 programs were left out — and the GPU still resets when the scene begins. This corroborates #1318 ("SKIP_CODE not enough") with the skip verified active:
Then:
Worth noting: the source comment says "about 30 programs use it". Only 10 had been reached when the reset happened, so it is possible the fatal program is among the ones not yet seen. If that is the case, the skip list cannot be assumed complete — a program list driven by observation will always under-cover.
2. Movie decoder starvation (low fps + audio drift, with a flat fps counter)
During intro movie playback the decoder repeatedly has nothing ready, and presentation waits on it:
What the user sees with this:
The slow frames in the same run are dominated by texture work at the scene transition, not by shader compilation:
3. A separate movie hang, worked around
On the same build, before any of the above, one draw took 20.5 s in the upscale network and the ring was reset:
fd029a317a9a4b94is in the defaultRX_VK_NETWORK_KEEPlist (gpu/vk/vk_shader.cpp, "amd-fix"). Excluding it kept the movie stable and the linear upscale took over:After that:
network fd029a0 occurrences,typed upscale helper0, no 20 s submit. It did not stop the Deku Tree reset, so these are separate faults.4. Operational note
Every run that ends in a GPU reset discards the shader program cache (
vk: program cache ...: 0 program keys kept) and the next launch rebuilds all 38,809 programs, measured at about 7-10 minutes on this device (~94 programs/s). Each crash therefore costs a full rebuild before the next test, which makes per-crash iteration on Deck expensive.Update: Steam Deck LCD — Kokiri rendering improvements, but memory pressure causes Hookshot to freeze and terminate
Hi everyone,
I'm sharing additional findings from my latest Hookshot tests on the Steam Deck LCD.
System:
1. Latest gameplay test
After rebuilding Hookshot with newer changes, I managed to reach Kokiri Forest.
Compared with my previous v2.0.10 tests, the rendering appeared noticeably better:
The intro still stutters, and some areas that should appear black are rendered green.
For comparison, an earlier v2.0.5 build allowed me to move around Kokiri and interact with the environment, although with significant rendering glitches.
2. Confirmed earlyoom termination
I inspected the system journal after the latest freeze.
Unlike my earlier crashes, which included AMDGPU ring timeouts and GPU resets, this test did not show another GPU ring timeout in the inspected kernel logs.
Instead, the SteamOS
earlyoomservice explicitly selected the Hookshot process for termination:The log also recorded:
This confirms that the latest incident involved memory pressure severe enough for SteamOS to intervene.
The approximately 2.5 GiB VmRSS value represents resident process memory, not total system or GPU memory consumption.
3. Memory information collected after the crash
These measurements were taken after Hookshot had already closed, so they should not be interpreted as peak memory usage during gameplay.
I also confirmed that previously installed Distrobox/Podman development environments were removed and were not occupying significant storage.
4. Two distinct failure modes
Across my tests, I have now documented two different outcomes:
Earlier v2.0.10 tests:
VK_ERROR_DEVICE_LOSTLatest rebuilt version:
earlyoomThese may be related, but the evidence does not establish a single underlying cause.
5. Possible connection to other Steam Deck reports
This behavior seems relevant to the memory-pressure and GPU-hang investigations in #817 and #150.
I noticed that other Steam Deck testers have experimented with limits for texture memory, VRAM and mirrors.
Would it be possible to introduce a Steam Deck / RADV VANGOGH low-memory preset, or recommend a tested combination of memory-related settings?
In particular, I'd be interested in knowing whether limiting texture dimensions, texture-cache size and mirror memory could reduce memory pressure without introducing the severe rendering issues seen when disabling mesh rendering.
I'm avoiding further stress tests for now because previous builds caused full GPU resets.
I can provide the system journal and additional logs if useful.
Thank you for continuing to investigate Linux and Steam Deck compatibility.
Test report: Ubuntu 24.04, NVIDIA PRIME laptop (RTX 3070 Laptop, 16 GB RAM), built from source
Setup
mainatc94d80e(hookshot v2.0.9-34-gc94d80e), built from source withmake_game.py --nup ... --jobs 8and system clang 18 (not the AppImage), so this is older than v2.0.11Works
SDL_VIDEODRIVER=x11needed.Findings
zstandard, missing CPM headers (RX_CPM) or missing FFmpeg dev packages each surface mid-build as a failed step (e.g.nup.py stopped: ModuleNotFoundError: No module named 'zstandard'), not as a list at the start. The readme lists them, so this is minor, and the AppImage avoids it.d3cold_allowed=0to avoid Xid 119 (GSP) when the GPU woke from D3cold. In on-demand mode the card then stayed in D3hot and kept warming the shared heatpipes. In-game, the GPU dropped to 210 MHz (thermal slowdown0x20) within seconds, and the engine scenes ran at 2-10 fps. Withoptions nvidia NVreg_EnableGpuFirmware=0(proprietary module only), D3cold is allowed again: 6 wake cycles and a 72-minute session with no Xid, and the GPU held 1,700+ MHz until the laptop's own cooling saturated.Follow-up on the Steam Deck Deku Tree hang (#817, tracked here): v2.0.11 fixes it.
Tested v2.0.11 on the same Steam Deck (CachyOS Deckify, RADV Van Gogh), loading from the save used in the earlier tests:
RX_VK_SKIP_CODESteam Deck workaround fixed the crash — the Great Deku Tree speech now plays through with no GPU hang. Overall it works well now. Huge win — thank you.RX_VK_NO_MESH=1workaround is no longer needed to avoid the crash.Two smaller things remaining, neither is a blocker:
Thanks again for the fix — this was the one keeping the game from being genuinely playable on the Deck.
Steam Deck (RADV VANGOGH), v2.0.11: the Deku Tree hang is the native task/mesh path, and the fallback that avoids it draws nothing. Details below, with two debugging techniques that may be worth adopting.
1. The hang is in native task/mesh, not in one program
A/B on the same build, same save:
RX_VK_NO_MESH=1(mesh/task draws left out): reaches the Deku Tree, creates and renders the12288x12288DEPTH16 target, 0 GPU resets — but the screen is black, because those draws carry the geometry.RX_VK_NO_MESH=2(everything except mesh/task draws left out): reaches the same target and resets —ring gfx_0.0.0 timeout, signaled seq=1220264, emitted seq=1220266, threadPresentation Th.So mesh/task draw execution is necessary and sufficient for the reset.
2. It is not one program — skip lists cannot fix it
Two runs, same config, breadcrumb naming the last dispatch issued:
Skipping the named program moved the hang to another one.
RX_VK_SKIP_CODE=2c56dc1006942f74also does not prevent it here — the program that hangs is not among the ones sharing that task shader. That is consistent with several programs hanging the same way rather than one bad shader.The set of mesh programs drawn at the fatal frame also differs between runs (only one of twelve from a previous fatal frame appeared in the next), so a frozen list cannot be bisected either.
3. The fallback avoids the hang but renders nothing
I ported PR #1314's SPIR-V fixes (
054f7a8,7c7bfe3,14e0865) onto v2.0.11 — they cherry-pick cleanly — and forcedRX_VK_FORCE_MESH_FALLBACK=1.vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback).12288x12288target created and rendered, nofallback: the compute pipeline ... could not be madelines.So the crash is in the native task/mesh path, and the fallback currently fixes it by not drawing.
4. Two things that made this measurable
RADV hang dumps don't reach disk with the default fault features.
vk_main.cppchainsVkPhysicalDeviceFaultFeaturesEXTand thevkGetPhysicalDeviceFeatures2call fills it in place, so whatever RADV advertises is enabled atvkCreateDevice— includingdeviceFaultVendorBinaryunderRADV_DEBUG=hang, which makes RADV keep the report in memory. This renderer only reads the address and vendor-info lists (vk_draw.cpp,counts.vendorBinarySize = 0), never the binary. One line makes the dumps land on disk:With that, two separate crashes produced
radv_dumps_*/trace.log, both ending on the same command:pipeline.logwas empty in both, so the dump does not name the pipeline.A breadcrumb survives the reset. Because the kernel reset kills the process, anything only in the log buffer is lost. Writing one small record before each native
vkCmdDrawMeshTasksEXT(frame, program key, groups) puts the last dispatch on disk in the page cache. That is what produced the two keys in section 2, and it may be a useful optional diagnostic for other Deck users.If it helps, I can attach the two
trace.logdumps and the exact patch series; I have kept them out of the issue since they contain GPU addresses and register dumps.Follow-up from #1318 (Steam Deck LCD, RADV VANGOGH, v2.0.11): false positive on “it works”.
Interior vs outdoor
RX_VK_SKIP_CODE=2c56dc1006942f74(+RX_VK_MESH_NOCULLsame key), but graphics are wrong (models those programs draw are missing — expected for SKIP_CODE).12288x12288DEPTH16-style upload / multi-second submits, with SKIP_CODE already engaged and logging programs left out. Latest outdoor reset also showedamdgpu: ring comp_1.3.0 timeout(not only gfx).So SKIP_CODE / MESH_NOCULL are not enough for the post-door outdoor load on this Deck. Matches omgitsgela’s note that the hang moves between mesh programs and is not covered by that one task-shader key.
Happy to run further A/Bs (
RX_VK_NO_MESH=1,RX_VK_FORCE_MESH_FALLBACK=1, checkpoints, etc.) if useful.Follow-up on v2.0.11, same machine as my earlier report: ROG Ally X, Ryzen Z1 Extreme, RADV, Mesa 26.2.6, Bazzite 45. One new finding, and a correction to two things I said before.
The integrated-GPU texture cap is being exceeded
This is the headline of v2.0.11 — "Textures are now capped at 2.5 GB on integrated GPUs" — and on this device it does not hold:
3515 MB against a 2560 MB budget, 37% over, then back under it with 612 textures instead of 1378. So the budget is not a ceiling but something the run overshoots and then falls back from, by evicting in bulk. Those eviction-and-reload waves are what hitching in a loaded area looks like from the outside, and the player here describes v2.0.11 as "not much better" than v2.0.10 for smoothness.
The cap itself clearly helps elsewhere: the process peaked at 4.83 GB RSS, against 6.9 GB when the kernel OOM-killed it on v2.0.10 on the same machine. No OOM on v2.0.11.
Correcting myself on two earlier guesses
In #1186 (now closed into #1126) I offered two log lines as possible mechanisms behind the stray-texture artefacts. v2.0.11 weakens both, and I would rather say so than leave anyone chasing them:
texture slots registered again at another size— a million of them on v2.0.10. The line does not appear at all in my v2.0.11 logs. That guess is dead.draws kept their neighbour's descriptors— was 59 in a 2012-draw frame (2.9%), is now 4–5 in a ~530-draw frame (0.75%). The mechanism is still there, four times rarer by share. If the artefacts look the same to the player while that counter fell that much, it argues against my guess rather than for it.I have no replacement hypothesis. Sorry for the noise.
Frame rate, without a comparison
I am deliberately not comparing this with the 28.9 fps I reported on v2.0.10: that was a 2012-draw frame and this is a 530-draw one, so they are different scenes and the numbers do not meet. I only note that nothing here is submit-bound: 6 submits a frame, GPU 12–13 ms.
Unchanged: 161 shader programs still fail to prepare, the same order as on v2.0.10.
Still happy to test
Device free for debugging, and I can build from source. If a
RX_VK_VRAM_MBvalue, or anything that makes the texture budget a hard limit rather than a target, is worth measuring on a Z1 Extreme, tell me which and I will run it.Steam Deck LCD (RADV VANGOGH), v2.0.11: device lost on loading a save with native mesh;
RX_VK_NO_MESH=1avoids it but flickers, and fps is submit-bound (not fill-bound).Setup: SteamOS 3.9.5 (kernel 7.2.7-valve2), Mesa 26.2.0-devel (git-5c65d4fc31), Proton Experimental 11.0-20261027b. Game built on Windows with v2.0.11 and copied to the Deck; the shader caches were rebuilt on the Deck (38,809 shaders, 940 s).
1. Device lost on the first mesh draws (native mesh path)
The title screen ran at 60 fps. Loading a save (Kokiri Forest, the starting area) reset the GPU every time:
Memory was not a factor (11 GB free at the time of the crash). With
RX_VK_NO_MESH=1there is no reset, which matches omgitsgela's A/B above.2. With
RX_VK_NO_MESH=1: no crash, but flickering and 13-23 fpsWith
NO_MESH=1, Kokiri Forest renders (not black), but it flickers heavily, and none of the settings below changed that. The log has 18upload over a drawn imagelines in one session.Frame breakdown (warm pipeline cache, 1,200-2,500 draws per frame):
NO_MESH=1 LOW_SPEC=1HOS_GRAPHICS_SCALE=0.5(log:GetCurrentGraphicsScale -> 0.50)NO_MESH=1 LOW_SPEC=1 VRAM_MB=4096 PROTON_USE_XALIA=0queue submit, which fits the userptr-import cost described in #789 (about 2.4 GB imported:imports: 53 live (1376 MB), 40 retired still imported (1056 MB)).xalia.exewas using about 40% of a core during play;PROTON_USE_XALIA=0removes it, which is worth adding to the Deck notes.3. The texture budget is overshot, and
RX_VK_VRAM_MBdoesn't move itThe log reports two different numbers for the cap:
Setting
RX_VK_VRAM_MB=4096(confirmed present in the process environment) still reportsbudget 2200 MB, and the run goes about 23% over it, the same pattern quazardous saw on the Ally X. If the flicker is eviction churn, this may be related.Happy to run A/Bs (
RX_VK_BATCH_POLL_US=2000,RX_VK_PARALLEL=4,RX_VK_FORCE_MESH_FALLBACK=1,RX_VK_CHECKPOINTS=1for the hang) and attach full logs.The same GPU crash also occurs with the Windows build running through Proton
I previously experienced this exact issue with the native Linux build of Hookshot. I have now tested the Windows build running through Proton-CachyOS, and the same problem occurs again.
This appears to be the same GPU hang and AMDGPU reset issue, not a different type of crash.
System specifications
7.3.3-1-cachyos26.2.6-126.2.6-1)proton-cachyos-11.0(build20261015)What happens
I built the Windows version of Hookshot and launched it through Proton-CachyOS.
During gameplay, the GPU hangs completely and both monitors lose their video signal. The AMDGPU driver then attempts to reset the GPU.
The reset eventually succeeds, but the game does not recover.
The same behavior was previously observed with the native Linux build of Hookshot.
Other games work normally on this system, and I have not experienced similar GPU crashes outside Hookshot.
Previous kernel log from the same issue
During the previous crash with the native Linux build, the kernel reported:
The affected process was identified as
sead::MainThrea, with aPresentation Ththread.I will also attach a fresh kernel log from the Windows build running through Proton to check whether the same errors occur.
Additional information
Since the same GPU hang occurs with both the native Linux build and the Windows build through Proton, I suspect this may be related to Hookshot's rendering workload or GPU command submission.
I would appreciate any suggestions for further debugging.
hookshot_log.txt
hookshot-proton-kernel.log
hookshot-windows-build.log
Steam Deck LCD — Hookshot v2.0.11: longer Kokiri gameplay with four workarounds, but severe overexposure and 19–23 FPS
Hi everyone,
Following up on my previous Steam Deck LCD reports, I managed to get significantly further into Kokiri Forest using four environment variables simultaneously.
System:
Exact launch command:
RX_VK_NO_FOLLOW=1 RX_VK_KEEP_RETIRED=1 RX_VK_NO_MESH=1 RX_VK_SKIP_CODE=2c56dc1006942f74 ./hookshot
Gameplay results
This is the most substantial gameplay progress I have achieved with v2.0.11, but the rendering quality remains severely compromised.
Log observations
[hos host] hookshot v2.0.11 (source 10f983ad)
[hos host] vk: device 0: AMD Custom GPU 0405 (RADV VANGOGH), Vulkan 1.4
[hos host] vk: swapchain 1280x800, 4 images, mailbox
Unlike previous crashes, the captured log did not end with "VK_ERROR_DEVICE_LOST". Its final message was:
[hos host] display: window closed, exiting
This does not independently establish whether a GPU error occurred at kernel level.
Important limitations
Because all four variables were enabled together, I cannot determine which one improved stability.
I also cannot confirm that "RX_VK_SKIP_CODE" actually skipped the targeted shader in this build.
"RX_VK_NO_MESH=1" may contribute to missing geometry, while "RX_VK_KEEP_RETIRED=1" may increase memory pressure.
Questions
I have a gameplay recording, screenshot and full "hookshot_log.txt" available as supporting evidence.
My next comparison will use v2.0.12 with the same configuration to determine whether the new release changes performance, rendering or stability.
Thanks for your continued work on Steam Deck - compatibility.
Hi! I'm testing Hookshot on a Steam Deck LCD (AMD Van Gogh / RADV, SteamOS 3.9.5).
I've been experiencing GPU hangs, ring timeouts and severe rendering corruption with native mesh shaders enabled.
Using "RX_VK_NO_MESH=1" allows me to explore Kokiri Forest without the GPU resets seen in earlier tests, but causes extreme overexposure, flickering and missing geometry. These issues persist in v2.0.12.
I saw your investigation into potentially invalid primitive counts in RADV mesh shaders.
Do you think this Mesa/RADV issue could be related to the GPU hangs on Van Gogh, or does the evidence suggest a separate problem?
Has the proposed driver fix been tested with Hookshot on an actual Steam Deck?
I'd be interested in testing a validated fix once available. Thanks for investigating this!
Steam Deck LCD (Jupiter, RADV VANGOGH, driver 0x6801063), SteamOS 3.8.28, kernel 6.18.50-valve2. v2.0.12: system RAM and swap run out about 3 minutes after loading a save next to the castle, and the Deck freezes.
On v2.0.11 the same save lasted about 14 minutes in Hyrule Field before the same thing happened. That is what made us measure it.
Build. v2.0.12 from source (
hookshot_vk.sorebuilt in an Ubuntu 22.04 container like the CI), with a few renderer changes for the Deck:RX_VK_MESH_NOCULL=2c56dc1006942f74on by default;RX_VK_WAIT_GPU=-1, which waits for the frame's own GPU work at present (without it, the lighting flashes on this UMA device);RX_VK_VRAM_MBtaking priority over the preset, the same idea as #1376;None of these touch texture or render-target lifetimes, but I have not ruled them out. Settings:
HOS_ASPECT=1.6, resolution 75%, frame generation on,RX_VK_VRAM_MB=2048,RX_VK_TEX_MAX_MB=128,RX_VK_TEX_MAX_DIM=1024,RX_VK_MIRROR_MB=256,RX_VK_MESH_OPT=1,RX_VK_CHECKPOINTS=1.What the memory did. Our launcher logs
/proc/meminfoand the game's/proc/<pid>/statusevery 15 s. The machine has 15 GB of RAM and 8.6 GB of swap. The player walked from the save into the castle area:Once RAM is full, about 7.4 GB of swap is used in two minutes, while the game's own RSS falls and only 1.3 GB of the game goes to swap. Whatever grows is outside the process RSS. My guess is GPU allocations in GTT, but I did not log
mem_info_gtt_usedthis time. The renderer's own counters stayed modest:The log also has many
re-uploaded (its memory was written)lines for 2048x2048 textures (12 MB each) at that point.Standing still, it does not happen. A headless run of the same build from the same save, standing just outside the castle for 12 minutes, held 31 fps with no GPU stalls. RSS went from 7.6 to 8.1 GB, and VRAM sat at 2.4 GB with 1.4 GB of textures. So it is tied to going into the castle area, not to time.
When it happens, the whole Deck stops responding: earlyoom logs "memory situation has recovered while selecting victim" and kills nothing. Even after our launcher killed the game at 1.2 GB free, the Steam client was already swapped out and stayed on a black screen until a reboot.
The player also reported that v2.0.12 has a different lighting flicker than v2.0.11 and a "swimming pixels" look. I have no measurement for either yet.
I can rerun with
mem_info_gtt_usedandmem_info_vram_usedlogged, or with any switch that helps narrow it down (render target pool off, upload budget, etc.).Building from source on Arch (CachyOS):
scripts/linux/deps.shassumes Debian pathsMinor, only affects building the deps yourself (the AppImage is fine). Two spots:
cp -L /usr/lib/x86_64-linux-gnu/libXft.so.2 /usr/lib/x86_64-linux-gnu/libXrender.so.1fails on Arch, Fedora and others, where the libs live in/usr/libor/usr/lib64. Because ofset -e, FFmpeg, SDL2 and the CPM headers are never built either./usr/share/doc/libxft2/copyrightand/usr/share/doc/libxrender1/copyrightare Debian-only. Arch has them at/usr/share/licenses/libxft/COPYINGand/usr/share/licenses/libxrender/COPYING.Workaround I'm using for the first one:
Also needs
nasminstalled for dav1d (not mentioned in the script's header). After that,make_game.pybuilds main with DLSS fine on an RTX 4070 SUPER (driver 615.78.08).Steam Deck LCD / RADV VANGOGH — v2.0.12: MESH_NOCULL confirmed active, but GPU still hangs and resets
Hi everyone,
Following up on my previous Steam Deck LCD reports and the "RX_VK_MESH_NOCULL" workaround discussed in PR #1300.
System: Steam Deck LCD, SteamOS 3.9.5, AMD Custom GPU 0405 (RADV VANGOGH), Vulkan 1.4.
Hookshot: v2.0.12, source "cfa1aebf".
Exact launch command:
RX_VK_MESH_NOCULL=2c56dc1006942f74 ./hookshot
Result
Unfortunately, the GPU still hung and reset.
Importantly, the workaround was successfully applied. The application log contains this message eight times:
vk: task code 2c56dc1006942f74: culling off, every meshlet drawn (RX_VK_MESH_NOCULL)
Application log
vk: texture 0x1147bf6000 12288x12288x1 x1 levels 1 NVN 0x32 -> vk 124
vk: slow upload 188.5 ms: #257 ... 12288x12288x1 ... 294912 of 294912 KB
vi: 5373 frames presented (20.6 fps over the last 6.9 s)
vk: slow submit: 5117.1 ms: slot wait 5116.4
vk: batched submit 5584 failed (-4)
vk: device lost: reading the fault info
vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST)
SteamOS kernel journal
At 10:17:56 on November 10:
amdgpu: ring gfx_0.0.0 timeout, signaled seq=172881, emitted seq=172885
amdgpu: Process hookshot pid 12047 thread sead::MainThrea pid 12052
amdgpu: Ring gfx_0.0.0 reset failed
amdgpu: MODE2 reset
amdgpu: GPU reset(1) succeeded!
The 12288×12288 depth target is interesting because it appears in other Steam Deck reports, although its presence does not establish that it caused the crash.
Comparison with previous tests
Using "RX_VK_NO_MESH=1" together with other workarounds, I previously managed to explore Kokiri Forest at approximately 19–23 FPS. However, the rendering suffered from extreme overexposure, severe flickering and missing geometry.
With "RX_VK_MESH_NOCULL" alone, the shader modification was confirmed active, but a GPU reset still occurred.
Could there be another task/mesh shader hang path on RADV VANGOGH beyond the culling loop addressed by MESH_NOCULL?
Is there a targeted patch or diagnostic test that could help investigate this without repeatedly triggering GPU resets?
I have the complete application log and kernel journal available.
Thanks for your continued work on Steam Deck compatibility!
Steam Deck OLED: GPU hang in Hookshot v2.0.12
System
7.2.7-valve2-2-neptune-72-g31504582a073cfa1aebfTest configuration
hookshot_env.txt:RX_VK_MESH_NOCULL=2c56dc1006942f74The log confirmed that MESH_NOCULL was active: it reported
culling off, every meshlet drawnfor task code2c56dc1006942f74.Failure
Hookshot slowed to 2.4 fps, then reported
batched submit 52273 failed (-4)andVK_ERROR_DEVICE_LOST. At 14:23:37 CET, the kernel logged agfx_0.0.0 timeout; the graphics-ring reset failed and SteamOS performed a MODE2 GPU reset. At 14:23:49, the kernel also logged acomp_1.1.0 timeout.The same GPU hang reproduces at different resolutions despite the documented MESH_NOCULL workaround being active.
Always hangs in the same point of the intro, before the deku tree animation after the Link's dream.
Can confirm exact same issue here on my OLED
Tested 2.0.13 same problem
System Information
• OS: Fedora 44 KDE
• GPU: AMD Radeon RX 6650 XT (Mesa / RADV driver)
• RAM: 32 GB DDR4
• Hookshot Version: v2.0.12 Linux AppImage
• Game Dump: 0400486024DEC000 (v131072) with transferred save data from Lichii emulator
Bug Description
The game crashes to a black screen with brief pink visual artifacts right during the spinning Triforce loading screen. This happens regardless of the save location: loading a save file that is currently placed right inside the door of the village/death valley area crashes immediately, and older saves (such as one located in Hyrule Field) crash in the exact same manner. The issue triggers a hard Vulkan device reset on Linux via the open-source RADV driver.
Relevant Log Output
Notes
• Confirmed that deleting the emulator-side options.sav to force a local geometry reset did not resolve the crash.
• Adjusting rendering configurations down to native 1080p inside the F1 settings menu did not bypass the loop.
• The driver explicitly reports This context is innocent, confirming an engine-side texture feedback loop/allocation allocation panic on boot rather than a physical hardware fault or system error.
Same card here: RX 6800 XT (RDNA 2), Linux, RADV (Mesa 26.2.6), Hookshot v2.0.13.
Device lost entering gameplay; always reproducible from the same save, at the same point (frame ~913–953, same marker sequence ending at an upload of texture 109f1bbc00).
What I tried, all with RX_VK_CHECKPOINTS=1:
task code 2c56dc1006942f74: culling off, every meshlet drawn(8 times), still hangs at the same point. So on this card it is not the culling loop from #817.journalctl shows some of the hangs on the compute ring (
ring comp_1.2.0 timeout), which is where RADV runs task shaders, so the gfx-ring markers may only show what the gfx ring was waiting on.The same game hangs the same way in CheezyEmu and Fritchii (fixed by EDEN_NX2_NO_MESH=1 there), while Windows with the AMD driver works.
So this looks like task/mesh execution on RDNA 2 + RADV rather than one specific program.
Logs attached (NOCULL run and the run without it).
hookshot_env.txt
hookshot_log.4.txt
Steam Deck OLED, stock SteamOS: neither Deck workaround stops the hang on v2.0.11;
RX_VK_NO_MESH=1gets through7.2.7-valve2-2-neptune, Mesa26.2.0-devel (git-5c65d4fc31)HOS_HANDHELD=1, shaders prepared with--prepare-shadersfirstRX_VK_MESH_NOCULL=2c56dc1006942f74RX_VK_SKIP_CODE=2c56dc1006942f74RX_VK_SKIP_CODE+RX_VK_LOW_SPEC=1RX_VK_NO_MESH=1Each hang has the same kernel signature:
The
LOW_SPECrun also hadring comp_1.1.0 timeout12 s later.One possible reason for the difference between SteamOS and CachyOS Decks: SteamOS boots with
amdgpu.lockup_timeout=5000,10000,10000,5000. That gives the gfx ring 5 s, against the kernel default of 10 s. hardicd's trace in #817 has the task shader still running at 3, 6 and 9 s. A pass that finishes within 10 s would show as a long stall under the default and as a reset here. I haven't tested this with a raised timeout. For reference, this Deck has 1 GiB of VRAM and 8 GiB of GTT.NO_MESHframe rates (vk: ... presentslines):In play there is heavy flicker and specks on the fallback path. #1509 and #1513 look like they cover this.
A note on testing cost: here the program cache survived the resets (
46517 program keys kepton the next start). It was rebuilt only when aRX_VK_*switch changed the programs.As a workaround for the intro, a save made on another PC (where the game runs) loads on the Deck without changes. So each retest takes about a minute instead of the whole intro.
Happy to test a build or a switch on this Deck.
hookshot_log.txt
✅ WORKAROUND FOUND: RX 6800 XT (RDNA 2) on Linux, no more device lost, native mesh shaders, everything drawn
TL;DR: On RDNA 2 + Linux the hang is RADV-specific. Running Hookshot with AMDVLK instead of RADV fixes it, for this game only, while the rest of the system stays on Mesa/RADV. No mesh fallback, no missing geometry.
My setup
What did NOT help on RADV (all with RX_VK_CHECKPOINTS=1)
RX_VK_MESH_NOCULL=2c56dc1006942f74+RX_VK_NO_PROGRAM_CACHE=1: the log confirmsculling off, every meshlet drawn, still hangs. So on desktop RDNA 2 it is not the #817 culling loop.RX_VK_WB_DIFF=0,RX_VK_BATCH=0,RX_VK_ASTC_CPU=1,RX_VK_SKIP_CODE=..., GPU at stock clocks, LTS kernel: all still hang.RX_VK_FORCE_MESH_FALLBACK=1: no hang, but broken/missing geometry.ring comp_1.2.0 timeout), which is where RADV runs task shaders. The same game hangs the same way in CheezyEmu/Fritchii (avoided there by skipping mesh draws), while Windows with AMD's driver works.🛠️ How to use AMDVLK only for Hookshot (nothing installed system-wide)
AMDVLK is discontinued and no longer in the Arch repos, but its last release still works for this.
1. Download
amdvlk_2025.Q2.1_amd64.debfrom https://github.com/GPUOpen-Drivers/AMDVLK/releases2. Extract it to a folder of your own:
3. Point its ICD file at the extracted library:
4. Check that it sees the card and has mesh shaders:
5. Start the game with it (adjust the game folder):
The first start recompiles the shaders and takes a while (AMDVLK's compiler is slower, like on Windows). Let it finish.
To make it permanent, put those two lines in a small script and add it to your menu or Steam as a non-Steam game, with no Proton.
VK_DRIVER_FILESonly affects that process: the desktop and other games keep using RADV.Tips:
RX_VK_VRAM_MB=12288(16 GB card), Upscaler AMD FSR 3.1 in the Insert menu for less aliasing, andRX_VK_UPLOAD_BUDGET_MS=0if textures pop in late in towns.For the developer
This points to how RADV executes OoT's task/mesh shaders on RDNA 2, likely the task stage, which RADV runs on a separate compute queue. Ideas that might avoid it without AMDVLK:
vkCmdDrawMeshTasksIndirectEXT, so RADV never uses its task-shader path. The fallback already translates task shaders to compute.Happy to test builds or switches on this card. Logs from the RADV runs (with markers) are attached.
RX 6800 XT (RADV, Mesa 26.2.6), Gentoo, v2.0.13: GPU hang during the Deku Tree's speech on every attempt;
RX_VK_NO_MESH=1avoids itHookshot v2.0.13 hangs the GPU on my RX 6800 XT while the Deku Tree speaks, right after the intro cinematic. It happens on every attempt: the picture freezes, the kernel resets the GPU, and the game closes with
VK_ERROR_DEVICE_LOST. SettingRX_VK_NO_MESH=1seems to fix it. In my latest run the checkpoint markers stop at the same two programs as #620.System
source cfc565a2), built with the v2.0.13 Linux AppImageRADV NAVI21, driver0x6802006Settings: default options.
hookshot_env.txthasRX_VK_CHECKPOINTS=1andRX_VK_FAULT_INFO=1; the runs that hung had noRX_VK_NO_MESH,RX_VK_SKIP_CODEorRX_VK_MESH_NOCULL.What happens
RX_VK_MESH_OPT=1the hang seems to be gone.hid: the game read no controller for 15.9 s): the kernel's 10 s timeout plus the reset. Then the game closes.Checkpoint markers, latest run
89ca750f9852b7ca, two draws afterc36a4f3f667c886a. #620's v2.0.5 checkpoints (RX 6600) stop at the same pair: last finishedc36a4f3f667c886a, first unfinished89ca750f9852b7ca(the foliage colour pass, per the summary above).636eed4d5000d1c0was running, after six finished draws ofc70332b4adb4aa9f. In omgitsgela's v2.0.11 log above,c70332b4adb4aa9fis listed with task code2c56dc1006942f74. So the program running at the hang changes from run to run, as omgitsgela saw on the Deck.RX_VK_FAULT_INFO=1gives nothing on RADV: thedevice fault:lines are empty.Kernel log
Latest run, local time (UTC-5):
ring gfx_0.0.0 timeout,Process hookshot pid 93359 thread Presentation Th, then the same failed ring reset and MODE1 reset.Attached
hookshot_log_v2.0.13_10-54.txt: the latest run (the markers above).hookshot_log_v2.0.13_10-37.txt: the earlier run.hookshot-v2.0.13-kernel-resets.log:journalctl -karound both resets.hookshot-v2.0.13-kernel-resets.log
hookshot_log_v2.0.13_10-37.txt
hookshot_log_v2.0.13_10-54.txt
Summary of a community-found work-around (thanks @Alexatre), not an official recommendation: on Linux, the RDNA2 hang looks specific to RADV (Mesa's AMD driver). Running Hookshot with AMD's AMDVLK driver instead avoided the hang on an RX 6800 XT: native mesh shaders, no device lost, everything drawn.
How: install AMDVLK alongside Mesa and start only Hookshot with it, for example with
AMD_VULKAN_ICD=AMDVLKin front of the game's command (or the way your distro offers to choose the Vulkan driver per program). The rest of the system stays on RADV. If you try it on another card, please post the result here.My only concern is AMDVLK was discontinued in September 2025. I will attempt it, but I have noticed
RX_VK_MESH_OPT=1seems like an acceptable workaround so far. If found sufficient after testing, maybe this could be baked in for this driver?A Linux NVIDIA report with nothing broken, for comparison: RTX 4090, driver 595.99.02, Ubuntu 26.04 (kernel 7.0, KDE Wayland), Ryzen 9 3950X. The v2.0.12 AppImage built the game from a two-title
.nupin 14 min (CLI, 16 jobs) and prepared the shaders in 3.5 min. A 43-minute headless run with teleports between Kokiri, Kakariko, Castle Town Market and Lake Hylia had no crash and no device lost; process memory settled at 16.2 GB and stayed flat for the last 30 minutes. A windowed run with an Xbox Series X controller also worked.Hi, I’d like to share my experience with a GPU reset on Steam Deck that still happens after applying the workaround from #1300.
I’m running Hookshot v2.0.12 (source
cfa1aebf, Linux AppImage build) on SteamOS in Game Mode. The game reportsAMD Custom GPU 0932 (RADV VANGOGH)with Vulkan 1.3.Steps to reproduce: Open Hookshot and load an existing save from after the opening cutscene. The save loads, then the game freezes and exits.
I set
RX_VK_MESH_NOCULL=2c56dc1006942f74inhookshot_env.txt, and the game log confirms that the workaround was applied:The kernel logged a graphics ring timeout followed by a GPU reset:
In an earlier test,
RX_VK_NO_MESH=1let me get past the crash, but I saw severe flickering and missing geometry during gameplay.The kernel messages look similar to those in #817. Is there a diagnostic flag or a specific build I could try to help identify what is still causing the reset?
i have amd6600 why every start it read the pipeline? in radv it load superfast
Follow-up (Steam Deck OLED, stock SteamOS 3.9.5):
RX_VK_MESH_OPT=1avoids the hang on v2.0.14RX_VK_MESH_OPT=1,HOS_HANDHELD=1and no other mesh switches, mesh shaders run on this Deck with no GPU hang. I loaded straight into a Kokiri Forest save, which hung within seconds withRX_VK_SKIP_CODE+RX_VK_LOW_SPEC=1. Then I played about 30 minutes across five launches, with nogfx_0.0.0timeout in the kernel log. This confirms @manianac's RX 6800 XT result on the Deck.GPU-bound waitat 3-4 ms of a ~52 ms frame. The resolution and upscaler choices don't change it. Descriptor reuse and Sampler cache are on.Correction to my earlier comment: the SteamOS 5 s gfx
lockup_timeoutdoesn't explain the difference. @manianac's 6800 XT hangs with the default 10 s timeout, and its freeze lasts about 16 s. Sorry for the noise.If it helps to bake
MESH_OPTin for VANGOGH / RADV RDNA2, I can test a build on this Deck.Steam Deck LCD / RADV VANGOGH — Combined workarounds: 14–15 FPS, 121 failed shader programs
Following up on my previous Steam Deck LCD reports, I tested a combination of workarounds, including settings investigated by @KewinBR and the experimental fixes from PR #1795.
System
Launch configuration
RX_VK_DECK_DEFAULTS=0
RX_VK_FORCE_MESH_FALLBACK=1
RX_VK_MESH_NOCULL=2c56dc1006942f74
RX_VK_MESH_OPT=1
RX_VK_WAIT_GPU=1
RX_VK_UB_SNAPSHOT=1
RX_VK_EVENT_WAITS=0
RX_VK_VRAM_MB=2048
RX_VK_TEX_MAX_MB=128
RX_VK_TEX_MAX_DIM=1024
RX_VK_MIRROR_MB=256
RX_VK_LOW_SPEC=1
RX_VK_CHECKPOINTS=1
HOS_HANDHELD=1
HOS_ASPECT=1.6
HOS_GRAPHICS_SCALE=0.75
Results from the captured gameplay log
Frame interpolation was active. These figures are not a controlled benchmark with frame generation disabled.
Important limitations
This was a combined test, so it is not possible to identify which individual setting contributed to stability.
The compute mesh fallback was enabled. Therefore, the benefits of "RX_VK_MESH_NOCULL" on native mesh rendering were not established.
"RX_VK_WAIT_GPU=1" was used because this fork does not reproduce @KewinBR's modified "RX_VK_WAIT_GPU=-1" behavior.
I cannot confirm that overexposure, flickering or missing geometry were fixed, since no controlled visual comparison was recorded.
Next test
I am rebuilding a separate official v2.0.14 installation. The recent Steam Deck OLED report showing approximately 30 minutes without GPU hangs using native mesh shaders and "RX_VK_MESH_OPT=1" is particularly promising.
I intend to test that configuration on the Steam Deck LCD and compare stability, rendering correctness and performance.
The full local log is available for further investigation.
I can report that I've tried the fix proposed by addisonbair and it yields some very good results (with a lot of room for improvement but still!).
RX_VK_MESH_OPT=1, HOS_HANDHELD=1
These launch options stopped the hanging and crashing on the opening cutscene ending and the game now boots and renders gameplay. The fps varies wildly between 14fps low 1% stutters and close to 60fps. This is likely caused by heavy RAM usage. As it uses 12GB of RAM and 6GB of VRAM (2GB of Swap RAM is probably causing the stuttering). The CPU usage is quite low, lower than I expected and the GPU usage is around 80%, higher than I expected for using FSR3. 1 in quality mode with the handheld low preset.
However, the visuals are all over the place in stability, there is random white flashes constantly when moving Link and the camera, textures frequently load and unload, and UI elements flash and stretch across the screen.
Steam Deck (RDNA2, no matrix cores), v2.0.14: the gameplay upscale network costs ~12 ms of GPU time a frame. AMD FSR 3.1 removes it
Kokiri Forest, the same spot each run, Link standing still, ~2,330 draws a frame. Env:
RX_VK_MESH_OPT=1,RX_VK_PER_QUEUE_FENCES=0,RX_VK_WAIT_GPU=0. Profiled withRX_VK_GPU_PROFILE=1 RX_VK_PASS_TIMING=2.GPU timeline)dispatch prog 9dc98871eb7fc101, at 11.5-12.6 ms a run. That's more than 8x the next span.vk_shader.cpp, it is the gameplay TAAU network, kept by the defaultRX_VK_NETWORK_KEEP("amd-fix"). On a GPU without cooperative-matrix hardware, its matrix multiplies run as ordinary shader code, which is why it is so slow here.Suggestion: on GPUs without cooperative-matrix support (RDNA2 such as the Deck's VANGOGH, likely also RDNA2 handhelds and desktop cards), default the Upscaler to FSR 3.1. The movie networks already get a linear stand-in on such GPUs. Players on those cards are unlikely to find this themselves: the resolution and quality rows barely move the frame rate there.
What remains after that, from the FSR profile:
43ec86f35fd937b9(~4.5 ms at 922x576).draw21.5, of whichdescriptors7.9).Happy to re-profile a build on this Deck.
Steam Deck LCD / RADV VANGOGH — v2.0.14: Best result so far, Kokiri gameplay renders, but severe flickering and ~19 FPS
Hi @NotRexed and everyone!
I'm following up on my previous Steam Deck LCD tests. On November 10, 2026, I achieved my best result so far using Hookshot v2.0.14.
The good news: Kokiri Forest is now visibly rendered, Link is controllable, and I can move around the environment.
The bad news: The whole image shakes, shimmers and flickers badly during movement and camera rotation. Performance is still around 19 FPS. It is far from playable.
System
Latest launch command
This is the launch configuration from my most recent testing sequence:
cd "/run/media/deck/f9b867d3-571f-493b-a22e-91206d74cdbc/GAMES/Hookshot-VanGogh-Jogo" &&
env
RX_VK_DECK_DEFAULTS=0
RX_VK_MESH_OPT=1
RX_VK_MESH_NOCULL=2c56dc1006942f74
RX_VK_WAIT_GPU=1
RX_VK_UB_SNAPSHOT=1
RX_VK_EVENT_WAITS=0
RX_VK_VRAM_MB=2048
RX_VK_TEX_MAX_MB=128
RX_VK_TEX_MAX_DIM=1024
RX_VK_MIRROR_MB=256
RX_VK_LOW_SPEC=1
RX_VK_CHECKPOINTS=1
HOS_HANDHELD=1
HOS_ASPECT=1.6
HOS_GRAPHICS_SCALE=0.75
./bin/hookshot
Unlike my previous experimental fork test, this command does not include "RX_VK_FORCE_MESH_FALLBACK=1" or "RX_VK_NO_MESH=1".
The latest log excerpt starts mid-execution, so it does not independently confirm which environment overrides were applied.
Measured results
Metric| Result
Presented frames| At least 5,846
Reported FPS| 18.9–19.1
Draws per frame| 2,771
Compute dispatches| 142
Shader programs| 52,305
Failed programs| 122
Textures| 1,261 / 2,032 MB
GPU time| 30.8 ms per frame
Replay submit time| 43.51 ms
Relevant log output:
vk: 5760 presents, 18.9 fps
a frame: 2771 draws (0 skipped)
142 dispatches, 167 passes
52305 programs (122 failed)
1261 textures (2032 MB)
vk: GPU time 30.8 ms a frame
vi: 5846 frames presented (19.1 fps)
display: window closed, exiting
No "VK_ERROR_DEVICE_LOST" appeared in the latest captured excerpt. The window was closed normally.
In a previous v2.0.14 run, the GPU failed with:
vk: batched submit 4006 failed (-4)
VK_ERROR_DEVICE_LOST
An earlier experimental build, v2.0.11-372-gef66f55, was tested with "RX_VK_FORCE_MESH_FALLBACK=1", "RX_VK_MESH_OPT=1", "RX_VK_MESH_NOCULL=2c56dc1006942f74" and the handheld/memory limits. That configuration reached roughly 14–15 FPS, with 121 failed programs.
Remaining issues
I recorded an approximately 11-second video showing Link moving around Kokiri Forest, with the scenery and UI visible but unstable.
Questions
Could the remaining visual instability be related to the failed shader programs, mesh rendering, or synchronization?
Is there a recommended minimal configuration specifically for Steam Deck LCD with RADV VANGOGH?
Which diagnostic options or development branch would be most useful to test next?
I'm happy to continue testing and provide additional logs or video evidence.
Thanks for all the work on Linux and AMD compatibility. We've made progress from black screens and GPU resets to actual rendered gameplay, but the rendering and performance still need substantial improvements.
Told to post here from the discord
Archlinux with KDE plasma v6.8.1
Nvidia 2060 Super FE
Intel i7-10700k
NVIDIA-SMI 615.78.08
KMD Version: 615.78.08
CUDA UMD Version: 13.4
hookshot v2.0.14
Ground textures became broken after loading the Lon Lon Ranch title card mini-cutscene. Log attached.
hookshot_log.4.txt
From Discord: Linux, NVIDIA RTX 2060 Super: the ground textures break after the Lon Lon Ranch cutscene. Same pattern as the ground textures going wrong after a while in #993; on NVIDIA Linux too, so not only AMD.
Steam Deck OLED (stock SteamOS 3.9.5), v2.0.14: the config that plays best here, ~24 fps base in Kokiri village (~48 with 2x frame generation)
These are working settings for other Deck owners, not a fix. Each one was measured on this Deck.
hookshot_env.txt:In-game menu: Handheld profile On, Upscaler AMD FSR 3.1 at Performance, Frame generation 2x, Descriptor reuse On, Sampler cache Off.
Steam > Performance, per-game profile: Manual GPU Clock 1200 MHz. This was the surprise. The Deck shares 15 W between CPU and GPU. On the automatic clock, in a busy view, the CPU ran at 3.5 GHz and the GPU was starved: GPU time 42.7 ms, 18.0 fps. Pinning the GPU at 1000 MHz in the same scene gave 31.3 ms and 21.7 fps, with CPU and GPU about even (~31 ms each). 1200 MHz played best.
Why FSR Performance: on RDNA2 the game's own TAAU network costs ~12 ms a frame (my comment above). FSR 3.1 replaces it, and Performance halved GPU time here (38 to 21 ms). That leaves the Deck CPU-bound on the replay (~25-35 ms a frame at ~1,800-2,300 draws).
I made the issue about it crashing on steam deck after the cutscene, wanted to let you know that it did it again after updating to 2.0.14
https://github.com/user-attachments/assets/ea390974-a5cd-4f07-b7d9-0d7048ceffae
https://github.com/user-attachments/assets/69829125-85fc-44ce-95af-dc3e0532b931
Steam Deck LCD / RADV VANGOGH — Hookshot v2.0.14: Native mesh rendering works, but severe black flashing and judder persist
Hi @NotRexed and contributors,
I'm sharing a follow-up with reproducible results from five consecutive tests on my Steam Deck LCD.
System
Progress
Kokiri Forest now loads, Link is controllable, and the environment renders with native mesh shaders enabled. I am no longer using "RX_VK_NO_MESH=1" or "RX_VK_FORCE_MESH_FALLBACK=1".
Test 11 confirms that "RX_VK_MESH_NOCULL=2c56dc1006942f74" was applied successfully.
However, severe graphical problems remain:
Test comparison
Test| Main change| Median FPS*
09| Base configuration, 75% scale| 17.9
10| Reduced scale to 50%| 15.8
11| Rebuilt installation, 75% scale| 15.4
12| Added "RX_VK_BATCH_POLL_US=2000"| 17.9
13| Also set "RX_VK_WAIT_GPU=0" and "RX_VK_PER_QUEUE_FENCES=0"| 18.1
These are medians from sampled scenes with at least 1,000 draws/frame, not controlled comparisons at identical locations.
Important findings
Reducing render resolution did not consistently improve performance.
Batch polling may have helped responsiveness, but the visual corruption appeared worse.
Test 13 used both synchronization workarounds reported in issue #1005. Unfortunately, the black flashing remained clearly visible in the attached video. Since two variables changed together, I cannot identify their individual effects yet.
All five captured sessions ended normally, without "VK_ERROR_DEVICE_LOST" in the application logs. However, earlier versions on this same device experienced GPU timeouts.
The later logs also report 11 failed shader programs.
Video evidence
Both videos have no audio. They demonstrate the persistent black flashes and visual instability.
The complete launch commands for tests 09–13 and the application logs are available.
Questions for developers
My priority is a faithful and visually stable experience, rather than artificially increasing the displayed FPS.
Finally, I want to sincerely thank @NotRexed and everyone contributing to this project. It's impressive to see how much progress has already been made, especially on hardware as challenging as the Steam Deck.
I'm genuinely happy to contribute through testing, detailed logs, and gameplay footage. Even when a test doesn't produce the expected result, I hope the information can help move the project forward.
I'm not a developer, but I'm enthusiastic about helping make this experience as faithful, stable, and enjoyable as possible on the Steam Deck. I'm happy to keep testing new builds, workarounds, or specific configurations whenever useful.
Thank you again for your dedication and for making this project possible!
Steam Deck:
main(fc375e9) is ~28% slower than v2.0.14 at the same scene, and the vcore counters went up ~7xSteam Deck OLED, SteamOS 3.9.5, RADV. Both builds are from source with the v2.0.14 AppImage toolchain, run with the same options file and env (
RX_VK_MESH_OPT=1 RX_VK_PER_QUEUE_FENCES=0 RX_VK_WAIT_GPU=0 RX_VK_BATCH_MAX=4 RADV_PERFTEST=cswave32, FSR 3.1 Performance, handheld, frame generation off). Same save, Kokiri village, Link idle, ~1,770 draws a frame in both:GPU timesubmitfc375e9GPU time and replay cost are the same or better on
main, but each frame is ~17 ms longer. The difference shows up in thevcores:line (per 5 s):On the Deck's 4 cores / 8 threads, I think that churn is what costs the frame time.
Ruled out on the Deck:
HOS_RESERVE_CORE=0onmaingives 15.7 fps, with the counters the same.RX_VK_TASK_MESH_FALLBACK=1: 16.1 fps, the same as native.Between v2.0.14 and
fc375e9, the only change to the vcore and wait code I can find is #1696 (WaitAny's scan without the checkpoint,event_peekin place ofevent_wait(e, 0, 1)). That's a guess from reading the code. I'll buildmainwith only #1696 reverted and post the Deck result.Follow-up: #1696 is not it.
fc375e9with #1696 reverted (same Deck, same save and settings): 16.2 fps, 28,861 draws/s. That's no different fromfc375e9(15.4-16.1), against v2.0.14's 22.4.The revert did cut the vcore churn (
232834 takes, 35922 waits, 17925 kicksper 5 s, from ~337k / ~90k / ~60k), so the churn followsmainwithout being what costs the frame.What does line up: on
mainthe GPU time and the replay add up to the frame, and on v2.0.14 they overlap.GPU timesubmitfc375e9- #1696So something since v2.0.14 seems to make the replay wait for the GPU (or the reverse) once per frame, on RADV at least. Frame generation was off in every run, so the present-ahead path isn't involved.
RX 6900 XT (RADV NAVI21, PCI 1002:73af), Fedora 44, v2.0.14: GPU hang entering the Great Deku Tree with MESH_OPT + MESH_NOCULL, and a kernel timeout finding
System: RX 6900 XT 16 GB, Mesa 26.2.6 (driver 0x6802006), kernel 7.2.15-200.fc44, KDE Plasma 6.8.2 Wayland, i7-13700K, 32 GB RAM, output 2560x1440, Upscaler: game's own, frame generation off, robust buffers on.
hookshot_env.txt:
RX_VK_MESH_OPT=1
RX_VK_MESH_NOCULL=2c56dc1006942f74
RX_VK_CHECKPOINTS=1
What happens: Kokiri Forest plays fine (GPU time 12-14 ms a frame). Entering the Great Deku Tree, or loading a save inside it, hangs the GPU every time. 6 hangs in one evening.
1. Kernels 7.x default
amdgpu.lockup_timeoutto 2000 ms (modinfo amdgpu: "default: 2000", on 7.1.8, 7.2.11 and 7.2.15), not the 10 s the comments in the code assume. With the default, every hang showed a submit blocked 2.5-3.0 s, then device lost.2. It is a real hang, not a slow pass. With
amdgpu.lockup_timeout=30000the save loads and plays about 5,500 frames, then on entering the tree the GPU stays stuck for the full 30 s (hid: the game read no controller for 30.3 s) until the reset:amdgpu: ring gfx_0.0.0 timeout, signaled seq=42343, emitted seq=42345
amdgpu: Process hookshot pid 10280 thread Presentation Th
amdgpu: Ring gfx_0.0.0 reset failed
amdgpu: GPU reset begin!. Source: 1
amdgpu: VRAM is lost due to GPU reset!
Markers of that hang (frame 5530):
RUNNING after: marker 3672141 (draw of program 636eed4d5000d1c0)
reached, earlier work unfinished: 55f9da6996166520 (x4), 87eab3665f2b872c, 918adef1afaa39d4, 0bbb4eef0b5122e9
Earlier hangs at the 2 s default pointed at mesh programs e3f341ac12c40e2c, 918adef1afaa39d4 and 31526778a6b5ade2. 918adef1afaa39d4 is in both. Some hangs time out on a compute ring (comp_1.x.0) and some on gfx_0.0.0.
Also: each MODE1 reset kills Xwayland and plasmashell, and once left one monitor frozen (
[CRTC:494] flip_done timed out) until reboot.Log attached. Happy to test
RX_VK_TASK_MESH_FALLBACK=1on RADV Navi 21 as soon as it is in a release.hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
Steam Deck LCD (RADV VANGOGH): the cull task 2c56dc1006942f74 still hangs the GPU with RX_VK_MESH_NOCULL, in open areas. The compute mesh fallback doesn't hang.
Build: v2.0.12 renderer with NOCULL on for
2c56dc1006942f74(#1300),RX_VK_MESH_OPT=1,RX_VK_WAIT_GPU=1, handheld, 1280x800 output. Tested on SteamOS 3.8.28 and again after updating to 3.9.5 (kernel 7.2, vulkan-radeon 26.05.19): same result on both.Repro: a save in Lon Lon Ranch, turning the camera towards the open landscape. In Game Mode the player gets a
ring gfx_0.0.0 timeoutand a MODE2 reset after 1 to 3 minutes. Headless (RX_VK_CHECKPOINTS=1, the camera turned throughHOS_INPUT_LIVE), the same save hangs 5 out of 5 runs, always between frames 3,800 and 5,100 of the same camera script. With the camera still, it ran 13,200 frames without a hang.What the markers say: every time, the draw left running is one whose task stage is
2c56dc1006942f74. It wasde17bf97df88d1aa(mesh201388b3ce37de7f) four times and5e15283778a635bfonce.What I ruled out:
RX_VK_MESH_NOCULL=0hangs right after the save loads: the original #817 hang.de17bf97df88d1aa(RX_VK_SKIP_PROG) only moves the hang to another program with the same task code.RX_VK_IR, aftermesh_nocull). The two pairs of loops stay in the program, because dead code elimination doesn't remove them, but both ends of each loop are clamped to[0, grid size - 1]. The grid size comes fromGetCbufU32x2 #3, #3088. I also replaced that read with 1, which pins the loops to a single iteration (22 reads replaced). It still hung at the same point.RX_VK_LOG_MESH_DRAWSreports 32 groups for the largest mesh draw of the session.What works:
RX_VK_FORCE_MESH_FALLBACK=1. It ran 15 minutes on the same save with the same camera script, with no hang and nothing missing in the screenshots, at 18 fps against 21 fps on the native path. We use it as the default for now.My guess is that drawing every meshlet, including the ones the game would have culled, sends RADV something it can't finish when the view is that open. I haven't found what yet. I can run builds or switches on this Deck with this save if that helps.
RX 6800 XT GPU hangs on CachyOS / RADV — Hookshot v2.0.14
I'm experiencing reproducible GPU hangs with an AMD Radeon RX 6800 XT when running Hookshot on CachyOS.
I've tested the available mesh-shader workarounds, and disabling mesh shaders entirely allows the game to run successfully.
System information
Problem description
When launching Hookshot normally, the game triggers an AMDGPU GPU hang.
The display session disconnects, and the kernel reports repeated graphics and compute ring timeouts, eventually requiring a full GPU reset.
This has reproduced multiple times.
The kernel identifies Hookshot as the process responsible for the outstanding GPU work.
Kernel logs
The following errors consistently appear:
Different compute rings have timed out across different runs, including:
The GPU reset itself succeeds, but the problem reproduces when launching the game again.
Testing and workarounds
1. Normal launch
Result: GPU hangs, AMDGPU ring timeouts, and full GPU reset.
2. AMD debugging enabled
Result: Does not prevent the GPU hang.
3. Disable mesh shaders
Result: The launcher opens and the game runs successfully.
This is currently the only tested workaround that allows me to play.
4. Disable the specific mesh culling task
Result: Does not resolve the issue. The game still exhibits the original problem.
Observations
The fact that
RX_VK_NO_MESH=1allows the game to run successfully, whileRX_VK_MESH_NOCULL=2c56dc1006942f74does not, suggests the issue may involve something beyond the specific culling task.It appears to be related to the mesh-shader rendering path on RDNA2/RADV, although I cannot determine whether the underlying problem is in Hookshot, RADV, or their interaction.
I'm running the latest Hookshot v2.0.14.
Questions
Another RDNA2 / RADV data point with buffer markers, from
mainbuilt locally.System: Ryzen 7 3800X, RX 6700 XT 12 GB (RADV NAVI22), Mesa 26.2.6, kernel 7.3.3-1-cachyos, niri (Wayland). Hookshot
main@c09e0ac(Vulkan back end compiled from source), and v2.0.14.Note on the kernel: on kernel 7.x the amdgpu default
lockup_timeoutis 2000 ms on every ring (it used to be 10 s gfx / 60 s compute). I raised it toamdgpu.lockup_timeout=10000for these runs, so the hangs below are real hangs, not long jobs cut short (nvn: GPU waits in 5 s: 1 sync waits (11211 ms)).Run 1 (
RX_VK_MESH_NOCULL=2c56dc1006942f74,RX_VK_CHECKPOINTS=1), Kokiri Forest, ~3 min in:Same pair as #620 (RX 6600): last finished before
89ca750f9852b7ca(foliage colour pass).Run 2 (same +
RX_VK_SKIP_PROG=89ca750f9852b7ca), fresh boot:With that program skipped it hangs after a different one (
636eed4d5000d1c0), earlier in the route. So the stop point moves between runs, like the markers in #1275, which points to a wait that never completes rather than one slow shader. Both runs:ring gfx_0.0.0 timeout-> ring reset failed -> MODE1. Before each hang the log showsa capture's wait for write-back ... timed outandslow submit: ~250 ms: memory sync.v2.0.14 without
RX_VK_MESH_NOCULLhangs the same way (gfx ring, ~80 s into gameplay). Happy to run more switches or a debug build if useful.Follow-up to my earlier comment:
RX_VK_MESH_OPT=1fixes it here too.Same system (RX 6700 XT, RADV NAVI22, Mesa 26.2.6, kernel 7.3.3-1-cachyos,
amdgpu.lockup_timeout=10000), Hookshotmain@c09e0ac, Kokiri Forest route:RX_VK_MESH_OPT=1+RX_VK_CHECKPOINTS=1RX_VK_MESH_OPT=1Without it, every run since v2.0.11 hung between ~80 and ~180 s (gfx ring timeout, MODE1), at a different draw each time (markers in my comment above), with or without
RX_VK_MESH_NOCULL. With it, the log no longer prints "task and mesh programs built without the driver's optimizer". So on RDNA2 + RADV the task/mesh programs built without ACO's optimizer are what hangs; this is a second confirmation after the RX 6800 XT and Steam Deck reports above. Turning the optimizer on by default for RADV RDNA2 (or for RADV in general) looks worth considering.RX 6600 (RADV NAVI23), CachyOS, v2.0.14: same hangs as #620 / @liomaroliveira's runs;
RX_VK_MESH_OPT=1gets past the Navi cutscene but not Kokiri; AMDVLK 2025.Q2.1 runs with no hangSystem: RX 6600 8 GB (RADV NAVI23, Mesa 26.2.4, driver 0x6802004), Xeon E5-2697 v3 (Haswell, 14C/28T), 32 GB RAM, CachyOS, kernel 7.3.1-1-cachyos (default
amdgpu.lockup_timeout, i.e. 2000 ms on 7.x), KDE Plasma Wayland. Hookshot v2.0.14 (source f2796384), built with the AppImage.1. Defaults (frame generation off),
RX_VK_CHECKPOINTS=1: GPU hang every time during the first Navi cutscene (Navi flying to Link's house), ~17 fps, frame 12726:Kernel:
ring gfx_0.1.0 timeout-> ring reset failed -> MODE1 reset. 4 earlier runs (frame generation on) ended the same way at the same scene. Frame generation is not the cause.hookshot_log_amdvlk_checkpoints.txt
hookshot_log_radv_defaults_checkpoints.txt
hookshot_log_radv_mesh_opt_checkpoints.txt
2.
RX_VK_MESH_OPT=1,RX_VK_CHECKPOINTS=1: the cutscene plays through and Kokiri runs ~1h40 (frame 116911). It hangs on leaving Kokiri Forest:Same two programs as @liomaroliveira's RX 6700 XT runs (
89ca750f9852b7ca, then636eed4d5000d1c0).3.
RX_VK_SKIP_CODE=463f42630fce83a0,d38b0d52a94ab5a8,40d0c0768e874600(from #1424) on top of 2: no hang in that session, but parts of the plants are drawn plain white.d38b0d52a94ab5a8is the fragment stage of89ca750f9852b7ca, the foliage colour pass, so this is expected. Not a usable workaround.4. AMDVLK 2025.Q2.1 for Hookshot only (as in @Alexatre's comment;
VK_DRIVER_FILESpointing at the extracted.deb, the rest of the system on RADV), withRX_VK_MESH_OPT=1 RX_VK_WAIT_GPU=0 RX_VK_BATCH_MAX=4andRX_VK_CHECKPOINTS=1: ~40,000 frames from Kokiri through the Hyrule Castle entrance cutscene. No device lost and no ring timeout injournalctl -k. Foliage is drawn normally.SLOW compile).mkw_vk_pipelines.binis dropped on a driver switch (pipelineCacheUUID check), so switching back and forth rebuilds it each time. I keep one copy per UUID with a launch script.Other notes:
CmpltAbrt(uncorrectable, non-fatal) from the GPU in the same second. I read it as a consequence of the hang, not its cause.Logs available if useful.
hookshot_log_radv_defaults_checkpoints.txt - 1: Navi cutscene hang (89ca750f9852b7ca) - 0,6 MB
hookshot_log_radv_mesh_opt_checkpoints.txt - 2: leaving Kokiri forest hang (636eed4d5000d1c0) - 7,1 MB
hookshot_log_amdvlk_checkpoints.txt - 3: session without hang on AMDVLK - 2,4 MB
Claiming a small Linux fix here (also posted in Discord #dev-work). It builds on #448.
If Hookshot can't open
/dev/udmabuf(on many distros it'sroot:kvm 0660), it quietly falls back to the slow path, and nothing tells you. On my RX 7900 XT (Mesa 26.2.3, kernel 7.2.7) that was 16 vs 36 game fps in Kokiri Forest, from that one permission.Plan: a one-time warning (terminal and
hookshot_log.txt) when it's a permission error, a short README section (device group or a narrow udev rule), and a game-free test. No renderer changes. Score: S2 × reach ~0.17 × confidence 1.0 ≈ 0.5. Branch:simonwjackson/Hookshot:udmabuf-warning.Following up on #817 with an RX 7900 XT (Navi31), Ryzen 5 7600X, Mesa RADV 26.2.3, Linux 7.2.7 / NixOS: the older local build hung entering Kokiri Forest in 3/4 matched native-mesh trials. This was our older 32df58e-based installation; its log identifies
hookshot unknown (source 802b5e54). One failure logged:Disabling mesh draws survived every such trial, but omitted geometry; that was not a rendering fix. With source v2.0.14 (
117eae79d6724331dfa71c9139fee993d158f245, logged ashookshot unknown (source 4ca6c9ae)), all completed trials survived:RX_VK_FORCE_MESH_FALLBACK=1RX_VK_TASK_MESH_FALLBACK=1These are medians of each run's final-five periodic samples, not frame-generated display fps. Run lengths were 137–231 s, at 1920×1080 with udmabuf active, built-in 2× frame generation and FSR enabled, audio disabled for the harness. One earlier task-fallback attempt timed out in shader preparation and is excluded, not counted as a successful load. Example:
vi: 3554 frames presented (46.5 fps over the last 5.0 s, interval 1).Mesa 26.2.3's Navi31 CI sets
RADV_DEBUG: nomeshshader # Disable mesh shaders until task shaders stop hanging. This is context, not proof of the same defect. These short v2.0.14 runs do not establish a long-term fix or identify a culprit shader.Follow-up on the Steam Deck testing from my v2.0.11 feedback above: v2.1.0 is built and deployed on the same Deck, ready to test.
Hookshot-v2.1.0-x86_64.AppImage(sha256 verified against the release SHA256SUMS), CLI mode, against the same game dump used for the v2.0.11 build. The build finished cleanly (exit 0). One observation: the full build took ~50 minutes wall clock here — after the main compile (0:08:59) there is a long shader stage that v2.0.11's build did not spend nearly as long on.~/Games/Hookshotby checksum rsync (~8.1 GB moved in 33 files).hookshot_version.txton the Deck now readsversion=v2.1.0. Existing options and saves were preserved; saves were also copied to the new~/.local/share/hookshotlocation noted by the build, with the originals left in place and a separate backup taken.RX_VK_MESH_NOCULLwork (#817) changes the task-shader hang behaviour on this RDNA2 Deck, and whether the choppiness/flicker from the v2.0.11 run is any different.The lost overlap reproduces on NVIDIA, so it isn't RADV-specific. You can see it without a Deck by locking the GPU clock until GPU time is close to the replay's.
Setup: ThinkPad P16 with an RTX PRO 2000 Blackwell Laptop GPU (driver 0x912c8100),
sudo nvidia-smi -lgc 900,900. It's the same headless scripted run from one save for both builds, ~1,750-1,800 draws a frame, with the Deck's env:HOS_HANDHELD=1 RX_VK_MESH_OPT=1 RX_VK_PER_QUEUE_FENCES=0 RX_VK_WAIT_GPU=0 RX_VK_BATCH_MAX=4. Each build ran once first to warm its caches. The numbers average the last 8 fps lines and the last 3replay time/GPU timelines.submitGPU time8ef8461)v2.0.14 overlaps ~4 ms of the replay with the GPU. On rc.2, the frame is the replay plus the GPU time, the same pattern as the Deck numbers above (v2.0.14 ~13 ms overlapped,
mainnone). rc.2 still comes out ahead here only because its replay is half of v2.0.14's on this CPU. On the Deck, the replay is about as long as the GPU time, so the lost overlap costs ~17 ms a frame (~22 to ~16 fps). At the stock clock (GPU ~10 ms), rc.2 is faster (45 vs 34 fps), which is probably why desktops haven't noticed.8ef8461is in v2.1.0, so v2.1.0 most likely has it too. I haven't benchmarked the final tag. I've only tried this with the Deck env above, so I can't say yet whether the default switches show it too.A
--first-parentbisect of v2.0.14..fc375e9 on this setup is running now. Before it starts, it checks that both ends built from source separate. I'll post the merge it lands on.Regression on the Steam Deck: the Deku Tree GPU hang is back in v2.1.0 — and still present in tonight's nightly (v2.1.0-rc.3-46-gddafc1f, main @
ddafc1f).Follow-up to my earlier report (#817, tracked here). Same machine as all previous tests: Steam Deck (CachyOS Deckify, RADV Van Gogh), same save, same repro spot — loading the save and letting the Great Deku Tree speech play.
Version history at this spot, on this Deck:
RX_VK_SKIP_CODEworkaround (#1165) is what did it;RX_VK_NO_MESH=1was no longer needed.hookshotprocesses hung the GPU between 21:33–21:38, across a save-load attempt and a new-game attempt. Signature identical to the original:ring gfx_0.0.0 timeout, signaled seq=11652699, emitted seq=11652701Process hookshot pid 223807 thread sead::MainThreaRing gfx_0.0.0 reset failed→ full GPU reset, then a follow-onring comp_1.2.0 timeout.ddafc1f): same hang. Tested tonight after the v2.1.0 result —ring gfx_0.0.0 timeoutat 22:25:11 (pid 237044), ring reset failed, GPU reset, thenring comp_1.1.1 timeout.Suspected cause: v2.1.0 replaced the
RX_VK_SKIP_CODEDeck workaround with the newRX_VK_MESH_NOCULLmode (#1300). On this Deck, NOCULL does not hold where SKIP_CODE did. Options file/settings are unchanged from the working v2.0.11 setup; nothing else on the machine changed.To be clear, v2.1.0 otherwise feels like a step forward — the long upfront pipeline compile looks like the right direction, and once this hang is corrected I'd expect it to run better than v2.0.11 did. Happy to test any build, and I can provide the full kernel log / AMDGPU coredump output if useful.
Steam Deck OLED / SteamOS — GPU hang on Hookshot v2.1.0 (RADV VANGOGH)
I'm experiencing an AMDGPU hang on a Steam Deck OLED running SteamOS with Hookshot v2.1.0.
The failure results in
VK_ERROR_DEVICE_LOST, an AMDGPU graphics ring timeout, a failed ring reset, and a successful MODE2 GPU reset.System information
20261023.100)7.2.7-valve2-2-neptune-72-g31504582a07326.2.0-devel (git-5c65d4fc31)1.4.350e561602ev131072Configuration
My
hookshot_env.txtcontains:My
hookshot_options.inicontains:One important discrepancy: although
RX_VK_TASK_MESH_FALLBACK=1is present in my environment file, the startup log says:I cannot confirm whether the fallback was actually enabled at runtime.
What happened
On November 11, 2026, at approximately 01:21:59 local system time, Hookshot triggered a GPU hang.
The kernel reported:
Hookshot's log ends with:
Vulkan checkpoints
RX_VK_CHECKPOINTS=1enabledVK_AMD_buffer_markeron this RADV device.At device loss, the log reported:
There were additional pending draws and dispatches after these markers. I am not assuming that any individual marker or shader is necessarily the cause.
Performance and memory observations
Shortly before the hang, Hookshot reported:
The last memory sample showed approximately 7.7 GB working set and 1,017 MB of device memory used out of 5,462 MB allowed. This does not indicate straightforward exhaustion of the reported device-memory budget.
Previous testing
I have also encountered GPU hangs on earlier Hookshot builds.
RX_VK_NO_MESH=1previously allowed the game to proceed, but caused missing geometry.I would prefer a solution that preserves mesh rendering.
The current v2.1.0 run still ended in a GPU reset, despite
RX_VK_TASK_MESH_FALLBACK=1being present in my environment file. However, the startup log creates uncertainty about whether that setting was active.Questions
RX_VK_TASK_MESH_FALLBACK=1was actually active in this run?Attachments:
hookshot_log.txt— complete v2.1.0 log with Vulkan checkpoints.hookshot_log.txt
I have paused further testing to avoid repeated GPU resets and desktop-session disruption.
On the latest version with an RX 6600, if I force mesh shaders from native to compute, it doesn’t crash, but in some areas I’m at 20 fps. I don’t know if that’s related to this setting. In native mode, it crashes when loading a save (my save is in Hyrule Field and Cocorico Village).
I also notice shader compilation it faster with native mesh mode.
hookshot_log_native_mesh_mode.txt
Edit: I still crash with RX_VK_TASK_MESH_FALLBACK=1
Game works in the main menu but crashes as it loads a new save file or new game right after cutscene ends.
Hookshot Version: v2.1.0
GPU: MD Radeon RX 6650XT
AMD Driver Version: Mesa 1:26.2.6-1 (RADV)
OS: Archlinux - Kernel 7.2.14-zen1-1-zen
The game works with RX_VK_NO_MESH=1 but is missing some geometry, no grass and bushes, tested with RX_VK_TASK_MESH_FALLBACK=1 and still crash.
hookshot_log.3.txt
cual seria la solucion? ya se soluciono para las rx 6000? o se sigue bloqueando y perdiendo el controlador grafico?
Adding my report here to consolidate the Linux/RADV performance investigation. I've already opened a separate issue documenting the problem in detail: #[your issue number].
System
Issue
I'm experiencing severe visual hitching and inconsistent performance, with no meaningful improvement after updating to v2.1.0.
The most noticeable issue is a disconnect between the reported framerate and the actual visual smoothness. The game exhibits substantial judder and hitching that feels significantly worse than the reported FPS would suggest.
The underlying rendering appears correct, but the visual motion is frequently disrupted.
Findings
RX_VK_PARALLEL=4provides a marginal performance improvement, but the severe hitching remains./dev/udmabufis accessible (Access OK).RX_VK_BATCH), VRAM mirroring, and submit-time memory capture are enabled.Additional observations
I've experienced a remarkably similar visual hitching problem in The Witcher 3 on the same system, which disappeared when signing out of my CDPR account. I don't believe this establishes a shared cause, but it may be relevant when considering whether the issue extends beyond Hookshot itself.
Given the discrepancy between reported performance and perceived smoothness, I'm wondering whether there could be irregular frame presentation, synchronisation stalls, or simulation timing issues not reflected in the available FPS metrics.
I've attached my Hookshot logs to the original issue and can provide additional diagnostics if useful.
hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
RX 6800 XT (RADV NAVI21, Mesa 25.0.7):
gfx_0.0.0timeout → MODE1 reset ~2 min into the opening, withRX_VK_MESH_OPT=1; last marker636eed4d5000d1c0Desktop RDNA2 data point, with the mesh optimizer on. Full
hookshot_log.txtand the kernel excerpt: https://gist.github.com/dvilelaf/a0fe9825d1a5ab12ece462b9360b2277System
source e561602e), officialHookshot-v2.1.0-x86_64.AppImage, native Linux build from my own.nup, game updatev131072, language es.1002:73bf) →AMD Radeon RX 6800 XT (RADV NAVI21), Vulkan 1.4, driver 0x6400007; mesh shaders yes, host memory import yes, pipeline libraries yesudmabufnow accessible (root:video):mem: the guest window is a memfd's (8), shared with the GPU as dma-bufsanddma-bufs of at most 64 MB (udmabuf's limit 64 MB); larger pools are host-pointer imports.Configuration
Everything else default: 2048x1152 output, frame generation off, robust buffers auto. The startup log no longer prints
task and mesh programs built without the driver's optimizer, so MESH_OPT was active.What happens
Kernel (
/var/log/kern.log, uptime 100679 s):After the reset, Xorg on the same GPU aborted inside Mesa (
Fatal server error: Caught signal 6 (Aborted)inamdgpu_winsys_create) and the whole X session went down. Happy to attach the Xorg log if it helps.Notes
636eed4d5000d1c0is the program @liomaroliveira saw on the RX 6700 XT (run 2, "RUNNING after"), and918adef1afaa39d4shows up in @rere225's 6900 XT markers too. On this 6800 XTRX_VK_MESH_OPT=1alone is not enough, unlike the 6700 XT result.RX_VK_TASK_MESH_FALLBACK=1,RX_VK_NO_MESH=1, andRX_VK_MESH_OPToff for comparison and post the results if that's useful.Two data points that may help the last two reports (same RX 7900 XT / Navi31 here, Mesa 26.2.3; rows in #2202):
RX_VK_FORCE_MESH_FALLBACK=1(task and mesh as compute, keeps all foliage) we've had no hang in any run since, and it was also our fastest mode (~46.5 vs ~45 native, game fps). Might be worth one try on the 6800 XT instead ofRX_VK_MESH_OPT=1.game Nline under it is what you feel. On our 7900 XT the game runs about 40–46 there at 1920x1080–2448x1848 standing in Kokiri Forest, so 60 isn't reached on this card yet. Worth comparing yourgamenumber with frame generation off.This configuration works on my RX 6600 and prevents the GPU crash with
RX_VK_TASK_MESH_FALLBACK=1:RX_VK_TASK_MESH_FALLBACK=1uses the compute fallback for task+mesh programs. With 0 (native path), I getVK_ERROR_DEVICE_LOST.The game is now playable without crashing, but the grass/foliage is white. Therefore, this is only a temporary workaround and still has a graphical issue.
Note: AI assistance was used on this test
Thanks for the suggestions! I ran some additional tests on my RX 7900 XT (Mesa 26.2.6, Ryzen 7 5800X3D).
Frame generation has generally been disabled throughout my testing, since I prefer native rendering.
I've discovered that resolution makes a substantial difference. My earlier testing was at native 2560 × 1440, whereas dropping back to the game's default rendering resolution produces considerably better performance, slightly better than the results you've reported.
However, my original issue wasn't simply the inability to reach 60 FPS. I was also experiencing noticeable visual hitching and judder during character and camera movement.
This at least clarifies that rendering resolution is a significant contributor to the performance difference. I'll distinguish between the resolution-related FPS drop and the movement-related hitching in my future testing.
@MattDev-974 try
RX_VK_FORCE_MESH_FALLBACK=1in place ofRX_VK_TASK_MESH_FALLBACK=1. It runs the mesh stage as compute too, not only the task stage. On our RX 7900 XT it drew all the grass and foliage in Kokiri Forest, with no hangs in any run (rows in #2202). TheRX_VK_SKIP_PROGlist may also be part of the white foliage, so one run without it would show that.One NVIDIA device lost on Linux, intermittent (1 of 2 sessions so far).
./bin/hookshotfrom the game folder.RX_VK_PARALLEL=4, no mods.About 8 minutes in, during free play after Kokiri Forest:
Kernel at the same second:
The GPU recovered without a reboot. These are the only Xid lines in this machine's kernel log since Nov 3.
The game's VRAM was 10.0-10.7 GB of 10.8 GB allowed in the minutes before (10,433 MB on the last line). But a second, 17-minute session on the same build reached the same VRAM (up to 10.5 GB; 11,951 of 12,282 MiB for the whole card) with no crash. So being near the limit is not enough by itself. The 5.4 s import just before the reset is the clearest lead (my guess). Both sessions also had a few
NVRM: memMap_IMPL: CPU mapping not supported for addressSpace: 0x1lines without a crash.The same Xid 109 is reported for Lichii (zortos293/Lichii #619) on an RTX 4070 with a 615-series driver, so this driver series may be involved. Full
hookshot_log.txtof the crashed run attached (home path removed). Discord was hooked into the game (game activity); I have not yet tried a crash run without it.hookshot_log_crash_2026-11-11.txt
Bisect result for the lost CPU/GPU overlap: #1375 (
e63d30d). I bisected--first-parent v2.0.14..fc375e9on the P16 setup from my previous comment (RTX PRO 2000, GPU locked to 900 MHz, the Deck's env). Each step was built from source, and the measure was overlap = replay + GPU time − frame time. The controls separated: v2.0.14 at +2.8 ms,fc375e9at −1.8 ms.10cfd70was good (+1.1) ande63d30dbad (−1.8).On current main (
ebbba2e), the overlap is −1.4 ms, and +1.4 ms with #1375 reverted. The revert costs its CPU gain, though: replay goes from 10.1 to 14.9 ms, programs from 1.3 to 5.1. So I don't think a revert is the right fix.What the Deck shows (
fc375e9, the same standing Kokiri scene):readbacks of GPU resultsline). v2.0.14 never logs that line in the same scene.RX_VK_LOG_READBACK_WAITS=1shows only two ranges, alternating:0x113b623000 +0x3980and0x113b628000 +0x3980.RX_VK_LOG_READBACKshows the same words in them every frame:3dcccccd 46c35000 3fe38e3b 3f7fffbd, i.e. 0.1, 25000, 1.777, 0.99999. They look like camera constants that the CPU writes and the GPU only reads, not GPU results.note_direct_writeshows these pages marked on every bind, fromgpu_buffer_bind(..., written=true). I haven't found yet which binding passeswritten.RX_VK_NO_READBACK_WAIT=1bringsfc375e9from 14.1-14.4 to 19.6 fps (v2.0.14: 19.7), and the game's fence waits come back (0 → 82 per 5 s). It showed no exposure steps: brightness over 150 screenshots, one every 6 frames, moved at most 0.34 between shots, against 0.39 on v2.0.14.On the Deck, reverting #1375 from
fc375e9alone didn't remove the waits (still ~170 per 3,000, ~30 ms each). So something else also marks those pages there. My guess is that the fix belongs in the write-back marking (a binding conservatively flagged as written), not in #1375's cache. That's from reading and logging, not proven.A tool offer, not a bug report — and if it is noise in a tracking issue, say so
and I will drop it.
Reading this issue, the hard part is rarely the symptom: it is that "stutters in
the forest" from one machine cannot be set against "stutters in the forest" from
another. Different save, different route, different settings, numbers read off
the OS rather than the renderer. So after reporting here from a ROG Ally X I
built the harness I needed to stop guessing, and it is now doing real work:
this game
What it does. The game runs headless in a nested Wayland compositor with a
virtual Xbox pad, driven by a YAML scenario rather than by hand. A scenario
waits on the game's own log lines instead of sleeping:
vk: replay ready,oe: startup logo finished, thencheats: inventory probefromHOS_OOT_CHEATS=1, which is how it knows Link exists rather than guessing froma picture. The title screen is recognised by comparing against a reference with
a mask over the shield so the movie behind it does not count. Then it plays a
scripted walk to the millisecond and collects
RX_VK_FRAME_LOG, captures, and amanifest holding the Hookshot version, the kernel, the driver and a digest of
the scenario and config. Two runs are comparable, and a result can be replayed
by someone else.
What it has produced this week, all of it on a Ryzen Z1 Extreme / Radeon
780M:
across versions — which is how I caught that my own first attribution of it
was unsound, because the container's RADV had moved under me between two
measurements;
located a brightness pulse that
RX_VK_PER_QUEUE_FENCES=0removes half of;for 3146 MB against a 2560 MB budget, with the eviction lines to match.
Two cautions it encodes, in case they help anyone here. The pad's confirm
button is B, not A, because
hookshot_options.inihaspad_a=1and that landson an Xbox pad's B. And the first start-ups after an update are very long — on
this machine it took three launches before the title screen appeared, while the
program cache filled to 6.7 GB; a scenario with a 240 s timeout simply fails
there, which looks like a hang and is not one.
On your rules. Neither repository holds any game file, dump, key, save or
build output, and nothing in them helps anyone obtain the game: they drive a
copy you already built yourself. Reference images and captures are gitignored
and stay on the machine that made them.
If a specific measurement on Z1 Extreme / RADV would help you — another scene, a
setting toggled, an rc build before you tag it — it is about two minutes a run
now. Ask here and I will post the numbers.
Steam Deck performance: what I measured over the last two days, and where I think the ceiling is. Steam Deck LCD, SteamOS 3.9, GPU at 1200 MHz, FSR 3.1 + handheld profile. All numbers are from a deterministic headless run of the standing Kokiri scene (~2,400 draws, the P16 bench save). A is pressed only until gameplay starts, so every run renders the same scene; runs are alternated A/B, ~2 min each, and the noise is ~1-4 ms of replay.
Where a frame goes (v2.0.14): ~20 fps, replay ~37 ms, GPU ~28 ms. The Deck is CPU-bound on the replay thread, and the GPU would already fit 30.
hookshot_vk.so(build_descriptors 6%, dw 5%, std::map walks 4%, texture_view_of 3%, gpu_buffer_bind 2.5%, __tls_get_addr 2%), ~17% RADV, ~10% kernel. It's on the CPU ~56% of the time. Most of the 7 msqueue submitis blocked, not working:pthread_mutex_lockinside RADV's submit.amdgpu_cs_ioctlis only ~0.9 ms a frame.Regressions since v2.0.14 on the Deck:
0x113b623000/628000 +0x3980) is bound written by six compute programs (stage 5, e.g.44511d69b52282ad,383a566958350efe, slots 0/9/10), through the storage-buffer path (d.is_written). The camera constants I decoded are only its first words, so the GPU may well write the rest, and the wait may be legitimate rather than a false positive. What costs the Deck is how it waits: the game thread waits ~25 ms each frame (replay caught up plus GPU done).RX_VK_NO_READBACK_WAIT=1gives back v2.0.14's speed with no visible exposure stepping. On the Deck, reverting #1375 fromfc375e9doesn't remove the waits, so something else marks those pages there.Tried, no win on the Deck (each as an A/B):
RX_VK_BATCH_MAX8/16 (still 6 submits)RX_VK_MIRROR=1(12.7 fps)RX_VK_IMPORT_CHUNK_MB64 (27 pools instead of 36, the same submit cost)RX_VK_PARALLEL2/3 (19.2/18.9 vs 19.1)RX_VK_CAPTURE_THREADS=0RX_VK_PER_QUEUE_FENCES=1RX_VK_EVENT_WAITS=0/RX_VK_SYNC_WAITS=0(submit -0.7 ms)HOS_PINfor OptimizeChangeBank / ParallelDecomp (its CPU halved, the same fps)-ftls-model=initial-execGPU, for later: the top passes are full-screen
43ec86f35fd937b93.75 ms (a deferred-lighting loop over lights, ~450 ALU a light),d8e59341cf4f629c1.7 ms andda7a7ab28b8e73d91.0 ms; barriers ~1 ms.The horizon as I see it. The replay's ~37 ms is spread over many functions, with no single hot spot. The incremental levers I can measure add up to perhaps 5-8 ms:
That's enough for mid-20s, not 30. Getting to 30 on this CPU probably needs the replay to skip translating work that repeats: reuse recorded Vulkan commands for passes whose NVN streams match a recent frame, with constants rebased through dynamic offsets. Before anyone builds that, it needs its repeat rate measured against the last N frames, not just the last one. I'm happy to measure that, or any candidate, on the Deck harness.
RX 6800 — RADV vs AMDVLK 2025.Q2.1 (CachyOS)
Hardware:
RADV testing:
With RADV, I was unable to get past the fairy cutscene near the beginning of the game. Shortly after that scene, the GPU driver would crash, making further gameplay impossible.
System logs showed
gfx_0.0.0 ring timeout, followed by failed GPU ring reset attempts.I also tried launching the game with
RX_VK_MESH_OPT=1, but this did not solve the problem.AMDVLK testing:
After switching to AMDVLK 2025.Q2.1, the game finally allowed me to get past the fairy cutscene and continue playing.
So far, gameplay has been relatively stable, with no comparable GPU driver crashes. Performance is not particularly high, hovering around 39–52 FPS, but the game is actually playable now.
Conclusion:
On my RX 6800, AMDVLK 2025.Q2.1 appears significantly more stable than RADV in the opening section of the game. Despite the relatively low FPS, being able to get past the point where RADV consistently crashed is a major improvement.
I will continue testing and report any further crashes or stability issues.
Steam Deck:
RX_VK_MESH_OPT=1stops the hang,RX_VK_MIRROR=1removes the flashing (measured)Setup: Steam Deck, SteamOS Game Mode, Mesa 26.2 RADV VANGOGH. Hookshot v2.0.11 (source c3d60938), the Linux game folder built with the AppImage's toolchain. Two local, logging-only switches were added; they were off in the runs below. Handheld profile on, frame generation off.
1. The hang: fixed by
RX_VK_MESH_OPT=1radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.→batched submit failed (-4)→ the process is killed.RX_VK_MESH_OPT=1, nothing else changed: Kokiri Forest loads. Six sessions of a few minutes each had no device loss.task and mesh programs built without the driver's optimizer (AMD; RX_VK_MESH_OPT=1: with it)is the setting that matters on RADV.2c56dc1006942f74. Its depth grid (c3+0xc10) is never larger than 32 × 18 cells on the Deck, so a runaway loop is not the cause.2. The full-screen flashing: data races, not exposure
Once in game, the screen flashed white/black about every second. I measured it with the built-in detector:
RX_VK_SHOTS=<dir> RX_VK_SHOT_EVERY=1 RX_VK_FLASH=1 RX_VK_FLASH_DUMPS=0 RX_VK_EXPOSURE_LOG=2.MESH_OPT=1 UB_SNAPSHOT=1)VRAM mirror of buffer pools off)RX_VK_MIRROR=173320e720a317817) is exactly 1.0 on every present, flash frames included.Tried without effect on the flashing (with mirrors off):
RX_VK_EVENT_WAITS=0RX_VK_PER_QUEUE_FENCES=0 RX_VK_WAIT_GPU=0 RX_VK_BATCH_MAX=4: also dropped the frame rate a lot.RX_VK_UB_SNAPSHOT=1(v2.0.11's version) was on in both runs in the table.Cost of
RX_VK_MIRROR=1on the Decksubmit(CPU)memory syncThe mirrors line reads
mirrors 65–68 (768 MB): 7.5–9.4 MB synced in ~860–1030 copies, ~12.5–12.9 MB written backa frame.The result is about 11–14 fps with mirrors on, against about 14–20 fps with them off (flashing). The replay thread's CPU time is now the limit; dropping the 3D resolution to 50% lowered GPU time to 33–46 ms but did not raise the fps.
Suggestion: on integrated GPUs it might be enough to mirror (or read from the submit-time captures) only the pools that hold per-frame data, such as the foliage instance data and the HUD constants. That would keep the flash fix without paying for all 768 MB. I can run a test build or more detector runs on the Deck if that helps.
Env for anyone on a Deck who wants to try (v2.0.11,
hookshot_env.txt):Follow-up to my Deck summary above: where the replay time goes, and one correction. Same harness: standing Kokiri scene, v2.0.14 unless noted.
Correction on #1375's readback wait: it is legitimate. I snapshotted the bytes the game reads before and after each wait. In ~92% of waits (5,300 measured) they change, by ~1.5 KB per wait, at offsets 5-7791 of the 14.7 KB block. So the GPU really rewrites it each frame.
RX_VK_NO_READBACK_WAIT=1makes the game read those results one frame stale, which v2.0.14 did implicitly and which showed no visible problem here. That makes it a trade-off for CPU-bound devices, not a bug fix.The replay is serialized under
sync_order_mu. I wrapped it to trace holders and waiters per frame:RX_VK_PER_QUEUE_FENCES=0: the Presentation Thread holds it 21 ms/frame (the main queue's whole replay). AModuleSystemWorkerwaits ~12.8 ms/frame for it inwait_queue_empty(), the readback catch-up. With per-queue fences on (the lightersync_settle()), that wait disappears and fps goes from 31.1 to 35.1.presentwaits ~11.6 ms. The held time adds up to ~45 ms of a ~53 ms frame, so the Deck's real per-frame replay work is ~45 ms, more than thereplay timeline's ~37.Negative results, so nobody repeats them:
RX_VK_RECORDER=thread(mainfc375e9+RX_VK_NO_READBACK_WAIT=1): commands go from 8.4 to 5.0 ms and the replay is ~2 ms lighter, but fps is flat (20.8/20.9 vs 21.2/20.8).Cross-frame repeat: keyed on the game's own inputs (program, textures, samplers, guest uniform-buffer address and size, storage bindings), draws repeat only 2.8% against the previous frame, but 79-80% against 2 frames back and 86-89% within 8. The game double-buffers its per-frame constants. A cache keyed on that could skip the handle → view resolution (~3 ms on the Deck); uniform copies and
gpu_buffer_bind's side effects still have to run every frame.What I'm working on next, each as its own PR with Deck numbers:
My estimate is ~8-15 ms together: mid-to-high 20s on the Deck, not a locked 30.
Steam Deck: where I think the CPU ceiling is. This closes out my Deck series above, with the same harness throughout: standing Kokiri scene, deterministic headless runs, A/B alternated.
The frame is the total replay work, serialized. On the Deck the held time of
sync_order_muadds up to ~45 ms of a ~53 ms frame. In sync modepresent()runsdrain(0)under that lock, which replays submissions stopped at an event wait, and the order thread replays the rest. So the ~11 ms gap between thereplay timeline and the frame time is replay work that the line doesn't count, not idle waiting. Moving work between threads doesn't shrink it:RX_VK_ASYNC=1(core reserved)RX_VK_ASYNC=1 HOS_RESERVE_CORE=0RX_VK_RECORDER=thread(fc375e9+RX_VK_NO_READBACK_WAIT=1)RX_VK_PARALLEL=2/3Async also brings the exposure stepping back: 90 brightness steps above 2 (largest 15.5) over 200 shots taken every 3 frames, against 0 in sync.
Reusing translated work across frames doesn't fit this game. Keyed on the game's own inputs (program, textures, samplers, guest uniform-buffer address and size, storage bindings), single draws repeat 79-89% within 2-8 frames. But whole replay segments (the work between pass starts, 177 a frame) repeat far less, measured on the P16:
The ~20% of draws that change each frame are spread evenly through the passes (0.8^8 ≈ 17% for an 8-draw chunk), so recording passes once and replaying them can skip only a small part. What's left is per-draw caching, and texture views are already cached (
handle_hits).Ceiling. The remaining levers I can measure are:
build_descriptorsrewrite (~1.5-5 ms);Together that's ~5-10 ms of the ~45, so ~22-25 fps on the Deck harness (real play somewhat higher, ~45+ shown with frame generation), not 30. A locked 30 on this CPU would need the per-draw memory bookkeeping (captures, write tracking, readback marking, uniform staging) redesigned around reuse. I don't see a safe path to that from these measurements. The full write-up with the prior-art comparison (Ryujinx, yuzu/Eden, DXVK, vkd3d-proton, RADV) is available if useful. I'm keeping the harness, so any candidate can be measured on the Deck in ~10 minutes.
More reports of this, collected here:
49f75dc8(v2.1.0-rc.3-53), built from source. The discard cod; RTX 4090, NVIDIA 590.48.01 (open kernel module); Ryzen 7 5700X3D, 125 GB, Arch Linux, kernel 6.19.8)Hey, I've been testing
v2.1.0(e561602e) on a Ryzen 5 5600GT (RADV Renoir iGPU, 16 GB shared RAM on Bazzite Linux) and managed to track down why AMD GPUs are gettingVK_ERROR_DEVICE_LOSTright after the intro cutscene, plus a config that fixes both the crash and the missing grass/leaves without needing to rebuild caches (there was also a graphical error from my previous report, which is now fixed inv2.1.0).Why it crashes by default (hookshot_log.1.txt & hookshot_log.2.txt)
On a 16 GB shared-memory APU, Hookshot automatically sets the VRAM limit to
5411–5543 MB. When the intro cinematic ends and Kokiri Forest loads (around frame 970–1276), the game tries to upload ~450 MB in a single frame—including a massive12288x12288shadow texture (288 MB) and two1365x1365x90ASTC texture arrays (213 MB each).As soon as it hits ~500 textures (
1691 MB), the log starts spammingtexture slot ... no image for itacross dozens of slots, the submit hangs for1577–2243 ms(also logginga capture's wait for write-back 8639 timed outon a fresh shader cache in hookshot_log.2.txt), andamdgpuresets the context (batched submit 1013 failed (-4)).I ran it with
RX_VK_CHECKPOINTS=1(hookshot_log.1.txt) and the buffer markers caught the exact moment it dies—it's not hanging on the lighting shader, it's dying mid-upload right around program5fbaa372e5b10593:How I fixed the crash + missing foliage (hookshot_log.3.txt & hookshot_log.txt
I was able to get past the intro and play for 4,500+ frames without a single crash using this
hookshot_env.txt:One really important detail I noticed while tweaking the RAM/VRAM values:
RX_VK_VRAM_MB=3072(hookshot_log.3.txt), the crash stopped completely (4,575+ frames at ~21–24 fps), but grass, leaves, and some meshes were invisible. Looking at the log, those 3 huge textures alone eat up714 MB, so a 3072 MB budget was constantly evicting 70–115 textures per frame and starving the compute mesh fallback buffers.RX_VK_VRAM_MB=3584(in my latest run, hookshot_log.txt) gave it just enough breathing room (~3165 MBused) so the storage buffers (prog 3a131272834635ab ssbo 0andprogram da7a7ab28b8e73d9) could stay bound. With 3584 MB, all the grass, leaves, and meshes render properly (scaling up to 4,012 draws at frame 4320) and the game survives even a4920 msscene-load spike without resetting the AMD driver.Additional Steam Deck OLED testing – Hookshot v2.1.0 / AMD RADV / Compute mesh shaders
I'd like to share the results of another round of testing on my Steam Deck OLED, this time using the new Mesh Shaders: Compute option available in Hookshot v2.1.0.
Hardware and software configuration
20261023.1007.2.7-valve2-2-neptune-72-g31504582a07326.2.0-devel(git-5c65d4fc31)Test configuration
RX_VK_VRAM_MB=1200I switched to Compute through Hookshot's settings rather than relying on the previous experimental mesh shader workarounds.
Visual results
This configuration produced a noticeable improvement:
This is the first configuration in my recent testing that gave me this combination of improved geometry and reduced visual artifacts.
Performance and crash
Performance was still inconsistent, however.
The last Hookshot log showed the following statistics:
Important finding: system memory exhaustion (OOM)
I checked the SteamOS kernel logs immediately after the crash.
At
17:29:02, the kernel reported:BaseProcExecuto invoked oom-killerThe subsequent stack trace included
out_of_memory()and__alloc_pages_slowpath().This indicates that Linux triggered its Out-Of-Memory Killer because a memory allocation could not be satisfied.
Importantly, I did not find a new AMDGPU ring timeout or GPU reset in the corresponding five-minute kernel log window. This suggests that this particular crash may be related to system memory pressure rather than the GPU reset issues observed in previous tests.
I have not yet identified which process was ultimately killed, so I cannot confirm that Hookshot itself was the OOM victim.
Possible connection with texture uploads
I also came across another user's report mentioning a very large texture uploading, involving a 12,288×12,288 shadow texture and large ASTC texture arrays.
I wonder whether this could be related to the memory pressure observed on my device, although I have not independently confirmed that these specific textures are responsible for my crash.
Summary
On my Steam Deck OLED, switching to Compute mesh shaders appears to resolve or significantly improve the previous visual problems:
However, performance still degrades considerably in more demanding areas, eventually leading to an OOM event and game closure.
I hope these results are useful. I will wait for further improvements before running more experimental configurations, but I wanted to share these findings because Compute seems to be a meaningful improvement on this hardware.
Steam Deck (RADV VANGOGH): @addisonbair's env worked here — playable through Kokiri / sword & shield, no crashes
Setup: Steam Deck, stock SteamOS, Hookshot v2.1.0 (
e561602e), RADV VANGOGH. Native mesh (noNO_MESH/ no forced mesh fallback).hookshot_env.txt(from addisonbair's measured Deck config), plusRADV_PERFTEST=cswave32from the launcher:In-game: Handheld on, AMD FSR 3.1 upscaler. In-game Frame generation left Off.
Frame generation: I used lsfg-vk (2×) instead of Hookshot's built-in FG. For me that felt better — smoother presentation without stacking two FG paths, and the base game fps stayed honest in the log.
Session: played from the start through getting the sword and shield. No GPU hang / no
VK_ERROR_DEVICE_LOST/ no crash in that stretch.Base fps from
hookshot_log.txt(game presents, before lsfg-vk multiply):So this matches Addison's ballpark (~20–24 base). With lsfg-vk 2× the motion feels closer to the mid/high 40s on screen, while the log still reports ~20 base in Kokiri-heavy areas.
Happy to retest builds that touch the mesh path or the replay CPU side — this Deck is in a good place for that with this env.
Follow-up: Mid-game save loading, BC3 compute hang, and GTT/System Heap exhaustion on 16 GB APUs
After playing further into the game (past the Great Deku Tree, Hyrule Field, Market, and up to Hyrule Castle), I ran into a few more specific bottlenecks on a 16 GB shared-memory AMD APU (Ryzen 5 5600GT / RADV Renoir on Bazzite, ~13.8 GB system RAM available to Linux) that might help explain why 16 GB APUs/handhelds crash later in the game:
1. Loading a mid-game save crashes on the GPU BC3 re-encode shader (
submit failed (-4))When loading a save file after the Deku Tree, both
1365x1365x90ASTC terrain arrays (0x10a0eda600and0x10a4752c00, 56.5 MB upload each) + ~78 CPU textures are submitted in the same frame:RX_VK_BATCH=0andRX_VK_PER_QUEUE_FENCES=0, keepingall large ASTC textures kept as BC3consistently resetsamdgpuon save load when both 90-layer arrays are decoded and re-encoded to BC3 on the GPU in the same frame.RX_VK_ASTC_RGBA8=1(along withRX_VK_BATCH=0) completely stops the GPU reset on save load and boosts performance to 30–37 fps.2.
RX_VK_ASTC_RGBA8=1balloons the1365x1365x90arrays to852 MBeach (Not enough memory for command submission)With
RX_VK_ASTC_RGBA8=1at default dimensions,0x10a0eda600and0x10a4752c00jump from213 MB(BC3) to852 MBeach (1,704 MBtotal). During a zone transition around frame 3647 (whendma-bufpool imports reach82 imports/~2.2 GB+4.6 GBin textures),radv/amdgpuhits the kernel GTT limit:3. Capping
RX_VK_TEX_MAX_DIM=1024fixes VRAM, butsystem heap+dma-bufimports hit the ceiling at Hyrule CastleTo keep
RX_VK_ASTC_RGBA8=1without blowing past the GTT allowance, I used:1365x1365x90arrays to682x682x90(212 MBeach, leaving 1 top mip level out), keeping active texture VRAM around1.9–2.2 GBand allowing smooth 30–38 fps gameplay across Kokiri Forest, Hyrule Field, and Market for 5,180+ frames.dma-bufpool imports spike up to96 imports(42 live (2080 MB)) andsystem heaphits2432 of 2501 MB(while also running120,000+DrawMeshTasksIndirectvia the compute fallback path and waiting on199 of 3000GPU write-backs), which eventually exhausts host/shared memory and closes the process without a Vulkan error.[Steam Deck OLED / RADV] Sacred Grove GPU timeout on v2.1.0 — RX_VK_NO_MESH=1 allows scene to load
Summary
I am running Hookshot v2.1.0 on a Steam Deck OLED with SteamOS and the AMD RADV VANGOGH Vulkan driver.
I have successfully progressed through the Great Deku Tree, Kakariko Village, and Death Mountain using several environment settings to improve stability.
However, entering Sacred Grove from Lost Woods consistently causes a GPU crash with normal mesh rendering enabled.
Important finding: Lowering graphics settings to Minimum does not prevent the crash, but enabling
RX_VK_NO_MESH=1allows Sacred Grove to load successfully.This suggests the crash is associated with the mesh/task rendering path rather than simply the overall graphics quality or resolution.
Steps to reproduce
Launch Hookshot v2.1.0 on Steam Deck OLED using the environment configuration below.
Load a save near Lost Woods.
Proceed into Sacred Grove.
During the scene transition, the game freezes or crashes.
Sometimes the Sacred Grove cutscene starts before crashing; other times the screen remains black.
The kernel reports an AMDGPU graphics-ring timeout and GPU reset.
Environment configuration
These settings allowed me to progress substantially further than my earlier configurations:
The last setting was added for GPU crash diagnostics.
Workarounds tested
Configuration | Result -- | -- Above configuration with normal graphics settings | Successfully progressed through multiple areas, but crashes entering Sacred Grove Minimum (4GB) graphics preset, 50% resolution, frame generation disabled | Still crashes entering Sacred Grove Above environment configuration plus RX_VK_NO_MESH=1 | Sacred Grove successfully loads Earlier targeted RX_VK_MESH_NOCULL=2c56dc1006942f74 testing | Setting was confirmed active in logs, but did not eliminate all GPU crashesI understand that
RX_VK_NO_MESH=1can produce missing geometry, making it unsuitable as a permanent solution. However, it is a useful diagnostic workaround.Crash log and GPU checkpoints
With
RX_VK_CHECKPOINTS=1enabled, the crash produced the following:The kernel reported:
Other observations
Immediately before the crash, the log included:
A
12288x12288render target (288 MB).Approximately 2.1 GB of active texture allocations.
Multiple ASTC texture uploads.
A slow submit of 741.7 ms, including 706.8 ms in texture lookups.
Several draws using program
8c62d1705ea73694remaining outstanding after the last completed GPU checkpoint.I cannot determine whether the outstanding texture upload or subsequent draw operations caused the timeout.
I also attempted to inspect the AMDGPU device coredump reported by the kernel, but
/sys/class/drm/card0/device/devcoredump/was not available when checked.Related issues
#817 — Steam Deck RADV GPU hangs involving mesh/task shaders.
#1318 — Steam Deck device loss during a transition involving a 12288 render target.
#1000 — Linux/Steam Deck GPU hang tracking issue.
Questions for developers
Does the fact that
RX_VK_NO_MESH=1allows Sacred Grove to load indicate another mesh/task shader hang, potentially distinct from the previously identified Great Deku Tree issue?Can the outstanding draw program
8c62d1705ea73694be mapped to its underlying shader code to identify a targeted workaround?Are there additional supported diagnostic settings or targeted fixes I can test without disabling mesh rendering globally?
I can reproduce this issue using my Sacred Grove save and can provide additional checkpoint logs or run specific tests if useful.
Thank you for the work on Steam Deck compatibility!
hookshot_log.txt
hookshot_log.1.txt
Another Linux/RADV datapoint, matching #2245's fingerprint exactly, plus the
workaround confirmed on the card.
Hyprland 0.57.2 / Wayland. Hookshot v2.1.0 (
e561602e).(
mesh_shaders=0→ native task/mesh) it dies as soon as the world/map loads;the in-game menu and the loading screens are fine.
ring comp_1.3.0 timeout(ring reset succeeded)→
ring gfx_0.0.0 timeout→Ring gfx_0.0.0 reset failed→GPU reset begin!. Source: 1→VRAM is lost due to GPU reset!→GPU reset(2) succeeded!.storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20plus
a capture's wait for write-back 6035 timed out (done 6031)andslow submit: 257.5 ms: memory sync 257.4.mesh_shaders=2(Compute), one line inhookshot_options.ini.Then: 49,584 frames, 57–60 fps, 0 ring timeouts, and it uses more VRAM
than the crashing run (5.4 GB used, 3069 MB of textures vs 1283 MB used in the
crashing one). Cost: longer first start (task/mesh re-prepared as compute) and
some fps.
down — Hyprland aborts in
Render::GL::CHyprOpenGLImpl::beginright after theVRAM loss, so users see the desktop go away, not just the game.
Full report with logs and dmesg: #2590
Is there a way to decrease even more the resolution of the game? Like 540p or else? Sorry if I bother in here, but I wanna know if there is any command on Hookshot_env.txt or something to decrease it
Tried the README workaround (RX_VK_MESH_NOCULL=2c56dc1006942f74 in hookshot_env.txt) — it didn't help.
The env file is picked up: the log shows "task code 2c56dc1006942f74: culling off, every meshlet drawn (RX_VK_MESH_NOCULL)" x8 and shaders were recompiled. But the hang is identical: ~3 min fine at 60 fps through intro/menu, then on New Game the first mesh draws appear, heavy texture uploads, fps drops to ~20 and the GPU hangs.
journalctl -k:
02:42:51 ring gfx_0.0.0 timeout, signaled seq=89387, emitted seq=89390 — hookshot thread mkw_vk (without workaround)
03:01:29 ring gfx_0.0.0 timeout, signaled seq=170715, emitted seq=170719 — hookshot thread Presentation Th (with workaround)
Ring gfx_0.0.0 reset failed
03:01:41 ring comp_1.0.1 timeout
Without the workaround the run ended with VK_ERROR_DEVICE_LOST (radv: "The CS has been cancelled because the context is lost. This context is innocent.").
Steam Deck OLED, SteamOS kernel 7.2.7-valve2 (neptune-72), RADV VANGOGH, hookshot v2.1.0 (e561602e).
Is there a way to force the mesh fallback path instead of native mesh shaders to test?
Logs attached.
kernel_crash.txt
hookshot_log_with_workaround.txt
More reports of this, collected here:
;)Steam Deck performance: where the frame goes, what helps today, and what didn't
We measured every change on a Steam Deck LCD in one deterministic scene: headless, standing in Kokiri Forest next to Saria (~2,400 draws), GPU fixed at 1200 MHz, same save, alternating A/B runs.
eaef1460, default switchesv2.0.14 is still the fastest Hookshot on the Deck, by 30-40 %. Per-thread perf traces of main show where it goes:
sched_yield) for workers that sit in readback waits. On main those are ~1 a frame of 10-14 ms each, on the newest submission; on v2.0.14 they're ~6 a frame of ~0.6 ms.RX_VK_DIRECT_WB_PAGES=0would show it, but watch for #1126's foliage glow in motion.The Deck's own ceiling: even on v2.0.14 the frame is ~37 ms of replay that runs in order under the order lock (on a P16 stand-in it's held 93-98 % of the time). Little of the frame is idle handoff. These were all measured and didn't help on the Deck:
Faster single-thread CPUs are what move this.
What works on the Deck today (v2.0.14):
RX_VK_MESH_OPT=1 RX_VK_PER_QUEUE_FENCES=0 RX_VK_WAIT_GPU=0 RX_VK_BATCH_MAX=4 RADV_PERFTEST=cswave32inhookshot_env.txt.That's ~24 fps base in villages. Hyrule Field is CPU-bound (~10 fps): there, a lower GPU clock (800-1000 MHz) leaves more of the 15 W for the CPU.
On v2.1.0 / main:
RX_VK_BATCH_IDLEat its default; set alone it lengthens readback waits. #2422 pairs it with a fix.The full numbers, the benchmark setup, and a v2.0.14-based branch with the merged Deck fix (#1965) are at https://github.com/addisonbair/Hookshot/blob/deck/docs/steam-deck.md. We're stepping back from Deck tuning for now; #2422 stays open.
🤖 Generated with Claude Code
amvlk here (amd 5600G + amd 6600 8gb), solve all the problem, but it rebuild the shaders (instead radv, load the shaders immediatly)
hookshot_gpu.txt
hookshot_log.txt
I'm experiencing GPU hangs on my Steam Deck OLED with Hookshot v2.1.0 (source
e561602e), running SteamOS.Even before the intro cutscene, the title screen has noticeable performance issues. FPS drops significantly during the close-up shot of the grass, and the frame rate is generally quite uneven. The frametime graph shows regular, periodic spikes, almost as if some part of the original game's 60 Hz timing or synchronization is still interfering with frame pacing. That's just a guess based on the graph, though.
The intro cutscene itself runs at around 60 FPS, but the frame pacing isn't consistently smooth. Right at the transition into gameplay, FPS drops to ~1, then slowly recovers to ~8 FPS while the screen remains black. On my latest attempt, I briefly saw the first second of gameplay before the GPU hung and the game eventually exited.
VRAM allocation shown by the Steam Deck overlay reached approximately 5.5–5.6 GB.
I tried the following settings in
hookshot_env.txt:The shaders were rebuilt (over 67,000 compilation operations), but the issue persists.
The kernel log confirms an AMDGPU hang:
On one attempt, the entire Steam Deck became unresponsive and required a forced reboot. On the latest attempt, SteamOS remained responsive and the game exited after the GPU reset.
I've attached
hookshot_log.txtandhookshot_gpu.txt.Let me know if any additional diagnostics would help!
Steam Deck LCD, v2.1.0: GPU only ~56% busy because of readback waits (#1375);
RX_VK_NO_READBACK_WAIT=1gives +16%. Also: whyRX_VK_ASYNC=1freezes at boot, with a patchHardware / build
0x6801063, GPU 1600 MHz, 15 W cape561602e), built on the Deck from my own.nup(v131072)Method
HOS_HEADLESS=1),HOS_HANDHELD=1,HOS_OUTPUT_RES=1280x800,RX_VK_MESH_OPT=1,RX_VK_PRECOMPILE=0vi: ... fps over the last 5.0 slines (90 s), after ~170 s of warm-up. Run-to-run spread of the baseline: 21.62-21.88 fps (5 runs).1. Configuration and hangs (loading the save into Kokiri)
gfx_0.0.0 timeout, GPU reset while loadingRX_VK_MESH_NOCULL=2c56dc1006942f74(the 2.1.0 workaround)gfx_0.0.0 timeout, GPU reset while loadingRX_VK_TASK_MESH_FALLBACK=1RX_VK_MESH_OPT=1RX_VK_MESH_NOCULL+RX_VK_MESH_OPT=1So on this Deck, NOCULL alone does not avoid the hang in 2.1.0; MESH_OPT does.
2. CPU and GPU take turns
Render resolution (menu row,
resolution=inhookshot_options.ini) against frame time:Frame time is about GPU time + ~21 ms in every case: the GPU and the CPU work one after the other.
gpu_busy_percent(amdgpu sysfs, 300 samples at 10 Hz) agrees: 55.7% busy at Auto, about half the samples near 100% and the rest near 0.An all-thread sample (
HOS_SAMPLE_ALL,scripts/crit.py) shows the CPU is not saturated either: on average fewer than 2 game threads run at once, sead::MainThread is blocked ~86% of the time (job waits in f_8007fe60 / the 20 µsSleepThreadpoll at lr0x8009a478, ~58k calls/s, and event waits), and the Presentation Thread waits inqueue_get~39% of the time.3.
RX_VK_NO_READBACK_WAIT=1: +16%RX_VK_NO_READBACK_WAIT=1No GPU hang.
RX_VK_FLASH=1withRX_VK_SHOT_EVERY=1over ~3 minutes of frames: no flash in either configuration. Screenshots at the same presents look the same: grass, fog and lighting. I only tested this one scene, so the CPU reads that the readback waits protect (#1375) may still matter elsewhere. Maybe the waits could be limited to the reads that need them, instead of waiting for every submission that wrote the page.4. Things that did not change fps here (each ±0.1-0.2 of the baseline)
HOS_RESERVE_CORE=0,HOS_VCORES=0,HOS_CORES=8,HOS_POLL_SLEEP_NS=5000,HOS_PRESENT_POLL=1,HOS_PRESENT_NOWAIT=1,RX_VK_BATCH_IDLE=0,HOS_SPIN_US=0HOS_PIN=Presentation=c0, the Presentation Thread on the reserved core, which on Linux sits idle without async becausereplay_pin_mask()is Windows-only: replay submit went from 30.7 to 26.7 ms, but fps stayed the same (21.7). The replay is not the frame's limit here.hookshot_vk.sowith-O3(21.9) or-mtls-dialect=gnu2(21.8). ThinLTO (-flto=thin) gave 22.2 alone, and nothing on top of NO_READBACK_WAIT (25.37).HOS_GRAPHICS_SCALE=0.5andHOS_RES_SCALE=0.5did not change the 3D scale (GPU time unchanged).5.
RX_VK_ASYNC=1freezes at boot on Linux/RADV: cause and patchWith
RX_VK_ASYNC=1the game stops after ~19 submits: no present, every thread idle. All-thread sample: sead::MainThread is inn_nvnSyncWait→mkwvk::wait()→vkWaitSemaphoreswith no timeout. The value it waits for belongs to work the replay thread has stopped at an event wait (submission 11..14 stopped at command buffer 0's wait for event ...), for the event the game signals after this wait. Or it is recorded but held in the batch (RX_VK_BATCH, on with RADV), which nothing flushes while the game waits. The 3 ms hold/drain inwait()is skipped by!async_on().RX_VK_ASYNC=1 RX_VK_BATCH=0: boots and plays, but at 11 fps, because unbatched submits cost ~15 ms a frame here.gpu/vk/vk_replay.cpp): inwait()with async on, it bumpsdrain_waitersand notifiesq_cvso that the replay thread runs its stopped work (drain 2, aswait_queue_emptydoes), and it waits in 2 ms steps, flushing the batch between them. With it, ASYNC + batching boots and plays with no freeze.I can run more A/B tests on this Deck if useful (same scene, same script).
The patch (gpu/vk/vk_replay.cpp, v2.1.0)
Blackscreen into crash, GPU reset (KDE plasmashell, steam, etc. crash & visual bugs)
GPU: RX 6600
OS: Linux (Bazzite)
hookshot version: 2.1.0
where it happens: after the intro cutscene title card cuts into black
hookshot_log.txt
Follow-up on the Deck readback waits: which readback costs the time
Same Steam Deck LCD and v2.1.0 setup as my comment above. I logged every readback wait (
RX_VK_LOG_READBACK_WAITS=1,RX_VK_LOG_READBACK=4000). Then I built a diagnostichookshot_vk.sothat reads the range before and after each wait ininvalidate()and counts how often the bytes changed. Scene: Kokiri Forest, standing.Wait time by range (300 logged waits):
0x113b623000/0x113b628000(+0x3980, alternating pair)0x115bcde000/0x115bcf9580+0x1b580,0x117cf04000/0x117cf9f040+0x9b040, ...)value == fence, the latest one), and its data changes. The first words are0.1, 25000, 1.7778, ~1.0, 0, 0, 24999.9: near, far and 16:9 aspect, so it looks like a camera-related GPU result (visibility/culling?).RX_VK_NO_READBACK_WAIT=1comes almost entirely from letting the game read that pair about 2 frames late.Backport of #2125 + #2222 + #2422 onto v2.1.0 (readback waits on, held submits sent during readback waits): 21.0 fps, GPU 53.9% busy, the same as plain 2.1.0.
RX_VK_NO_READBACK_WAIT=1on top of the backport: 25.4 fps. On this Deck the cost is the wait itself, not when the held work goes out.Camera test (
RX_VK_NO_READBACK_WAIT=1): Saria's dialogue, where the scripted camera cuts between shots.HOS_REALTIME_STEP=0,HOS_INPUT_FRAME_CLOCK=1, a shot every 20 presents. Without waits the scene ran at 26.4 fps, against 22.8 / 20.9 with them. Comparing shots of the same moment, I saw no missing or late geometry: grass, trees, fairies and houses are all there. But two runs with waits already diverged (dialogue progress differs), so this is not a frame-exact comparison. I can't rule out a one- or two-frame pop-in at cuts.If that pair is something the game can read one frame late, special-casing it would give the Deck about +16% while keeping the wait for the exposure meter and everything else. I can test a build that skips the wait for one range if you tell me what it is.
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).Several old summary entries can be marked completed on main
51da0464: #1012 packages the missing AppImage header, #1839 fixes SDL2's COSMIC/libdecor startup deadlock, #1936 supplies the supported container build on non-Ubuntu hosts, #2111 explains denied udmabuf access, #2340 stops refused NVIDIA dma-buf import attempts, and #1965 enables the task/mesh optimizer on RADV. #2362 additionally makes Linux AMD Automatic choose full Compute. These are bounded fixes, not proof that every Deck/RADV hang, memory-pressure exit or NVIDIA crash is gone. In particular #2411's memfd-discard fault remains separate, and #2431 deliberately waits behind it. Please update those stale subcases without closing this tracker; no new game run was made for this note.Steam Deck: three system settings that removed most of the long frame-rate drops for me (swap order, a memory protection, huge pages)
Edit, same day: use
MemoryLow=6G, not8G. With 8G, loading a save took 80 s on this Deck; with 6G, same game and same renderer, 12 s (12 to 15 s before the protection was set). The game grows to about 10 GB while a save loads and the GPU driver asks for memory at the same time; at 8G the kernel had almost nothing it could take quickly: a 64 MB allocation took 3.4 s, and 180,000 to 240,000 pages went to swap per 30 s against 650,000 to 980,000 without the protection. With 6G the protection still holds in play: the game keeps 5.7 to 8.2 GB resident, and swap-outs fall to 6,000 to 7,000 pages per 30 s once the save is loaded. The commands below now say 6G; the numbers in section 2 were measured with 8G.Sharing measurements from one Steam Deck, because the default SteamOS memory setup works against this game and the fix is outside Hookshot. Related to the memory reports in #993.
Setup. Steam Deck OLED (Van Gogh
0x1435, 16 GB), SteamOS 3.9.5, kernel 7.2.7-valve2, Mesa 26.2.0-devel (RADV). Game built from main atc544828f. Play sessions used a renderer built fromc544828fwith #2789, #2644, #2774, #2731, #2767 and #2649 merged on top; the headless A/B below used the unchangedc544828frenderer. Not default switches:HOS_HANDHELD=1,RX_VK_LOW_SPEC=1,RX_VK_VRAM_MB=2000,RX_VK_TEX_MAX_MB=128,RX_VK_TEX_MAX_DIM=1024,RX_VK_TEX_SKIP_MB=4,RX_VK_FRAMEGEN_MULT=2,RX_VK_FSR_FG=0. The swap file had already been enlarged from SteamOS's 1 GB to 16 GB.The game's footprint here is about 15.6 GB (its cgroup: ~4 GB resident plus ~11.6 GB swapped at one point), so several GB always live in swap on a 16 GB Deck. What matters is how.
1. zram before the disk swap file costs RAM instead of saving it. SteamOS puts a 7.2 GB zram device at priority 100 and
/home/swapfileat -1. The game's cold pages compress badly. After 20 hours of uptime (/sys/block/zram0/mm_stat,/proc/vmstat): zram's peak memory use was 4.48 GB for at most 7.2 GB stored, 6.7 million pages had been stored uncompressed (huge_pages_since), 192 GB had been swapped out and 46 GB back in.Swap file first (
swapon -p 200 /home/swapfile), same scene, headless, standing still in Hyrule Field, 110 s measured:The frame rate of a still scene does not change. In play the long collapses went away.
2. The kernel then still evicted the game with gigabytes free. In play, with the swap file first: game resident 2.7 GB, 11.1 GB in swap, 4.0 GB of RAM free.
/proc/buddyinfoshowed 3.4 GB free and no free block of order 7 or more. Over 4 minutes kswapd ran 1,861 times (pageoutrun) and reclaimed 4.14 million pages (pgsteal_kswapd): 2,225 pages a run, which iscompact_gapfor an order-10 request (2,048). So something asks for 4 MB blocks about 8 times a second, memory is too fragmented to give them, and each try evicts ~8 MB. I did not trace the caller; the GPU driver's page pool is my guess, and the pinned dma-buf imports may be what keeps memory fragmented. The cost was swap-in storms: 339,000 pages read back in 30 s and 5.5 to 6.2 fps for about 35 s at the Kakariko windmill, in a scene of 1,100 to 1,450 draws with nothing compiling.systemctl set-property --runtime user.slice MemoryLow=8Gstopped it (8G is what I measured here; 6G is the value to use, see the edit at the top): pages swapped out went from 100,000 to 580,000 per 30 s to 9,000 to 17,000, then 0 for the next minutes; memory pressure (/proc/pressure/memory, full avg10) from 5.5 % to 0.0 to 0.5 %.3. Transparent huge pages off (
alwaystomadvise,khugepaged/defrag0). The amount evicted did not change, but windows of 120 presents under 12 fps went from 7 in 9 minutes to 2 in 6.5 minutes. Weaker evidence: one session each, not exactly the same route.All three together, 4 minutes through Castle Town market, 30 windows of 120 presents at ~2,150 draws: mean 16.8 fps, one window under 12 fps (8.5, on arrival in an area), 96,000 pages swapped out in total, against 4.1 million in 4 minutes before.
Commands (root; the last three do not survive a reboot as written):
The swap priority can be kept across reboots with a drop-in for
home-swapfile.swapholding[Swap]andPriority=200, and the protection by leaving--runtimeout.To check a Deck:
swapon --show,cat /sys/block/zram0/mm_stat(third field: bytes of RAM zram uses now, fifth: its peak),cat /proc/pressure/memory.Limits. One Deck, short sessions, a renderer with open PRs in play. The settings are system-wide. Swap on the SSD means more writes to it. The 6 GB figure fits 16 GB of RAM and this GPU memory use; 8 GB was too tight (the edit at the top), and I did not try other values.
If it is useful I can send a troubleshooting row for the README, and a Linux line for the boot memory notice when a zram device outranks a disk swap. Huge pages could also be turned off for the game's process alone (
prctl(PR_SET_THP_DISABLE)), which I have not tried yet.A report for the RADV GPU hang section: VK_ERROR_DEVICE_LOST on a Van Gogh APU (ROG Xbox Ally, Ryzen Z2 A), with the kernel side of it.
Same signature as #2245, on a different Van Gogh device. Three things here may be new: the kernel's own verdict on the hang, a measurement that rules out the
lockup_timeouttheory, and the reason the #1300 Steam Deck workaround does not reach this title even on the same GPU.I no longer have
hookshot_log.txt— the install was removed before I thought to keep it — but the kernel log of the crashed boot survived and is attached. The game lines below are the ones I recorded at the time.System
Symptom
Exactly as in #2245: the game starts, the file-select works, the opening cutscene plays, and the handover to gameplay loses the device. Reproduced three times out of three.
The last frame before the loss was a heavy upload frame:
What the kernel says
This is the part I have not seen posted in the Linux reports.
journalctl -kfor the crashed boot:Two details worth noting:
emitted seq=504079,signaled seq=504077. That is consistent with a shader that does not terminate, not with an out-of-bounds access.The
lockup_timeouttheory does not holdSome reports suggest the kernel may be giving up too early on a long submission. On this system that is not what happened:
/proc/cmdlinecarries onlyamdgpu.ppfeaturemask=0xfff7ffff).So the hung job did not merely overrun a tight deadline — it never completed at all. Raising
lockup_timeoutwould delay the reset, not prevent it.RX_VK_MESH_NOCULL=1does not reach this title's task shader#1300 added
RX_VK_MESH_NOCULLfor a Steam Deck task-shader hang. The Steam Deck and this device are both Van Gogh, so this looked like the same bug. It is not reachable from here:The whole run compiles exactly one task code, and the pattern the workaround looks for is not present in it. With the variable set, the build still produced the unmodified shader and the configuration is byte-for-byte the one that hangs.
If the culling pattern is title-specific, OoT's task shader appears to use a different shape than the one #1300 targets, and the workaround silently does nothing rather than reporting that it cannot help. The log line is clear enough once you look for it, but nothing surfaces it to the user.
mesh_shaders=2(Compute) does avoid the hangConfirmed over a long session: file select, cutscene, handover, and extended gameplay with zero device losses. Two costs worth recording:
20463pipelines. Compute:67099predicted. On this hardware the first build of the compute path is a one-to-two hour job, and it is easy to mistake for a hang — the ETA climbs for a long while before it falls.Performance notes on the Z2 A, in case they are useful
Steady ~19-20 fps in normal outdoor areas, with the GPU idle:
GPU-bound wait 0.3 mswith the CPU pinned at its 3799 MHz ceiling: the limit is draw submission on four Zen 2 cores, not the GPU. Lowering resolution or quality preset changes nothing measurable, and the power limit is not the constraint either.One option made a large difference and is off by default:
sampler_cache=0sampler_cache=1descriptorstexture lookupsSame scene class, from
slow submitlines. If there is no correctness reason to keep it off, it may be worth defaulting on — or at least worth mentioning in the handheld guidance.Suggestions
RX_VK_MESH_NOCULLis requested but the pattern is not found, consider surfacing that to the user rather than only to the log — it currently looks like the workaround is active when it is not.RX_VK_UNEVEN_BC=0) are Windows-shaped. For Linux/RADV,mesh_shaders=2is the one thing that worked here, and the kernel ring-timeout signature above is a quick way for a reporter to confirm they have this bug rather than a different one.Happy to run further tests on this hardware, including with
RX_VK_CHECKPOINTS=1or a debug build. The install has been removed since, but I can rebuild it if a freshhookshot_log.txtor adevcoredumpwould help.Appendix: the kernel log around the hang
journalctl -kfor the crashed boot, from the first amdgpu message to the end of the recovery. Pasted rather than attached because it is short.Steam Deck OLED: @camilobt's readback finding tested in play. It holds, and the game is clearly better with it
@camilobt I tested your lead on a second Deck, in play with the camera moving. It is solid: this is the biggest frame-rate improvement I have had on the Deck so far.
Setup. Steam Deck OLED (Van Gogh
0x1435, 16 GB), SteamOS 3.9.5, kernel 7.2.7-valve2, Mesa 26.2.0-devel (RADV). Game built from main atc544828f. Renderer:c544828fwith #2789, #2644, #2774, #2731, #2767 and #2649 merged, with and without the test patch below. Switches and memory settings as in my comment above.The same pair is here. Two ranges of
0x3980bytes,0x5000apart, read in turn (0x113b1c3000/0x113b1c8000in one area). Without the patch, 444 of 3,000 readbacks waited for their write-back, 4.42 ms each.What I ran. A small test patch around
invalidate()ingpu/vk/vk_replay.cpp:RX_VK_READBACK_LATE=newestskips the wait when the range's write-back value is the newest value handed out (v >= fence()on entry), which is your "read right after the submission that writes it". UnlikeRX_VK_NO_READBACK_WAIT=1it keepswb_pages_note,memory_note_readbackand the catch-up, and a range whose writer is an older submission still waits.One difference from your v2.1.0 numbers: on this build the large ranges (
+0x9b040,+0x8b040,+0x1b580) also have the newest submission as their writer (75 of 75 calls each), so the rule lets them through as well. Between 440 and 1,100 of 3,000 readbacks, depending on the area, are then read without their wait, and what is left waits 0.02 to 0.2 ms.In play, not headless. One session of 12 minutes with the patch (several areas, camera moving), against the session before it on the same renderer without the patch. Windows of 120 presents, grouped by draws a frame:
RX_VK_READBACK_LATE=newest(windows)device lost.Limits. One Deck, one session each, two different routes, few windows in some rows. I do not know what the pair holds either. The texture half of
invalidate()(the 1x1 luminance textures of #2462) is not touched.The finding is yours, so the PR is yours to open if you want one. Take the patch below as a starting point or leave it. I am glad to run any build of yours on this OLED and report the numbers.
The test patch (gpu/vk/vk_replay.cpp, on main
c544828fwith the six PRs above)Steam Deck LCD — ~35 configuration tests, v2.1.0 results, memory exhaustion and comparison with v2.0.14
I'm sharing my results after approximately 35 configuration attempts on a Steam Deck LCD, hoping to help other users avoid repeating experiments that haven't produced sustainable gameplay on my device.
Hardware and software
General configuration tested
One of my main configurations was:
HOS_HANDHELD=1
RX_VK_MESH_OPT=1
RX_VK_PER_QUEUE_FENCES=0
RX_VK_WAIT_GPU=0
RX_VK_BATCH_MAX=4
RX_VK_CHECKPOINTS=1
I also experimented with "RADV_PERFTEST=cswave32", "RX_VK_NO_READBACK_WAIT=1", texture/VRAM limits, LOW_SPEC, mesh fallback and related Vulkan settings across different runs.
These were exploratory tests, not controlled single-variable A/B benchmarks. I cannot attribute every FPS change to a specific flag.
An important detail: one log explicitly reports that "RADV_PERFTEST" was ignored when placed inside "hookshot_env.txt". This variable must be supplied through the process environment to be effective.
Results — v2.1.0
Test| Observations
33| Gameplay fell below 20 FPS and eventually recorded approximately 0.3 FPS
34| Approximately 25 FPS in a lighter scene (~800 draws/frame), followed by major degradation and eventually near-zero FPS
35| Short periods above 20 FPS in lighter scenes; gameplay later around 5–12 FPS
Test 34 was particularly revealing.
The external memory monitor showed:
The game became effectively unplayable. The log ended after window closure, with exit code 0; this should not be described as a confirmed Vulkan device-loss crash.
In test 35, available RAM dropped from 6,283 MB to 1,409 MB. An external safety script terminated the process at its threshold. The script's swap-reading field was broken, so this test does not establish swap exhaustion.
The game also suffered from inconsistent frame pacing and graphics problems, including an incorrectly rendered Link in the equipment menu under some experimental configurations.
Comparison: v2.0.14 versus v2.1.0
I also installed and tested v2.0.14.
On my specific Steam Deck LCD, v2.1.0 gave me a better overall experience than v2.0.14.
Version 2.0.14 displayed Link correctly in the equipment menu, but several other graphics issues returned, and the overall gameplay experience was worse for me.
This is my direct experience, not a controlled same-scene FPS comparison. I'm aware that other Steam Deck LCD users have measured better results on v2.0.14, so I do not claim that v2.1.0 is universally faster.
Regarding camilobt's readback findings
The recent tests showing approximately +16% with "RX_VK_NO_READBACK_WAIT=1" are particularly interesting because I have also experimented with this setting.
However, my runs did not isolate it in a reliable A/B comparison. Moreover, the severe system-memory pressure remained a separate obstacle.
I would be cautious about presenting this flag as a universal fix, given the evidence that some of the skipped readbacks contain changing data.
What I think other Steam Deck users should know
I'm attaching the original logs from tests 33–35, including memory monitoring for tests 34 and 35.
I hope these results help narrow down the remaining problems and avoid redundant testing.
My current conclusion: Hookshot v2.1.0 can enter gameplay on my Steam Deck LCD and occasionally achieve around 25 FPS in less demanding scenes, but I have not yet reproduced stable, visually correct gameplay at - consistently acceptable FPS.!
Linux data point on a 16 GB AMD handheld: crashes and stutter in Hyrule Field, plus a frame-rate finding.
Setup: ROG Ally (Z1 Extreme, Radeon 780M), 16 GB with a 4 GB UMA frame buffer (11.6 GB usable), Mesa RADV, kernel 7.2, Hookshot v2.1.0 built from source in a container. My build carries a few local renderer changes; see the caveat at the end.
Crashes (out of memory)
Stutter (what is left)
a frame's uploads took N ms; one 5 MB texture took 19.5 s.RX_VK_IMPORT_HIGH/RX_VK_IMPORT_LOW: there were no idle imports to give back;HOS_MEMORY_MBbelow 9809: every value from 6656 to 9216 fails at boot ("memory pool without storage", or an indirect call into nothing).Frame rate: the readback wait in
invalidate()RX_VK_NO_READBACK_WAIT=1it ran at 42–45 fps. Every-frame captures in Hyrule Field (500 frames) and Kokiri Forest (600) showed no white flashes or other glitches.mainhas since reworked the readback settle and addedRX_VK_READBACK_WAIT_MS. I'll retest on the next release and report back.