[Tracking] GPUs without mesh shaders (GTX 9xx/10xx, RX 400/500/5000, Iris Xe/UHD): v2.0.6 fallback reports #1001
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#1001
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 GPUs without mesh shaders, 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
The game draws its foliage, grass and many effects with mesh shaders. Before v2.0.6, GPUs without
VK_EXT_mesh_shadergot:The log says
this GPU has no mesh shaders. v2.0.6 brings the compute fallback back (PR #779 by Nitnek), with the cause of the device lost that got it removed fixed. The release notes say these cards are untested by the team, so it is not known yet how well they run. Please update to v2.0.6 and post the result here.GTX 16xx and every RTX card do have mesh shaders, so they are not in this group.
Affected GPUs and versions
Evidence from the logs
vk: AMD Radeon RX 580 2048SP ... mesh shaders no.Workarounds
Update to v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6).
Reports merged here (19 issues, about 35 people)
Adding 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 post: GPU, driver, OS, does it start and reach gameplay on v2.0.6, fps in Kokiri Forest, and
hookshot_log.txt.All tracking issues
GPU: GTX 1080 Ti
Driver: 582.78
OS: Windows 11
Does it start and reach gameplay on v2.0.6? No, it gets to the menus, but as soon as you load a game, it freezes and stays on a black loading screen. In previous builds (v2.0.5) I was able to play it fine, although it had the visual defects from lack of mesh shader support.
FPS in Kokiri Forest: Does not get there anymore
Logs: hookshot_log.txt
One important detail is that the logs show that the window was closed, but I didn't close it.
I also tested a PR that was closed in favor of the merged one, and that one works flawlessly, see #792
Fallback report from a card that has mesh shaders but runs with
RX_VK_NO_MESH=1forced, as the workaround for the AMD device lost in #996: RX 6800 (16 GB), Adrenalin 26.10.1 (0x800161), Windows 11, v2.0.7.Stable and ~60 fps with the fallback (it gets past burning the web, which crashes every time on the mesh path). But in the Great Deku Tree, B1 (around the torch / chest room), with the fallback:
Screenshots:
GPU: GTX 1060
CPU: I7 Gen8
Memory :32GB
OS: Windows 11
log:
hookshot_log.1.txt
The game run smoothly up to the for the first cutscene until the tree start talking to Navi the screen turn black and nothing happen, previous build would give me black screen too but i could hear the audio of dialogs in the background, i want also to add that on Litch emulator, it would go until before this same point it will take little time load the shaders and load my issue with the emulator is the performance and the low FPS
GPU: GTX 1070
driver: game ready 582.78
OS: Windows 10
does it start and reach gameplay on v2.0.6: black screen after link wakes up in cut scene
fps in Kokiri Forest: N/A
hookshot_log.txt
Intel Iris Xe (Gen12.2), Linux ANV, v2.0.7: the fallback reaches the first mesh draw and the driver segfaults inside
libvulkan_intel.so, with RSS climbing 5.7 -> 22.5 GB at the same timeThis is the Iris Xe / Gen12.0-12.2 case from the tracker. Those parts have no
VK_EXT_mesh_shaderat all (features.txt:VK_EXT_mesh_shader DONE (anv/gfx12.5+, ...)), so everything below is the fallback path.System. Intel Iris Xe Graphics (Raptor Lake-U, gfx12.2), Mesa 26.2.6 (ANV), Vulkan 1.4.354; i5-1345U, 30 GB, Arch Linux, kernel 7.2.14, niri/Wayland. Hookshot v2.0.7, built from the Linux AppImage with my own copy of the game (0400486024DEC000 / v131072 / e0f3ccfa), 0 failures.
What works
With
RX_VK_PRECOMPILE=0the window opens, the title screen renders, and the intro movie plays to the end. That part is solid now.What happens at the first 3D frame
The first mesh draw is submitted and the driver crashes. The kernel log:
Hookshot's own handler agrees (
0xc0000005, read 0x4):The two lines before it are the draw and the pool imports it ran after:
Note it is a small draw:
d.yis 2, sogroups = {2, 1, 1}- two task workgroups with a 256-word payload each. It does not look like a case that needs much scratch.Memory, sampled once a second (RSS, anonymous RSS, GPU clock):
RssAnonstays flat at ~1.3 GB the whole time - the growth is not a malloc leak in the renderer, it is file/shmem pages, i.e. the guest memory imported in place. RSS then peaked at 26 GB before the process was reaped. It was not the OOM killer that ended the run; the SEGV did.A second, independent reproduction: the leak needs no game at all
./bin/hookshot --prepare-shaders(no game, no window, nothing drawn) leaks on its own:@@progress 0.020 -> 0.028RssAnonwas 18.16 GB andRssFile27 MB here, so on this path it is heapMinute-by-minute:
19:35:50 rss=4.0GB prog=0.028/19:36:50 8.5GB/19:37:50 13.0GB/19:39:50 14.2GB/19:40:50 17.6GB/ all atprog=0.028.The active work at that point was mesh program translation (
vk: mesh <key>: threads 32 max v 126 p 126 payload 64, ...in the log). With--prepare-shadersthere is no game, no window and no draw, so this one is entirely inside the preparation of the fallback programs.For comparison, a v2.0.6-era build without the fallback prepared 14179 programs in 55.5 s with flat memory, so the translation and Mesa compilation themselves are fine on this machine.
Workaround, and what it does not fix
RX_VK_PRECOMPILE=0gets past the preparation leak and gives a window and a playable intro. It cannot get past the crash at the first mesh draw.Cross-reference
#1072 (RX 5700 XT, RDNA1) reports the same shape - the video plays, then a black screen and RAM filling to the limit. That is a different vendor and a different driver, both without mesh shaders, so whatever is growing here is likely in
gpu/vkand not in ANV alone. The difference in my log is that the run also takes a SIGSEGV inside the driver at that exact frame, so the crash and the growth should probably be looked at together.Possibly related: PR #1023's payload-address fix
I have not built #1023, so this is a guess from reading it, not a result. That PR says the fallback's payload address was read from the push constants using its byte offset (64) as a member index, so every task-driven program read and wrote its payload at a garbage address, and that almost every fallback program failed
spirv-valbefore its fixes and all 1,347 pass after them.The draw that crashes this machine reads as
[1: stage 6, ..., isbe 1 payload 256]- it is task-driven with a payload. Passing invalid SPIR-V to ANV would be a plausible way to get a SEGV insidelibvulkan_intel.sorather than a clean rejection, which is what I see here. If #1023 is the right fix for that, this report is a second data point for it on a non-AMD driver; if not, the report stands on its own.I can build and run any branch on this machine (Iris Xe / Gen12.2, Mesa ANV, Linux) and report logs, per-second memory samples,
RX_VK_DUMP_*output, or A/B against a build with the fallback off. If a build of #1023 is useful, say which commit and I will run it here - that is the part I can actually test that nobody in that PR has an Intel card for. I have ahookshot_log.txtand the core file from this run.Hello! First of all, thank you for your work on Hookshot! I'm experiencing a severe slowdown / freeze after the first opening cinematic, when the game transitions into the next scene. The game initially runs at approximately 60 FPS, but after the opening cinematic it becomes extremely slow and eventually stops responding.
System information:
I'm attaching the complete redacted log file for investigation.
hookshot_log.txt
Thank you for your time and for investigating compatibility with older NVIDIA GPUs!
hookshot_log.txt
Same issue happens here on AMD Ryzen 5.
That is exactly what happens. These screenshots are from Lichii because I was comparing it with Hookshot, but aside from that detail, this is exactly the issue I’m experiencing.
It’s fixed in [Lichii build 125](https://github.com/zortos293/Lichii/releases/tag/build-125), but performance drops significantly.
hookshot_log.txt
Common lead across the fallback reports: logs from a GTX 970 (v2.0.8), a GTX 1070 and #1056 all repeat
vk: view of texture ... (vk 139) as vk 95 type 1 ... not made, the same BC4 block view (a BC4 array viewed as R16G16B16A16_UINT) that #1101 found refused on RADV. That failed view is being looked at as the shared cause of the hangs at 0 fps after loading a save.Hookshot Version
v2.0.9
GPU
GTX 960M (4GB)
OS
Windows 10
Hookshot Log
hookshot_log.txt
The game starts, but it freezes when the logo appears.
Additional report — GTX 1070, Windows, v2.0.7
Hookshot starts normally, but loading my Ocarina of Time Remake save results in a black loading screen. The audio cuts out, and it remains frozen after waiting 10 minutes.
In hookshot_log.1.txt, line 992 reports: vk: fallback: the compute pipeline of 4fd4fe678f729933 could not be made, followed by a mesh draw program entry.
I’ve attached the full log for investigation.
hookshot_log.1.txt
First of all, thank you for the great work—it's coming along wonderfully.
I m submitting my report and hope it helps in some way with ongoing development and bug fixing.
I experiencing a black screen issue after the intro video, everything is frozen.
System Information:
Graphics Card: GTX 1070
Driver: 582.78
OS: Windows 10
HookShot v2.0.9
hash a5da9f84b72d1471
hookshot_log.txt
AMD Radeon RX 580 2048SP – Vulkan driver crash on Hookshot v2.0.8 and v2.0.9
First of all, thank you for your continued work on this project and for improving compatibility with GPUs that lack native mesh shader support.
I'd like to report a reproducible crash affecting my AMD Radeon RX 580 2048SP (8 GB, Polaris architecture) on Windows.
Unfortunately, updating from Hookshot v2.0.8 to v2.0.9 did not resolve the issue. Both versions crash during the initial Vulkan shader preparation process.
System specifications:
Error details
Both versions produce the same access violation:
CRASH: exception 0xc0000005
(read 0x21, guest 0xfffff00000000021)
at amdvlk64.dll+0x1cb8bf9
hookshot_log.txt
The logs also confirm that my GPU does not support native mesh shaders:
vk: no mesh shaders:
task and mesh programs run as compute shaders
(issue 640 fallback)
The crash occurs while Hookshot is initializing mesh programs through the compute shader fallback.
Thank you for your work and for continuing to support older GPU architectures. I'm happy to provide additional logs or test future builds if needed.
GTX 1070: Mesh shader compute fallback still fails in v2.0.9, while Lichii renders correctly
Hardware and environment
VK_EXT_mesh_shaderProblem
I am testing Hookshot with a GTX 1070. The game reaches the loading process, but when loading my save, it gets stuck on a black screen with the loading icon.
The same behavior occurs in both Hookshot v2.0.7 and v2.0.9.
Relevant log output (v2.0.9)
The log contains the following error:
This is followed by a mesh draw involving program
18cbwith three stages.The renderer also reports:
The same compute pipeline hash was also reported as failing in my v2.0.7 log.
Comparison with Lichii
On the exact same GTX 1070 system, I tested Lichii and Ocarina of Time renders correctly.
Lichii has recently implemented and improved its compute-based mesh shader fallback:
VK_EXT_mesh_shader.VK_EXT_mesh_shader.Hookshot has also reintroduced its fallback:
However, the fallback still appears to fail on my GTX 1070.
Questions / possible investigation
Could the Hookshot fallback implementation be compared against Lichii's implementation, particularly:
The failing pipeline hash
4fd4fe678f729933may help identify the specific shader or pipeline that is failing.I can provide the complete v2.0.9 log and test additional builds on this GTX 1070.
Since Lichii renders correctly on the same hardware, I believe this is worth investigating as a Hookshot fallback implementation issue rather than an inherent GTX 1070 limitation.
hookshot_log.txt
RX 590 8 GB (Polaris), Linux RADV: the fallback works with the four fixes from the closed PR #792 (preliminary)
System: RX 590 8 GB (RADV POLARIS10), Mesa 26.2.5, CachyOS kernel 7.3.1, Ryzen 5 3600, Resizable BAR on.
Build: main at
8b2e1d3(2026-11-09, between v2.0.8-rc.4 and v2.0.10), plus #792's four fallback commits on top:e6e816a: payload push member index, started word, Aligned 42511050: SPIR-V that passes spirv-val6be15ce: a fallback draw after a dispatch rebuilds its descriptorsb9d6c6f: mesh workgroup index within its task workgroupAs far as I can tell, none of these four are on main or in v2.0.10.
e6e816a's message says that without it, RADV crashed at the first task/mesh draw.Result, Kokiri Forest, 1280x720 window, 75% resolution, no frame generation:
no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback).0 skipped), and no device lost.Caveats:
I have the log if it helps.
Follow-up, RX 590 / RADV: stock v2.0.10 does crash, and the #792 fixes prevent it
Stock v2.0.10 (same PC: RX 590, Mesa 26.2.5) gets into Kokiri Forest with the fallback running and foliage drawn. Then RADV starts faulting while it compiles one fallback compute pipeline:
The fault repeats every time that program is drawn: 12,160 times in this log, all for that one program. Then the game exits, with nothing more in the log.
The build with #792's four commits (
e6e816a25110506be15ceb9d6c6f) on top has zero driver faults, and no failed fallback pipelines, in the same area. That matchese6e816a's description: the payload's push member index and the bool stored into a u32 word make RADV's SPIR-V parser fail.Two smaller notes from the same run:
RX 590 / RADV, the fps comparison: stock v2.0.10 vs v2.0.10 + #792's fixes
Same PC (RX 590 8 GB, Mesa 26.2.5), same spot in Kokiri Forest, nothing else running, second launch of each (shaders already prepared). One correction to my last comment: I put stock's low fps down to a compile running in the background. With nothing else running, it's just as slow.
a5da9f84b72d1471)Almost all of stock's frame is the replay re-attempting the pipeline that RADV faults on, for every draw that uses it. GPU time is about the same in both.
To be fair about what else differs: my build also turns off VRAM mirrors and batched submits on RADV. Stock's mirrors write back about 67 MB a frame here, which costs fps and probably causes some of the flashing. But the driver faults, the skipped draws and the crash are the fallback's own, and they go away with #792's commits.
So I'd like to suggest landing #792's fallback fixes (
e6e816a25110506be15ceb9d6c6f, by AmiriisCustoms/hckrman101). #792 was closed in favour of #779, but these four never came over. Without them, the fallback crashes the driver on RADV; with them, it runs here with 0 faults. They also apply cleanly on v2.0.10. It might also be worth remembering a pipeline that faulted, so one bad program costs a missing effect instead of the frame rate and then a crash.One more data point: the neon/glowing plant stems from #667/#696 don't show up on this card with the fallback.
GTX 1070 8GB, RYZEN 5 3600X, 16GB RAM DDR4.
HOOKSHOT V2.0.10
Menu cinematic runs at steady 60fps, no stutter while the scene changes.
Hit new game and the first cinematic have stutter and desynchronization.
The game crash after the "new game" cinematic.
Lichii v5 runs well at 30 fps, normal stutter of residual shader compilation. Kinda playable.
I reccomend to see how Lichii fixed the render on GTX saga.
hookshot_log.txt
GPU:RX 5600XT
driver: 26.10.2
OS: Windows 11 25h2
does it start and reach gameplay on v2.0.6: No, The game Crash my pc in deku tree scene after reach all 20gb ram of my pc, the first cutscene its 60fps, but the deku tree scene its 10 fps and all my ram. This don't happen in the older versions. (<< 2.0.4)
and after the first cutscene the games freeze for a moment.
2.0.4 and lower versions freeze after first cutscene, the only version when i reach the gameplay its the ultrawide version.
hookshot_log.txt
GPU: RX 580
Driver: 31.0.21921.1000
OS: Windows 10
Before 2.0.6: Crashed after first cutscene, before gameplay starts
After 2.0.6: Crashes while loading initial shaders
hookshot_log.txt
GTX 1070 (Pascal), NVIDIA 580.178.04, Linux: #792's four fallback fixes make the fallback run. Stock freezes at the intro's forest scene.
This confirms Crono141's RADV result on NVIDIA. The cause is the same. The payload address is read through
OpAccessChainmember 64, which is its byte offset, not its member index. NVIDIA's compiler segfaults on that module. Stock is then frozen on the forest scene's first frame for good, which matches the black or frozen screens the GTX 1060 / 1070 / 1070 Ti reports above describe at the intro or at the Deku Tree.a5da9f84b72d1471), then no more presents. With the fixes there are 0 faults and 0 skipped draws, and it reaches the Deku Tree with the foliage drawn, at 22–28 fps at 1080p, GPU-bound. Not checked yet: playing past the intro and loading a save. The BC4 view lines (vk 139 as vk 95 ... not made) show up 16 times in both runs, so they are not what froze the intro here.The PR that ports the four commits onto main: #1314. A separate one stops a failed fallback pipeline from being compiled again on every draw: #1317.
Summary
On a GTX 1070, the game boots, the menu and first cutscene play at 60 fps, and then the screen goes black when gameplay starts. The log shows the NVIDIA driver faulting while compiling the first compute pipeline of the mesh-shader fallback (issue 640 fallback). After the second mesh draw the presentation thread stops logging and presenting entirely, while other game threads keep running.
Environment
Log excerpts
Startup:
At the end of the cutscene (about 12,120 presents in):
After that second mesh draw there is no further output from the Presentation Thread. Other threads (rmbl::VibrationThread, tera::FileResourceMgr) keep logging for 40+ seconds until I close the window. Before this point the Presentation Thread logged stats every 120 presents.
What I think is happening
a5da9f84b72d1471.Workaround
Launching with
RX_VK_NO_MESH_FALLBACK=1avoids the fault. The game reaches gameplay and holds 60 fps, but everything drawn through mesh shaders is missing: grass, foliage, and some solid objects (a door in the opening area).Request
RX_VK_NOOPTdoes not appear to affect the fallback pipelines, so I could not test this myself.hookshot_log.1.txt
@RafaeldeGomesMonteiro same card, driver and program here. The cause is in #1314: the fallback reads the payload address through
OpAccessChainmember 64 (its byte offset, not its member index), so the SPIR-V is invalid and NVIDIA's compiler segfaults on it. Turning the optimizer off wouldn't help, because the module itself is wrong. With #1314, all 2,468 fallback compute modules compile on a GTX 1070 / 580.178.04, and the intro gets to the Deku Tree with the foliage drawn. #1317 stops a failed fallback pipeline from being compiled again on every draw. You're right that a fault can leave the driver stuck, and #1317 doesn't cover that.GPU: AMD Radeon (TM) Graphics (Ryzen 7 5825U integrated GPU)
Driver: AMD Vulkan driver
0x800117OS: Windows 11
Hookshot version: v2.0.11 (source d6369f1e)
Result: The game crashes during startup, before reaching the main menu or gameplay.
The log confirms that my GPU does not support mesh shaders and that Hookshot uses the compute shader fallback:
The application then crashes inside the AMD Vulkan driver:
The same crash address appears repeatedly in the log.
Additional information:
Unlike some reports in this issue, my game does not reach the intro or Deku Tree scene. It crashes while initializing the graphics pipeline.
This appears to be related to the AMD compute shader fallback for GPUs without mesh shader support.
I've attached my
hookshot_log.txtfor investigation.hookshot_log.txt
Summary
On Hookshot v2.0.11 (source d6369f1e) the game renders at low FPS in places and, after a long session, crashes in a heavy scene. An earlier build ran fine on the same PC (version:
<previous version>).System
<driver version>)<resolution/window or fullscreen, env vars such as RX_VK_NO_FOLLOW, Lossless Scaling on/off>Problem 1: crash
After ~7,600 s of play, in a heavy scene (754 draws, 331 pipelines, 577 textures / 1844 MB in one frame), FPS fell to 0.5. Then:
VRAM was only 1407 of 7383 MB, so this looks like host memory exhaustion. The program cache is 6.5 GB and the game reserves 9809 MB plus a 6894 MB heap, on a 16 GB system. The
bad_allocis not caught, so it becomes a hard crash instead of skipping the shader.Problem 2: low FPS
no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback)andmatrix multiplies in software.slow submitentries, all memory sync, up to 121 ms.rejected computeshaders.Expected
Same performance and stability as
<previous version>; a shader translation failure should not crash the emulator.Questions
Attached
hookshot_log_1.txt (crash), hookshot_log_2.txt (empty cache, no crash)
hookshot_log.1.txt
hookshot_log.2.txt
Fixed in the v2.0.12 branch, closing when it ships. The fallback fixes are merged (#1314: the payload member, started word and alignment; #1317: a failed fallback pipeline is not compiled again every draw). In testing a GTX 1070 reaches the Deku Tree at 22-28 fps and an RX 590 runs at about 23 fps instead of 2-3.
AMD Radeon RX 580 2048SP – Vulkan crash on Hookshot v2.0.11
I'm experiencing a reproducible crash during the initial shader preparation process.
System specifications:
Error:
The game crashes during initial shader preparation.
The log also confirms that the GPU uses the compute shader fallback because it does not support native mesh shaders.
This appears to be very similar to another RX 580 2048SP report in this issue.
I've attached my complete hookshot_log.txt for comparison.
RX 580 2048SP (8 GB), i5-7400, 12 GB RAM, Windows 11, v2.0.11, AMD driver 26.5.2. Same crash as #1455: amdvlk64.dll+0x1cb8bf9.
Details that might help:
Will retest on v2.0.12 when it is out. Logs are in #1455.
almost the exact same problem. Crashes just as navi flies under the kids legs in the initial cut scene, after navi leaves the deku tree.
Bazzite Linux with Intel 13700k - AMD 6950xt (Mesa 26.2.5)
2.0.11 build
hookshot_log.txt
Feedback test with the RX 5500 XT on Linux build v2.0.11
Hello! I know my GPU doesn't support mesh shaders, so I didn't expect to run Hookshot in the best way. Even so, I decided to test the new release (build v2.0.11), since the fallback was implemented for testing in version v2.0.6 and I wanted to help with feedback.
What happens:
In the menus: performance is good, 60 FPS or more with frame generation on.
Outside the menus: FPS plummets to about 1 FPS with frame generation on or off and then the game crashes shortly after.
Despite everything, it's already a big step forward: in previous versions the game wouldn't even open on my GPU, and now it at least starts and reaches the menus. The shaders are still buggy, but seeing the game running is already a great sign.
Thank you for your hard work so far!
Specs:
GPU: RX5500XT 8gb / CPU : Xeon 2650v4 / 16gb Ram ddr4 2666mhz / OS: Linux Cachy Os with Vram management installed
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
GPU: GTX 1060 3GB (Vulkan 1.4), driver: <0x91870000>
CPU/RAM: Ryzen 5 5600G, 16 GB
OS: Windows 10
Version: v2.0.11
Starts, logo and intro movie play, then black screen. Does not reach
gameplay. No crash; the game keeps presenting until I close it.
Insert (options menu) shows nothing on the black screen.
Log shows "no mesh shaders ... issue 640 fallback", VRAM about 1.1 GB
of 2.6 GB allowed. Possibly the Pascal driver issue fixed in PR #1314.
Full log attached.
The issue is obvious and should be addressed - there is improper Vulkan extension detection happening. With infinite slop machine it shouldn't be that hard to create either compatibility tiers or just straight up hide more uncommon extensions under flags.
Fixes for the compute fallback, from an RX 5500M (RDNA1, 4 GB VRAM, 16 GB RAM, Windows 11)
These open PRs fix what the fallback still gets wrong on a card without mesh shaders. Each one is small, merges cleanly with main and with the others, and was played together on main
779bdcf.Also for these cards: #1507 (dark lighting and glowing bloom on AMD), #1505 and #1514 (rainbow block noise and texture noise when VRAM or RAM is short).
With all of them, Hyrule Field runs at about 31-34 fps on the RX 5500M. Anyone else without mesh shaders who can test them would help them get merged.
An update on the PRs above: all ten now merge cleanly with main
779bdcfand with each other (all 45 pairs and all ten together). Each passed CI, 8 of 8; #1507 and #1581 are re-running after small updates. Since my last comment, a GTX 1070 (Pascal) report on #1023 shows the geometry fix on NVIDIA as well.A merge order that keeps each step small:
@NotRexed I opened PR #1657 for the RDNA 1 subgroup path relevant to the RX 5500 XT / RX 5600 XT / RX 5700 XT reports here.
It selects the wave32/wave64 profile per Vulkan stage, keeps compute fallback stages at 32 lanes where actually pinned, preserves 32-lane guest warps inside wider graphics subgroups, and enables the AMD proprietary fragment-shuffle broadcast fallback. The translated-program cache identity includes those choices.
This overlaps the subgroup/fragment-shuffle work in #1507; the original work is credited in the PR. Please consider that overlap when reviewing the stage-profile implementation.
The Windows renderer build, 7 selected regression checks and 18 synthetic SPIR-V validations passed locally. Current-main gameplay validation is still pending; the attached RX 5500 XT 20 FPS screenshot comes from an earlier local experimental build, not a benchmark of this PR. RX 5600 XT / RX 5700 XT have not been tested locally.
The three CI workflows are awaiting maintainer approval. Could you approve them and review this RDNA 1 change? This is a proposed fix for this part of the tracker, not a claim that all GPUs without mesh shaders are resolved.
AMD Radeon RX 580 8 GB (GCN4/Polaris, no mesh shaders) — v2.0.12: same guest null-deref as #192/#369, reproduced with VRAM pressure ruled out
GPU / driver: Radeon RX 580 Series, AMDVLK 31.0.21925.1001 (driver 0x800117), Vulkan 1.3, no
VK_EXT_mesh_shader, no GPL. Compute fallback active:no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback).The error
Identical signature to #192 and #369 (
guest 0x150= null pointer + 0x150 offset, same host offset+0x11df8243). Happens right after the opening sequence, shortly into gameplay.Two runs, same crash — VRAM pressure is not the trigger
0xc0000005 ... guest 0x150,hookshot.exe+0x11df8243slow submit: 97867.5 ms, slowest frame 114640.1 ms (424 pipelines built in 91536 ms)Run 1's freeze did not repeat (pipelines cached in
hookshot_pipelines.bin), and lowering the preset to free 6 GB of VRAM did not prevent the crash. So the null-deref is not a memory-pressure problem.What works
The compute fallback itself runs well: 12 000+ frames at 60 fps, no device lost, no graphical corruption reported in these runs. The 11
program ... not translated: a network left out on this cardmessages are the neural movie-upscaling networks absent on this card, as expected.Logs
hookshot_log.txt— run 2 (lowered preset, VRAM 16%, no freeze, crash)hookshot_log.2.txt— run 1 (default preset, 114 s pipeline freeze, VRAM 100%, crash)Full logs: gist -
hookshot_log.txt(run 2, lowered preset) andhookshot_log.2.txt(run 1, default preset).Happy to run further tests if they help isolate this.
Related: #192, #369, #351, #640.
Black screen issue is now fixed for me on v2.0.13
AMD Ryzen 7 5800X 8-Core Processor (3.80 GHz) and NVIDIA TITAN X (Pascal) (12 GB), Windows 11
Gameplay running smooth.
GTX 1080, tried v2.0.13, still freezes or crashes after the initial Zelda logo and before Deku tree scene.
The log says:
Complete log here:
hookshot_log.txt
Intel Iris Xe (Gen12.2), Linux ANV 26.2.6, v2.0.12: the driver segfault is fixed, and the first world frame waits on ANV's compile of the fallback compute pipelines
This follows my v2.0.7 report in this issue (the same machine, same account). Short version:
#1314and#1317did what they say — noSIGSEGVinlibvulkan_intel.soat the first mesh draw any more — and the game now stops a step earlier than the driver crashing, in the compute pipeline builds themselves.System. Intel Iris Xe Graphics (Raptor Lake-U, gfx12.2, no
VK_EXT_mesh_shader), Mesa 26.2.6 (ANV), Vulkan 1.4.354; i5-1345U, 30 GB RAM, 8 GB swap, Arch Linux, kernel 7.2.14, niri/Wayland. Hookshot v2.0.12, built from the Linux AppImage with my own copy of the game (0400486024DEC000 / v131072 / e0f3ccfa), 186,588 files, no failures, build 26:42.What v2.0.12 fixed here
With
RX_VK_PRECOMPILE=0the window opens and the title and the opening movie play to the end:10200 presents, 60.0 fps, no crash, no device lost, no entry incoredumpctl, and the process exits cleanly when I close the window. On v2.0.7 the same run faulted in the driver at the first 3D frame (libvulkan_intel.so+0xa1fa14, RSS 5.7 -> 22.5 GB).hookshot_pipelines.binandhookshot_programs.binstop growing once the scene starts, so a failed fallback pipeline is no longer rebuilt on every draw.Where it stops
At the switch to the first gameplay frame: 8 mesh draws, the
12288x12288depth target is made, and then nothing is presented again. 40left out: its compute pipeline is still compilinglines, and noSLOW compileand nonot madeline at all — no build finishes and none fails.Measured on the process: GPU at its idle clock the whole time (300 MHz, i.e. it is not drawing), the presentation thread at about 100% of one core, RSS 6.2 -> 14.7 GB over 12 minutes, shmem (the GPU buffers) flat at 4.4 GB, so the growth is host-side.
eu-stackon the busy thread, ten frames, all inside the driver:The same addresses (
+0x4f9144,+0x4fcc27) as the frames in my v2.0.7SIGSEGV, so it is the same part of ANV, now spinning instead of faulting.The switches I tried
RX_VK_PRECOMPILE=0+ RX_VK_NOOPT=1+ RX_VK_COMPUTE_WAIT=1compute pipeline of a54f19e927d8faef: compiling, nothing after it for 6 min+ RX_VK_NO_SUBGROUP_PIN=1fallback_recordbuild (this is the same result as #775's run 10 on Meteor Lake)+ RX_VK_FORCE_UPSCALE_STUB=1and=2uses_cooperative_matrix, which is false here+ RX_VK_SKIP_PROG=...a54f19e927d8faefSLOW compile0.2 s to 27.4 s), then it stalls in another fallback buildNO_SUBGROUP_PIN+COMPUTE_SERIAL=0+SKIP_PROG+PRECOMPILE=0)739acd678ae08655stalls for over 8 min with no line, RSS 14.7 GBSo
RX_VK_COMPUTE_SERIAL=0(which is serial by default becausevendorID == 0x8086) does help, and skipping the one program that never returns helps, but every run then stops at the next build. The game needs a couple of dozen of them through before the first world frame.One module, measured on its own
To tell "the fallback path is slow here" from "the driver does not finish", I pulled the modules out of the program cache (
hookshot_programs.bin, 361 keys kept) into plain.spvfiles (kept local; I am not posting game data) and built a 130-line harness: stock loader,vkCreateShaderModule,vkCreateComputePipelines, a pipeline layout generated from the module's ownOpDecoratebindings, no game and no Hookshot code.spirv-val --target-env vulkan1.3 --uniform-buffer-standard-layout.mesh_cs/task_cs) modules build, 17 KB to 748 KB, in 1 ms to 9.2 s.a54f19e927d8faef, 1014 KB: 20 min 37 s of CPU, then still not returned (1238 s user time, RSS held at 4.1 GB).VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BITmakes no difference.mkwvk::pin_subgroupsetsrequiredSubgroupSize = 32on the fallback stages (stages 0xe0: compute/task/mesh). On this GPU ANV's default subgroup size is already 32, so the pin changes nothing about the shader's meaning, but it changes the compile:requiredSubgroupSize = 322bcc4174a654992ftask_cs, 119 KB28dd2baa17ba10e1task_cs, 748 KB3b8c07f2eb4bb7d9mesh_cs, 313 KBAdding
REQUIRE_FULL_SUBGROUPSmakes no difference on that last one.Two smaller things from the same runs
hookshot --prepare-shaders) takes 23.3 GB of RSS on this machine and stops at@@progress 0.003with no I/O for minutes at 591% CPU. That is the same step as #775, one Intel generation older, andRX_VK_PRECOMPILE=0avoids it as it does there.269 textures, 10391 MBwhile the same run's budget line saystextures 143 MB (budget 2560 MB), i.e. the integrated-GPU cap is not holding for the12288x12288depth target (quazardous reports the same on an ROG Ally X in #1000, at 3515 MB of 2560 MB).What I think this means
The fallback modules that build, build fast; the ones that do not are in the driver, not in the module (all of them pass
spirv-val). The subgroup pin looks like the thing worth looking at first, because it turns a 20 ms compile into one that has not finished in 8 minutes on a part whose default subgroup size is already 32 — andRX_VK_NO_SUBGROUP_PIN=1costs nothing semantically there.I am happy to re-run any of these on v2.0.13 (whose notes say everything but the menu and the frame cap is v2.0.12) and to give the harness to whoever wants it. I can also attach the
hookshot_log.txtfor each of the runs above if that helps.[Feature Request] Add Three Mesh Shader Modes: Automatic, Native and Compute
Hello developers! 👋
I'd like to suggest a feature inspired by Fritchii v5.6 that could improve compatibility with older graphics cards.
Fritchii recently introduced three selectable Mesh Shader modes in its graphics settings:
Why is this important?
I have an AMD Radeon RX 5500 XT 8GB, which doesn't support native Mesh Shaders.
When I selected Compute in Fritchii v5.6, previously missing geometry started rendering correctly, including doors, trees, leaves, and other environmental objects.
This is a significant compatibility improvement!
However, performance is still very low, around 2–5 FPS, and the emulator process consumes approximately 10–11 GB of system RAM.
My suggestion
Could you consider implementing a similar three-mode Mesh Shader selection system in your project?
This would allow users with
Correction to my comment above: I titled it after the fallback, which is the path this GPU takes, but I should not have generalised from one machine.
An Arc A750 reports
mesh shaders yesand still stays black after the intro (#17), so the fallback is not what the Intel reports have in common.What they do share is that the affected programs compile through the software-matrix path — a correlation across the logs, not a root cause I can prove. Compared by program key, since the key is a hash of the shader's contents and so the same key on two machines is the same shader:
a54f19e927d8faefSLOW compile, 67126 ms3e6fe279463b020eSLOW compile, 14662 msSLOW compile, 37208 ms(in game)4b03b3040d7cf076SLOW compile, 17723 ms(in game)Separately,
4b03b3040d7cf076is the program named at the device-lost checkpoints in #17 (Arc 140V), #366 and #741 (Core Ultra 7 155H), #374 (Arc 140V) and #999 (Arc B580, v2.0.13). On this machine it compiles in 17.7 s and does not crash, so that is one place the two platforms differ.a54f19e927d8faefis 1,014,936 bytes of SPIR-V (253,734 words) — one of the 25 program-cache compute modules, not one of the 42 fallback stages — and is one of the networks that runs on software matrices. The A750 log (#17) states the project's reason for the software path and carries the same subgroup pin:(both lines from #17)
So the subgroup pin is not specific to this machine either, and it stands as a separate finding. In the standalone harness all 42 fallback modules build in 1 ms to 9.2 s, but with
requiredSubgroupSize = 32pinned — as the project pins it on the fallback stages — fallback module3b8c07f2eb4bb7d9(313 KB) goes from 20 ms to not returning after 8 min 25 s, on a GPU whose default subgroup size is already 32 lanes, so the pin should be a no-op there. I am not claiming that is what hangs the game; it is only the sharpest reproducible difference I could measure.Whether this is better tracked as one entry keyed by program rather than one per GPU, I will leave to you. I can test any build or branch on this machine (Iris Xe, gfx12.2, ANV 26.2.6, Linux) and report per-module compile times from a 130-line standalone harness (stock Vulkan loader,
vkCreateComputePipelines, pipeline layout from the module's ownOpDecoratebindings, no game code).By ‘old shaders,’ I meant cached shader files left by an older Hookshot version, not a mod
hookshot_log.txt
hookshot_log.txt
GPU : RX 580 8GB
AMD DRIVER : 26.5.2
HOOKSHOT : v2.0.13
still crashed on Deku Tree cutscene after the intro, with texture flickering glitch
hookshot_log.txt
CPU: intel core i7 (tiger lake UP3)
GPU: TigerLake-LP GT2 [Iris Xe Graphics]
Mesa 26.2.5
16 go Ram ddr4
Hookshot : v2.0.13
Pipelines won't load before launch...
My game seems to come to an odd crash after the owl flys over links house, fades to black then locks up the whole window, task manager is needed to close window, also strange audio delay to where i can just hear ganons horse coming across the bridge while the owl is starting to fly by the how in intro cutscene, before on a previous version like 2.0.6 ish i was able to go all the way to navi meeting link in the tree and as soon as i touched the door it would crash, i have yet to leave the tree once. XD having a blast tho trying, included all logs still saved intel UHD Graphics Intigrated 8Gb Vram 11th gen core i3 1115G4 @3.0ghz 2 cores 16gb windows 11
hmmm guess its too longhookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
Windows 11 Pro
CPU: AMD Ryzen 7 5800X
GPU: GTX 1080 Ti
RAM: 32GB 3200 MT/s
Hookshot : v2.0.14
Some issues with texture loading and textures not appearing; this log corresponds to a saved game in the Desert of the Colossus; some FPS drops, but nothing serious
Crash after loading a save into the world: AMD RX 580 2048SP, v2.0.14 (source 3a9998c3)
System
Fallback path (from the log)
Good news: the v2.0.11 driver crash is gone. On v2.0.11 I crashed inside amdvlk64.dll (amdvlk64.dll+0x1cb8bf9) right after the mesh draw for mesh a5da9f84b72d1471, 3 runs out of 3 (logs available if useful). On v2.0.14 that same mesh program translates and draws fine (20,000+ DrawMeshTasksIndirect calls, no driver crash).
New crash, 2 of 2 runs. It happens about 30 s after my save loads into the world (Kokiri Forest, running at 0.3 to 7 fps during the load):
Ruled out: run 1 started with a nearly empty pipeline cache and had a ~3.5 minute compile freeze before the crash. Run 2 started with warm caches (about 32 MB) and no long freeze. Same crash both times, so it does not look cache or compile related.
Also in the logs: 10 to 12 programs failed to translate, VRAM sits at 7367 of 7367 MB during the load, in-world fps is about 1 to 18.
Logs: three files are attached at the bottom of this comment: hookshot_log.txt, hookshot_log.1.txt and hookshot_log.2.txt, all from the same install. hookshot_log.txt is run 1 (cold cache, ModuleSystemWorker1). The full run 2 log (warm cache, ModuleSystemWorker2) is also available.
Happy to test any build or env var.
hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
Crash after the opening cutscene or when loading a save file: Hookshot v2.0.14
GPU: GTX 1060 6GB, Vulkan 1.4, driver 0x91540000
CPU: Ryzen 5 3600
OS: Windows 11, 16GB RAM DDR4
vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more (on Linux, dmesg or journalctl -k around this time names the reset)hookshot_log.txt (log from the v2.0.14)
On a previous version (v2.0.11) instead of crashing it instead froze in a completely black screen, with no audio in the background.
hookshot_log.3.txt (log from the v2.0.11)
I just started the game, all logs from the very first quick saves of the game, inside the tree house and then it crashes without being able to leave. I'm using Intel(R) Core(TM) i3-10100 and AMD Radeon RX 580 2048SP (8 GB)
hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
The game can make it to the 3D space now!
Of course, the common lagging. And vertex explosions/neon color.
But worst of all, Link has no door..! /j
VK_ERROR_DEVICE_LOST crash (~4000 frames in) on RX 5700 XT right after a runtime compute program is rejected ("a network left out on this card")
Summary
Hookshot v2.0.14 crashes with
VK_ERROR_DEVICE_LOSTon an AMD RX 5700 XT (RDNA1). Two separate runs crashed at the exact same point, right after the same compute program6676619641320ba7is rejected, immediately following a ~600 ms "slow submit". Earlier builds ran fine on this PC, but I don't remember which version. Performance is also poor in other runs (see below).System
Capabilities reported by the log for this GPU: no mesh shaders (compute fallback, "issue 640"), software matrix multiplies ("cooperative matrices lack 16x8x16 f16"), FSR 3.1 available.
What happens
Two runs (
hookshot_log.txt,hookshot_log_1.txt) crash with the same sequence at roughly 3,800–4,000 presented frames, after about 60 fps in the earlier part of the run:vk: in play: compute 6676619641320ba7 ... grid 32x18x1vk: program 6676619641320ba7 not translated: a network left out on this cardvk: rejected compute 6676619641320ba7 ... grid 32x18x1vk: typed upscale helper generic RGB9E5 fallbackslow submit: 580.4 ms(log) /621.6 ms(log_1), almost all in draw → descriptors → texture lookups → uploadsvk: submit 30178 failed (-4)(log) /submit 35554 failed (-4)(log_1)vk: device lost: reading the fault infoFATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST)VRAM is not the cause: the last status lines show
VRAM 1154 MB used of 7383 MB allowed.Other observations
graphics pipeline for 6eaa646d07ea4e43 not made (-13).hookshot_log_3.txt): 1920x1080, frame cap 144, 2x frame interpolation. 27.4 fps, GPU time 20.8 ms/frame, 3482 draws, 1620 textures (2089 MB) after ~13,300 presents. Also logged:a capture's wait for write-back 53999 timed out. No crash in this run, and another program (0775215f8da720e6, grid 40x23x1) was rejected the same way.hookshot_log_2.txt,hookshot_log_4.txt): steady 60 fps at what looks like the title/menu (few draws per frame), ended by the Insert-menu Restart.log_4used frame interpolation "Auto" (144 Hz). On restart,slow present: 1536.0 ms.Log files
Expected behavior
No GPU reset. If a program can't be translated on this GPU, fall back gracefully or skip it.
Questions
hookshot_log.4.txt
hookshot_log.3.txt
hookshot_log.2.txt
hookshot_log.1.txt
hookshot_log.txt
[hos host] vk: device 0: Radeon RX 570 Series, Vulkan 1.3, driver 0x800117, type 2
no mesh shaders
hookshot_log.txt
game starts i managed to pass the cutscene of deku tree but after it in link's room the game closes after at least 20 seconds
CPU | AMD Ryzen 5 3400G
GPU | AMD Radeon RX Vega 11 Graphics
VRAM | 2 GB (shared memoria)
RAM | 16 GB DDR4
RAM Speed | 2400 MT/s
Operational System | Windows 11 Pro 26H2
Mother-Board
| Gigabyte AB350M-DS3H V2
hookshot_log.txt
hookshot_log.txt
https://github.com/user-attachments/assets/902c1753-0ee1-4726-bffa-c1f4f1edb2b7
severe graphical issue when selecting games own rendering at 100%, also general graphical issues aswell.
Linux
RX 580 2048sp | Mesa 26.2.6
Ryzen 7 5800x
24gb ram
One more from Discord: invisible walls on a GTX Titan (Maxwell, no mesh shaders) with a complete dump, on v2.0.14.
I'm currently chasing the no-walls problem on RX590 linux. Will let you know if I find a cause/fix
Follow-up on the invisible walls (RX 590, Linux/RADV, v2.0.14 + the compute fallback). The GTX Titan report fits: I think this is the fallback itself, not the GPU or the dump.
Where: Deku Tree, the door room on 2F. The walls beside the door can't be seen but are solid.
What a frame dump shows (
RX_VK_DUMP_KEY, then the same withRX_VK_DUMP_EACH=2,600for one depth image per draw):cb71f79f6129aab8,e28434e1afe8321a,8e2f7af4245747ef,8a8304edb7bdf4bf,9d8403e2e566c773,6afe3fda3f4b1752,a6a688bae3c9b80c.1. Indirect task draws never ran their mesh stage. For an indirect task + mesh draw,
DrawArgs.groups[0]is 0, because the count is in the indirect record.fallback_recordworks outslotsfrom it, so it came out 0 and the mesh dispatch was skipped. The programs affected here were8e2f7af4245747ef,8a8304edb7bdf4bf,28dd2baa17ba10e1,51183fe750d5d0c8and43ec86f35fd937b9. Reading their records on the CPU showed 32 and 90 task groups. The change I tested runs every slot for them; the ones the task didn't start cull themselves:2. With that change, their mesh stage still writes no primitives. I added a probe that copies the payload "started" flags and the records' per-slot primitive counts out after a draw. In the same room:
87eab3665f2b872c8a8304edb7bdf4bf43ec86f35fd937b951183fe750d5d0c86afe3fda3f4b1752,e28434e1afe8321a,3b8c07f2eb4bb7d9Direct task draws produce primitives for every slot their task stage starts. The indirect ones don't.
3. One difference in the IR (
RX_VK_IR): the failing mesh stages (8a8304ed,8e2f7af4,43ec86f3) containLoadGlobal32/LoadGlobal128. In8e2f7af4the pointer is aLoadStorage64from ssbo 0 at a cbuf offset, plus an offset. Peeking guest memory, c0+0x770 holds0x117e7be000, which is the start of the buffer bound at c0+0x880/0x890 (size 0x454000). The working mesh stages (87eab366,a5da9f84) only useLoadStorage*. Translating again withRX_VK_FOLLOW_MESH=1didn't help:8e2f7af4went from 0 to 10 slots with primitives, and the rest stayed at 0. So either those loads still miss, or something else in these programs fails in the fallback.Two smaller things I noticed:
WorkgroupIdas the slot,wg * threads + thread. On native hardware it would be the index inside the task's launch. Direct draws produce primitives anyway, so it may not matter here.To reproduce this on a card with mesh shaders, the new Mesh shaders → Compute row (#1971) should do it.
@kleinergoo7 your video looks like what I had on my RX 590 (also Polaris, Linux, RADV). Two things fixed most of it for me:
1. GCN runs every shader stage 64 lanes wide. Switch shaders are written for 32-lane warps, and Polaris can't be held to 32 for any stage. The ballots, votes and shuffles then run across both halves of a 64-lane wave. For me that meant objects flickering in and out, glowing white, and broken lighting. I tested blackxzin's patch that makes the translator emulate 32-lane warps on 64-lane hardware, and it took away most of the flicker. Turning it off brought the flicker back.
Upstream has since fixed this generally in #1507, which is in v2.1.0-rc.1 and the nightlies. It sends any graphics stage the GPU can't pin to 32 lanes through that path, and on GCN that's all of them. I haven't run rc.1 on the RX 590 myself, but on GCN it should behave the same as the patch I tested. v2.0.14 and earlier don't have it.
2. The bright, blinding flashes: set
RX_VK_PRECOMPILE=0inhookshot_env.txtbeside the game. That turns off the start-up pipeline precompile. With it on, my RX 590 flashed bright on starts that loaded shaders from the cache, and never on a start that translated them all again. With it off, the flashes stopped, at the cost of a few short hitches the first time each pipeline is drawn. I haven't found the root cause.What's still left after both: distant foliage in Kokiri still pops in and out at low camera angles, and some walls go missing (my earlier comment above). Those look like separate mesh-fallback problems.
How do I update to version 2.0.6?
Crash / Freeze when the fairy arrives (Cutscene transition / Deku Tree dialogue) on AMD RX 580
Hi, thank you for the amazing work on Hookshot!
I'm experiencing a hard freeze/lockup right when the fairy arrives / during the cutscene transition on version v2.0.14.
System details:
CPU: Intel Xeon E5-2650 v3 (10 Núcleos / 20 Threads, Haswell architecture)
GPU: AMD Radeon RX 580 2048SP (8GB VRAM, Polaris architecture - No native Mesh Shaders support)
RAM: 32GB DDR4 Dual Channel
SSD: 120gb free
FONTE: Corsair 600W
OS: Windows 10/11 64-bit
[hos Presentation Thread] vk: program e409733c45530d75 not translated: a network left out on this card
[hos nn.npln.Worker] mutex 0x100ac110c8 (obj 000001C2395C8390): nn.npln.Worker waiting 10 s; held by nn.npln.Worker
Attached is the full log file demonstrating the hang during the thread wait. Could this be related to compute shader/network translation fallbacks on Polaris architecture?
hookshot_log.txt
GPU: NVIDIA GeForce GTX 1080 (8 GB), driver GRD 582.78
CPU / RAM: Intel Core i7-12700, 32 GB DDR4
OS: Windows 11
Hookshot version: v2.0.14 (source 3a9998c3)
Does it start and reach gameplay? Yes, it reaches gameplay and runs.
FPS in Kokiri Forest: stable 60 fps at 1920x1080, FSR 3.1 Quality (67%), frame generation off, Robust buffers Auto.
With "Descriptor reuse" and "Sampler cache" off it was ~20-40 fps; turning both on (and restarting) brought it to a stable 60.
Problem: some objects/geometry are missing on the compute fallback
hookshot_log.txt
Update on RX 580 4GB on Fedora 44!
ver: 2.0.14
still at 6 FPS on kokiri village..
Workaround:
Starting the game on terminal with the command: "RX_VK_NO_MESH=1 ./hookshot"
FPS goes up to 20 -25 fps!
i will say something obvious.. on Great Deku Tree, the walls is missing, probably because the Mesh Shaders missing, Vegetation/Foliage too..
Ryzen 7 1700x
24GB ram
Fedora 44
Mesa 26.2.6
Keep up with the good work!
hookshot_log.txt
UPDATE: My missing textures/objets issue was solved updating to v2.1.0, with flawless performance even at 120fps with frame generation, thanks a lot for the amazing work!
Still crashing after opening cutscene or when loading a save. Hookshot v2.1.0
GPU: GTX 1060 6GB, Vulkan 1.4, driver 0x91540000
CPU: Ryzen 5 3600
OS: Windows 11, 16GB RAM DDR4 3200MT/s
vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more (on Linux, dmesg or journalctl -k around this time names the reset)hookshot_log.4.txt
After crashing, booting up the game shows only a black screen, I can't see the main menu, only audio plays.
hookshot_log.txt
GTX 1080 on v2.1.0 (compute fallback): framerate dips in some areas.
Observed: fps drops after the Deku Tree and in Hyrule Field; after restarting the game it stabilizes when I reach the castle.
From the attached log (v2.1.0, ~79,800 presents, 32 GB RAM):
Setup: GTX 1080, i7-12700, Windows 11, 1920x1080, FSR 3.1 Quality 67%, Frame generation 2x selected in the menu (the log reports frame interpolation "Auto", 165 Hz display).
Settings: Frame pacing Off, Robust buffers Off, Descriptor reuse On, Sampler cache On, Anisotropic 4x, Profile Docked.
hookshot_log.txt
Freeze at start menu – Quadro M2000M (Maxwell, GM204), v2.1.0
GPU: NVIDIA Quadro M2000M (Maxwell, GM204, 4 GB VRAM)
OS: windows 10
Version: v2.1.0
The game freezes at the start menu. The log confirms the compute fallback is active:
[hos host] vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback)
No crash, no black screen — just a hard freeze. Tried:
Latest NVIDIA drivers
Minimum (4 GB) quality preset
No overlays (Afterburner, Discord, etc.)
Verified game files
Full log attached.
i know that it is a really old gpu but i can´t even access to the game to see if i can run it
hookshot_log.txt
On my GTX 1080, Hookshot v2.1.0 crashed at the scene transition after the opening cutscene. I’m on Windows 10 build 19045 with NVIDIA driver 581.80 (Vulkan driver 0x91540000). The startup log confirms that the compute fallback was active.
The crash log showed submit 96511 failed (-4), and both NVIDIA checkpoints pointed to draw of program 53509044401d78d2 on frame 13787. This is the scene-load noise pass discussed in #1338.
I added the following line to hookshot_env.txt in the game folder and restarted.
With that setting, the same transition completed and I reached the dialogue between the Great Deku Tree and Navi.
hookshot_log.txt
hookshot_log.1.txt
I’ve attached hookshot_log.1.txt from the crash and hookshot_log.txt from the successful run with the workaround.
Update on my RX 590 (Polaris, no mesh shaders, Linux/RADV, Ryzen 5 3600): stock v2.1.0 fixes the missing walls, the missing foliage and the flicker I reported above. The Deku Tree door room has its walls and floor, and Kokiri's foliage no longer pops in and out.
For the record, the two problems I found earlier are fixed upstream:
2611a999): the mesh stage still drew nothing, because its workgroup id was the global slot. That picked a meshlet past the end of each task's list. The id is now the index inside the task's launch, as on native hardware.The
hookshot_env.txtthat works best here:What I measured, Deku Tree to Kokiri, one change per run:
RX_VK_PRECOMPILE=0RX_VK_MIRROR=0RX_VK_PARALLEL=3The limit on this machine is now the CPU. At 50% render resolution GPU time halved, but fps didn't change. The replay thread takes 23–29 ms a frame for ~2,350 draws, and the GPU sits at ~17 ms. A higher render resolution costs nothing, so I'm on FSR 3.1 Quality at 2048×1152, at about 20–26 fps in Kokiri.
@Vinni5147, @kleinergoo7: on Polaris, v2.1.0 with those settings should help you too. That includes the Deku Tree walls without
RX_VK_NO_MESH=1.I did not experience the new game crashes described on the NVIDIA hardware above, so I think its NVIDIA specific.
On Hookshot v2.1.0, I could hear the sound af the game's title screen and i could hear the intro getting started, but the screen was off, still the fps counter was displayed.
My machine : GTX 1060 6gb ; 32gb RAM ; Ryzen 5 2600
I tried lowering the settings to a minimum and tried playing with the mesh shader setting but it could not work.
hookshot_log.txt
RX 5700 XT (RDNA1, no mesh shaders): device lost on every load of a save — v2.1.0, four attempts
Setup
GPU: AMD Radeon RX 5700 XT 8 GB — log says no mesh shaders: task and mesh programs run as compute shaders, so it runs the #640/#779 fallback path
Driver: 32.0.21045.16010, 0x800161 (Adrenalin 26.10.1), Vulkan 1.4
CPU / RAM / OS: Ryzen 5 5600 (6C/12T), 16 GB DDR4-2666, Windows 10 22H2 (19045)
Display: 1920x1080 @ 144 Hz, borderless fullscreen
Hookshot v2.1.0 (source 633eb435), Vulkan back end
Options: options_version=4, output 1920x1080, preset Balanced (8 GB), Upscaler = the game's own, Render resolution 75%, sharpness 20, frame generation 2x, frame pacing on, cap 60, descriptor reuse 1, sampler cache 1
Env: HOS_WINDOW_SIZE=1920x1080, freeze watchdog on, HOS_LOG_SYNC=0
What happens The game starts, reaches the file-select/load screen, the display goes black and the window closes; the log ends in VK_ERROR_DEVICE_LOST. It happens on every attempt to load a save, at the same point of the load. A new game and a session already in gameplay run fine (that session reached 48k presents). It began after the save was overwritten a few times in one session: the earlier state loaded, the later one crashes every time. The save mounts normally (fs: mounted save: -> ...\user\save...), so this is not save data.
Four logs, two variants — all end with:
vk: submit N failed (-4)
vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)
vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST)
Variant A (mirrors on, log.2:835-837 / log.3:878-880):
vk: pool 0x7fd9000000 remade larger (2 retired)
vk: pool 0x7fd8000000..0x7fdd000000: mirror made with the GPU's contents of 1 retired pool(s)
vk: submit 7890 failed (-4)
Variant B (no mirrors / mesh path skipped, log.4:901-904 / log.1:944):
vk: pool 0x7fd3000000..0x7fdd000000 took in 2 pools
vk: submit 9836 failed (-4)
So it is the first submit after the game's memory pools are remade or merged. This is the #150 signature (closed into #996) and matches #1125, which you linked here.
Tried, all still crash at the same point: the option set that ran fine earlier the same day; RX_VK_MIRROR=0 (log.4 line 93: VRAM mirror of buffer pools off); RX_VK_NO_MESH=1 (log.1, also draws away foliage). Windows has no TDR event (no 4101/4102) for these crashes; pagefile is on the C: NVMe, 10.5 GB RAM free before launch.
Two details that may help
Crashing runs import pools at 74-129 ms each (vk: import 74.0 ms: ... allocate 73.8), a working run of the same build: 10-20 ms. VRAM in play peaks at 7145 MB used of 7241 MB allowed (8 GB card) — this is with #1383's shared per-thread FallbackBuffers, which v2.1.0 does have.
The working session: menus 60 fps, ordinary areas 44-56 fps; the densest part has 3993 draws a frame with GPU 20.9 ms but replay submit 29.88 ms (draw 16.83, commands 6.03, descriptors 5.93, memory sync 5.41) → 29 fps, CPU-bound on the replay thread, not GPU-bound.
Ask — anything to test on this card for the load crash (the #1314/#1317 fallback fixes you mentioned)? I can run any build or switch and attach full logs, including RX_VK_CHECKPOINTS=1 runs. The performance numbers are from the same machine, if useful for #995.
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.1.txt
Update: v2.1.0 on RX 580 — rendering is fixed, but stuttering and high RAM usage remain
Everything now renders correctly on the RX 580 with v2.1.0. The remaining problems are:
Log: hookshot_log.txt
Gameplay recording (default settings)
https://github.com/user-attachments/assets/c21e4f3b-2b15-47ba-b706-110c85d416d4
RAM usage comparison
Workaround found
Thanks to @Crono141's suggestion: adding a
hookshot_env.txtfile with the following contents significantly reduces both stuttering and RAM usage:Gameplay recording (with
hookshot_env.txt)https://github.com/user-attachments/assets/19d91da4-2777-4d51-996d-9d0107e36b28
RAM usage (with
hookshot_env.txt)Update after v2.1.0 — the
guest 0x150crash is gone; fps drops and two visual artifacts remainSetup: Radeon RX 580 8 GB (GCN4, no mesh shaders → compute fallback, #640), AMDVLK 31.0.21925.1001, Ryzen 7 3800X, Windows. Same route every run: new game → opening → Link's house → walk to a house in Kokiri.
1. The crash is fixed
exception 0xc0000005 ... guest 0x150display: window closed, exitingThree clean runs on v2.1.0, two different routes. The null-deref no longer reproduces here.
2. Settings A/B on v2.1.0 (same route)
Frame generation 2x → Off, Anisotropic filtering 16x → Game's, Sampler cache Off → On:
(The "before" run had frame generation on, so its counter included interpolated frames — real game fps in the walk was ~8, not 16.)
3. What still happens on this card
VRAM fullspills to system memory per run. The new VRAM budget row (bb1ffa2f) landed after the v2.1.0 tag, so it can't be used yet — wouldRX_VK_VRAM_MB=4800be the right way to test a larger budget on this build?Logs: gist —
run1.txt(v2.1.0, default settings) andrun2.txt(v2.1.0, tuned settings).More reports of this, collected here:
Measurements on a Radeon Vega 7 iGPU (Ryzen 5 5600G), compute fallback
Setup: Ryzen 5 5600G, Vega 7 iGPU at 2300 MHz (no mesh shaders, compute fallback #640), 32 GB DDR4-3800, AMD driver 31.0.21925.1001 (AMDVLK), Windows 11. Build: main
7759a6f3plus a few local changes, Balanced 58% (896x504), frame generation 2x, Handheld profile.Method: the game driven through the control bridge (#926): Continue, the newest save in Kokiri Forest (child), Link standing still, 4-6 samples of 300 frames; GPU spans with
RX_VK_PASS_TIMING=2. FPS is the game's own frames. Between runs of the same settings the fps varies by about 2, so only bigger differences below mean something.Where the GPU time goes (Kokiri Forest; FSR 3.1 from a run with it on, the rest from runs with the game's upscaler)
43ec86f35fd937b9's mesh dispatch, ~2.5 ms on its own. The next ones ared8e59341cf4f629c(0.7 ms) andd905f52b7517c681(0.3 ms); the task dispatches and the setup are small.RX_VK_NO_MESH_FALLBACK=1(foliage missing) the same spot runs at 31.7 fps and 23.3 ms of GPU, against ~25-28 fps and ~31 ms with it: the fallback costs this iGPU about 7-8 ms a frame.0e0016204515849a, 2 draws a frame, ~3.4 ms. Left out withRX_VK_SKIP_PROG, fps goes 22.2 -> 24.3, and the Great Deku Tree's moustache was then seen missing (so it is not a fix, just where the time goes).What made no difference here
7759a6f3): full barriers 420 -> 314 a frame, GPU 32.6 -> 31.7 ms, fps the same (24.7 / 24.7). Idle time between the fallback's small dispatches does not seem to be what costs on this GPU.RX_VK_BATCH=1): 22.2 -> 19.8 fps, and 18.8 withRX_VK_BATCH_IDLE=0. Off is better on this APU, as #2422 found on the Deck.What helped
d8e5...0.72 -> 0.60 ms, picture unchanged. That a coalescing change only gives ~15% suggests the grass's mesh dispatch is mostly the game's own mesh program arithmetic, not memory. Happy to open it as a PR if it is wanted.Preparation on a 32 GB PC
The noted-pipelines step used ~20 GB and the PC paged (12 threads at once), and with "one build of a program goes to the driver at a time (AMD)" it slowed to ~0.1 pipeline a second; #2323 looks like it addresses the first part.
Measured with Claude Code driving the game through the control bridge; logs available.
Intel UHD 770 (Raptor Lake-S, no mesh shaders), Mesa 26.2.5 ANV on i915, Arch Linux, built from source. First runs on main
872cb68(2026-11-10), then on today's maina5b955fb, which has #2513 in. Headless, i9-13900K (32 threads), 93 GB RAM, the game capped at 32 GB per run, the same save in Kokiri Forest each time.(The last line is only in today's main.) Three faults showed on
872cb68. #2288 fixed the third, and #2513 fixed part of the first two. Ona5b955fbthe start-up precompile is still killed for memory, and the false colours are still there.1. The first start runs out of memory, as in #775 and the Iris Xe reports above. On
872cb68:hookshot --prepare-shaders: OOM-killed at the 32 GB cap after 297 s (16 workers), still compiling compute pipelines.53caac5f38279735,f55579c6c7b39d05,a54f19e927d8faef(the Iris Xe's 20-minute one above) anddad2a8fbef3fd020, about 250,000 SPIR-V words each.53caac5f38279735still hadn't finished compiling when the run's 8 minutes ran out. The process went from 0.6 to 8.2 GB in that time and was still growing.On
a5b955fb, #2513 halves the table-heavy programs here:53caac5f38279735from 249,540 to 112,170 words,a54f19e927d8faeffrom 253,774 to 116,364. But the start-up precompile still ran out of memory. With the caches from one play session, both main's 32 workers and #1610's 16 were OOM-killed. That happened right after the 19 compute programs the precompile builds first, while it was building the no-mesh fallback's compute pipelines. That is inferred from the precompile's order, since the log doesn't name the compiles in flight. The machine was busy during those runs, so I'm not giving times yet. I'll post them on #1610 once I have them from a quiet machine. I haven't run the full shader preparation ona5b955fb.2. After loading a save, the world is in false colours (posterized magenta, yellow and green over black; the HUD is right). That's the black-screen-after-loading report in another form. Since #496, Intel builds compute pipelines in play one at a time, in the order play first asks for them. On
872cb68the first was53caac5f38279735, and ANV was still on it when each run ended, the longest after 15 minutes. So every compute dispatch was left out for the whole session. Among them was6637ac1d052d22d4, which writes the scene into the upscaler's input as RGB9E5 (#1960), and without it the upscale reads the wrong bits. A frame dump against the RTX 4090's showed the scene passes are fine and the picture goes wrong at the upscale.On
a5b955fb,53caac5f38279735built in play in 17.7 s, and at least 12 compute pipelines finished building in play (the log names the builds of 200 ms or more), where none had on872cb68. The picture is still in false colours, though. Over two starts, 16 minutes of play in all,6637ac1d052d22d4was never dispatched: it isn't inhookshot_computes.bin, where the game notes each compute program at its first dispatch, and the second start logsdispatch of 6637ac1d052d22d4 left out: its compute pipeline is still compiling. The one-at-a-time thread is still busy with something ahead of it. The other big compute programs of 117,000-182,000 words are barely smaller after #2513, and four of them took 37 to 122 s each to build, on a busy machine. The no-mesh fallback's compute pipelines go to the same thread too. I suspect those, but the log doesn't show which build it's on.Letting the smaller compute builds use the shared workers made this worse here, because they then hold up shader translation (details on #1610).
3. The integrated-GPU texture budget counted native ASTC textures 16-144 times too big. Kokiri Forest counted
textures 17608 MB (budget 2560 MB)while the process held4854 MBin all. Fixed by #2288 (merged):2241 MB (budget 2560 MB)with the fix.No i915 line in the kernel log in any run. Sound not checked (runs are muted).
UPDATE: RX 580 4GB on Fedora 44
ver: 2.1.0
Mesa 26.2.6
Now after update 2.1.0 the game is not launching..
When loading the pipelines.. is consuming all Ram and the system is closing the app..
I wIll try reinstall and update here soon!
More reports of this, collected here:
github-sync referenced this issue2026-11-12 06:22:54 +00:00
RX 580 8GB 31.0.21923.11000
Ryzen 5 3600
Unplayable fps and stutters, along with usual missing textures from no mesh shader support
hookshot_log.txt
RX 5600 XT 6 GB (RDNA1), Windows 11, main
de866017: Crono141's three switches, one at a time.Each switch was run on its own, and the large differences twice. Every run starts from the same copied save and follows a scripted route through the control bridge (Kokiri Forest and Hyrule Field: settle 15 s, then 60 s standing); fps are the medians of the log's
N presentslines. Adrenalin 26.10.1, Ryzen 5 5600X, 24 GB, 1920x1080, frame generation off.RX_VK_MIRROR=0RX_VK_PARALLEL=3RX_VK_PRECOMPILE=0RX_VK_COMPACT=0(compaction off)So on RDNA1 Windows, the mirrors-off gain matches Crono141's RX 590 on Linux (+10-17% here), and so does the parallel replay in the heavier spot. Precompile off didn't change the frame rate here, but it saves ~7 GB of private memory, which matters on 16 GB PCs.
The first start on this card (shader programs 120 s, predicted pipelines 3,603 s, noted pipelines 2,355 s, private memory up to ~30 GB during the noted part) is in #2505.
Follow-up: RX 5700 XT — three save loads in a row without a device lost after
RX_VK_PARALLEL=3+RX_VK_MIRROR=0; and a warning aboutRX_VK_PRECOMPILE=0on no-mesh cardsSame machine as my earlier report (RX 5700 XT, no mesh shaders → compute fallback; Ryzen 5 5600;
16 GB; Windows 10 19045; driver 32.0.21045.16010 / 0x800161; Hookshot v2.1.0, source 633eb435).
Since my last report I ran the same save with
RX_VK_PARALLEL=3andRX_VK_MIRROR=0inhookshot_env.txt. Three launches, three successful loads, sixpool ... took in N poolseventsin all, no
submit failed (-4), no device lost, every one exits withdisplay: window closed, exiting:Where it used to die, the log now just carries on:
Caveat, because it matters for your triage: this is not proof of a fix. The failure is not
deterministic on my card. One earlier launch with the default switches also loaded and played
12,650 lines through two
took in 2 pools(hookshot_log.3.txt), and another launch with the samedefault switches died at the same point within 923 lines (hookshot_log.4.txt). So a load either
lands in the bad case or it does not, and
PARALLEL=3may simply be shifting the timing ratherthan closing the hole.
RX_VK_MIRROR=0alone was not enough: with mirrors off but no parallelreplay it still died right after
took in 2 pools(submit 9836 failed (-4)).Second finding:
RX_VK_PRECOMPILE=0washes the picture out on a no-mesh card. With it set, thefallback compute pipelines are built during play, and until they exist their draws are skipped:
The result is a scene that looks white/faded for the first minutes (the foliage and grass - exactly
what the fallback draws - are the missing part). With
RX_VK_PRECOMPILE=1the log showsprecompile: 9582 programs, 11046 graphics and 1060 compute pipelines ... in 7478 msat start-up,then
0.0 draws left out (not ready)for the whole session and the picture is correct. If theswitch is documented as a memory saving (it does save ~7 GB of private memory, which is why I tried
it on a 16 GB PC), it may be worth a note that on cards without mesh shaders it also means missing
foliage until the fallback pipelines are built.
Performance side note from the same runs: with
RX_VK_MIRROR=0the GPU time in a 1,646-drawframe went from about 19 ms to 7.6 ms,
a frame's replay timefrom about 25 ms to 15 ms, and VRAMfrom
7.1 of 7.1 GB(at the driver's limit) to5.9 of 7.2 GB. 37-43 fps in the draw-heavy parts,60 fps elsewhere, and the frame interpolation reports 0 late frames. The
0 programs (10 failed)line is unchanged from before.
Happy to attach any of the four logs, or to run a specific combination twice for a cleaner A/B.
hookshot_log.txt
hookshot_log.4.txt
hookshot_log.3.txt
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).Main contains #1314's fallback payload/SPIR-V repairs, #1317's failed-pipeline retry guard, #1510/#1511's indirect-task and workgroup-capacity repairs, #2327's 3D BC attachment fix and #2343's unsupported-f16 handling. #2525 is a GCN mitigation that omits oversized programs, not complete geometry support. Two implementation gaps still exist on
51da0464: fallback draws with a count buffer are explicitly left out, and fallback graphics pipelines declared a dynamic vertex stride they never set (the validation message in #2494): #2796 is open for that. Please keep the tracker open and distinguishRX_VK_NO_MESH=1, which skips draws, from actual Compute fallback. This note confirms code and merges only, not a new hardware test.A count for whoever takes the count-buffer part of the fallback: in these two scenes the game never issues such a draw.
Census, 12 November: main
e2057b2plus logging only, Intel UHD 770, Mesa ANV 26.2.5-arch1.1, Arch Linux; windowless, startup precompile off.The shared counter runs at the start of
draw(), before argument conversion and every shader/target skip; its printing interval does not limit counting. Mesh totals include internal direct-draw batches.The unsupported count-buffer branch was never reached, so it does not explain the missing rendering in these two runs. There are no counted-program hashes or count-buffer writers to identify here.
The inspected captures are black with HUD while compute pipelines remain pending: not evidence of correct rendering, restored objects, or the cause of the black picture. No rendering change was added.
Not covered: the deferred Deku Tree room, other dungeon rooms/areas, combat or effect sequences, native-mesh comparison, Windows or other GPUs. Count-buffer support remains unimplemented; this is not a fix for the tracker.