[Tracking] AMD handhelds and APUs (ROG Ally / Ally X, Legion Go, Radeon 780M/860M/890M): black screen, device lost, reboot #997
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#997
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 AMD handhelds and APUs: black screen, device lost or reboot, 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
On Windows AMD handhelds and laptops with Radeon iGPUs:
Steam Deck and SteamOS reports are in the Linux tracker.
Affected GPUs and versions
Evidence from the logs
Workarounds
Reports merged here (11 issues, about 19 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 add: device, UMA/VRAM setting, driver version, preset, and
hookshot_log.txt.All tracking issues
Hi NotRexed,
I'm reporting an update regarding my issue #426, which is included in this AMD tracking thread.
Unfortunately, the black screen issue still persists in Hookshot v2.0.7 on my Lenovo Legion Go (AMD Ryzen Z1 Extreme, 16 GB RAM, Windows 11).
However, I've noticed something important that might help identify the cause:
This suggests that the game logic continues running and that the issue may be specifically related to rendering or displaying the game image after the opening cinematic.
The issue is still reproducible in v2.0.7.
I hope this additional information helps narrow down the problem. Thank you for your continued work on AMD compatibility!
hookshot_log.txt
hookshot_log.1.txt
Hi NotRexed,
I have an important update regarding my issue #426 on the Lenovo Legion Go (AMD Ryzen Z1 Extreme, 16 GB RAM), using Hookshot v2.0.7 (9b541c9c).
I can now confirm that the game continues running AND successfully autosaves despite the permanent black screen.
Here is what happens:
I also examined the v2.0.7 logs, which show continued Vulkan frame presentation, 176 failed programs and approximately 20–29 draw operations per frame reported as not ready in several late samples. No explicit "VK_ERROR_DEVICE_LOST" was found.
This seems to suggest that the game logic and save system are functioning while the rendering or presentation path is failing on the AMD GPU.
I'm attaching the screenshot and both log files ("hookshot_log.txt" and "hookshot_log.1.txt") to help with debugging.
I'm also willing to test an experimental diagnostic build if needed.
Thank you for your continued efforts to improve AMD compatibility!
Hi NotRexed,
I have discovered something important about the black screen issue on my Lenovo Legion Go (AMD Ryzen Z1 Extreme), running Hookshot v2.0.7.
It seems that the game itself keeps running normally, but the entire visual output becomes frozen.
I can confirm the following:
This last part may be especially relevant: it is not just the 3D scene that fails to render. The FPS overlay, loading indicator, and Hookshot's own interface also stop updating, while the game's logic, controls, audio, and save system continue functioning.
Could the Vulkan rendering/presentation thread be stuck waiting on a synchronization primitive, GPU fence, or pipeline compilation task while the game threads continue running?
The logs still show frame presentation activity without an explicit device-lost error, so I'm not sure whether the problem is in the renderer, swapchain presentation, or UI thread.
I hope this helps narrow down the issue. I'm happy to test a diagnostic build that logs render-thread progress and Vulkan synchronization waits.
Thank you again for your work!
hookshot_log.txt
hookshot_log.1.txt
I am having the exact same problem, I'm using the ASUS ROG Ally (AMD Ryzen Z1 Extreme, 16 GB RAM) on hookshot v2.0.7. This seems to have been a problem for the past few updates and was fixed in update v2.0.2, there was other visual bugs though such as the map, hearts, and button tips flickering. I would be more than happy to test out future updates for these kinds of problems. Thank you!
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
OS: Windows 11 Insider Preview, build 29648
UMA / VRAM: 8 GB Out of 24GB (Armoury Crate -> Memory Assigned to GPU)
Driver: Vulkan driver 0x800184 (latest offered by Armoury Crate Update Center)
Hookshot: v2.0.6 and v2.0.7 (source 9b541c9c); also tried an older faster-builds build (71e8cff6), same result
Settings: Custom preset, frame generation off, fullscreen; tried resolution 50% and 67%, Handheld profile on and off
What happens: full system reboot (no blue screen), usually within ~15 s of loading a save, or at the Deku Tree / Navi scene on a new game. The log just stops mid-frame. Right before it there are always multi-second submits, e.g.:
Several crashes die during large ASTC uploads (1365x1365x1 x90 levels 11 ... ASTC (BC3)) or right after a long compute dispatch.
Tried, no lasting fix:
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.4.txt
hookshot_log.3.txt
](url)
Hi notrexed, I want to submit a report ( a similar one was previously submitted by other users, but maybe mine would add more insight; as it is kind of a detailed log for all the runs i tried, combined.) :
Legion Go (Z1 Extreme, Radeon 780M): hard reboot (bugcheck 0x119) at the first 3D frame, v2.0.6
Device: Lenovo Legion Go 8APU1 (Z1 Extreme, 16 GB), Windows, BIOS N3CN40WW
GPU driver: AMD Radeon Graphics 32.0.23044.19 (29 Jun 2026); Adrenalin offers no newer driver
Version: v2.0.6 (source 9b541c9c); also tried honest-eta (bd9bcd71) and v2.0.5 (cd9cebb6)
UMA frame buffer: tried 6G and 8G, no change.
Preset: Minimum (4GB), Resolution 50%, Handheld profile on, frame generation on and off
What happens: the logo, intro movie and title run (60 fps). At the first 3D scene (a 768x432 pass) the whole
device freezes and reboots. Windows System log, event 41, on every crash:
BugcheckCode 0x119 (VIDEO_SCHEDULER_INTERNAL_ERROR), P1 = 0x1 (invalid fence ID)
P2/P3 = 0xB0C7/0xB0C9, 0xB333/0xB335, 0x49EFC/0x49EFE (P3 = P2 + 2 each time)
No Display 4101 event, no dump in LiveKernelReports.
From the logs:
kept running with a black picture (the original black screen with sound).
ends (no device lost line).
against a budget of 4526 MB, 16 "image ... not made" lines for large images (3072x3072, 6144x6144),
and the picture had heavy flicker, black characters and random-colour models.
The same settings crashed on the next run.
Tried with no change: Minimum preset, 50% resolution, Handheld profile, frame generation on/off,
RX_VK_NO_MESH=1, UMA 6G and 8G, driver check, restarts. A second recompilation project also
crashes the device at the same step.
Because the device blue-screens, RX_VK_CHECKPOINTS=1 cannot write its report. Could a build write a short
trail file to disk (flushed before each GPU submit) so the last line names the job in flight? I can test
builds and attach logs.
Attached: hookshot_log.txt and hookshot_log.1.txt from the crashed runs, plus the one run that reached gameplay.
Hey @NotRexed
I'm running into the issue where the shaders are taking forever to prepare prior to the game launching. I've had it opened for about 10 minutes now and it's having a tough time getting past 4%. It's moving but very slowly, sometimes a single integer every 30 seconds to a minute.
Log attached.
CPU: AMD Ryzen AI 7 350, 32GB RAM
GPU: AMD Radeon 860M 8GB RAM
Win 11
hookshot_log.txt
@NotRexed I'm also seeing #1126 during gameplay on AMD Radeon 860M with 8GB. Gameplay is getting better, running at a solid 30-40fps but still encountering the stuttering, UI overlays jumping along the screen and white glowing textures. Log attached.
hookshot_log.2.txt
Hello, since I may be an outlier when it comes to the game running on an APU I figured I'd submit a log for you to look at. Game runs pretty well on my AMD RYZEN AI MAX+ 395 w/ Radeon 8060s but I do experience occasional bright yellow glow on objects and flickering terrain here and there. The terrain flicker was most notable once I entered Hyrule Field.
hookshot_log.txt
Hello!! Thanks for creating this issue!
For my ROG Ally the game now runs much more stable in v2.0.9! At around 40-50 fps with Balanced (8GB) graphics on the first cutscene with the Deku Tree.
There are some bugs with the light and the textures that flash constantly.
https://streamable.com/urlgb4
EDIT: Forgot to attach the log:
Update (ROG Ally X): v2.0.8 fixed the reboots for me, but v2.0.9 and v2.0.10 bring them back
Setup: ROG Ally X (AMD iGPU, 24 GB RAM with 8 GB assigned to the GPU), Vulkan driver 0x800184, Windows 11 Insider build 29648. Settings: Handheld profile, 50% resolution, RX_VK_GPU_UNSWIZZLE=0 plus the AMD fog/exposure lines.
Every time, it reboots within seconds of the area first drawing after Continue. The last lines in the log are always small 192x108 effect textures being set up on the host thread, for example:
[hos host] vk: slow submit: 36.0 ms: texture lookups 80.4 uploads 20.3 dispatch 13.3
[hos host] vk: texture #420 at 0x10000769800 beside #229: 192x108x1 x1 levels 1 layout 0x4 class 0x1007e NVN 0x34 target 1, the other 1000x1000x1 x3 levels 1 layout 0x4 class 0x1007c NVN 0x32 target 4
AllyX_v2.0.10_reboot_on_save_load.txt
AllyX_v2.0.9_reboot_on_save_load.txt
ROG Xbox Ally X (Ryzen AI Z2 Extreme, Radeon 890M), Windows 11, AMD driver 0x800196, 8 GB UMA. Results on v2.0.8 to v2.0.10. This is the same machine as the #708 report linked above.
Native mesh path: device lost. On v2.0.10 with default mesh settings, loading a Kokiri save hangs every time. First
slow submit: 22957.1 ms: draw 25202.7, thensubmit 8676 failed (-4)and a device lost. Log: hookshot_log.v2.0.10-conmesh.txt.RX_VK_NO_MESH=1(task/mesh draws left out): stable, but enemies are invisible.RX_VK_WB_DIFF=1andRX_VK_PRESENT_QUEUE=1.So on this iGPU the only stable path is to skip the mesh draws, which leaves the game partly unplayable. Next I'm trying
RX_VK_FORCE_MESH_FALLBACK=1, following pavelrossi's Legion Go result above, and will report back.Also noted: with 8 GB carved out, Windows keeps 15.6 GB of RAM. The process sits at about 23-26 GB private, so it pages 5-6 GB to the pagefile, and that is where most of the fps drops come from (GPU time is only 12-15 ms a frame).
ROG Ally X on v2.0.9: no more device lost (thanks!), but memory keeps growing during play until FPS drops from 60 to 0 and the whole system freezes (~41 min unresponsive). Log attached.
Setup
hookshot.exe, noRX_variables, no overlaysWhat happens
Menu and opening: 60 fps. In gameplay, 60 fps at first, then a steady decline: 60 -> 46 -> 40 -> 36 -> 32 -> 26 -> 20 -> under 1 fps. Then
0.0 fps over the last 2513.4 sand Windows stops responding until it recovers. Restarting the game brings it back to 60.From the log
OptimizeChangeBanc):76385 live copies (25.1 MB)->(840.1 MB)->(2268.9 MB)->(2865.5 MB)vk: imports: 58 live (1520 MB), 46 retired still imported (1312 MB), 0 retired given back (0 MB)Resource Memory (priority 21) ran without a core after 2463043.7 msandOptimizeChangeBanc waiting 10 s; held by nobodyhandheld_profile=1on a 1920x1080 screen. Not sure if that's expected.The v2.0.8 notes say old memory pools are now given back on NVIDIA. On this AMD iGPU (shared RAM) the same buildup seems to fill system memory and freeze Windows.
On v2.0.5 the same device lost the GPU right when gameplay started (
device lostafterstorage buffer NOT boundfrom mesh programs). That's gone since the update.This matches what @pcornejov saw above on the same model (process at 23-26 GB private, paging to the pagefile): here the growth shows up as nvn live copies and retired imports that are never released, so the drop gets worse the longer you play.
Log for my comment above (the attachment didn't upload the first time):
log_cuelgue_2.0.9_20261109_1949.txt
@Villanro: thanks for the log. Memory growing until the system freezes on the Ally X is a known problem on integrated GPUs, which share system RAM. v2.0.11 (out now) caps textures at 2.5 GB and the shadow copies at 512 MB on integrated GPUs, and a bigger memory fix is being worked on; please retest on v2.0.11.
ROG Xbox Ally X (Radeon 890M) on v2.0.11. UMA is now 4 GB (19.6 GB RAM visible), down from 8 GB. This is the same machine as my earlier reports above.
1.
RX_VK_WB_DIFF=1causes one-frame HUD-garbage flashes on v2.0.11 (new).Every few seconds a single frame shows broken 2D/HUD elements:
The next frame is clean again. This didn't happen on v2.0.8–v2.0.10 with the same env. It persists without
RX_VK_PRESENT_QUEUEand with the texture budget raised, and it stops completely whenWB_DIFFis removed.2. Without
RX_VK_NO_MESH, v2.0.11 still hits device lost.After the save loads, it shows
slow submitof 4 s, thensubmit 14771 failed (-4). This is the same pattern as v2.0.10.3.
NO_MESHalso hides chunks of level geometry, not only enemies.In Kokiri/Lost Woods areas, parts of the scenery are missing and show as flat green/black blocks.
4. Without
WB_DIFF(but withNO_MESH), v2.0.11 hits device lost in 3 of 4 runs.Settings: 75% resolution, handheld twice and docked once. The sequence was
slow present: ~4300 ms, thenqueue submit 1000/2000 ms, then a fewslow submitof up to 5 s, thensubmit failed (-4). Two of the losses came about 30 s after launch, the docked one a few minutes into gameplay. The same settings withWB_DIFF=1had 0 device lost across 3 sessions. SoWB_DIFFseems to be what keeps this iGPU alive, flashes included.5. The default 2.5 GB texture cap is too small at 1080p.
v2.0.11's default iGPU texture cap (2560 MB) sat at 2535/2560 MB in Kokiri at 1080p.
RX_VK_VRAM_MB=3072gives enough headroom.Most stable config so far, about 35–50 fps:
HOS_FULLSCREEN=1,RX_VK_WB_DIFF=1,RX_VK_MOVIE_UPSCALE=linear,RX_VK_NO_MESH=1,RX_VK_VRAM_MB=3072Remaining problems: the
WB_DIFFflashes, plus invisible enemies and missing geometry (both fromNO_MESH). Logs for all of the above are available if useful.On my Xbox Ally X Z2E the game still freezes in a black screen after the logo after the first cutscene. Some times the audio continues but no image appears.
hookshot_log.txt
hookshot_log.txt
Having flickering issues with latest build (2.0.11)
Device: ASUS ROG Ally X, AMD Ryzen Z1 Extreme (RADV PHOENIX), Bazzite 45, Linux AppImage build 2.011
Allocated RAM is 14 GB, VRAM is 10 GB and SWAP is 6 GB
1280x720 resolution and 1920x1080 output mode
Frame rate averages between 30-45 FPS depending on area.
Seems very similar to an issue I saw for AMD users in one of the Shadow of the Colossus ports. Had something to do with Far Shadows. On AMD if enabled they would flicker so need to disable them. Sure it's unrelated but would make sense if it's a similar issue given I noticed it more once in Hyrule field which would have a lot of subtle distant shadows.
Asus Rog Ally X
Gam
hookshot_log.txt
e works just with a ton of visual problems
Same with my ROG Ally. The more I increase the graphic presets, the more intense are the visual problems. Just a detail I saw that I hope it helps.
Lenovo Legion Go S (Ryzen Z2 Go / SteamOS) — GPU hang persists in v2.0.11, mesh fallback allows gameplay
Hardware / environment
I have experienced a reproducible GPU hang during the Great Deku Tree / Navi opening sequence, whether I let the cutscene play or skip it.
The issue still occurs on v2.0.11.
Tests performed
With ´RX_VK_NO_MESH´ and the skip code, I can get past the opening sequence and actually control Link in Kokiri Forest.
Unfortunately, rendering is severely corrupted (widespread visual glitches), and performance is extremely poor. This is not a playable workaround, but it is a significant behavioral difference.
Game running video
Kernel evidence
The GPU hangs with the mesh rendering path enabled:
´´´
amdgpu: ring gfx_0.0.0 timeout
Process hookshot pid 17580 thread mkw_vk
Starting gfx_0.0.0 ring reset
Ring gfx_0.0.0 reset failed
GPU reset begin!
MODE2 reset
GPU reset succeeded
´´´
Earlier runs with RX_VK_CHECKPOINTS=1 repeatedly showed:
´´´
Last completed draw: 3741fc69b2a60e64
First unconfirmed draw: a6d0f6a379e407c4
Next draw: ffe0b5b31697ea95
´´´
These checkpoints identify where GPU progress stopped, not necessarily the shader responsible.
Conclusion / possible investigation direction
Disabling mesh shaders changes the outcome from a reproducible GPU hang to successful gameplay with broken rendering and very low FPS.
This strongly suggests investigating the mesh/task shader rendering path or its interaction with RADV on this APU, although it does not conclusively establish the root cause.
A targeted workaround preserving correct mesh rendering would be preferable to disabling the entire path.
I’m available to test diagnostic builds or additional flags on the actual hardware.
Debug and message generated by Codex. If LLM generated report are not allowed please le me know.
Follow-up (ROG Ally X): v2.0.11 still hard-reboots the Ally on save load
Same setup as my last comment (Handheld profile, 50% resolution, RX_VK_GPU_UNSWIZZLE=0, speed settings off, driver 0x800184). One game window each time, checked in the log.
v2.0.11 (source d6369f1e):
v2.0.10 behaved the same way: the first load after updating worked, the next launch rebooted on load. v2.0.8 never rebooted for me.
So it doesn't look like heat, resolution, the two speed settings or the pipeline cache. It seems tied to loading the save on a launch after the first one on v2.0.9+.
AllyX_v2.0.11_reboot_after_pipeline_cache_cleared.txt
AllyX_v2.0.11_reboot_second_load.txt
Legion go Z1. After disabling mesh shaders was able to get to gameplay. Link turned white a few times and I had to restart the second intro which worked fine the second time. hookshot_log.1.txt
Before RX_VK_NO_MESH=1
Legion go Z1. Not able to get past opening scene. Lowered resolution and tried 50% and auto. Tried different vram auto and 6g. Auto didn't crash but hung, 6g crashed. hookshot_log.1.txt
hookshot_log.2.txt
@git-hub-al have you tried
RX_VK_NO_MESH=1?Actually upon closer inspection when looking around the entrance to Hyrule field it appears to be weird vertex explosions and bits of the ui that is flickering in front of the screen.
Most of the flickering and stuttering has stopped. Great work!
I was able to get through the Deku Tree dungeon, beat the boss but then it crashed just as the cutscene went to transition. Performance has been incredibly stable up until this point running at a solid 40-60 fps.
CPU & RAM: AMD Ryzen AI 7 350, 32GB RAM
GPU: Radeon 860M 8GB
hookshot_env.txt
hookshot_log.txt
Folded in: #1126 (v2.0.7 on an AMD iGPU with RADV: objects glowing white, whole-screen whiteouts while moving), plus #1481 and #1482 earlier.
hookshot_log.txt
hookshot_log1.txt
still the same issue on 780M devices (and maybe other amd apu):
intro starts, then on deku scene black screen. sound does not stutter anymore on 2.0.11, but still no screen (black and 0fps in corner). if you wait you can control link and hear sound, but still no picture. auto-save is generated. if you restart the game and load save, still black screen
8gb vram in bios does not help
2 logs attached. one where it restarts, the other where black screen and link controlable
I have the same issue on a Ryzen 7 7840U (Radeon 780M). Black screen with audio after the intro cutscene. Driver crashes. Log attached. v2.0.11
hookshot_log.1.txt
hookshot_log.txt
On v2.0.12 no more deku scene black screen but heavy lags and white flashes.
AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (4.00 GHz), 16G of RAM, 512M of VRAM, drivers up to date. (On an asus vivobook)
I can't play link. Navi arrives on link and it freezes.
hookshot_log.txt
Here is the logs
Thanks for the work !
Was told to add my log here
hookshot_log.txt
ROG Ally Z1 Extreme model, Full system crash after first cutscene. Will try proposed 8GB UMA fix advised.
I’m experiencing micro-stutters on my ROG Ally Z1 Extreme, along with visual artifacts and a glitchy HUD.
hookshot_log(20261110-123453).txt
Still crashing on v2.0.13.
Device: Radeon 780M (Ryzen 7 7840U).
Issue: AMD driver crashes, game instantly closes.
Note: v2.0.11 had black screen with audio, but v2.0.12 and v2.0.13 just crash.
Tried: Clean rebuild and deleted config files.
Log attached.
hookshot_log.1 (1).txt
hookshot_log (1).txt
v2.0.13 on ROG Xbox Ally X (Radeon 890M, RDNA 3.5), retest of the mesh paths. Windows 11, AMD driver 0x8001a0, 4 GB UMA, 19.6 GB RAM visible. Fresh build with
--no-prepare-shaders; the first start prepared 38.8k shaders + 12.6k pipelines in about 10 min with no errors. Base env:RX_VK_WB_DIFF=1,RX_VK_VRAM_MB=3072, docked, 1080p output at 75%.RX_VK_NO_MESH=1NO_MESH)48 57 60 56 8 36 48 4.5 1.0 1.0 0.8 1.0 ... 0.6, the GPU 3D engine sat at 1%, the process at 6% CPU, and nvn loggedGPU waits in 5 s: 1 sync waits (4419 ms). It never recovered.RX_VK_FORCE_MESH_FALLBACK=1So on this iGPU the native mesh path no longer dies on save load, but it stalls the GPU a few minutes into gameplay.
Last 300 lines of each run:
hookshot-2.0.13-890m-conmesh-pegado.txt
hookshot-2.0.13-890m-fallback-negro.txt
Update, same Ally X / 890M, same v2.0.13 native-mesh config (no
NO_MESH; envRX_VK_WB_DIFF=1,RX_VK_VRAM_MB=3072,RX_VK_MOVIE_UPSCALE=linear, 1080p output at 75%, docked).A second run with the exact same settings played through to the end of the Deku Tree and beat Queen Gohma, with scenery and enemies all drawn. Over about 15 minutes there were 0 device lost, the median was 42 fps (range 28-60), and memory stayed at 7.5-9.8 GB.
There were 2 short stalls where one 5 s window fell to about 2-4 fps, but each time it recovered on its own within seconds. In the first run (my comment above) a stall like that never came back: it stayed at about 1 fps with the GPU idle and 4 s nvn sync waits. So the native mesh path on this iGPU looks playable now, but it sometimes stalls, and a stall can either recover or stay hung.
Update: Lenovo Legion Go 1 (AMD Z1 Extreme), 16gb ram, allocated vram = auto.
I managed to get the game running again. Performance has been surprisingly good so far: a consistent 60 FPS inside the first dungeon, and Kokiri forest, using FSR 3.1 Performance mode with no frame generation.
There are still some significant issues with texture loading. I'm encountering numerous texture-loading errors, and several textures aren't rendering correctly. I haven't progressed beyond the first dungeon yet, because of the aforementioned texture loading problems, so I can't comment on performance in the overworld yet.
However, updating from v2.0.11 to v2.0.12 fixed some previously missing UI elements. Menus and HUD elements that weren't loading before, or were glitching and broken, are now displaying correctly. Also, a lot of the artifacting, screen tearing and ghosting either stopped or just decreased substantially.
I also added "RX_VK_NO_MESH=1" to a newly created "hookshot_env.txt" file, which wasn't applied to runs on previous versions, but on this version i suspect that it applied, as the game wasn't launching at all on 2.0.12 out of the box, but it launched when i added the env file, but i still didn't verify from the actual log.
I'll continue testing and report back as I make progress.
Extra note: For those of you who are still experiencing the game crashing every single time, out of all the fixes i tried, like changing UMA frame buffers to 4, 6 and 8, adding a .bat file, and applying multiple external commands, the only one that actually made the game stop crashing was changing UMA Frame buffer size from the BIOS menu to auto. Give it a try and hopefully it'll work for you.
Tried v2.0.13 on my ROG Ally and big improvement! Now on Minimal graphic preset the visual problems are almost unnoticeable (there's still a small flickering happening). The Low preset has big visual problems rarely and the Balanced preset has them but less than before.
Hookshot 2.0.13 crashes my ASUS ROG Ally (Windows BSOD)
Hello,
I'm having a serious issue with Hookshot 2.0.13 on my ASUS ROG Ally Z1 Extreme.
When I launch and play the game, my entire system crashes and restarts.
Windows reports the following error:
VIDEO_SCHEDULER_INTERNAL_ERROR (0x119)
My setup:
Previous versions also had graphical issues, including flickering textures and large gray polygons.
Other games work normally. This problem only happens with Hookshot.
I've attached the Hookshot log.
Is this a known issue with AMD GPUs? Is there a possible fix?
Thanks!
hookshot_log.txt
With the last version 2.0.13 and the following flags, I was able to run the game quite playable (talking 30fps with 2x frame gen FSR 3.1) on my Legion Go S z2 Go 16GB.
Also some tweaks with the resolution and frame gen.
On an AMD handheld under SteamOS, v2.0.12 shows short bursts of broken graphics in Hyrule Field. Adding RX_VK_MIRROR=1 to the launch options removed all of them in my test. The cost was the frame rate: the game went from about 39 fps to about 20.
Tested on
Hardware
Software
Settings
v2.0.13 was not tested. Its changes are the menu and the frame-rate cap, not the renderer.
What goes wrong
Standing in Hyrule Field, these show up within seconds, every session. Each lasts a few frames and then the picture is normal again.
The game does not crash. Startup and shader precompile finish normally.
What made it stop
One change: RX_VK_MIRROR=1 in front of the launch options. Same install, same save, same place.
With it, none of the above appeared in a session of 3,000 game frames.
What it costs
Broken frames Yes, within seconds None seen
Game frame rate about 39 fps about 20 fps
GPU time per frame 17.8 ms 33.6 ms
Memory sync per frame 0.6 ms 16.9 ms
Copied back to game memory per frame nothing 68 MB
Memory was not short. Usage was lower in the second run (5.5 GB against 9.6 GB). The time goes into copying.
Why I think this happens
The game writes a frame's data into its memory, submits the frame, and starts writing the next one into the same memory.
On a dedicated graphics card, Hookshot gives the GPU its own copy of that memory, taken when the frame was submitted. That copy is the VRAM mirror.
On integrated graphics the mirror is off by default. The GPU reads the game's memory directly, and may read it after the game has started on the next frame. A HUD element or a full-screen effect drawn from half-old, half-new data would look like the sheets and triangles above.
Where this is in the source (tag v2.0.13):
What I can't be sure of
What it is not
Also in the log
hookshot-steam-v2.0.12-baseline.txt
hookshot-test1-mirror-v2_0_12.txt
Strix Halo (Radeon 8060S, GPD Win 5): near-locked 60 fps in Kokiri Forest with no flashes. Two local changes and the settings behind it.
Follow-up to #1186 (closed in favour of this tracker). Same device: GPD Win 5, Ryzen AI Max+ 395, Radeon 8060S (8 GB UMA), Bazzite, Mesa/RADV 26.2.6, Steam Game Mode, on the charger.
Result: v2.0.11 with the two patches below, Handheld profile on, Resolution 100%, Output 1920x1080, frame generation off. Kokiri Forest at ~2,300–3,000 draws a frame runs at 57–60 fps, mostly a steady 60. No white flashes, stray HUD pieces or missing objects. Before the patches it was ~36 fps, with flashes once parallel replay was on.
1. The flashes:
value_reckeeps the first part of a split submission (gpu/vk/vk_replay.cpp,submit_recording)With
RX_VK_PARALLEL(andRX_VK_CHUNK), a submission is sent in several recordings. The first one carries the submission's value withsignal_value = false.value_rec.emplacekeeps that first recording's seq, and the tail's later seq never replaces it. Sowait_recorded(the game's fence waits and the readback waits) returns as soon as the first part finishes, while the segments and the tail are still on the GPU. The log showed 0 sync waits in 5 s. The game then writes the next frame's data while the GPU is still drawing with it. That gives the one-frame flashes, the unlit objects and the stray HUD on a UMA APU, where the GPU reads guest memory live. After the fix there are ~229 waits in 5 s and no flashes.I checked v2.0.13: it still has the
emplaceversion (lines 335–336), so the bug is still there. The patch applies cleanly on v2.0.13 too.2. CPU: all threads on one CCD (
RX_VK_PIN_L3=1, local option)Once the GPU was waited on correctly, the frame became CPU-bound: the main thread plus the replay thread. The Max+ 395 has two CCDs. Pinning every thread of the process to the CPUs that share CPU 0's L3 (
0-7,16-23) withsched_setaffinityover/proc/self/task, called once at device creation, raised heavy scenes from ~53–56 to 57–60. That's 14 threads moved, and the ones created later inherit it. It's about 40 lines invk_main.cpp, and I can share it if it's useful.Settings
Power matters on this APU: TDP 85 W with the GPU clock locked high gave the best result. At 80 W, locking the GPU clock took power from the CPU and was slower than automatic clocks.
Investigation done with Claude (Anthropic's AI assistant).
CRITICAL: System BSOD (VIDEO_SCHEDULER_INTERNAL_ERROR, 0x119)
Device: Radeon 780M (Ryzen 7 7840U, 32GB RAM, Win11).
Running the game causes a full system crash and forces the PC to reboot.
hookshot_log.2.txt
hookshot_log.1.txt
hookshot_log.3.txt
Community work-around from Discord, not an official recommendation: on a Legion Go S (Z2 Go) the game is playable at about 30 fps with FSR 3.1 frame generation 2x, using these lines in hookshot_env.txt (in the game folder, next to image.bin):
RX_VK_NO_MESH=1skips the mesh draws (some objects may be missing), and the last three keep memory use small (smaller mirror budget, textures capped at 1024 pixels and 128 MB). If you try it on another handheld, please post the result here.Hi mate, I have a flow z13 with the same APU, how can I apply the first setting? The second one I put on a hookshot_env.txt but it doesnt seem to matter much.
Thank you in advance.
Rog ally Z1E X 8gb vram, Win 11
Ive not had any black screens since 2.0.14 only issue is hard reboot occasionally but it works fine next load in have been playing for almost n hour n half, while reloading saves and intro to make sure black screen is gone! Flickering goes away when I turn frame gen x2 on, and frame pacing off. Also keep frame rate limited to 60 in settings or else it hardcrash everytime. I attached pic of ingame hookshot settings. Will attach a log next hardcrash upon loading.
Tested in legion go z1 Xtreme 16gb 4gb uma, deleting the no mesh options works too, very little flickering but it's ok the problem I had more stuttering, if I delete the shaders manually the program will compile it again ? Thanks
Thanks! Is this aimed at the AMD reboot on save load as well, or just
performance? On the Ally X, v2.0.8 was stable, but v2.0.9–v2.0.11
hard-reboot on the second launch's save load. Happy to test a build with
the thread change if it might help.
On Tue, Nov 10, 2026, 2:29 PM ricardoluevano @.***>
wrote:
Hi @NotRexed ,
I’m testing Hookshot on a Lenovo Legion Go 1 with a Ryzen Z1 Extreme, integrated Radeon graphics, 16 GB of shared memory, and Windows 11. I’m posting this in issue #997 because the behavior may be relevant to the AMD handheld reports.
Build and previous progress
A/B test
I ran the prepared A/B launchers on the same v2.0.14 installation, using the same graphics settings and save. The only intended difference between the runs was:
B:
RX_VK_PER_QUEUE_FENCES=0
I did not enable RX_VK_NO_MESH=1, RX_VK_MIRROR=1, RX_VK_MIRROR_MB=256, RX_VK_TEX_MAX_DIM=1024, or RX_VK_TEX_MAX_MB=128. I also did not change the graphics settings specifically for B. The point was to isolate the fence behavior while keeping the other settings the same.
Result so far
During a short test in Kokiri Forest, the B run appeared to eliminate the flashing, and the frame rate felt much steadier. I have not played long enough or repeated the test enough times to call this confirmed, but it is the clearest improvement I have seen so far.
Earlier log observations
The earlier log from this setup identified the integrated AMD Radeon GPU and Vulkan 1.4, and reported mesh shader support. It showed a 2560 MB texture-cache budget, with reported texture use close to that budget at one point. The VRAM mirror path was reported as off.
That earlier run recorded about 5,280 presents and a final reported rate of 34.1 FPS; there were also periods where the rate fell into the low 20s and later recovered into the 50s. The log contained some long queue-finish/wait intervals, including intervals around 0.9–1.4 seconds. Those observations are from the earlier run, not measurements from the latest B test.
Could you please look at the attached A and B logs and check:
I’ll repeat the B test for longer and report whether the result is consistent. For now, this is promising but preliminary.
Thanks for your work on Hookshot.
A-hookshot_log.1.txt
A-hookshot_log.txt
B-hookshot_log.1.txt
B-hookshot_log.txt
@romulo-arpini Neither of them is a setting. Both are code changes in my own local build, and that's why the env line did nothing for you:
RX_VK_PIN_L3only exists in that build, so the official one ignores it.submit_recordingingpu/vk/vk_replay.cppfrom my comment above (the twoemplacelines replaced with thestd::maxversion). It needshookshot_vk.so/ the Vulkan back end rebuilt from source.vk_main.cpp. Without a rebuild you can get much the same effect on Linux by starting the game pinned to one CCD, for example with Steam launch optionstaskset -c 0-7,16-23 %command%. On Windows: Task Manager → Details → Set affinity → CPUs 0-7 and 16-23, orstart /affinity FF00FF hookshot.exe. The CPU numbering for each CCD can differ, so check yours first.I'd rather not pass binaries around. The clean way is for the flash fix to go into Hookshot itself. @NotRexed, would you take a PR with the
value_recchange? It's small, and it's what removed the flashes and stray HUD here withRX_VK_PARALLELon.RX_VK_REC_MAP_FIRST=1keeps the old behaviour for A/B testing.Investigation done with Claude (Anthropic's AI assistant).
One more from Discord (v2.0.14, Windows, Radeon 780M, 24 GB of memory): white flashing textures, then a crash while loading in. The log runs normally at 0.4 GB of VRAM and a 2560 MB texture budget, then ends with
vk: slow submit: 91392.5 ms ... slot wait 91360.8,submit 34168 failed (-4)andVK_ERROR_DEVICE_LOST: the GPU stalled for about 90 seconds before the driver reset it, the same device-lost pattern as #996.ROG Ally X (Z1 Extreme, RADV PHOENIX, Linux): the one-frame flashes and stray HUD are gone with the
value_recfix, confirming @myylkn 's finding above on another device.Symptoms before, in Hyrule Field and Castle Town: HUD pieces drawn stretched across the screen for one frame (the minimap as a cone from a point, the slingshot's "22" drawn huge, hollow hearts), grass drawn flat white or blue, and whole-screen brightness jumps. The frame before and the frame after were always clean. The log shows
VRAM mirror of buffer pools offandbatched submits on (RX_VK_BATCH, on with RADV).Cause (as myylkn described): in
submit_recording(gpu/vk/vk_replay.cpp),value_rec.emplacekeeps the first recording of a submission split byRX_VK_CHUNK(on by default, 120 draws a part), or of one stopped at an event wait and finished later.wait_recordedthen returns after the first part, for both the fence waits and the exposure readback wait, and the game rewrites memory the later parts still read in place. It is still there onmainandv2.1.0-rc.2.Fix used (a variant of the patch above that keeps registering
r.valuewhen the recording does not signal, so a wait on a stopped submission still finds its recording):Only
hookshot_vk.soneeds rebuilding (RX_VK_ONLY=1, built per release, since the renderer API version changes between releases).Measured on v2.0.13 in Hyrule Field, counting one-frame luminance spikes in screen recordings:
GPU waits in 5 s: 4–109 sync waits (31–232 ms) before, 103–137 (1.4–1.8 s) after. It costs frame rate: the FPS overlay in the field read roughly 45–70 before and 38–49 after (two recordings, not a controlled benchmark). Part of the old frame rate came from the game running ahead of the GPU.This may also bear on #1795, which copies uniform buffers on GPUs without mirrors for the same symptoms. An A/B with this fix alone, with
RX_VK_UB_SNAPSHOT=0, would show how much of that is this wait.The analysis was done with AI assistance (Claude); the testing and recordings are mine.
AMD APU (Radeon 760M): v2.0.11 runs, v2.0.13 crashes while loading — guest null deref, not a driver fault
Adding a data point that may not be in this tracker yet: on this machine the crash is inside the recompiled game, not in
amdvlk64.dll, and it arrived with v2.0.13.Machine
e0f3ccfa(the supported one), built with the bundled builderResults
v2.0.13 log (swapchain is fine here —
immediate):It is reproducible with the program/pipeline caches deleted (
hookshot_programs.bin,hookshot_pipelines.bin,hookshot_prepared.bin), so it is not a corrupt cache. It also happens withRX_VK_PRECOMPILE=0. No TDR (Event ID 4101) is logged, andamdvlk64.dllis not in the backtrace.Question: is a start-up regression on APUs between v2.0.11 and v2.0.13 known? #1719/#1750 (Z1 Extreme, v2.0.13, crash after intro / loading) look like the same thing; they were closed, so I am posting here instead of opening a new issue. Happy to run any build with extra logging (
RX_VK_*,HOS_*) if that helps narrow it down.2.1 Legion go 1 z1. Tested with auto 6g and 8g for device vram. Seemed best with 6 or 8, crash on auto. Seemed to prevent crashing with system os power mode on performance. Not sure of best game settings, tried to turn most things off and run with the system on lowest resolution. 10-30 fps. Excited how much more playable this is now!
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
For my ROG Ally Z1E, v2.1.0 was a HUGE improvement! I no longer have any visual problems in the first cutscene with the Deku Tree. Also the game runs at 35-40 fps with Balanced (8 GB) graphic preset and with AMD FSR 3.1 and 4 GB allocated for VRAM. Also, I am running it in Bazzite OS.
If I lower the graphic preset to Low (6 GB), I gain +10 fps.
After the cutscene, when playing as link inside his house, I got some big stutters but they go away after a minute of moving around.
Great work!!! Thank you!!
hookshot_log_para_github.txt
hookshot_log_para_github.txt
Device: ASUS ROG Ally (RC71L), Ryzen Z1 Extreme / Radeon 780M-class iGPU, 16 GB LPDDR5-6400 (4 GB UMA frame buffer, 11.7 GB visible to Windows), Windows 11 (build 26200)
Driver: AMD 32.0.31007.6002 (May 2026)
Hookshot: v2.1.0 (updated from v2.0.14 via the launcher)
Preset: Minimum (4GB VRAM / iGPU) → Handheld profile, Resolution 50%, Lanczos, Sharpness 30%, Frame pacing on, AMD Anti-Lag 2 on, mesh shaders Automatic (native)
What happens: In the very first area, turning the camera with the right stick drops to ~10 fps with heavy stutter. Standing still it holds ~43-45 fps (GPU time ~13.6 ms/frame with the Minimum preset; it was ~31 ms/frame and ~25 fps on the default Custom/Docked 2048x1152).
What the log shows during the stutter:
In one session: 25 "slow upload", 21 "slow submit ... memory sync" and 11 "ASTC textures left for a later frame" lines. "ASTC is decoded on the GPU (Eden's decoder, Switch 2 tiling)". VRAM is not full (3.1-3.6 of 6.3 GB), so it looks like the ASTC upload cost (40 ms default upload budget per frame) plus memory-sync spikes, not memory pressure.
Also seen many times:
vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20Testing now (hookshot_env.txt):
RX_VK_UPLOAD_BUDGET_MS=8,RX_VK_TEX_CAPTURE=0,RX_VK_TEX_MAX_DIM=1024. Will report back whether it helps.Full hookshot_log.txt available on request.
Follow-up to my ROG Ally Z1E comment above (v2.1.0, Minimum preset + Handheld profile, fullscreen on). ~30 min in Kokiri Forest with
RX_VK_UPLOAD_BUDGET_MS=8,RX_VK_TEX_CAPTURE=0,RX_VK_TEX_MAX_DIM=1024(log confirmstexture storage in the submit-time capture off).Result: mostly playable but still stutters. ~40 fps average (37-43 in most stretches, ~55 at the end), lows of 22-27 fps.
So
RX_VK_TEX_CAPTURE=0+ the lower upload budget clearly cut the long spikes. What's left:vk: an integrated GPU shares the system's RAM: textures at most 2560 MB). The forest sits right at it (2.40-2.52 GB) the whole time: ~198,000 textures retired in 30 min (4,535 "textures retired" lines, e.g.444 textures retired (1262 left, 2239 MB)) while VRAM is only 3.8 of 6.3 GB. The re-uploads look like the source of the regular hitches: in 53 of 133 600-frame windows the slowest frame was >100 ms. Small ASTC textures sometimes take 50+ ms on the GPU decoder, and 60 "slow upload" lines remain even with the 8 ms budget.vk: compute pipeline of 32181d6d0de7191d: SLOW compile, 5357 ms (on a worker)(alsoebd3b57c88a833d15237 ms,3cc366c42baaf4d55745 ms,faaa7dfb77ab84d94992 ms).Next I'm testing
RX_VK_VRAM_MB=3072to see if a slightly bigger texture budget stops the churn without running out of RAM (16 GB device, 4 GB UMA, 11.7 GB visible to Windows). Will report back.Result of
RX_VK_VRAM_MB=3072(ROG Ally Z1E, v2.1.0, Minimum preset + Handheld, on battery in Turbo, same Kokiri Forest area as my comments above; other env unchanged:RX_VK_UPLOAD_BUDGET_MS=8,RX_VK_TEX_CAPTURE=0,RX_VK_TEX_MAX_DIM=1024).With the env set, the
textures at most 2560 MBline no longer appears, and it did not run out of RAM (16 GB device, 4 GB UMA).Texture churn dropped a lot: ~11,300 textures retired in a ~6 min session (most of them in the first 3 minutes), compared with ~198,000 in 30 min at the default 2560 MB, so roughly 70% fewer per minute. After the first minutes the per-600-frame "textures retired" totals fell to 12-120. The worst frames per 600-frame window fell to 40-90 ms, instead of the regular 100-250 ms hitches before. Average ~45 fps, reaching 60 at the end.
What's left is mostly the first ~3 minutes after starting: texture loading (515-2,850 retired per window) plus compute pipelines compiled during play:
These match the worst freezes (up to 1.7 s). Each new compute pipeline takes ~5 s on this APU on battery (one took 37 s), and they were different keys from the previous session (
32181d6d0de7191d,ebd3b57c88a833d1, ...). They do get saved to play cache files afterwards (play file 11/12/13 saved, ~90 pipelines).Suggestion: on iGPUs, a texture budget a bit above 2560 MB (3072 here) might be a better default when the UMA frame buffer is 4 GB or more. Precompiling these compute pipelines (or shipping them in the pipeline list) would remove most of the first-minutes stutter on AMD APUs.
Hi what do you suggest as settings?I have exactly the same device as you and with hookshot_env.txt I can now start to play because before I was stuck on the black screen of hell,but the game now is super slow and not stable,before it was running super smooth but possible to see just the opening.what is your advice?
More reports of this, collected here:
With ROG Ally Z1E, It ran stable at 35-40 fps in Balanced (8 GB) quality preset during the first cutscene with the Deku tree and then moving around Link's house. When opening the door, the game froze and my ROG Ally became unresponsive so I had to manually restart it.
More reports of this, collected here:
github-sync referenced this issue2026-11-12 06:23:32 +00:00
@bika66 Here's what works best for me on the ROG Ally Z1E (v2.1.0). It's playable, not perfect.
In-game menu (F1 → Graphics):
hookshot_env.txt(next tohookshot.exe, one per line):RX_VK_UPLOAD_BUDGET_MS=8: spreads texture uploads over several frames (default 40 ms in one frame). This helped most with stutter when turning the camera.RX_VK_TEX_CAPTURE=0: fewer long "memory sync" spikes.RX_VK_TEX_MAX_DIM=1024: smaller textures, less to decode and upload. Barely visible on the Ally's screen.RX_VK_VRAM_MB=3072: raises the iGPU texture budget from 2560 to 3072 MB, so it stops evicting and reloading textures all the time (about 70% fewer for me). No out-of-memory with 4 GB UMA. If yours crashes, remove this line first.Keep the env lines that fixed your black screen and add these to them.
Outside the game:
Expect the first ~3 minutes in a new area to stutter badly while it compiles shaders (about 5 s each in my log, one took 37 s). They're saved after that, so the same place runs smoother next time.
If it's still very slow, post your
hookshot_log.txtand say which env lines you're using.hookshot_log.txt
i tried all but the game is always crashing
Hi @NotRexed
I have a very promising update from my Lenovo Legion Go (Ryzen Z1 Extreme, 16 GB RAM, Windows 11) regarding the AMD Vulkan crashes tracked in #997.
After extensive testing, I finally managed to get Hookshot v2.1.0 running successfully in Kokiri Forest, with no noticeable flickering, flashing, or missing geometry during my latest tests.
What I found
With v2.1.0 and "RX_VK_PER_QUEUE_FENCES=0", the game reaches the menu but crashes while loading my Kokiri save.
Diagnostic checkpoints identified pending draws associated with different shader programs. Skipping individual programs did not resolve the issue.
The logs consistently showed "VK_ERROR_DEVICE_LOST", and Windows recorded Display event 4101, indicating an AMD driver timeout and recovery.
I tested the following configuration:
RX_VK_PER_QUEUE_FENCES=0
RX_VK_FORCE_MESH_FALLBACK=1
This was tested using the official v2.1.0 build, without custom renderer patches.
The game now loads Kokiri successfully, and I can move around and play without the visual corruption I experienced in earlier versions.
More importantly, I was able to close the game normally, relaunch it, and load my save again successfully.
I initially observed approximately 26–28 native FPS, with around 77–80 displayed FPS using 3× frame generation.
I subsequently enabled AMD FSR 3.1 Quality and 4× frame generation, with very encouraging visual results.
I have not yet measured the native FPS again with those latest settings.
Why this may be useful
An earlier v2.0.14 test ran successfully for an extended session using native mesh shaders and "RX_VK_PER_QUEUE_FENCES=0", but subsequent launches became unstable.
With v2.1.0, global compute mesh fallback has produced the most promising and repeatable results so far.
This suggests that the native mesh rendering path, or its interaction with Vulkan synchronization and AMD drivers, deserves further investigation. It does not necessarily mean an individual mesh shader is defective.
I can provide both the failing native-mesh log and the successful compute-fallback log for comparison.
I will continue testing stability and performance and report any further findings.
Thank you for your continued work on AMD handheld compatibility!
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).The split-submission fence bug is fixed in main by #2419:
gpu/vk/vk_replay.cppnow maps a submission to its last recording rather than the first part. #2125 and #2602 cover related readback ordering, while #1906 changes retired-import reclamation and #2603 changes integrated-GPU budgeting. These are useful completed entries, not evidence that every handheld freeze is gone. On51da0464, uniform snapshots without mirrors still default on only for Intel; #1795 owns the wider change. Please keep this tracker open for the remaining freezes, device losses and memory-pressure reports, with effective mesh mode, UMA settings and matching OS evidence.following @pavelrossi i made an hookshot_env.txt with
RX_VK_PER_QUEUE_FENCES=0
RX_VK_FORCE_MESH_FALLBACK=1
RX_VK_UPLOAD_BUDGET_MS=8
RX_VK_TEX_CAPTURE=0
RX_VK_TEX_MAX_DIM=1024
RX_VK_VRAM_MB=3072
and the game pipeline made a check of 1h, then i closed and opened my rog ally and the pipeline's done in 5 min.
the game is playable just like pavel tell. At the opening of the scene the assets, texture and fog loading make a good 2/3 min to stabilize, the sliced signal turn very bright but for at least 2 min then normalize itself. when i used sword for the first time all foliage disappear for a flash (every hit) but this stop after a while to. i attach the log of the game start and the game after i saved, closed and reopened.
hookshot_log.1.txt first play
hookshot_log.txt second play
Hey ! That's me again !
I just wanted to let you know that the game is fully playable but is really lagging all the time with dark or white shapes. Not smooth at all in other words. But no crashes !
hookshot_log.txt
I added some SWAP memory to not run out of RAM.
v2.1.0
AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (4.00 GHz)
16Go of physical RAM & 32Go SWAP
Windows 11
I hope this will help for future work of optimization and debugging
Thanks !
Progress update: Lenovo Legion Go Z1 Extreme — Hookshot 2.1.0 (AMD Vulkan)
Hi everyone!
I wanted to share some encouraging progress with Hookshot 2.1.0 on my Lenovo Legion Go (Ryzen Z1 Extreme, 16 GB RAM, Windows).
After extensive testing and troubleshooting, I've managed to make significant progress. The game is now much more playable than before, although there are still some rendering issues to resolve.
The biggest breakthrough came from using these Vulkan environment variables:
RX_VK_FORCE_MESH_FALLBACK=1
RX_VK_PER_QUEUE_FENCES=0
With global compute mesh fallback enabled, I've been able to avoid the severe flashing, missing geometry and AMD driver resets that affected my previous configurations during the areas tested.
I've successfully managed to:
The visual quality has been excellent in the areas that render correctly, without the graphical corruption I experienced with earlier compute fallback implementations.
With AMD FSR 3.1 Quality enabled, I initially observed approximately 26–28 native FPS, with 77–80 displayed FPS using 3× frame generation.
I also experimented with 4× frame generation. It looked impressively smooth, but I encountered a white screen when leaving the Great Deku Tree.
Disabling frame generation allowed me to get past that transition.
I later crossed Hyrule Field using 2× frame generation and successfully reached Hyrule Castle.
However, my latest tests confirm that frame generation is not the only cause of the remaining problems.
I've now identified a consistent issue when entering Hyrule Castle.
The screen turns completely black immediately upon crossing the entrance, before I can see any part of the new area.
Interestingly:
To investigate this, I ran a separate test with frame generation disabled ("frame_generation=0"), while retaining the compute mesh fallback configuration.
The black screen still occurred.
This confirms that disabling frame generation does not resolve the Hyrule Castle black screen.
The diagnostic log from this test revealed several interesting issues:
What I find particularly interesting is that the renderer releases a substantial amount of render target memory but subsequently encounters additional image allocation failures.
This suggests a possible issue involving render target lifetime, memory budgeting or image reuse.
Of course, these logs do not conclusively establish the cause of the black screen.
I'm currently investigating whether the changes proposed in PR #2766 could help:
#2766
This PR addresses the eviction and reuse of covered render targets, which seems potentially relevant to the allocation failures I'm observing.
My next step is to verify whether this patch can be applied independently to the exact source revision used by my current Hookshot 2.1.0 build.
If compatible, I plan to test it in a separate experimental build without changing my working Vulkan configuration.
I haven't tested this PR yet, so I'm not claiming it fixes the issue.
Summary
Based on my testing so far, I suspect there may be two distinct AMD Vulkan-related problems:
The encouraging part is that I've gone from experiencing frequent driver resets and serious rendering corruption to being able to complete the first dungeon and reach Hyrule Castle with good visual quality.
I now have a reproducible black-screen scenario and diagnostic logs that may help narrow down the remaining problem.
I'll share another update once I've tested the experimental PR #2766 build.
Thanks to the developers for their continued work on Hookshot and AMD GPU compatibility. I hope these findings are useful!
Thanks for doing this testing, I am using the same device. Can you tell me you current device and game settings? I've noticed a difference with the device OS Power Modes effecting gameplay for instance. Happy to help test as well.