MagicBeanDev/Hookshot

Archived

Watch

Fork 0

perf(vk): on the Steam Deck's APU, no idle send by default, and held submits go out while a readback waits #2422

Open

addisonbair wants to merge 2 commits from addisonbair/deck-batch-idle into main

addisonbair commented

2026-11-11 18:24:17 +00:00

(Migrated from github.com)

#1999 (from #1993) sends a held batch as soon as the GPU is idle. On an RX 9070 XT that took Kokiri Forest from 33-41 fps to 46-61. On a Steam Deck (Van Gogh, RADV) each submit costs ~1 ms of CPU, so the idle send costs more than it saves. Two commits:

No idle send on the Deck's APU by default. The rule is limited to Van Gogh by device ID (0x163f LCD, 0x1435 OLED). Every other GPU, other APUs included (780M, 890M, 8060S), keeps it: none of them is measured. RX_VK_BATCH_IDLE=1 or 0 still chooses, and the log says which (vk: idle send on/off).
While a readback waits for the GPU, held submits go out every 8 command buffers. Without the idle send, the work the replay records during a readback's catch-up (#2125) was held until the wait's own flush, so the GPU started it cold and the reader waited for all of it. Now invalidate() sends what is held when the wait begins, then again every 8 held command buffers while it waits. The waits themselves are unchanged. RX_VK_READBACK_SEND=0 turns it off; RX_VK_READBACK_SEND_CBS sets the count.

Deck measurements on unmodified main (eaef1460, which includes #2125 and #2222), default switches, standing Kokiri scene (~2,400 draws), GPU at 1200 MHz, deterministic headless runs, two passes:

	fps	replay `submit`	`queue submit`
main	13.8 / 13.5	40.5 ms	11.7 ms
commit 1 only	12.8 / 12.8	31.4 ms	2.0 ms
commits 1 + 2	14.6 / 14.3

Commit 1 alone saves ~9 ms of replay but loses fps: readback waits gate the frame, and holding batches makes them longer. That's why the two belong together. The Deck runs used the same change with a few off-by-default diagnostics compiled in; this branch drops them.

P16 (NVIDIA, RX_VK_BATCH=1 RX_VK_BATCH_MAX=32 to imitate RADV's batching): main 40.9 fps / 15.6 flushes a frame, commit 1 34.8 / 2.8, both 38.6 / 5.4. So on a GPU that keeps the idle send, commit 2 only acts while a readback waits.

Testing: tests/run_all.py in an Ubuntu 22.04 builder: the same failures as main (tools missing in my container), plus a new tests/test_readback_send.py. The renderer builds.

🤖 Generated with Claude Code

#1999 (from #1993) sends a held batch as soon as the GPU is idle. On an RX 9070 XT that took Kokiri Forest from 33-41 fps to 46-61. On a **Steam Deck** (Van Gogh, RADV) each submit costs ~1 ms of CPU, so the idle send costs more than it saves. Two commits: 1. **No idle send on the Deck's APU by default.** The rule is limited to Van Gogh by device ID (`0x163f` LCD, `0x1435` OLED). Every other GPU, other APUs included (780M, 890M, 8060S), keeps it: none of them is measured. `RX_VK_BATCH_IDLE=1` or `0` still chooses, and the log says which (`vk: idle send on/off`). 2. **While a readback waits for the GPU, held submits go out every 8 command buffers.** Without the idle send, the work the replay records during a readback's catch-up (#2125) was held until the wait's own flush, so the GPU started it cold and the reader waited for all of it. Now `invalidate()` sends what is held when the wait begins, then again every 8 held command buffers while it waits. The waits themselves are unchanged. `RX_VK_READBACK_SEND=0` turns it off; `RX_VK_READBACK_SEND_CBS` sets the count. **Deck measurements** on unmodified main (eaef1460, which includes #2125 and #2222), default switches, standing Kokiri scene (~2,400 draws), GPU at 1200 MHz, deterministic headless runs, two passes: | | fps | replay `submit` | `queue submit` | |---|---|---|---| | main | 13.8 / 13.5 | 40.5 ms | 11.7 ms | | commit 1 only | 12.8 / 12.8 | 31.4 ms | 2.0 ms | | commits 1 + 2 | **14.6 / 14.3** | | | Commit 1 alone saves ~9 ms of replay but loses fps: readback waits gate the frame, and holding batches makes them longer. That's why the two belong together. The Deck runs used the same change with a few off-by-default diagnostics compiled in; this branch drops them. P16 (NVIDIA, `RX_VK_BATCH=1 RX_VK_BATCH_MAX=32` to imitate RADV's batching): main 40.9 fps / 15.6 flushes a frame, commit 1 34.8 / 2.8, both 38.6 / 5.4. So on a GPU that keeps the idle send, commit 2 only acts while a readback waits. **Testing:** `tests/run_all.py` in an Ubuntu 22.04 builder: the same failures as main (tools missing in my container), plus a new `tests/test_readback_send.py`. The renderer builds. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Joey-Magnus (Migrated from github.com) reviewed

2026-11-11 20:08:36 +00:00

Joey-Magnus (Migrated from github.com) left a comment

The code change is fine: dev.props is filled before the first submit, the function-local static is initialised once, and RX_VK_BATCH_IDLE=0/1 still chooses either way. The two C++ fixtures that stub batch_gpu_idle() (tests/draw_stream_visibility_test.cpp, tests/fsr_image_retirement_test.cpp) aren't affected. My questions are about the default's reach and the evidence behind it, not the code:

question gpu/vk/vk_replay.cpp:179-180: batching is on by default only with RADV (batch_on), so in practice this default lands on every RADV APU: the Deck, but also 780M/890M laptops and the Radeon 8060S from issue 413, the machine batching was introduced for. As you say yourself, the Deck is the only one measured. The 8060S is a much stronger GPU that is more likely to sit idle between flushes, which is the case #1993 was fixing. Could you either get one A/B run on another APU (anyone from issue 413 / #1000), or narrow the rule (Van Gogh by deviceID, or a GPU-clock/CU threshold)? Otherwise, please state in the PR body that the 8060S is expected to change and nobody has checked.

question: the Deck numbers were taken on main with #1375 reverted and RX_VK_NO_READBACK_WAIT=1, so neither is what players run. #1375 changed how much the replay thread copies, which shifts exactly the CPU-vs-submit balance this default is about. Does the ~1.3 fps / ~4-5 ms of queue submit still show on unmodified main with default switches? With two runs per side the gap (18.6-18.8 vs 20.0-20.7) is plausible but small, and confirming it on the shipped configuration would make the default easy to accept.

minor: batch_on() logs its choice and why. batch_gpu_idle() now also depends on the device type but logs nothing, so a player's hookshot_log.txt won't show whether the idle send was on. A one-time logf beside batch_on's ("idle send off on an integrated GPU (RX_VK_BATCH_IDLE=1: on)") would make reports readable.

Only the title check has run in CI on this PR so far. The game-free suite still has to run once the workflow is approved.

The code change is fine: `dev.props` is filled before the first submit, the function-local static is initialised once, and `RX_VK_BATCH_IDLE=0/1` still chooses either way. The two C++ fixtures that stub `batch_gpu_idle()` (`tests/draw_stream_visibility_test.cpp`, `tests/fsr_image_retirement_test.cpp`) aren't affected. My questions are about the default's reach and the evidence behind it, not the code: **question** `gpu/vk/vk_replay.cpp:179-180`: batching is on by default only with RADV (`batch_on`), so in practice this default lands on every RADV APU: the Deck, but also 780M/890M laptops and the Radeon 8060S from issue 413, the machine batching was introduced for. As you say yourself, the Deck is the only one measured. The 8060S is a much stronger GPU that is more likely to sit idle between flushes, which is the case #1993 was fixing. Could you either get one A/B run on another APU (anyone from issue 413 / #1000), or narrow the rule (Van Gogh by `deviceID`, or a GPU-clock/CU threshold)? Otherwise, please state in the PR body that the 8060S is expected to change and nobody has checked. **question**: the Deck numbers were taken on main *with #1375 reverted* and `RX_VK_NO_READBACK_WAIT=1`, so neither is what players run. #1375 changed how much the replay thread copies, which shifts exactly the CPU-vs-submit balance this default is about. Does the ~1.3 fps / ~4-5 ms of queue submit still show on unmodified main with default switches? With two runs per side the gap (18.6-18.8 vs 20.0-20.7) is plausible but small, and confirming it on the shipped configuration would make the default easy to accept. **minor**: `batch_on()` logs its choice and why. `batch_gpu_idle()` now also depends on the device type but logs nothing, so a player's `hookshot_log.txt` won't show whether the idle send was on. A one-time `logf` beside `batch_on`'s ("idle send off on an integrated GPU (RX_VK_BATCH_IDLE=1: on)") would make reports readable. Only the title check has run in CI on this PR so far. The game-free suite still has to run once the workflow is approved.

Joey-Magnus (Migrated from github.com) reviewed

2026-11-11 21:26:41 +00:00

Joey-Magnus (Migrated from github.com) left a comment

The code is correct (vk_replay.cpp:179 reads dev.props once, and RX_VK_BATCH_IDLE still overrides). The rule is broader than the title, though. Batching is only on with RADV, so "integrated" hits every RADV APU (780M/890M laptops, Radeon 8060S), not just the Deck. The Deck numbers were also taken with #1375 reverted and RX_VK_NO_READBACK_WAIT=1, not the shipped configuration. Either narrow it to Van Gogh by deviceID or measure another APU. A log line showing whether the idle send is on would help with reports.

The code is correct (`vk_replay.cpp:179` reads `dev.props` once, and `RX_VK_BATCH_IDLE` still overrides). The rule is broader than the title, though. Batching is only on with RADV, so "integrated" hits every RADV APU (780M/890M laptops, Radeon 8060S), not just the Deck. The Deck numbers were also taken with #1375 reverted and `RX_VK_NO_READBACK_WAIT=1`, not the shipped configuration. Either narrow it to Van Gogh by deviceID or measure another APU. A log line showing whether the idle send is on would help with reports.

hckrman101 (Migrated from github.com) reviewed

2026-11-11 22:18:52 +00:00

hckrman101 (Migrated from github.com) left a comment

Thanks for measuring this on a Deck, the per-submit cost on Van Gogh is a useful data point. I read the change and agree with Joey-Magnus's review: the code is correct (dev.props is filled before the first flush, the static is set once, RX_VK_BATCH_IDLE=0/1 still overrides either way, and main hasn't touched batch_gpu_idle() since, so it merges cleanly).

His open points still stand and I'd like them settled before this goes in:

Reach: batching is only on by default with RADV, so "integrated" means every RADV APU, including the Radeon 8060S from issue 413 that batching was added for. A stronger APU is more likely to sit idle between flushes, which is the case #1993 fixed. Either one A/B on another APU, or narrow the rule to Van Gogh by deviceID.
Configuration: the numbers come from main with #1375 reverted and RX_VK_NO_READBACK_WAIT=1. One A/B pair on unmodified main with default switches would show the gain holds for what players actually run.
A one-time logf of the idle-send choice next to batch_on()'s, so hookshot_log.txt shows which path a report came from.

CI: only the title check has run; the game-free suite still needs the workflow approved. No verdict from me until the reach question is answered.

Thanks for measuring this on a Deck, the per-submit cost on Van Gogh is a useful data point. I read the change and agree with Joey-Magnus's review: the code is correct (`dev.props` is filled before the first flush, the static is set once, `RX_VK_BATCH_IDLE=0/1` still overrides either way, and main hasn't touched `batch_gpu_idle()` since, so it merges cleanly). His open points still stand and I'd like them settled before this goes in: - Reach: batching is only on by default with RADV, so "integrated" means every RADV APU, including the Radeon 8060S from issue 413 that batching was added for. A stronger APU is more likely to sit idle between flushes, which is the case #1993 fixed. Either one A/B on another APU, or narrow the rule to Van Gogh by `deviceID`. - Configuration: the numbers come from main with #1375 reverted and `RX_VK_NO_READBACK_WAIT=1`. One A/B pair on unmodified main with default switches would show the gain holds for what players actually run. - A one-time `logf` of the idle-send choice next to `batch_on()`'s, so `hookshot_log.txt` shows which path a report came from. CI: only the title check has run; the game-free suite still needs the workflow approved. No verdict from me until the reach question is answered.

gpu/vk/vk_replay.cpp

nit: "current main" here isn't quite what was measured (main with #1375 reverted and RX_VK_NO_READBACK_WAIT=1, per the PR body). Either say so, or re-measure on stock main and keep the wording.

nit: "current main" here isn't quite what was measured (main with #1375 reverted and `RX_VK_NO_READBACK_WAIT=1`, per the PR body). Either say so, or re-measure on stock main and keep the wording.

addisonbair commented

2026-11-12 00:58:52 +00:00

(Migrated from github.com)

Thanks, both. All three points are addressed at dc25850:

Reach: the rule is now limited to Van Gogh by device ID (0x163f, 0x1435). Every other APU, the 8060S included, keeps the idle send.
Configuration: re-measured on unmodified main (eaef1460) with default switches. This answer is less flattering: the idle-send change alone loses fps there (13.65 → 12.8). It saves ~9 ms of replay, but readback waits gate the frame, and holding batches makes those waits longer. So I added a second commit. While a readback waits, held submits go out, which brings it to 14.45 (two passes each). The table is in the description. The comment at vk_replay.cpp:182 now quotes the stock-main numbers.
Log line: vk: idle send on/off (RX_VK_BATCH_IDLE…) next to batch_on()'s, and the readback send logs its choice too.

The second commit touches the readback path from #2125, so it's worth a look by whoever reviewed that one. A new source check, tests/test_readback_send.py, covers it.

🤖 Generated with Claude Code

Thanks, both. All three points are addressed at dc25850: - **Reach:** the rule is now limited to Van Gogh by device ID (`0x163f`, `0x1435`). Every other APU, the 8060S included, keeps the idle send. - **Configuration:** re-measured on unmodified main (eaef1460) with default switches. This answer is less flattering: the idle-send change alone loses fps there (13.65 → 12.8). It saves ~9 ms of replay, but readback waits gate the frame, and holding batches makes those waits longer. So I added a second commit. While a readback waits, held submits go out, which brings it to 14.45 (two passes each). The table is in the description. The comment at `vk_replay.cpp:182` now quotes the stock-main numbers. - **Log line:** `vk: idle send on/off (RX_VK_BATCH_IDLE…)` next to `batch_on()`'s, and the readback send logs its choice too. The second commit touches the readback path from #2125, so it's worth a look by whoever reviewed that one. A new source check, `tests/test_readback_send.py`, covers it. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

addisonbair commented

2026-11-12 01:28:38 +00:00

(Migrated from github.com)

Confirmed on the Deck with this exact head (dc25850, built against today's main), against main's stock renderer on the same eaef1460 game, with default switches and the standing Kokiri scene at a 1200 MHz GPU clock: main 13.5 / 13.5 fps, this PR 14.3 / 14.4. GPU time is unchanged (29.9 ms vs 29.8), so the gain is on the CPU side, as expected.

🤖 Generated with Claude Code

Confirmed on the Deck with this exact head (dc25850, built against today's main), against main's stock renderer on the same eaef1460 game, with default switches and the standing Kokiri scene at a 1200 MHz GPU clock: **main 13.5 / 13.5 fps, this PR 14.3 / 14.4.** GPU time is unchanged (29.9 ms vs 29.8), so the gain is on the CPU side, as expected. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

github-sync referenced this pull request

2026-11-12 06:22:46 +00:00

[Tracking] Linux and Steam Deck: GPU hangs, crashes, low FPS and build failures #1000

github-sync commented

2026-11-12 08:31:15 +00:00

Owner

@Brett-D commented on GitHub · 2026-11-12 07:27 UTC · original

Steam Deck results for this PR merged onto current main. They show a regression there, and I think it comes from its interaction with #2602.

Setup: Steam Deck OLED (Galileo, APU 0932, RADV, SteamOS 3.9.5 Game Mode, handheld profile, docked to a 1920x1080 gamescope screen). Linux x86-64-v3 builds with the release play profile. Kokiri Forest standing scene from the same save (~2,400 draws). Each start loads the save, then logs 30 s of frame times and takes 80 compositor screenshots.

Builds: main 6749ba21 plus the Deck patches (UB snapshot without mirrors), with and without this PR merged (a clean merge). The two arms alternated start by start on the same caches.

	FPS	p50	p95	readbacks that waited (of 3000)
without the PR, 2 starts	30.0 / 30.1	31.3 / 30.5 ms	66.6 / 66.4 ms	49-79, ~40 ms each
with the PR, start 1	9.6	66.4 ms	366 ms	~200, ~40 ms each
with the PR, start 2	24.0	22.0 ms	70.8 ms	210-223, ~35 ms each
with the PR, start 3	stalled: 0 frames in the 30 s window, presents down to 3 fps			198-228

The logs confirm the PR's switches were active: idle send off (... off on the Steam Deck) and held submits go out while a readback waits: on. On start 3 the stall repeats this line: a readback's wait for write-back 35850 timed out after 250 ms (done 35849, submitted 35851, handed out 35851). That is the same one-short timeline that #2222 bounds. Without the idle send, readbacks wait far more often (~4x), and the waits run into that cap.

The PR's own numbers were taken on eaef1460, before #2602 (readbacks wait for the part that writes their range back), and #2602 changes when readbacks wait. On current main the same build without this PR is already at ~29-30 FPS on the Deck (b7e0e043, before #2602: ~25). So I'd re-measure the idle-send default on the Deck against current main before merging.

> [@Brett-D](https://github.com/Brett-D) commented on GitHub · 2026-11-12 07:27 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2422#issuecomment-6817524375) Steam Deck results for this PR merged onto current main. They show a regression there, and I think it comes from its interaction with #2602. **Setup:** Steam Deck OLED (Galileo, APU 0932, RADV, SteamOS 3.9.5 Game Mode, handheld profile, docked to a 1920x1080 gamescope screen). Linux x86-64-v3 builds with the release play profile. Kokiri Forest standing scene from the same save (~2,400 draws). Each start loads the save, then logs 30 s of frame times and takes 80 compositor screenshots. **Builds:** main `6749ba21` plus the Deck patches (UB snapshot without mirrors), with and without this PR merged (a clean merge). The two arms alternated start by start on the same caches. | | FPS | p50 | p95 | readbacks that waited (of 3000) | |---|---|---|---|---| | without the PR, 2 starts | 30.0 / 30.1 | 31.3 / 30.5 ms | 66.6 / 66.4 ms | 49-79, ~40 ms each | | with the PR, start 1 | 9.6 | 66.4 ms | 366 ms | ~200, ~40 ms each | | with the PR, start 2 | 24.0 | 22.0 ms | 70.8 ms | 210-223, ~35 ms each | | with the PR, start 3 | stalled: 0 frames in the 30 s window, presents down to 3 fps | | | 198-228 | The logs confirm the PR's switches were active: `idle send off (... off on the Steam Deck)` and `held submits go out while a readback waits: on`. On start 3 the stall repeats this line: `a readback's wait for write-back 35850 timed out after 250 ms (done 35849, submitted 35851, handed out 35851)`. That is the same one-short timeline that #2222 bounds. Without the idle send, readbacks wait far more often (~4x), and the waits run into that cap. The PR's own numbers were taken on `eaef1460`, before #2602 (readbacks wait for the part that writes their range back), and #2602 changes when readbacks wait. On current main the same build without this PR is already at ~29-30 FPS on the Deck (b7e0e043, before #2602: ~25). So I'd re-measure the idle-send default on the Deck against current main before merging.

github-sync commented

2026-11-12 10:34:34 +00:00

Owner

@hclaria commented on GitHub · 2026-11-12 10:01 UTC · original

A second Deck's numbers, in case they help. On mine this PR is slower than main at c544828f, in two scenes.

Setup. Steam Deck OLED (Van Gogh 0x1435), SteamOS 3.9.5, kernel 7.2.7-valve2, Mesa 26.2.0-devel (RADV). Game built from main at c544828f (v2.1.0-rc.3-248). Two renderers built the same way: main at c544828f unchanged, and this PR's head dc258507 merged onto c544828f (it merges cleanly). Headless runs on a fixed save, standing still, 110 s measured per run, two alternating passes.

Not default switches. This Deck runs with HOS_HANDHELD=1, RX_VK_LOW_SPEC=1, texture caps (RX_VK_VRAM_MB=2000, RX_VK_TEX_MAX_MB=128, RX_VK_TEX_MAX_DIM=1024) and frame generation at 2x (RX_VK_FRAMEGEN_MULT=2, RX_VK_FSR_FG=0). I did not measure default switches, so this does not contradict the 13.5 to 14.4 fps above. It says the result depends on the configuration.

scene	main `c544828f`	`dc258507` on `c544828f`
Kokiri Forest, ~2930 draws	22.90 / 22.79 fps	18.48 / 18.60 fps
Hyrule Field, ~1600 draws	21.09 / 21.01 fps	18.64 / 18.59 fps

Kokiri, per frame:

	main `c544828f`	`dc258507` on `c544828f`
queue submit	4.0 ms	1.2 ms
replay `submit`	30.4 ms	34.8 ms
frame	43.7 ms	54.1 ms
readbacks that waited	1154 of 3000, 2.19 ms each	604 of 3000, 6.13 ms each

The log confirms the PR's paths were active (idle send off (RX_VK_BATCH_IDLE, off on the Steam Deck), held submits go out while a readback waits: on).

Two things I take from it:

At c544828f the idle send costs much less than it did. Queue submit is 4.0 ms a frame in Kokiri here; a build from main at e19d969 (11 November, with local changes, so not a clean comparison) gave 12.2 ms on the same scene. So there is less left to save by sending less often.
What is saved on submits (2.8 ms) is lost to the GPU starting later: the readbacks wait three times longer each, and the frame is 10 ms longer.

I also tried a middle way on c544828f, holding the idle send until 12 command buffers or 2.5 ms. It lands between the two (22.12 / 22.32 fps in Kokiri, 20.76 / 20.78 in Hyrule Field), so still under unchanged main. Happy to run another configuration on this Deck if it helps.

> [@hclaria](https://github.com/hclaria) commented on GitHub · 2026-11-12 10:01 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2422#issuecomment-6820548948) A second Deck's numbers, in case they help. On mine this PR is slower than main at `c544828f`, in two scenes. **Setup.** Steam Deck OLED (Van Gogh `0x1435`), SteamOS 3.9.5, kernel 7.2.7-valve2, Mesa 26.2.0-devel (RADV). Game built from main at `c544828f` (`v2.1.0-rc.3-248`). Two renderers built the same way: main at `c544828f` unchanged, and this PR's head `dc258507` merged onto `c544828f` (it merges cleanly). Headless runs on a fixed save, standing still, 110 s measured per run, two alternating passes. **Not default switches.** This Deck runs with `HOS_HANDHELD=1`, `RX_VK_LOW_SPEC=1`, texture caps (`RX_VK_VRAM_MB=2000`, `RX_VK_TEX_MAX_MB=128`, `RX_VK_TEX_MAX_DIM=1024`) and frame generation at 2x (`RX_VK_FRAMEGEN_MULT=2`, `RX_VK_FSR_FG=0`). I did not measure default switches, so this does not contradict the 13.5 to 14.4 fps above. It says the result depends on the configuration. | scene | main `c544828f` | `dc258507` on `c544828f` | |---|---|---| | Kokiri Forest, ~2930 draws | 22.90 / 22.79 fps | 18.48 / 18.60 fps | | Hyrule Field, ~1600 draws | 21.09 / 21.01 fps | 18.64 / 18.59 fps | Kokiri, per frame: | | main `c544828f` | `dc258507` on `c544828f` | |---|---|---| | queue submit | 4.0 ms | 1.2 ms | | replay `submit` | 30.4 ms | 34.8 ms | | frame | 43.7 ms | 54.1 ms | | readbacks that waited | 1154 of 3000, 2.19 ms each | 604 of 3000, 6.13 ms each | The log confirms the PR's paths were active (`idle send off (RX_VK_BATCH_IDLE, off on the Steam Deck)`, `held submits go out while a readback waits: on`). Two things I take from it: - At `c544828f` the idle send costs much less than it did. Queue submit is 4.0 ms a frame in Kokiri here; a build from main at `e19d969` (11 November, with local changes, so not a clean comparison) gave 12.2 ms on the same scene. So there is less left to save by sending less often. - What is saved on submits (2.8 ms) is lost to the GPU starting later: the readbacks wait three times longer each, and the frame is 10 ms longer. I also tried a middle way on `c544828f`, holding the idle send until 12 command buffers or 2.5 ms. It lands between the two (22.12 / 22.32 fps in Kokiri, 20.76 / 20.78 in Hyrule Field), so still under unchanged main. Happy to run another configuration on this Deck if it helps.

github-sync commented

2026-11-12 14:42:34 +00:00

Owner

@Joey-Magnus requested changes on GitHub · 2026-11-12 14:32 UTC · original

My earlier points are addressed: Van Gogh only by device ID (gpu/vk/vk_replay.cpp:206), numbers from stock main, both choices logged.

I merged it into current main and ran tests/run_all.py. Two failures are this PR's: tests/test_draw_stream_visibility.py (red in CI too) and tests/test_fsr_image_retirement.py cut submit_recording out, and their fixtures don't declare readback_send_now or FR_READBACK. Both pass on main; please add the stubs.

The bigger problem is the measurements since. Brett-D (Deck LCD, recent main) saw 30 fps drop to 9.6 and 24, and one start stalled with readbacks hitting the 250 ms cap. hclaria (Deck OLED, non-default switches) saw 22.9 to 18.5 fps in Kokiri. Both suspect #2602 changed when readbacks wait after your eaef1460 runs. Could you re-measure on current main?

Smaller:

The readback send in invalidate() (:2388) is on for every RADV GPU, not just the Deck, and that's unmeasured.
RX_VK_READBACK_SEND is read with atoi (:192), so =on turns it off; use env_value_off, and env_int for _CBS (:200).

> [@Joey-Magnus](https://github.com/Joey-Magnus) requested changes on GitHub · 2026-11-12 14:32 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2422#pullrequestreview-5876211555) My earlier points are addressed: Van Gogh only by device ID (`gpu/vk/vk_replay.cpp:206`), numbers from stock main, both choices logged. I merged it into current main and ran `tests/run_all.py`. Two failures are this PR's: `tests/test_draw_stream_visibility.py` (red in CI too) and `tests/test_fsr_image_retirement.py` cut `submit_recording` out, and their fixtures don't declare `readback_send_now` or `FR_READBACK`. Both pass on main; please add the stubs. The bigger problem is the measurements since. Brett-D (Deck LCD, recent main) saw 30 fps drop to 9.6 and 24, and one start stalled with readbacks hitting the 250 ms cap. hclaria (Deck OLED, non-default switches) saw 22.9 to 18.5 fps in Kokiri. Both suspect #2602 changed when readbacks wait after your eaef1460 runs. Could you re-measure on current main? Smaller: - The readback send in `invalidate()` (`:2388`) is on for every RADV GPU, not just the Deck, and that's unmeasured. - `RX_VK_READBACK_SEND` is read with `atoi` (`:192`), so `=on` turns it off; use `env_value_off`, and `env_int` for `_CBS` (`:200`).

github-sync referenced this pull request

2026-11-12 15:49:19 +00:00

[Tracking] Linux and Steam Deck: GPU hangs, crashes, low FPS and build failures #1000

Commenting is not possible because the repository is archived.

No reviewers