MagicBeanDev/Hookshot

Archived

Watch

Fork 0

[AMD iGPU / RADV] v2.0.7: objects render glowing white, whole-screen whiteouts while moving, heart drawn over the minimap (Legion Go S, SteamOS) #1126

Closed

opened 2026-11-09 13:26:54 +00:00 by drpowerup · 4 comments

drpowerup commented

2026-11-09 13:26:54 +00:00

(Migrated from github.com)

Hookshot version

v2.0.7

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

Summary

1.	Fixed by v2.0.6: the bright green lines on foliage that v2.0.5 showed on this device are gone. Thank you for #759 and 6dcf6f1.
2.	Still present in v2.0.7: grass, bushes, other plants and later fences render solid glowing white with bloom halos. There are also whole-screen white flashes while moving.
3.	Turning off draw-state reuse removes the steady glow: with RX_VK_NO_DESC_REUSE=1 RX_VK_PICK_BIND_GEN=1, objects standing still render normally. The glow and the whiteouts come back while running through the area.
4.	Separate issue: a large heart (the life-heart art) flickers in and out over the minimap and sometimes elsewhere on screen. Unchanged by the switches above.

What was tested (each step one change, Gaming Mode)

Test Result
v2.0.5 → v2.0.7 Green lines gone; white glow and flashes remain
RX_VK_SKIP_FILE with da7a7ab28b8e73d9 (the only program logging storage buffer NOT bound) Flashes unchanged
RX_VK_SKIP_FILE with all 57 mesh programs met in Kokiri Flashes much rarer, mostly in the first seconds
Hide only the first 29 of the 57 Dense ground grass glows white everywhere
Hide only the other 28 Branch-like bushes still glow, and now fences glow (not mesh programs)
RX_VK_NO_DESC_REUSE=1 RX_VK_PICK_BIND_GEN=1, nothing hidden Steady glow gone while standing; glow and whiteouts return while running; heart unchanged

Which objects glow depends on which other draws are present. That points to state carried from neighbouring draws, not to one shader. The A/B switches support this: they are the descriptor and constant-bank reuse (vk_draw.cpp:4777, :1593) and the program pick kept across uniform rebinds (vk_shader.cpp:1821). They fix the static case but not the moving case.

Log evidence (v2.0.7)

Not the cause:

•	No compute dispatch is left out for a compiling pipeline (0 left out: its compute pipeline is still compiling, 0 SLOW compile).
•	draws left out (not ready) only spikes in the first seconds (max 18.2 per frame), not while running.

Images the GPU drew are uploaded over from guest memory (32 lines per session), on full-screen targets and their half- and quarter-size chain:

vk: upload over a drawn image: #200 0x10000000000 2048x1152x1 x1 NVN 0x34 at present 943 (texture frame 944), finalized, 9216 KB dirty in 1 ranges
vk: upload over a drawn image: #856 0x10001380800 512x288x1 x1 NVN 0x14 at present 943 (texture frame 944), finalized, 0 KB dirty in 0 ranges, a GPU buffer wrote it
vk: upload over a drawn image: #294 0x10003200e00 2048x1152x1 x1 NVN 0x25 at present 2683 (texture frame 2684), finalized, 1156 KB dirty in 1 ranges

The VRAM mirror is off on this integrated GPU (vk: VRAM mirror of buffer pools off). So guest memory for these targets may not hold what the GPU drew. Re-uploading it over a bloom or exposure-chain image would fit both the whiteouts and the heart showing in the minimap's place. This is a hypothesis. The log has no timestamps to line these up with the flashes.

Unbound storage buffer in a fragment stage:

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

The "address" is 16.0f followed by 512. It is the same pattern as ceada14, which is geometry-only. Hiding this program did not stop the flashes.

Two source-level observations (not tested on device)

On integrated GPUs the readback wait from 98563eb never engages.

• In gpu_buffer_bind() (vk_memory.cpp, v2.0.7), the no-mirror branch returns at line ~2277, before wb_pages_note() at ~2301.
• So in-place GPU writes are never recorded, and invalidate() never waits for them. This is the OoT exposure meter case.
• A v2.0.5 session of 85,000+ presents never logged readbacks of GPU results: … waited.
• A 5-line patch is attached: hookshot-igpu-readback-wait.patch. It applies cleanly to v2.0.7 and v2.0.8-rc.2. It has not been built or run.
The colour-output NaN guard clamps to ±1e30 (EmitSetFragColor).

• An infinity becomes 1e30.
• In a 16-bit float target that is 65504 or infinity, still enough to blow bloom up from one pixel.
• A lower ceiling might be worth considering if these values turn out to be finite but huge.

Heart over the minimap

•	The life-heart art, full size and crisp, appears in the minimap's place and flickers in and out. Once it also appeared elsewhere on screen.
•	It is present in a v2.0.5 recording with frame generation off.
•	It is unchanged by RX_VK_NO_DESC_REUSE=1, by hiding all mesh programs, and by v2.0.6/v2.0.7.

Linux precompile crash (likely fixed in v2.0.8-rc.1; for confirmation)

On v2.0.5, Gaming Mode starts crashed in RADV during precompile. Four of five logs show libvulkan_radeon.so+0x147cfc, a write to 0x40, through libVkLayer_steam_fossilize.so. Mapped with v2.0.5's hookshot_vk.so (fingerprint cd9cebb6 = the v2.0.5 tag):

•	0x30e32d returns from vkCreateComputePipelines in precompile_run()'s worker.
•	Log 1 is the same call in prepare_run()'s seed_compute.

The guard then alternated crash, crash, play. ff95e92 and 2079b41 describe exactly this. It has not been retested on the release candidate.

Where in the game

Kokiri Forest

How often

Every time

Graphics card and driver version

AMD Ryzen Z1 Extreme integrated graphics (RADV PHOENIX) - Mesa RADV 26.1.99 (Vulkan 1.4)

CPU, RAM and operating system

Ryzen Z1 Extreme, 8 cores and 16 threads (Zen 4) / 32GB RAM / SteamOS

Changes from the defaults

Insert menu (changed from defaults):

Frame generation: 2x (default Off)
Frame pacing: On (default Off)
Resolution: 100% (default Auto)
Upscaling: Catmull-Rom (default Off)
Sharpness: 25% (default 0)
Show FPS: On (default Off)
Quality preset: Balanced (8GB) was selected earlier; individual options changed since then

Unchanged: output resolution 2048x1152, handheld profile Off, ultrawide 16:9, robust buffers Auto.

No hookshot_env.txt. Environment variables are set through Steam launch options instead:
RX_VK_NO_DESC_REUSE=1 RX_VK_PICK_BIND_GEN=1 RX_VK_MESH_OPT=1 HOOKSHOT_NO_UPDATE_CHECK=1 RX_VK_PRECOMPILE=0
(RX_VK_NO_DESC_REUSE and RX_VK_PICK_BIND_GEN were added during testing: they remove the steady glow. The glow and flashes happened without them too.)

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot-steam-v2.0.7.txt

Screenshots or video

Before you send it

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

### Hookshot version v2.0.7 ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened Summary 1. Fixed by v2.0.6: the bright green lines on foliage that v2.0.5 showed on this device are gone. Thank you for #759 and 6dcf6f1. 2. Still present in v2.0.7: grass, bushes, other plants and later fences render solid glowing white with bloom halos. There are also whole-screen white flashes while moving. 3. Turning off draw-state reuse removes the steady glow: with RX_VK_NO_DESC_REUSE=1 RX_VK_PICK_BIND_GEN=1, objects standing still render normally. The glow and the whiteouts come back while running through the area. 4. Separate issue: a large heart (the life-heart art) flickers in and out over the minimap and sometimes elsewhere on screen. Unchanged by the switches above. What was tested (each step one change, Gaming Mode) Test Result v2.0.5 → v2.0.7 Green lines gone; white glow and flashes remain RX_VK_SKIP_FILE with da7a7ab28b8e73d9 (the only program logging storage buffer NOT bound) Flashes unchanged RX_VK_SKIP_FILE with all 57 mesh programs met in Kokiri Flashes much rarer, mostly in the first seconds Hide only the first 29 of the 57 Dense ground grass glows white everywhere Hide only the other 28 Branch-like bushes still glow, and now fences glow (not mesh programs) RX_VK_NO_DESC_REUSE=1 RX_VK_PICK_BIND_GEN=1, nothing hidden Steady glow gone while standing; glow and whiteouts return while running; heart unchanged Which objects glow depends on which other draws are present. That points to state carried from neighbouring draws, not to one shader. The A/B switches support this: they are the descriptor and constant-bank reuse (vk_draw.cpp:4777, :1593) and the program pick kept across uniform rebinds (vk_shader.cpp:1821). They fix the static case but not the moving case. Log evidence (v2.0.7) Not the cause: • No compute dispatch is left out for a compiling pipeline (0 left out: its compute pipeline is still compiling, 0 SLOW compile). • draws left out (not ready) only spikes in the first seconds (max 18.2 per frame), not while running. Images the GPU drew are uploaded over from guest memory (32 lines per session), on full-screen targets and their half- and quarter-size chain: vk: upload over a drawn image: #200 0x10000000000 2048x1152x1 x1 NVN 0x34 at present 943 (texture frame 944), finalized, 9216 KB dirty in 1 ranges vk: upload over a drawn image: #856 0x10001380800 512x288x1 x1 NVN 0x14 at present 943 (texture frame 944), finalized, 0 KB dirty in 0 ranges, a GPU buffer wrote it vk: upload over a drawn image: #294 0x10003200e00 2048x1152x1 x1 NVN 0x25 at present 2683 (texture frame 2684), finalized, 1156 KB dirty in 1 ranges The VRAM mirror is off on this integrated GPU (vk: VRAM mirror of buffer pools off). So guest memory for these targets may not hold what the GPU drew. Re-uploading it over a bloom or exposure-chain image would fit both the whiteouts and the heart showing in the minimap's place. This is a hypothesis. The log has no timestamps to line these up with the flashes. Unbound storage buffer in a fragment stage: vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20 The "address" is 16.0f followed by 512. It is the same pattern as ceada14, which is geometry-only. Hiding this program did not stop the flashes. Two source-level observations (not tested on device) 1. On integrated GPUs the readback wait from 98563eb never engages. • In gpu_buffer_bind() (vk_memory.cpp, v2.0.7), the no-mirror branch returns at line ~2277, before wb_pages_note() at ~2301. • So in-place GPU writes are never recorded, and invalidate() never waits for them. This is the OoT exposure meter case. • A v2.0.5 session of 85,000+ presents never logged readbacks of GPU results: … waited. • A 5-line patch is attached: hookshot-igpu-readback-wait.patch. It applies cleanly to v2.0.7 and v2.0.8-rc.2. It has not been built or run. 2. The colour-output NaN guard clamps to ±1e30 (EmitSetFragColor). • An infinity becomes 1e30. • In a 16-bit float target that is 65504 or infinity, still enough to blow bloom up from one pixel. • A lower ceiling might be worth considering if these values turn out to be finite but huge. Heart over the minimap • The life-heart art, full size and crisp, appears in the minimap's place and flickers in and out. Once it also appeared elsewhere on screen. • It is present in a v2.0.5 recording with frame generation off. • It is unchanged by RX_VK_NO_DESC_REUSE=1, by hiding all mesh programs, and by v2.0.6/v2.0.7. Linux precompile crash (likely fixed in v2.0.8-rc.1; for confirmation) On v2.0.5, Gaming Mode starts crashed in RADV during precompile. Four of five logs show libvulkan_radeon.so+0x147cfc, a write to 0x40, through libVkLayer_steam_fossilize.so. Mapped with v2.0.5's hookshot_vk.so (fingerprint cd9cebb6 = the v2.0.5 tag): • 0x30e32d returns from vkCreateComputePipelines in precompile_run()'s worker. • Log 1 is the same call in prepare_run()'s seed_compute. The guard then alternated crash, crash, play. ff95e92 and 2079b41 describe exactly this. It has not been retested on the release candidate. ### Where in the game Kokiri Forest ### How often Every time ### Graphics card and driver version AMD Ryzen Z1 Extreme integrated graphics (RADV PHOENIX) - Mesa RADV 26.1.99 (Vulkan 1.4) ### CPU, RAM and operating system Ryzen Z1 Extreme, 8 cores and 16 threads (Zen 4) / 32GB RAM / SteamOS ### Changes from the defaults Insert menu (changed from defaults): - Frame generation: 2x (default Off) - Frame pacing: On (default Off) - Resolution: 100% (default Auto) - Upscaling: Catmull-Rom (default Off) - Sharpness: 25% (default 0) - Show FPS: On (default Off) - Quality preset: Balanced (8GB) was selected earlier; individual options changed since then Unchanged: output resolution 2048x1152, handheld profile Off, ultrawide 16:9, robust buffers Auto. No hookshot_env.txt. Environment variables are set through Steam launch options instead: RX_VK_NO_DESC_REUSE=1 RX_VK_PICK_BIND_GEN=1 RX_VK_MESH_OPT=1 HOOKSHOT_NO_UPDATE_CHECK=1 RX_VK_PRECOMPILE=0 (RX_VK_NO_DESC_REUSE and RX_VK_PICK_BIND_GEN were added during testing: they remove the steady glow. The glow and flashes happened without them too.) ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot-steam-v2.0.7.txt](https://github.com/user-attachments/files/34580818/hookshot-steam-v2.0.7.txt) ### Screenshots or video <img width="1284" height="1830" alt="Image" src="https://github.com/user-attachments/assets/2bf38f0e-52a7-43d0-8f4f-33ea49a7391f" /> <img width="642" height="1389" alt="Image" src="https://github.com/user-attachments/assets/4290e59e-d81b-4b87-80cd-27eb7b267cc0" /> <img width="642" height="1389" alt="Image" src="https://github.com/user-attachments/assets/e9e9e79f-dc82-4f0f-830e-e5ea86de5fef" /> <img width="3024" height="4032" alt="Image" src="https://github.com/user-attachments/assets/f824f087-9125-448a-9926-aeaebcd0dbe1" /> ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

👍 1

NotRexed commented

2026-11-09 13:45:36 +00:00

(Migrated from github.com)

Thanks for the careful one-change-at-a-time tests; the descriptor and bank reuse A/B is a strong lead. Linking this to the AMD handhelds and APUs tracker #997 (the glow is also collected in the lighting tracker #1004).

👍 2

drpowerup commented

2026-11-09 14:16:35 +00:00

(Migrated from github.com)

Proposed fix for the readback wait never engaging on iGPUs (mirror off). Untested: written from source analysis, not built or run.

hookshot-igpu-readback-wait.patch

Proposed fix for the readback wait never engaging on iGPUs (mirror off). Untested: written from source analysis, not built or run. [hookshot-igpu-readback-wait.patch](https://github.com/user-attachments/files/34582941/hookshot-igpu-readback-wait.patch)

👍 1

NotRexed commented

2026-11-10 05:07:52 +00:00

(Migrated from github.com)

Thanks for the report. This is part of the AMD handheld and APU rendering problems (here: glowing white objects and whiteouts on RADV), so it's followed in the tracking issue #997, along with the other reports from the same family of cards. Your exact repro steps are linked from there; please add new logs or results to #997. Closing in favour of the tracker.