MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
3
0
Fork
You've already forked Longshot
 10
Code Issues 25 Pull requests 51 Projects 1 Releases Packages Wiki Activity Actions 85

docs: #2789 measured against Kokiri camera turns on a 9800X3D / RTX 4070 Ti #16

Open
TrashPanda wants to merge 2 commits from TrashPanda/Longshot:docs/kokiri-turn-2789 into main
pull from: TrashPanda/Longshot:docs/kokiri-turn-2789
merge into: MagicBeanDev:main
Conversation 3 Commits 2 Files changed 2 +2 -1
TrashPanda commented 2026-11-12 23:11:08 +00:00
First-time contributor

Why

The worklist says the next step for the Kokiri Forest camera-turn stutter is to remove a wait in take_capture. Hookshot #2789 removes it, but on a fast PC that wait turns out to be zero, so the row should point at the PCs where it isn't. This PR records that measurement. It changes no code.

What changed

  • docs/tested-configurations.md: a row for the A/B of #2789 below.
  • docs/worklist.md: the Kokiri row's next step is now #2789's A/B on a PC where the wait shows (the reporter's 14700KF, a Steam Deck), and finding the 20-26 ms frames on fast PCs.

Measurements

Before: main @ 012dfc51, the renderer with Hookshot #2789 (ed5c6549) applied, RX_VK_CAPTURE_GPU_LATE=0 (#2789's switch off: the old wait)
After: the same build, RX_VK_CAPTURE_GPU_LATE=1 (#2789's GPU copy)
Hardware: RTX 4070 Ti 12 GB, NVIDIA 595.99.02, Ryzen 7 9800X3D, 32 GB, Ubuntu 26.04.1 (kernel 7.0)
Scene: Kokiri Forest, the test save's spawn point; headless, the test folder's settings, 60 fps cap
Method: one warm-up run, then 4 runs alternating off, on, off, on. Each run has 600 settled frames, then 1,800 frames turning the camera right (scripted input). Numbers are from RX_VK_FRAME_LOG over the turning window only; the table gives the median of the 2 runs each way.

Before (off) After (on)
mean frame time 16.67 ms 16.67 ms
1% low 47.0 fps (46.6, 47.4) 47.7 fps (47.2, 48.2)
frames over 20 ms of 1,804 22.5 (22, 23) 21.5 (23, 20)
frames over 33 ms 0 0
worst frame 24.6 ms (25.5, 23.7) 24.3 ms (26.3, 22.2)
take_capture's GPU wait 0.000 ms (0-1 of 600 takes) 0.000 ms (0 of 600 takes) 
off: vk: a capture taken (ms): all 0.004; late pages copied on the GPU 0.000 (0 of 600 takes), GPU wait for them 0.000 (1 takes), ...
on:  vk: a capture taken (ms): all 0.004; late pages copied on the GPU 0.000 (0 of 600 takes), GPU wait for them 0.000 (0 takes), ...

The differences are within run-to-run noise. On this PC #2789 does not help, because the wait it removes is not there. The same numbers are on the Hookshot PR: https://github.com/NotRexed/Hookshot/pull/2789#issuecomment-6838492536

Not tested

#2789's newer head (c898b45d). Any PC where the wait shows up: a slower CPU such as the 14700KF from the report, a Steam Deck, Windows, AMD or Intel GPUs. I have asked the team for the GPU wait for them figure from such a PC.

Screenshots

Nothing on screen.

Issues

See #2789 (Hookshot).

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main (main merged in at d4a69456; no force-push).
  • python -I -B tests/run_all.py: 457 passed, 2 failed, 69 skipped. The 2 failures are this PC's environment: test_lift_cache (the lift scripts' imports) and test_updater_asset_digest. This PR is docs only.
  • Tested in the game (the measured runs above). The PR itself is docs only.
  • Measurements before and after, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
  • No game files, dumps, build output or generated files.
  • third_party/ untouched.
  • AI assistance recorded with a Co-Authored-By: trailer.
  • The license is OK.

If applicable

  • A row in docs/tested-configurations.md for each measured run.
  • Docs updated.

🤖 Generated with Claude Code

## Why The worklist says the next step for the Kokiri Forest camera-turn stutter is to remove a wait in `take_capture`. Hookshot #2789 removes it, but on a fast PC that wait turns out to be zero, so the row should point at the PCs where it isn't. This PR records that measurement. It changes no code. ## What changed - `docs/tested-configurations.md`: a row for the A/B of #2789 below. - `docs/worklist.md`: the Kokiri row's next step is now #2789's A/B on a PC where the wait shows (the reporter's 14700KF, a Steam Deck), and finding the 20-26 ms frames on fast PCs. ## Measurements Before: main @ 012dfc51, the renderer with Hookshot #2789 (ed5c6549) applied, `RX_VK_CAPTURE_GPU_LATE=0` (#2789's switch off: the old wait) After: the same build, `RX_VK_CAPTURE_GPU_LATE=1` (#2789's GPU copy) Hardware: RTX 4070 Ti 12 GB, NVIDIA 595.99.02, Ryzen 7 9800X3D, 32 GB, Ubuntu 26.04.1 (kernel 7.0) Scene: Kokiri Forest, the test save's spawn point; headless, the test folder's settings, 60 fps cap Method: one warm-up run, then 4 runs alternating off, on, off, on. Each run has 600 settled frames, then 1,800 frames turning the camera right (scripted input). Numbers are from `RX_VK_FRAME_LOG` over the turning window only; the table gives the median of the 2 runs each way. | | Before (off) | After (on) | |---|---|---| | mean frame time | 16.67 ms | 16.67 ms | | 1% low | 47.0 fps (46.6, 47.4) | 47.7 fps (47.2, 48.2) | | frames over 20 ms of 1,804 | 22.5 (22, 23) | 21.5 (23, 20) | | frames over 33 ms | 0 | 0 | | worst frame | 24.6 ms (25.5, 23.7) | 24.3 ms (26.3, 22.2) | | `take_capture`'s GPU wait | 0.000 ms (0-1 of 600 takes) | 0.000 ms (0 of 600 takes) | ``` off: vk: a capture taken (ms): all 0.004; late pages copied on the GPU 0.000 (0 of 600 takes), GPU wait for them 0.000 (1 takes), ... on: vk: a capture taken (ms): all 0.004; late pages copied on the GPU 0.000 (0 of 600 takes), GPU wait for them 0.000 (0 takes), ... ``` The differences are within run-to-run noise. On this PC #2789 does not help, because the wait it removes is not there. The same numbers are on the Hookshot PR: https://github.com/NotRexed/Hookshot/pull/2789#issuecomment-6838492536 ## Not tested #2789's newer head (c898b45d). Any PC where the wait shows up: a slower CPU such as the 14700KF from the report, a Steam Deck, Windows, AMD or Intel GPUs. I have asked the team for the `GPU wait for them` figure from such a PC. ## Screenshots Nothing on screen. ## Issues See #2789 (Hookshot). ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main` (main merged in at d4a69456; no force-push). - [x] `python -I -B tests/run_all.py`: 457 passed, 2 failed, 69 skipped. The 2 failures are this PC's environment: `test_lift_cache` (the lift scripts' imports) and `test_updater_asset_digest`. This PR is docs only. - [x] Tested in the game (the measured runs above). The PR itself is docs only. - [x] Measurements before and after, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched. - [x] AI assistance recorded with a `Co-Authored-By:` trailer. - [x] The license is OK. ### If applicable - [x] A row in `docs/tested-configurations.md` for each measured run. - [x] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
HumanBean commented 2026-11-12 23:13:45 +00:00
Owner

Has this been tested and shown to actually help

Has this been tested and shown to actually help
HumanBean commented 2026-11-12 23:33:21 +00:00
Owner

@TrashPanda use the new issue template please!

@TrashPanda use the new issue template please!
TrashPanda commented 2026-11-12 23:57:39 +00:00
Author
First-time contributor

@hckrman101 It's tested, and it shows the opposite: on this PC #2789 doesn't help, because the wait it removes is already 0 ms (0 of 600 frames wait). That's what this PR records. It changes no code: it adds the measurement and moves the Kokiri row's next step to a PC where the wait does show. 2 runs each way, interleaved: 1% low 47.0 vs 47.7 fps, frames over 20 ms 22.5 vs 21.5, within noise. The description now follows the new template, with the full table and log lines. I also merged main in.

@hckrman101 It's tested, and it shows the opposite: on this PC #2789 doesn't help, because the wait it removes is already 0 ms (0 of 600 frames wait). That's what this PR records. It changes no code: it adds the measurement and moves the Kokiri row's next step to a PC where the wait does show. 2 runs each way, interleaved: 1% low 47.0 vs 47.7 fps, frames over 20 ms 22.5 vs 21.5, within noise. The description now follows the new template, with the full table and log lines. I also merged main in.
This pull request has changes conflicting with the target branch.
  • docs/tested-configurations.md
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u 'docs/kokiri-turn-2789:TrashPanda-docs/kokiri-turn-2789'
git switch 'TrashPanda-docs/kokiri-turn-2789'
Sign in to join this conversation.
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

  
needs measurements
Waiting for before/after measurements

  
question
Further information is requested

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

  
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
needs measurements
question
testing wanted
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
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/Longshot!16
No description provided.