MagicBeanDev/Hookshot
Archived
Watch
2
0
Fork
You've already forked Hookshot
 0
Code Issues 125 Pull requests 205 Activity

perf(vk): with frame generation, the replay no longer waits behind each present, and a capture waits for less of the frame before #2633

Open
hckrman101 wants to merge 3 commits from hckrman101/perf/framegen-present into main
pull from: hckrman101/perf/framegen-present
merge into: MagicBeanDev:main
Conversation 4 Commits 3 Files changed 8 +429 -20
hckrman101 commented 2026-11-12 03:35:14 +00:00 (Migrated from github.com)

Draft, not yet run in the game. With frame generation on, the game's replay spends several milliseconds of every frame waiting on things that are not its own work: a lock the display thread holds while the driver waits inside each present, and a wait for the whole of the frame before's GPU work. This removes the first and narrows the second.

Measured on main with DLSS, frame interpolation 4x and NVIDIA Reflex on, cap 120, Hyrule Field (RTX 3090, Ryzen 9 7900X, Linux, NVIDIA 620.70.06): the replay's submit is 11.5 ms a frame against 6.8 ms with default options in the same place. 3.8 ms of the difference is the lock, 2.3 ms the capture's wait.

1. A present on the replay's queue waits for its copy with the queue's lock let go

143b5e54

  • NVIDIA's driver on Linux waits inside vkQueuePresentKHR, on the CPU, until the frame's copy into the window is done on the GPU.
  • A present made on the replay's queue held dev.present_mu through that wait. Every submit of the replay takes the same lock.
  • With frame interpolation the display thread presents four times a game frame. In an all-thread sample the game's presentation thread was in submit_recording's wait for the lock at 17.2 % of all instants, while the display thread was inside present_out, in the driver's wait, at 34.5 %.
  • Now present_out waits for the copy's fence first, with the lock let go, and takes it again for the present itself. The present goes out when the driver would have let it: it waited for the same copy.
  • It covers frame generation's presents (both the paced ones and present-ahead's) and the game's own present.
  • Switch: RX_VK_PRESENT_COPY_WAIT=0 / =1. On by default only with NVIDIA's driver on Linux, where the wait was seen. Off on Windows, where a note in the code says the same idea was tried and was worse, and off for other Linux drivers, which were not seen to wait for the copy in the present.

2. A capture's late pages wait for the part that writes them back

d533cd18

  • A capture finds pages the CPU wrote that work still on the GPU writes back (OoT's exposure meter page), and waits for that work before the replay uses the capture.
  • The wait was for the page's submission value, which is done only with that submission's last part: all of the frame before's GPU work.
  • With frame generation the game runs ahead of the GPU, so this wait happens every frame: 97 of 600 takes, 2.4 ms each. With default options it is 0 of 600, because the present has already waited for the frame.
  • It also stalls. The same run has 7 "slow submit" lines whose whole time is this wait (16 to 240 ms, the limit is 250 ms); a run with RX_VK_CAPTURE_WAIT=0 has none.
  • Now a page whose part is already done on the GPU is not late at all, and the others wait for the newest of their parts, using the page-to-part table #2602 added for readbacks. A late page that was written in place (no mirror) keeps the wait for the submission's value, for the whole capture.
  • Switch: RX_VK_CAPTURE_PART=0 restores the old wait.
  • The 600-take log line now also counts the takes that waited for a whole submission and the pages a part had already written back. RX_VK_LOG_CAPTURE_LATE=1 logs each late wait.

What change 2 does and does not do (measured on the #2622 stack, which makes the game run ahead in the same way; default options, Hyrule Field and Kokiri Forest, RX_VK_LOG_CAPTURE_LATE=1):

  • It reduces the pages waited for: about 125 pages a frame that used to count as late are now taken without a wait.
  • The exposure page's wait stays. One take a frame, on the game's main thread, still waits for one page, 1.4-1.6 ms on average, because that page's part is the last part of the frame before. The stalls in that wait (16 ms and more, 5-8 a 30 s run) are still there.
  • So this commit alone will not remove the 2.4 ms a frame or the stalls described above. Removing them needs the next frame's submits held until that last part is done, instead of a wait at the capture. That is a separate change, in progress on #2622.

Tests

  • New tests/test_present_copy_wait.py: both callers give present_out their copy's fence and take it away; a failed submit gives none; the lock is let go for the wait and taken again before the present; the wait has a limit and sees a lost device; the default per platform and vendor; the presenter thread's hand-off is unchanged.
  • New tests/test_capture_part.py: the choice of a wait, cut from the source and run (a page whose part is done; the newest part; a page in place; a part not known; the switch), and the order in capture_make and take_capture.
  • tests/test_present_semaphores.py updated for the changed function.
  • tests/test_present_device_loss.py now covers the new fence wait (ten sites).
  • The whole suite on Linux (python -I -B tests/run_all.py): every failure it has is also a failure on main itself at 7297d93d, checked by running each one there: test_readback_part, test_dlss_checks, test_framegen_preset, test_hdr_encode, test_audio_biquad, test_audio_aux, test_mods_size_table, test_rumble_menu, test_mouse_native, test_linux_docker_packages, test_wayland_libdecor_hint, test_display_startup_failure, test_texel_buffer_ownership, and three known on this PC (test_bake_portability, test_builder_log_read_only, test_env_on).
  • Build: hookshot_vk.so builds on main at a016b7a6 with both commits and passes the ABI check.

Not yet tested in the game

Nothing here has been run with frame generation yet. For testers with frame generation on (any multiplier, DLSS-G or the renderer's own), NVIDIA on Linux first:

  • fps of the game's own frames and of the shown frames, against the same build with RX_VK_PRESENT_COPY_WAIT=0 RX_VK_CAPTURE_PART=0, same place, same settings.
  • Hitches: frames over 16.7 ms, 20 ms and 33 ms, and the log's slow submit lines (how many, and how many say memory sync).
  • Frame pacing of the shown frames (even spacing, no judder), with and without frame pacing, V-Sync Auto and On.
  • Flashes or flicker, above all exposure steps (the picture brightening or darkening for one frame) in Kokiri Forest and Hyrule Field.
  • Input feel with Reflex on.
  • The log lines vk: presents on the replay's queue ... and vk: a capture taken (ms): ... (the late pages' numbers).
  • On Windows and on AMD or Intel the first change is off; a run with RX_VK_PRESENT_COPY_WAIT=1 there would say whether it helps.
**Draft, not yet run in the game.** With frame generation on, the game's replay spends several milliseconds of every frame waiting on things that are not its own work: a lock the display thread holds while the driver waits inside each present, and a wait for the whole of the frame before's GPU work. This removes the first and narrows the second. Measured on `main` with DLSS, frame interpolation 4x and NVIDIA Reflex on, cap 120, Hyrule Field (RTX 3090, Ryzen 9 7900X, Linux, NVIDIA 620.70.06): the replay's `submit` is 11.5 ms a frame against 6.8 ms with default options in the same place. 3.8 ms of the difference is the lock, 2.3 ms the capture's wait. ## 1. A present on the replay's queue waits for its copy with the queue's lock let go `143b5e54` - NVIDIA's driver on Linux waits inside `vkQueuePresentKHR`, on the CPU, until the frame's copy into the window is done on the GPU. - A present made on the replay's queue held `dev.present_mu` through that wait. Every submit of the replay takes the same lock. - With frame interpolation the display thread presents four times a game frame. In an all-thread sample the game's presentation thread was in `submit_recording`'s wait for the lock at 17.2 % of all instants, while the display thread was inside `present_out`, in the driver's wait, at 34.5 %. - Now `present_out` waits for the copy's fence first, with the lock let go, and takes it again for the present itself. The present goes out when the driver would have let it: it waited for the same copy. - It covers frame generation's presents (both the paced ones and present-ahead's) and the game's own present. - **Switch:** `RX_VK_PRESENT_COPY_WAIT=0` / `=1`. On by default only with NVIDIA's driver on Linux, where the wait was seen. Off on Windows, where a note in the code says the same idea was tried and was worse, and off for other Linux drivers, which were not seen to wait for the copy in the present. ## 2. A capture's late pages wait for the part that writes them back `d533cd18` - A capture finds pages the CPU wrote that work still on the GPU writes back (OoT's exposure meter page), and waits for that work before the replay uses the capture. - The wait was for the page's submission value, which is done only with that submission's last part: all of the frame before's GPU work. - With frame generation the game runs ahead of the GPU, so this wait happens every frame: 97 of 600 takes, 2.4 ms each. With default options it is 0 of 600, because the present has already waited for the frame. - It also stalls. The same run has 7 "slow submit" lines whose whole time is this wait (16 to 240 ms, the limit is 250 ms); a run with `RX_VK_CAPTURE_WAIT=0` has none. - Now a page whose part is already done on the GPU is not late at all, and the others wait for the newest of their parts, using the page-to-part table #2602 added for readbacks. A late page that was written in place (no mirror) keeps the wait for the submission's value, for the whole capture. - **Switch:** `RX_VK_CAPTURE_PART=0` restores the old wait. - The 600-take log line now also counts the takes that waited for a whole submission and the pages a part had already written back. `RX_VK_LOG_CAPTURE_LATE=1` logs each late wait. **What change 2 does and does not do** (measured on the #2622 stack, which makes the game run ahead in the same way; default options, Hyrule Field and Kokiri Forest, `RX_VK_LOG_CAPTURE_LATE=1`): - It reduces the pages waited for: about 125 pages a frame that used to count as late are now taken without a wait. - The exposure page's wait stays. One take a frame, on the game's main thread, still waits for one page, 1.4-1.6 ms on average, because that page's part is the last part of the frame before. The stalls in that wait (16 ms and more, 5-8 a 30 s run) are still there. - So this commit alone will not remove the 2.4 ms a frame or the stalls described above. Removing them needs the next frame's submits held until that last part is done, instead of a wait at the capture. That is a separate change, in progress on #2622. ## Tests - New `tests/test_present_copy_wait.py`: both callers give `present_out` their copy's fence and take it away; a failed submit gives none; the lock is let go for the wait and taken again before the present; the wait has a limit and sees a lost device; the default per platform and vendor; the presenter thread's hand-off is unchanged. - New `tests/test_capture_part.py`: the choice of a wait, cut from the source and run (a page whose part is done; the newest part; a page in place; a part not known; the switch), and the order in `capture_make` and `take_capture`. - `tests/test_present_semaphores.py` updated for the changed function. - `tests/test_present_device_loss.py` now covers the new fence wait (ten sites). - The whole suite on Linux (`python -I -B tests/run_all.py`): every failure it has is also a failure on `main` itself at `7297d93d`, checked by running each one there: `test_readback_part`, `test_dlss_checks`, `test_framegen_preset`, `test_hdr_encode`, `test_audio_biquad`, `test_audio_aux`, `test_mods_size_table`, `test_rumble_menu`, `test_mouse_native`, `test_linux_docker_packages`, `test_wayland_libdecor_hint`, `test_display_startup_failure`, `test_texel_buffer_ownership`, and three known on this PC (`test_bake_portability`, `test_builder_log_read_only`, `test_env_on`). - Build: `hookshot_vk.so` builds on `main` at `a016b7a6` with both commits and passes the ABI check. ## Not yet tested in the game Nothing here has been run with frame generation yet. For testers with frame generation on (any multiplier, DLSS-G or the renderer's own), NVIDIA on Linux first: - fps of the game's own frames and of the shown frames, against the same build with `RX_VK_PRESENT_COPY_WAIT=0 RX_VK_CAPTURE_PART=0`, same place, same settings. - Hitches: frames over 16.7 ms, 20 ms and 33 ms, and the log's `slow submit` lines (how many, and how many say `memory sync`). - Frame pacing of the shown frames (even spacing, no judder), with and without frame pacing, V-Sync Auto and On. - Flashes or flicker, above all exposure steps (the picture brightening or darkening for one frame) in Kokiri Forest and Hyrule Field. - Input feel with Reflex on. - The log lines `vk: presents on the replay's queue ...` and `vk: a capture taken (ms): ...` (the late pages' numbers). - On Windows and on AMD or Intel the first change is off; a run with `RX_VK_PRESENT_COPY_WAIT=1` there would say whether it helps.
github-sync changed title from WIP: perf(vk): with frame generation, the replay no longer waits behind each present, and a capture waits for less of the frame before to perf(vk): with frame generation, the replay no longer waits behind each present, and a capture waits for less of the frame before 2026-11-12 07:28:06 +00:00
github-sync commented 2026-11-12 07:28:07 +00:00
Owner

@jabbaxipil commented on GitHub · 2026-11-12 06:41 UTC · original

Tested in the game on NVIDIA Linux with frame generation, A/B against the same build with RX_VK_PRESENT_COPY_WAIT=0 RX_VK_CAPTURE_PART=0.

Setup: RTX 4070, NVIDIA 615.71.09, Ryzen 7 5800X3D, Ubuntu 26.04.1 (kernel 7.0), GNOME Wayland, 2560x1440 at 144 Hz. CI AppImage v2.1.0-rc.3-237-g6be69c79. DLSS on, Reflex on, frame pacing on, V-Sync Auto.

Log lines asked for: with the PR, vk: presents on the replay's queue wait for their copy first, the queue's lock let go; with both switches at 0, ...made with the queue's lock held. So change 1 engages on this machine.

2x, DLSS Frame Gen making every frame, uncapped, 60 s standing still, same spot and facing. Run order: PR on, PR off, PR on.

PR on (3rd run) PR off PR on (1st run, cold)
Hyrule Field fps (avg / low) 58.0 / 49.6 57.8 / 55.3 52.8 / 51.6
Field late waits 78 of 36600 takes, 0 whole-submission 2291 of 25800, all whole-submission 536 of 29400, 0 whole
Kokiri fps (avg / low) 51.9 / 50.3 51.7 / 49.5 46.5 / 45.2
Kokiri late waits 2474 of 22800, 4.3 ms each, 0 whole 1656 of 25200, 4.2 ms each, all whole 2778 of 21000, 4.6 ms each, 0 whole

The first run was about 10% slower in both places, and the PR-on repeat matched PR off, so I read that as warm-up. Standing still, the fps is the same with and without the PR. Change 2 took whole-submission waits to 0 and removed almost all late waits in Hyrule Field. In Kokiri the count and the time per wait stayed about the same, which matches your note about the exposure page.

Free play, 2x uncapped (about 19 min PR off, about 14 min PR on; Kokiri, Hyrule Field, load zones):

PR off PR on
Game fps mean / median / 5th percentile 51.3 / 50.9 / 41.8 52.2 / 52.0 / 45.0
10 s windows with a frame over 33 ms 65 of 94 21 of 51
...over 100 ms 10 3
Late waits 2.9% of takes, all whole-submission 0.8% of takes, 1 whole-submission

The routes weren't identical, but every measure leaned slightly toward the PR. The PR-on run's one slow submit (387.5 ms, a texture upload, not memory sync) and its two windows over 250 ms came during a pipeline warm-up at start-up that the PR-off run didn't have.

Also seen: about one a capture's wait ... write-back timed out per run, early in the run, with the PR on and off (on: 0 to 2 a run, off: 1), each with an 80 to 176 ms sync wait.

No slow submit lines in any standing run. Shown-frame spacing was 90 to 99% within 7 to 12 ms with and without the PR. No flashes or exposure steps I could tie to the PR in Kokiri or Hyrule Field, and input with Reflex felt the same throughout.

4x, cap 144: the game held 36.0 fps with and without the PR, with no slow submit lines. 4x doesn't measure the PR on this machine: DLSS-G's runtime here makes at most 1 frame, so the renderer's own generator makes them, but V-Sync Auto still picks FIFO, which holds the game at 144 / 4. Opened as #2695.

Not tested: frame pacing off, V-Sync On, Windows, AMD/Intel.

> [@jabbaxipil](https://github.com/jabbaxipil) commented on GitHub · 2026-11-12 06:41 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2633#issuecomment-6816708607) Tested in the game on NVIDIA Linux with frame generation, A/B against the same build with `RX_VK_PRESENT_COPY_WAIT=0 RX_VK_CAPTURE_PART=0`. **Setup:** RTX 4070, NVIDIA 615.71.09, Ryzen 7 5800X3D, Ubuntu 26.04.1 (kernel 7.0), GNOME Wayland, 2560x1440 at 144 Hz. CI AppImage `v2.1.0-rc.3-237-g6be69c79`. DLSS on, Reflex on, frame pacing on, V-Sync Auto. **Log lines asked for:** with the PR, `vk: presents on the replay's queue wait for their copy first, the queue's lock let go`; with both switches at 0, `...made with the queue's lock held`. So change 1 engages on this machine. **2x, DLSS Frame Gen making every frame, uncapped, 60 s standing still, same spot and facing.** Run order: PR on, PR off, PR on. | | PR on (3rd run) | PR off | PR on (1st run, cold) | |---|---|---|---| | Hyrule Field fps (avg / low) | 58.0 / 49.6 | 57.8 / 55.3 | 52.8 / 51.6 | | Field late waits | 78 of 36600 takes, 0 whole-submission | 2291 of 25800, all whole-submission | 536 of 29400, 0 whole | | Kokiri fps (avg / low) | 51.9 / 50.3 | 51.7 / 49.5 | 46.5 / 45.2 | | Kokiri late waits | 2474 of 22800, 4.3 ms each, 0 whole | 1656 of 25200, 4.2 ms each, all whole | 2778 of 21000, 4.6 ms each, 0 whole | The first run was about 10% slower in both places, and the PR-on repeat matched PR off, so I read that as warm-up. Standing still, the fps is the same with and without the PR. Change 2 took whole-submission waits to 0 and removed almost all late waits in Hyrule Field. In Kokiri the count and the time per wait stayed about the same, which matches your note about the exposure page. **Free play, 2x uncapped** (about 19 min PR off, about 14 min PR on; Kokiri, Hyrule Field, load zones): | | PR off | PR on | |---|---|---| | Game fps mean / median / 5th percentile | 51.3 / 50.9 / 41.8 | 52.2 / 52.0 / 45.0 | | 10 s windows with a frame over 33 ms | 65 of 94 | 21 of 51 | | ...over 100 ms | 10 | 3 | | Late waits | 2.9% of takes, all whole-submission | 0.8% of takes, 1 whole-submission | The routes weren't identical, but every measure leaned slightly toward the PR. The PR-on run's one `slow submit` (387.5 ms, a texture upload, not `memory sync`) and its two windows over 250 ms came during a pipeline warm-up at start-up that the PR-off run didn't have. **Also seen:** about one `a capture's wait ... write-back timed out` per run, early in the run, with the PR on and off (on: 0 to 2 a run, off: 1), each with an 80 to 176 ms sync wait. **No `slow submit` lines** in any standing run. **Shown-frame spacing** was 90 to 99% within 7 to 12 ms with and without the PR. **No flashes or exposure steps** I could tie to the PR in Kokiri or Hyrule Field, and **input with Reflex** felt the same throughout. **4x, cap 144:** the game held 36.0 fps with and without the PR, with no `slow submit` lines. 4x doesn't measure the PR on this machine: DLSS-G's runtime here makes at most 1 frame, so the renderer's own generator makes them, but V-Sync Auto still picks FIFO, which holds the game at 144 / 4. Opened as #2695. **Not tested:** frame pacing off, V-Sync On, Windows, AMD/Intel. <!-- github-sync:c:6816708607 -->
github-sync commented 2026-11-12 07:28:07 +00:00
Owner

@hckrman101 commented on GitHub · 2026-11-12 07:13 UTC · original

Timing result with frame generation on: no gain in the first pair, so this stays a draft.

One pair, standing in Hyrule Field, RTX 3090 + Ryzen 9 7900X, Linux (NVIDIA, Wayland), 2560x1440 window, DLSS, frame generation 4x, Reflex on, cap 120. DLSS, 4x interpolation and Reflex were active in both logs:

main this PR
game fps (before interpolation) 69.1 63.2
  • Both sides still wait for late pages, 2.4-2.75 ms a frame, so the wait this PR removes behind the present is not what limits the frame here.
  • This is one pair in one order; the pair in the opposite order is still to run, and I will post it here. Until then, read it as "no gain shown", not as a measured loss.
  • My earlier estimate of about +20 % was wrong.
> [@hckrman101](https://github.com/hckrman101) commented on GitHub · 2026-11-12 07:13 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2633#issuecomment-6817275939) Timing result with frame generation on: no gain in the first pair, so this stays a draft. One pair, standing in Hyrule Field, RTX 3090 + Ryzen 9 7900X, Linux (NVIDIA, Wayland), 2560x1440 window, DLSS, frame generation 4x, Reflex on, cap 120. DLSS, 4x interpolation and Reflex were active in both logs: | | main | this PR | |---|---|---| | game fps (before interpolation) | 69.1 | 63.2 | - Both sides still wait for late pages, 2.4-2.75 ms a frame, so the wait this PR removes behind the present is not what limits the frame here. - This is one pair in one order; the pair in the opposite order is still to run, and I will post it here. Until then, read it as "no gain shown", not as a measured loss. - My earlier estimate of about +20 % was wrong. <!-- github-sync:c:6817275939 -->
github-sync commented 2026-11-12 08:31:22 +00:00
Owner

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

Steam Deck data for part 2 (a capture's late pages wait for the part that writes them back). It probably doesn't change much on GPUs without mirrors.

Setup: Steam Deck OLED (Galileo, APU 0932, RADV, Game Mode, handheld profile, docked), main 6749ba21 plus the Deck patches, Kokiri Forest standing scene, 30 s frame logs per start.

  • Without mirrors, every late page comes from note_direct_write (part 0, written in place). Your late_page() sends those to the whole-submission wait (whole = true), so this PR leaves the Deck's waits as they are: 177-195 of 600 takes wait, ~3.5-4.5 ms each.
  • I also tried removing that wait entirely on the Deck: defer the late pages and copy them again at a later take, or when a read needs one (local branch, not a PR). The take waits went to 0 of 600, but FPS didn't move: about 29.0 with it against 28.9 without, over 6 and 3 starts. The frame is bound by a serial CPU chain there (HOS_CHAIN: the render thread with the inline replay, then the main thread), and the deferred pages are read again soon (40-70 reads per 600 takes wait ~13-15 ms each), so the wait just moves. p50 got worse (30-31 ms against 26-28), and one start hitched 1.07 s.

So on mirrorless iGPUs, the late-page wait isn't where the Deck's frame time goes. I won't open a PR for the deferral. Your part-based wait looks right for the mirrored case it targets.

> [@Brett-D](https://github.com/Brett-D) commented on GitHub · 2026-11-12 07:28 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2633#issuecomment-6817527566) Steam Deck data for part 2 (a capture's late pages wait for the part that writes them back). It probably doesn't change much on GPUs without mirrors. Setup: Steam Deck OLED (Galileo, APU 0932, RADV, Game Mode, handheld profile, docked), main `6749ba21` plus the Deck patches, Kokiri Forest standing scene, 30 s frame logs per start. - Without mirrors, every late page comes from `note_direct_write` (part 0, written in place). Your `late_page()` sends those to the whole-submission wait (`whole = true`), so this PR leaves the Deck's waits as they are: 177-195 of 600 takes wait, ~3.5-4.5 ms each. - I also tried removing that wait entirely on the Deck: defer the late pages and copy them again at a later take, or when a read needs one (local branch, not a PR). The take waits went to 0 of 600, but FPS didn't move: about 29.0 with it against 28.9 without, over 6 and 3 starts. The frame is bound by a serial CPU chain there (HOS_CHAIN: the render thread with the inline replay, then the main thread), and the deferred pages are read again soon (40-70 reads per 600 takes wait ~13-15 ms each), so the wait just moves. p50 got worse (30-31 ms against 26-28), and one start hitched 1.07 s. So on mirrorless iGPUs, the late-page wait isn't where the Deck's frame time goes. I won't open a PR for the deferral. Your part-based wait looks right for the mirrored case it targets. <!-- github-sync:c:6817527566 -->
github-sync commented 2026-11-12 14:43:41 +00:00
Owner

@PedroFlaminio commented on GitHub · 2026-11-12 14:33 UTC · original

Tested in the game on Linux + NVIDIA with frame interpolation on: no change in frame rate here.

Hardware: RTX 3060 12 GB, NVIDIA 615.71.09, Manjaro (kernel 6.12), Core Ultra 7 265KF (8 P-cores + 12 E-cores), Wayland. Built on main 51da0464: each PR merged onto it, only hookshot_vk.so built (container build, RX_MARCH=x86-64-v3 RX_RELEASE=1) and swapped into the same game folder; main's hookshot_vk.so built the same way as the baseline.
Settings: 3440x1440 monitor, picture 2576x1080 (Aspect ratio: monitor's), frame interpolation 2x, Reflex on, V-Sync off, no frame rate cap; otherwise unchanged between runs.
Scene: Hyrule Field from the same save, standing, no input, 3.5 to 7 minutes a run; only the 5 s windows after loading (3,370-3,760 draws in every run) are counted. One run each, in the order main, #2633, #2644, #2559.

renderer fps median (min-max) replay submit draw descriptors memory sync
main 42.7 (41.4-43.4) 21.4 ms 9.4 3.5 9.4
#2633 42.8 (40.6-43.8) 19.9 ms 7.6 2.7 9.4
#2644 42.6 (40.2-43.5) 21.2 ms 8.9 2.9 9.5
#2559 43.0 (42.3-43.8) 20.1 ms 7.7 2.7 9.6

(replay columns: medians of the last 20 a frame's replay time lines; GPU-bound wait was 0.0 ms in all runs)

  • The log confirms the switch was on: presents on the replay's queue wait for their copy first, the queue's lock let go.
  • Frame interpolation stayed even: 424 of 426 frames 9-12 ms apart (main: 426 of 426).
  • The lower draw time is within run-to-run noise: #2559, which changes only GPU barriers, shows the same drop. With 2x interpolation, the present lock does not seem to be what limits the frame on this machine; memory sync (~9.5 ms) is the largest part of the replay in every run.
  • No device lost in any run, and no visual problem seen while playing.
> [@PedroFlaminio](https://github.com/PedroFlaminio) commented on GitHub · 2026-11-12 14:33 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2633#issuecomment-6826488840) Tested in the game on Linux + NVIDIA with frame interpolation on: no change in frame rate here. Hardware: RTX 3060 12 GB, NVIDIA 615.71.09, Manjaro (kernel 6.12), Core Ultra 7 265KF (8 P-cores + 12 E-cores), Wayland. Built on main `51da0464`: each PR merged onto it, only `hookshot_vk.so` built (container build, `RX_MARCH=x86-64-v3 RX_RELEASE=1`) and swapped into the same game folder; main's `hookshot_vk.so` built the same way as the baseline. Settings: 3440x1440 monitor, picture 2576x1080 (Aspect ratio: monitor's), frame interpolation 2x, Reflex on, V-Sync off, no frame rate cap; otherwise unchanged between runs. Scene: Hyrule Field from the same save, standing, no input, 3.5 to 7 minutes a run; only the 5 s windows after loading (3,370-3,760 draws in every run) are counted. One run each, in the order main, #2633, #2644, #2559. | renderer | fps median (min-max) | replay submit | draw | descriptors | memory sync | |---|---|---|---|---|---| | main | 42.7 (41.4-43.4) | 21.4 ms | 9.4 | 3.5 | 9.4 | | #2633 | 42.8 (40.6-43.8) | 19.9 ms | 7.6 | 2.7 | 9.4 | | #2644 | 42.6 (40.2-43.5) | 21.2 ms | 8.9 | 2.9 | 9.5 | | #2559 | 43.0 (42.3-43.8) | 20.1 ms | 7.7 | 2.7 | 9.6 | (replay columns: medians of the last 20 `a frame's replay time` lines; `GPU-bound wait` was 0.0 ms in all runs) - The log confirms the switch was on: `presents on the replay's queue wait for their copy first, the queue's lock let go`. - Frame interpolation stayed even: 424 of 426 frames 9-12 ms apart (main: 426 of 426). - The lower `draw` time is within run-to-run noise: #2559, which changes only GPU barriers, shows the same drop. With 2x interpolation, the present lock does not seem to be what limits the frame on this machine; memory sync (~9.5 ms) is the largest part of the replay in every run. - No device lost in any run, and no visual problem seen while playing. <!-- github-sync:c:6826488840 -->
Commenting is not possible because the repository is archived.
Reviewers
No reviewers
Labels
Clear labels   
accessibility
Barrier affecting people with disabilities

  
autorelease: pending

   
autorelease: tagged

   
bug
Something isn't working

  
dependencies
Pull requests that update a dependency file

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
github_actions
Pull requests that update GitHub Actions code

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
question
Further information is requested

  
testing wanted

   
wontfix
This will not be worked on

No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
2 participants
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!2633
No description provided.