fix(vk): the load default's safety net counts only what the loads found in no cache #2884

Closed
github-sync wants to merge 1 commit from github/pr/2884 into main
Owner

@hckrman101 opened this pull request on GitHub · 2026-11-12 18:26 UTC · original
Merged on GitHub in 15d4ae8c61

What

The safety net that takes an install back to RX_VK_LOAD=start now counts only what loads at create calls are responsible for. Since #2869 it also counted every left-out draw and every pipeline wait of a session, which a healthy install reaches in ordinary play.

Status: built and unit-tested. Not yet run in a game.

Why

Since #2869 a session with over 2,000 draws left out, or over a second of waits for shaders or pipelines, writes hookshot_load_start.txt and the next start is back on RX_VK_LOAD=start.

Those counters are not this mode's alone. A draw of a state no list names is left out in start mode just the same. One session on a healthy prepared folder (RTX 3090, a new game's opening, about 8 minutes) had 1,906 draws left out and 353 ms of waits, with every listed pipeline answered by the caches and nothing compiled. A slightly longer session would have turned loads at create calls off for an install that had nothing wrong.

Change

  • load_default::caches_lacked: the rule now reads the listed pipelines (noted graphics pipelines and compute pipelines) that a load asked the caches for and no cache had. Those are the ones compiled in play because of this mode. Over 500 in a session trips it.
  • The left-out and pipeline-wait inputs are removed from the rule.
  • The first-use load-wait rule (100 ms at once, 500 ms in all) is unchanged.

Numbers behind 500:

session listed pipelines no cache had
every tour where the caches held the preparation's work (RTX 3090) 0
a GPU without mesh shaders (RX 580), at most 39
two sessions of a folder whose caches did not answer 4,189 and 5,384

Tests

  • load_default_test: 0, 39 and 500 do not trip; 4,189 and 5,384 do. A session's left-out draws are no input at all.
  • test_load_default.py: a source check that the note reads the two load counters and none of the left-out ones.
  • The renderer built on Linux on the previous main; after the rebase onto current main (menu and frame generation files only, no overlap) the test passes but the renderer was not rebuilt.
  • The full test suite was not run.

Not tested

  • No game run.
  • A session that is rough only through pipelines no list names is not caught by this rule, by design: #2882 is for those, in both modes.
> [@hckrman101](https://github.com/hckrman101) opened this pull request on GitHub · 2026-11-12 18:26 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2884) > **Merged on GitHub** in https://git.magicbean.dev/MagicBeanDev/Hookshot/commit/15d4ae8c6188bd681ab0547e4536cb2ad3fe6dc1 ## What The safety net that takes an install back to `RX_VK_LOAD=start` now counts only what loads at create calls are responsible for. Since #2869 it also counted every left-out draw and every pipeline wait of a session, which a healthy install reaches in ordinary play. **Status: built and unit-tested. Not yet run in a game.** ## Why Since #2869 a session with over 2,000 draws left out, or over a second of waits for shaders or pipelines, writes `hookshot_load_start.txt` and the next start is back on `RX_VK_LOAD=start`. Those counters are not this mode's alone. A draw of a state no list names is left out in start mode just the same. One session on a healthy prepared folder (RTX 3090, a new game's opening, about 8 minutes) had 1,906 draws left out and 353 ms of waits, with every listed pipeline answered by the caches and nothing compiled. A slightly longer session would have turned loads at create calls off for an install that had nothing wrong. ## Change - `load_default::caches_lacked`: the rule now reads the listed pipelines (noted graphics pipelines and compute pipelines) that a load asked the caches for and no cache had. Those are the ones compiled in play because of this mode. Over 500 in a session trips it. - The left-out and pipeline-wait inputs are removed from the rule. - The first-use load-wait rule (100 ms at once, 500 ms in all) is unchanged. Numbers behind 500: | session | listed pipelines no cache had | |---|---| | every tour where the caches held the preparation's work (RTX 3090) | 0 | | a GPU without mesh shaders (RX 580), at most | 39 | | two sessions of a folder whose caches did not answer | 4,189 and 5,384 | ## Tests - `load_default_test`: 0, 39 and 500 do not trip; 4,189 and 5,384 do. A session's left-out draws are no input at all. - `test_load_default.py`: a source check that the note reads the two load counters and none of the left-out ones. - The renderer built on Linux on the previous main; after the rebase onto current main (menu and frame generation files only, no overlap) the test passes but the renderer was not rebuilt. - The full test suite was not run. ## Not tested - No game run. - A session that is rough only through pipelines no list names is not caught by this rule, by design: #2882 is for those, in both modes. <!-- github-sync:item:2884 -->
Since #2869 a session with over 2,000 draws left out, or over a second of waits for
shaders or pipelines, took the install back to RX_VK_LOAD=start. Those counters are
not this mode's alone: a draw of a state no list names is left out in start mode just
the same. A healthy prepared folder had 1,906 of them, and 353 ms of waits, in eight
minutes of a new game's opening, so a slightly longer session would have turned loads
at create calls off for an install that had nothing wrong.

The rule now counts what loads at create calls are responsible for: the listed
pipelines (noted graphics pipelines, compute pipelines) a load asked the caches for
and no cache had, which are then compiled in play. Over 500 in a session trips it:
0 in every tour where the caches held the preparation's work (39 at most on a GPU
without mesh shaders), 4,189 and 5,384 in the two sessions of the folder whose caches
did not answer. The waits of first uses for loads are counted as before.

Co-Authored-By: Claude Fable 5.2 <[email protected]>
github-sync closed this pull request 2026-11-12 19:03:23 +00:00
Commenting is not possible because the repository is archived.
No description provided.