White flashes, white bands and stray HUD pieces flicker on screen (AMD Radeon 8060S / Strix Halo, Linux RADV, GPD Win 5) #1186

Closed
opened 2026-11-09 16:42:40 +00:00 by mavszorg · 4 comments
mavszorg commented 2026-11-09 16:42:40 +00:00 (Migrated from github.com)

Hookshot version

v2.0.9 (source ed212f62). Also seen on v2.0.8. On v2.0.7 there was flicker too, at the time with frame generation on.

What kind of problem

Graphics

What happened

During normal play the picture flashes for a few frames, several times a minute:

  • a large white glow / blow-out appears around Link (looks like bloom or exposure going to white for a frame)
  • a white band covers the top part of the screen
  • stray HUD pieces pop up for a frame (an empty heart outline, an extra button prompt)

Textures themselves look correct; it is whole-frame flashing rather than garbled textures. Between the flashes the image is clean and runs smoothly (about 50-60 fps, no stutter). Expected: no flashes.

Where in the game

Kokiri Forest, near Link's house / the tree platforms, walking around normally in daylight. The attached video is from there.

How often

Every session, several times a minute.

Graphics card and driver version

AMD Radeon 8060S (Strix Halo, RDNA 3.5, integrated), RADV, Mesa 26.2.6, Vulkan 1.4.354. 8 GB of system memory reserved as VRAM (UMA). Mesh shaders, host memory import and pipeline libraries all reported "yes" in the log.

CPU, RAM and operating system

  • Device: GPD Win 5 (handheld)
  • CPU: AMD Ryzen AI Max+ 395, set to 8 cores / 16 threads in the BIOS
  • RAM: 32 GB total, about 23 GB visible to the OS (8 GB reserved for the GPU)
  • OS: Bazzite 45.20261105 (Fedora 45), kernel 7.2.15-ogc1.1.fc45
  • Screen: built-in 1920x1080 at 120 Hz
  • Launched through Steam. Reproduced in Bazzite Game Mode (gamescope session; the attached log is from there) and also when launched from Steam on the KDE Plasma (Wayland) desktop.

Changes from the defaults

Insert menu (hookshot_options.ini):

fullscreen=1
frame_generation=0
frame_pacing=1
handheld_profile=0
resolution=1          (100%, 2048x1152)
upscaling=2           (Lanczos)
sharpness=20
fps_counter=1
game_speed=1          (real time)
controller_in_background=1
layout_preset=1       (Xbox / PC)

hookshot_env.txt:

RX_VK_FIFO=1
HOS_FULLSCREEN=1

Steam launch options: HOS_INPUT_BACKGROUND=1 %command% (the controller was ignored in gamescope otherwise: "game window not in front, foreground window: process 0").

Things I tried that did not stop the flashes (one at a time, each removed again):

  • frame generation 2x -> Off (Off now; flashes stayed)
  • handheld profile On -> Off, resolution Auto -> 100%
  • RX_VK_ANISO=8 (removed)
  • RX_VK_WB_DIFF=0 and RX_VK_BC_IDLE_S=0 (#993's workaround): no change to the flashes, about 10 fps lower
  • updating v2.0.8 -> v2.0.9 (present queue and write-back diff back to v2.0.7 behaviour)
  • RX_VK_SYNC_PIPELINES=1 (the attached session ran with it): no change

Possibly related, from the log: "draws left out (not ready)" is non-zero in some frames, and textures are retired constantly (about 80 at a time, roughly 120 events in a few minutes) although textures stay well under the 6144 MB budget (about 4 GB).

Other software hooked into the game

None besides Steam itself (Steam overlay / Steam Input, gamescope's WSI layer in Game Mode). No ReShade, no injectors.

hookshot_log.txt

https://gist.github.com/mavszorg/2dd67700ad55e7cb5387d9541228420f

On Linux, launched from Steam, no hookshot_log.txt file was written beside the game, so this is the game's own output for one full v2.0.9 run (Game Mode, about 5 minutes), taken from the system journal. Home folder paths shortened to ~.

Screenshots or video

  • flicker-recording.mp4: 7 s phone recording of the screen; the flashes are at about 4 s.
  • flicker-frames.png: six consecutive frames around the flash (top row normal, bottom row: white glow around Link, white band across the top, then normal again).
### Hookshot version v2.0.9 (source ed212f62). Also seen on v2.0.8. On v2.0.7 there was flicker too, at the time with frame generation on. ### What kind of problem Graphics ### What happened During normal play the picture flashes for a few frames, several times a minute: - a large white glow / blow-out appears around Link (looks like bloom or exposure going to white for a frame) - a white band covers the top part of the screen - stray HUD pieces pop up for a frame (an empty heart outline, an extra button prompt) Textures themselves look correct; it is whole-frame flashing rather than garbled textures. Between the flashes the image is clean and runs smoothly (about 50-60 fps, no stutter). Expected: no flashes. ### Where in the game Kokiri Forest, near Link's house / the tree platforms, walking around normally in daylight. The attached video is from there. ### How often Every session, several times a minute. ### Graphics card and driver version AMD Radeon 8060S (Strix Halo, RDNA 3.5, integrated), RADV, Mesa 26.2.6, Vulkan 1.4.354. 8 GB of system memory reserved as VRAM (UMA). Mesh shaders, host memory import and pipeline libraries all reported "yes" in the log. ### CPU, RAM and operating system - Device: GPD Win 5 (handheld) - CPU: AMD Ryzen AI Max+ 395, set to 8 cores / 16 threads in the BIOS - RAM: 32 GB total, about 23 GB visible to the OS (8 GB reserved for the GPU) - OS: Bazzite 45.20261105 (Fedora 45), kernel 7.2.15-ogc1.1.fc45 - Screen: built-in 1920x1080 at 120 Hz - Launched through Steam. Reproduced in Bazzite Game Mode (gamescope session; the attached log is from there) and also when launched from Steam on the KDE Plasma (Wayland) desktop. ### Changes from the defaults Insert menu (hookshot_options.ini): ``` fullscreen=1 frame_generation=0 frame_pacing=1 handheld_profile=0 resolution=1 (100%, 2048x1152) upscaling=2 (Lanczos) sharpness=20 fps_counter=1 game_speed=1 (real time) controller_in_background=1 layout_preset=1 (Xbox / PC) ``` hookshot_env.txt: ``` RX_VK_FIFO=1 HOS_FULLSCREEN=1 ``` Steam launch options: `HOS_INPUT_BACKGROUND=1 %command%` (the controller was ignored in gamescope otherwise: "game window not in front, foreground window: process 0"). Things I tried that did **not** stop the flashes (one at a time, each removed again): - frame generation 2x -> Off (Off now; flashes stayed) - handheld profile On -> Off, resolution Auto -> 100% - `RX_VK_ANISO=8` (removed) - `RX_VK_WB_DIFF=0` and `RX_VK_BC_IDLE_S=0` (#993's workaround): no change to the flashes, about 10 fps lower - updating v2.0.8 -> v2.0.9 (present queue and write-back diff back to v2.0.7 behaviour) - `RX_VK_SYNC_PIPELINES=1` (the attached session ran with it): no change Possibly related, from the log: "draws left out (not ready)" is non-zero in some frames, and textures are retired constantly (about 80 at a time, roughly 120 events in a few minutes) although textures stay well under the 6144 MB budget (about 4 GB). ### Other software hooked into the game None besides Steam itself (Steam overlay / Steam Input, gamescope's WSI layer in Game Mode). No ReShade, no injectors. ### hookshot_log.txt https://gist.github.com/mavszorg/2dd67700ad55e7cb5387d9541228420f On Linux, launched from Steam, no hookshot_log.txt file was written beside the game, so this is the game's own output for one full v2.0.9 run (Game Mode, about 5 minutes), taken from the system journal. Home folder paths shortened to `~`. ### Screenshots or video - `flicker-recording.mp4`: 7 s phone recording of the screen; the flashes are at about 4 s. - `flicker-frames.png`: six consecutive frames around the flash (top row normal, bottom row: white glow around Link, white band across the top, then normal again).
NotRexed commented 2026-11-09 16:46:49 +00:00 (Migrated from github.com)

Thanks for the detailed report and video. Linking this to the AMD handhelds and APUs tracker #997 (Strix Halo / 8060S); whole-frame flashes in general are collected in #1005, and #1126 has similar flashes and stray HUD pieces on a Legion Go S.

Thanks for the detailed report and video. Linking this to the AMD handhelds and APUs tracker #997 (Strix Halo / 8060S); whole-frame flashes in general are collected in #1005, and #1126 has similar flashes and stray HUD pieces on a Legion Go S.
myylkn commented 2026-11-09 17:14:13 +00:00 (Migrated from github.com)

Same device here (GPD Win 5, Radeon 8060S, Bazzite, Mesa 26.2.6), same flashes: white glow/whiteout, white band, stray HUD pieces (empty heart, heart over the minimap). Some findings that may help narrow it down:

It is timing, not shaders. The flashes go away completely when the replay is not allowed to run ahead of the GPU:

  • The flash detector itself (RX_VK_FLASH=1 + RX_VK_SHOT_EVERY=1) almost removes them, because each shot waits for the GPU.
  • RX_VK_WAIT_GPU=1 removes them on v2.0.8 with default settings (only a few at load-in).
  • With RX_VK_PARALLEL=4 (which gives a locked 60 fps here, ~2 ms of segment recording instead of ~8 ms on one thread) the HUD flicker comes back with RX_VK_WAIT_GPU=1. It goes away only when waiting for the current frame's own GPU work at its present (a local 3-line patch: RX_VK_WAIT_GPU=-1 → wait_value(value)), at 40–50 fps.
  • RX_VK_MIRROR=1 also removes them, but costs ~8 ms of memory sync a frame on this APU (~40–50 fps).

So on a UMA APU with dma-buf guest memory, the GPU reads the game's buffers live, and the game's CPU writes the next frame's HUD/exposure data before the GPU has read the current one. The capture wait (#645) seems to cover only the exposure page, not the HUD's data.

Workaround for now: RX_VK_WAIT_GPU=1 in hookshot_env.txt (no flashes, ~45–53 fps). Or RX_VK_WAIT_GPU=1 + RX_VK_PARALLEL=4 for a steady 60 with occasional HUD flicker.

Investigation done with Claude (Anthropic's AI assistant).

Same device here (GPD Win 5, Radeon 8060S, Bazzite, Mesa 26.2.6), same flashes: white glow/whiteout, white band, stray HUD pieces (empty heart, heart over the minimap). Some findings that may help narrow it down: **It is timing, not shaders.** The flashes go away completely when the replay is not allowed to run ahead of the GPU: - The flash detector itself (`RX_VK_FLASH=1` + `RX_VK_SHOT_EVERY=1`) almost removes them, because each shot waits for the GPU. - `RX_VK_WAIT_GPU=1` removes them on v2.0.8 with default settings (only a few at load-in). - With `RX_VK_PARALLEL=4` (which gives a locked 60 fps here, ~2 ms of segment recording instead of ~8 ms on one thread) the HUD flicker comes back with `RX_VK_WAIT_GPU=1`. It goes away only when waiting for the current frame's own GPU work at its present (a local 3-line patch: `RX_VK_WAIT_GPU=-1` → `wait_value(value)`), at 40–50 fps. - `RX_VK_MIRROR=1` also removes them, but costs ~8 ms of memory sync a frame on this APU (~40–50 fps). So on a UMA APU with dma-buf guest memory, the GPU reads the game's buffers live, and the game's CPU writes the next frame's HUD/exposure data before the GPU has read the current one. The capture wait (#645) seems to cover only the exposure page, not the HUD's data. **Workaround for now:** `RX_VK_WAIT_GPU=1` in `hookshot_env.txt` (no flashes, ~45–53 fps). Or `RX_VK_WAIT_GPU=1` + `RX_VK_PARALLEL=4` for a steady 60 with occasional HUD flicker. Investigation done with Claude (Anthropic's AI assistant).
quazardous commented 2026-11-09 19:16:00 +00:00 (Migrated from github.com)

First of all: congratulations. I built this headless on Linux in 24 minutes and played for 22 minutes on a ROG Ally X (Z1 Extreme, RADV, Bazzite) with zero crashes, no device lost and 60 fps on light scenes. A Switch 2 recompilation running that well on an AMD handheld iGPU is genuinely impressive work, and the logs you emit are the most useful I have read in a long time — most of what follows came straight out of them.

Confirming this issue on one more AMD iGPU, v2.0.10, and adding two log lines that may narrow it down.

Same family, Z1 Extreme

Stray texture and icon fragments drifting across the screen, shadows and foliage shimmering, and occasional whole-screen white flashes. Textures are correct between the flashes, exactly as you describe.

Two log lines that look like a mechanism

vk: a frame: 59 draws kept their neighbour's descriptors
vk: texture slots registered again at another size: 1000000 (of 1423413 registrations;
    slot 13566 256x256 -> 512x512)

59 draws a frame reusing the previous draw's descriptors is, if the heuristic ever mis-fires, precisely "an object drawn with its neighbour's texture". And a million slot re-registrations at a different size is the other classic way stale content surfaces. I have no proof these cause it — but they are the only two lines in my log that describe the right kind of wrongness.

Two things that do not change it

  • Resolution 50%: no effect. Worth noting because #361 used exactly that as a workaround for its coloured noise, so this looks like a different cause.
  • Running under gamescope: no effect either — a completely different presentation path, same artefacts. That seems to rule out the game's own present/swapchain path.

Full platform report and numbers in my comment on #1000.

Happy to film it, run with any RX_* / HOS_* variable, or build from source with a patch — the device is free for debugging and I am a developer. Thanks again for this.

First of all: congratulations. I built this headless on Linux in 24 minutes and played for 22 minutes on a **ROG Ally X (Z1 Extreme, RADV, Bazzite)** with zero crashes, no device lost and 60 fps on light scenes. A Switch 2 recompilation running that well on an AMD handheld iGPU is genuinely impressive work, and the logs you emit are the most useful I have read in a long time — most of what follows came straight out of them. Confirming this issue on one more AMD iGPU, **v2.0.10**, and adding two log lines that may narrow it down. ## Same family, Z1 Extreme Stray texture and icon fragments drifting across the screen, shadows and foliage shimmering, and occasional whole-screen white flashes. Textures are correct between the flashes, exactly as you describe. ## Two log lines that look like a mechanism ``` vk: a frame: 59 draws kept their neighbour's descriptors vk: texture slots registered again at another size: 1000000 (of 1423413 registrations; slot 13566 256x256 -> 512x512) ``` 59 draws a frame reusing the previous draw's descriptors is, if the heuristic ever mis-fires, precisely "an object drawn with its neighbour's texture". And a million slot re-registrations at a different size is the other classic way stale content surfaces. I have no proof these cause it — but they are the only two lines in my log that describe the right kind of wrongness. ## Two things that do *not* change it - **Resolution 50%**: no effect. Worth noting because #361 used exactly that as a workaround for its coloured noise, so this looks like a different cause. - **Running under gamescope**: no effect either — a completely different presentation path, same artefacts. That seems to rule out the game's own present/swapchain path. Full platform report and numbers in [my comment on #1000](https://git.magicbean.dev/MagicBeanDev/Hookshot/issues/1000). Happy to film it, run with any `RX_*` / `HOS_*` variable, or build from source with a patch — the device is free for debugging and I am a developer. Thanks again for this.
NotRexed commented 2026-11-09 22:51:42 +00:00 (Migrated from github.com)

Thanks for the report. To keep each problem in one place, this is tracked in #1126 (the flicker, white flashes and stray HUD pieces on AMD iGPUs under RADV), which links your details. Closing this as a duplicate; please follow #1126 for updates.

Thanks for the report. To keep each problem in one place, this is tracked in #1126 (the flicker, white flashes and stray HUD pieces on AMD iGPUs under RADV), which links your details. Closing this as a duplicate; please follow #1126 for updates.
Commenting is not possible because the repository is archived.
No milestone
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Hookshot#1186
No description provided.