[AMD RX 9070 / RADV Linux] Low FPS (22-25) in Kokiri Forest + color distortion & background flicker

juanfelipeocampopinzon commented

2026-11-08 08:37:40 +00:00

(Migrated from github.com)

Software matrix fallback: "[hos host] vk: matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)"
Failed shaders: "[hos Presentation Thread] vk: program 3f6f2b1d671badcd not translated: a network left out on this card" (22060 programs, 12 failed).

CachyOS Linux (Kernel 7.3.0, Hyprland), 170 GB free

[hookshot_log.txt](https://github.com/user-attachments/files/34540180/hookshot_log.txt) From hookshot_log.txt: - Software matrix fallback: "[hos host] vk: matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)" - Failed shaders: "[hos Presentation Thread] vk: program 3f6f2b1d671badcd not translated: a network left out on this card" (22060 programs, 12 failed). CachyOS Linux (Kernel 7.3.0, Hyprland), 170 GB free

Delfinobeso commented

2026-11-08 12:36:22 +00:00

(Migrated from github.com)

Another RADV data point, with a regression in b5ed417 and a setting that fixes most of it.

System: RX 9060 XT 16 GB (RADV GFX1200), Mesa 26.2.6, kernel 7.2.15 (Bazzite, Gaming Mode / gamescope), Ryzen 7 5700X3D, 32 GB, THP madvise. Kokiri Forest, frame generation 2x, Resolution 100%.

Build / setting	Game fps	Flushes per 120 presents (by reason)	`queue submit` per frame	GPU time per frame
`3601726` (ultrawide), defaults	11.5	239 (poll 238)	49 ms	14 ms
`b5ed417` (main, with faster-fps), defaults	2.5	2406 (poll 2205)	176 ms	13 ms
`b5ed417` + `RX_VK_BATCH_POLL_US=2000`	13	123 (poll 4, cap 60, value 58)	30 ms	17.5 ms
same + `RX_VK_WAIT_GPU=2`	14	121 (poll 1, cap 60, value 60)	30 ms (present 13.6, slot wait 10.7)	11.7 ms

Since faster-fps, the progress polls flush about 10 times more often on RADV (poll 238 → 2205 per 120 presents), and fps fell from 11.5 to 2.5. RX_VK_BATCH_POLL_US=2000 brings it back to about one flush a frame. As myylkn suggested in #413, defaulting it to ~2000 with RADV looks worth it.
Even at one flush a frame, that one CS costs ~30 ms, with ~1.5 GB of userptr imports live (imports: 59 live (1472 MB)). The GPU is ~30% busy, and the Presentation thread is the busiest one (~64% of a core). That matches what Naneek-code measured in #312.

I can run more builds or env settings on this machine if that helps.

Another RADV data point, with a regression in `b5ed417` and a setting that fixes most of it. **System:** RX 9060 XT 16 GB (RADV GFX1200), Mesa 26.2.6, kernel 7.2.15 (Bazzite, Gaming Mode / gamescope), Ryzen 7 5700X3D, 32 GB, THP `madvise`. Kokiri Forest, frame generation 2x, Resolution 100%. | Build / setting | Game fps | Flushes per 120 presents (by reason) | `queue submit` per frame | GPU time per frame | |---|---|---|---|---| | `3601726` (ultrawide), defaults | 11.5 | 239 (poll 238) | 49 ms | 14 ms | | `b5ed417` (main, with faster-fps), defaults | **2.5** | **2406 (poll 2205)** | 176 ms | 13 ms | | `b5ed417` + `RX_VK_BATCH_POLL_US=2000` | 13 | 123 (poll 4, cap 60, value 58) | 30 ms | 17.5 ms | | same + `RX_VK_WAIT_GPU=2` | 14 | 121 (poll 1, cap 60, value 60) | 30 ms (present 13.6, slot wait 10.7) | 11.7 ms | 1. **Since faster-fps, the progress polls flush about 10 times more often on RADV** (poll 238 → 2205 per 120 presents), and fps fell from 11.5 to 2.5. `RX_VK_BATCH_POLL_US=2000` brings it back to about one flush a frame. As myylkn suggested in #413, defaulting it to ~2000 with RADV looks worth it. 2. **Even at one flush a frame, that one CS costs ~30 ms**, with ~1.5 GB of userptr imports live (`imports: 59 live (1472 MB)`). The GPU is ~30% busy, and the Presentation thread is the busiest one (~64% of a core). That matches what Naneek-code measured in #312. I can run more builds or env settings on this machine if that helps.

t0masz407 commented

2026-11-08 16:43:55 +00:00

(Migrated from github.com)

System: RX 7900 XTX (RDNA 3, RADV NAVI31), Mesa 26.2.6, Ryzen 7 7700X, kernel 7.3.1, NixOS, Hyprland 0.56, Linux AppImage.

Another RADV data point, this time RDNA 3 (RX 7900 XTX, Mesa 26.2.6, Hyprland/XWayland), build a598b9f, same spot in
Kokiri Forest, frame generation 2x. Started through Steam, each value the mean of several 120-present stat blocks:

Setting	fps (presents)	GPU busy (sysfs)	flushes / 120 presents (poll)
defaults	16.3–17.4	33 %	~245 (poll ~180)
`RX_VK_BATCH_POLL_US=2000`	27.8–27.9	57 %	~200 (poll 0–2)
+ `HOS_SHORT_SLEEP_TIMER=1`	27.6–27.9	58 %	same
+ `SDL_VIDEODRIVER=wayland`	27.1–27.5	57 %	same (and grey picture, see #679)

So +65 % from the poll setting alone, and it confirms the suggestion to default it to ~2000 on RADV. What is left is the
submit itself: with the poll fixed, the replay still spends ~23–25 ms per frame in submit and ~9 ms in present
(a frame's replay time), the GPU sits at ~57 % and no CPU thread is saturated. That is the same per-CS cost you
measured.

#448 (udmabuf dma-bufs) on RADV – I built a598b9f + #448 (+ #438, #485 and the swapchain fix from #679) on this
machine and ran the same spot, loaded through a scripted HOS_INPUT_LIVE sequence so every run is identical:

Build / setting	fps (presents)	`submit` / frame	GPU busy
`a598b9f`, `RX_VK_BATCH_POLL_US=0`	16.7–18.3	34–39 ms	38 %
`a598b9f`, `RX_VK_BATCH_POLL_US=2000`	27.4–27.9	25 ms	58 %
+ #448 (`guest memory as dma-bufs: yes`)	42.6–43.5	12.7 ms	71 %
+ #448, native Wayland with the swapchain fix	47.6	12.9 ms (present 5.8 ms vs 8.0)	72 %

So on RDNA 3 / RADV #448 halves the submit cost and is worth +55 % on top of the poll setting; together with it,
16–18 → 43–48 fps. No crashes or visual differences in these runs (short runs, Kokiri Forest only).

Other observations from the same session (defaults, before the poll setting):

five ModuleSystemWorker threads spend ~40 % of their time in the kernel: strace -c on one of them plus the main
thread for 3 s: 131,763 sched_yield, 18,187 futex (~44k yields/s), from sleep_ns()'s sub-millisecond path
yielding until the deadline. HOS_SHORT_SLEEP_TIMER=1 did not change fps here (see table), so it is CPU waste rather
than the limit on this machine.

🤖 Measured and written with Claude Code

**System:** RX 7900 XTX (RDNA 3, RADV NAVI31), Mesa 26.2.6, Ryzen 7 7700X, kernel 7.3.1, NixOS, Hyprland 0.56, Linux AppImage. Another RADV data point, this time RDNA 3 (RX 7900 XTX, Mesa 26.2.6, Hyprland/XWayland), build `a598b9f`, same spot in Kokiri Forest, frame generation 2x. Started through Steam, each value the mean of several 120-present stat blocks: | Setting | fps (presents) | GPU busy (sysfs) | flushes / 120 presents (poll) | |---|---|---|---| | defaults | 16.3–17.4 | 33 % | ~245 (poll ~180) | | `RX_VK_BATCH_POLL_US=2000` | 27.8–27.9 | 57 % | ~200 (poll 0–2) | | + `HOS_SHORT_SLEEP_TIMER=1` | 27.6–27.9 | 58 % | same | | + `SDL_VIDEODRIVER=wayland` | 27.1–27.5 | 57 % | same (and grey picture, see #679) | So +65 % from the poll setting alone, and it confirms the suggestion to default it to ~2000 on RADV. What is left is the submit itself: with the poll fixed, the replay still spends **~23–25 ms per frame in `submit`** and ~9 ms in `present` (`a frame's replay time`), the GPU sits at ~57 % and no CPU thread is saturated. That is the same per-CS cost you measured. **#448 (udmabuf dma-bufs) on RADV** – I built `a598b9f` + #448 (+ #438, #485 and the swapchain fix from #679) on this machine and ran the same spot, loaded through a scripted `HOS_INPUT_LIVE` sequence so every run is identical: | Build / setting | fps (presents) | `submit` / frame | GPU busy | |---|---|---|---| | `a598b9f`, `RX_VK_BATCH_POLL_US=0` | 16.7–18.3 | 34–39 ms | 38 % | | `a598b9f`, `RX_VK_BATCH_POLL_US=2000` | 27.4–27.9 | 25 ms | 58 % | | + #448 (`guest memory as dma-bufs: yes`) | **42.6–43.5** | **12.7 ms** | 71 % | | + #448, native Wayland with the swapchain fix | **47.6** | 12.9 ms (present 5.8 ms vs 8.0) | 72 % | So on RDNA 3 / RADV #448 halves the submit cost and is worth +55 % on top of the poll setting; together with it, 16–18 → 43–48 fps. No crashes or visual differences in these runs (short runs, Kokiri Forest only). Other observations from the same session (defaults, before the poll setting): - five `ModuleSystemWorker` threads spend ~40 % of their time in the kernel: `strace -c` on one of them plus the main thread for 3 s: 131,763 `sched_yield`, 18,187 `futex` (~44k yields/s), from `sleep_ns()`'s sub-millisecond path yielding until the deadline. `HOS_SHORT_SLEEP_TIMER=1` did not change fps here (see table), so it is CPU waste rather than the limit on this machine. 🤖 Measured and written with [Claude Code](https://claude.com/claude-code)

sak963 commented

2026-11-08 17:01:20 +00:00

(Migrated from github.com)

Same 22-25 fps in Kokiri Forest on an AMD Radeon 860M (RDNA 3.5 iGPU), RADV, CachyOS. The log shows the same matrix multiplies in software (the cooperative matrices lack 16x8x16 f16). Full log and frame statistics in #628.

t0masz407 commented

2026-11-08 17:45:56 +00:00

(Migrated from github.com)

Follow-up on RADV / RDNA 3 (RX 7900 XTX, Mesa 26.2.6): with #448 the replay thread is the limit here (submit ~13 ms + draw ~9 ms + present ~6 ms a frame, GPU ~75 % busy), so I tried the existing RX_VK_PARALLEL, which is off by default because on your NVIDIA card it gave no fps and black frames in Kakariko.

Build: v2.0.1 + #448 + #438 + #485 + #642 + #679/#680, native Wayland, RX_VK_BATCH_POLL_US=2000, frame generation 2x. Kokiri Forest, the same spot every run (scripted with HOS_INPUT_LIVE), 20 s each:

Setting	fps (presents)	the game's own limiter (`HOS_FPS_LOG`)
default	42–47 (4 runs)	nominal 45–46
`HOS_FPS_TARGET=60`	44.8–46.0	45–46
`RX_VK_PARALLEL=4`	50.0 in 3 of 3 runs, `GPU-bound wait 0.0 ms`	(capped at 50)
`RX_VK_PARALLEL=4 HOS_FPS_TARGET=60`	55.2–55.8	nominal 53–57

So on RADV the parallel replay is worth +18 % here, but only together with HOS_FPS_TARGET=60: on its own the game's adaptive limiter (vrr on) settles at 50 and stays there.

Flashes: RX_VK_FRAMELOG + scripts/framelog.py over 20 s in Kokiri: 0 events with and without RX_VK_PARALLEL=4 (2,701 and 3,177 frames; frame gaps median 7.6 → 6.5 ms, worst 13.3 → 10.7 ms). That is standing in Kokiri only; I cannot reach Kakariko with this save, where you saw the black frames, so that part is still open on AMD.

🤖 Measured and written with Claude Code

Follow-up on RADV / RDNA 3 (RX 7900 XTX, Mesa 26.2.6): with #448 the replay thread is the limit here (`submit` ~13 ms + `draw` ~9 ms + `present` ~6 ms a frame, GPU ~75 % busy), so I tried the existing **`RX_VK_PARALLEL`**, which is off by default because on your NVIDIA card it gave no fps and black frames in Kakariko. Build: v2.0.1 + #448 + #438 + #485 + #642 + #679/#680, native Wayland, `RX_VK_BATCH_POLL_US=2000`, frame generation 2x. Kokiri Forest, the same spot every run (scripted with `HOS_INPUT_LIVE`), 20 s each: | Setting | fps (presents) | the game's own limiter (`HOS_FPS_LOG`) | |---|---|---| | default | 42–47 (4 runs) | nominal 45–46 | | `HOS_FPS_TARGET=60` | 44.8–46.0 | 45–46 | | `RX_VK_PARALLEL=4` | **50.0** in 3 of 3 runs, `GPU-bound wait 0.0 ms` | (capped at 50) | | `RX_VK_PARALLEL=4 HOS_FPS_TARGET=60` | **55.2–55.8** | nominal 53–57 | So on RADV the parallel replay is worth +18 % here, but only together with `HOS_FPS_TARGET=60`: on its own the game's adaptive limiter (vrr on) settles at 50 and stays there. Flashes: `RX_VK_FRAMELOG` + `scripts/framelog.py` over 20 s in Kokiri: **0 events** with and without `RX_VK_PARALLEL=4` (2,701 and 3,177 frames; frame gaps median 7.6 → 6.5 ms, worst 13.3 → 10.7 ms). That is standing in Kokiri only; I cannot reach Kakariko with this save, where you saw the black frames, so that part is still open on AMD. 🤖 Measured and written with [Claude Code](https://claude.com/claude-code)

NotRexed commented

2026-11-09 05:48:59 +00:00

(Migrated from github.com)

Tracked in #1000, follow there. That issue collects every report of Linux / Steam Deck GPU hangs, crashes, low fps and build failures, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Tracked in #1000, follow there. That issue collects every report of Linux / Steam Deck GPU hangs, crashes, low fps and build failures, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your `hookshot_log.txt`.