fix(vk): the start-up screen counts the compute pipelines and says when it writes the pipeline cache #721

Merged

HumanBean merged 1 commit from HumanBean/Longshot:fix/startup-wait-at-100 into main 2026-11-15 06:17:02 +00:00

Conversation 0 Commits 1 Files changed 6 +53 -7

HumanBean commented 2026-11-15 06:16:19 +00:00

Owner

• Copy link
• Copy Markdown

Type: fix · Risk: low · Tested on: none yet (game-free checks to run in CI) · Needs: Windows or Linux, a GPU with mesh shaders (any NVIDIA RTX, RDNA2+), a first start after a preparation

Why

On the first start after the shaders were prepared, the start-up screen can sit at Loading pipelines, 100%, every pipeline counted and "a few seconds left", for a long while before the game comes up. It isn't a hang, but it looks like one. The screen had stopped counting before the work was done: what it still did after that wasn't shown. Fixes #714.

How to reproduce

Seen on: v3.0.0-rc.4, reported on Discord (GPU, driver and OS not known yet). Read off the code: the path runs where programs load when the game makes them (RX_VK_LOAD=create, the default on GPUs with mesh shaders).
Settings and switches: defaults
Steps: prepare the shaders (the Builder or the launcher), then start the game: the first start after the preparation builds the noted pipelines into the pipeline cache (precompile_warm).
Expected: once the bar reads 100%, the screen soon moves on to "Starting the game".
Actual: after the noted pipelines, precompile_warm builds every kept compute pipeline and then writes the whole pipeline cache (a GB and more). Through both the screen shows "32,623 / 32,623 pipelines", 100%, "a few seconds left": the compute pipelines were reported as progress(total, total), and the write isn't counted at all.

What changed

The compute pipelines the warm builds are now in its progress total from the start, so the bar holds under 100% while they're built and the time left covers them. Once the bar is full, the screen says what the start is still doing in place of "a few seconds left": "Saving the pipeline cache" while the cache is written, and "Getting the game ready" for anything else left (precompile_at_create, the threads ending).

• vk (gpu/vk/vk_draw.cpp, precompile_warm): program_cache_compute_keys() is taken before the noted pipelines (it is an in-memory index), and progress is reported over all_n = notes + compute pipelines. The compute pipelines are still only built once every note is done. The forced pipeline_cache_save(true) is bracketed by a flag, prepare_saving() (declared in vk_internal.h), and its time is logged: vk: precompile: the pipeline cache written out in N s.
• start-up screen (gpu/vk/vk_progress.h): StartupState::saving, and waiting_text() choosing the text right under the bar. gpu/vk/vk_main.cpp's painter fills saving from prepare_saving().
• tests: tests/test_startup_progress.py checks the new texts (100% counted, saving, and the time left while there is work counted). tests/test_warm_bounded.py checks that the warm counts its compute pipelines in the total and flags the cache's write.

Measurements

Verdict: not measured yet. The wait itself isn't shortened: the same work is now counted and named on the screen. What's left to measure is that the bar now holds under 100% until the compute pipelines are built, and how long the cache write takes (the new log line).

Flags and settings

None

Testing

Tested: nothing yet. The change is read against the code paths. Per this PC's rules the checks aren't run here: python -I -B tests/run_all.py is left to the forge's CI.

Not tested: a build on either platform; a start in the game; the --prepare-shaders run (the Builder's), whose bar now also counts the compute pipelines in its last part.

Must be tested:

• Linux or Windows, a GPU with mesh shaders (NVIDIA RTX, RDNA2 or newer), on a build of this PR: prepare the shaders, then start the game once. Expect the bar to stay under 100% while the log shows vk: compute pipelines: N of M, then "Saving the pipeline cache" under the bar, then "Starting the game". The log should have vk: precompile: the pipeline cache written out in N s (Test Farm: @Beanstalk the first start after preparing the shaders, watching the start-up screen at its end, and the log lines vk: precompile:)
• Any GPU: a start with the caches already built, expecting the screen to go as before, with no "Saving the pipeline cache" (by hand or Test Farm).

Risks

What could break: only the start-up screen's numbers and texts, and the Builder's progress bar's last part (now larger by the compute pipelines). What's built and when is unchanged.

Turning it off: revert the commit.

Compatibility: Nothing changes: no file format, cache, option or MKWVK_API_VERSION change.

Issues

Fixes #714

Checklist

Everyone

• One topic.
• The title is a Conventional Commit (type(scope): description) of the status line's type.
• Why gives the reason plainly and links the issues that fit (the tracker searched).
• Measurements has a verdict, or one line saying why there is nothing to measure. (not measured yet: needs a start in the game)
• Testing names what was tested, what wasn't, and what must still be tested, where and how.
• Rebased on current main.
• python -I -B tests/run_all.py passes (any failure that also fails on main is named). (not run on this PC: waiting for CI)
• No game files, dumps, build output or generated files.
• third_party/ untouched (a new folder with a PROVENANCE.md instead).
• The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

When it applies

• AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
• Screenshots of the same spot, captioned like the Measurements columns, for a change that shows on screen. (needs the run in the game above)
• A game-free test added for the fix, failing on main and passing here. (added; it fails on main by reading it, since the checks look for code main doesn't have; passing here waits for CI)
• A check under tests/ that reads changed source updated in this PR, not weakened.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (portable C++ only, no paths; the builds wait for CI)

🤖 Generated with Claude Code

**Type:** fix · **Risk:** low · **Tested on:** none yet (game-free checks to run in CI) · **Needs:** Windows or Linux, a GPU with mesh shaders (any NVIDIA RTX, RDNA2+), a first start after a preparation ## Why On the first start after the shaders were prepared, the start-up screen can sit at **Loading pipelines**, 100%, every pipeline counted and "a few seconds left", for a long while before the game comes up. It isn't a hang, but it looks like one. The screen had stopped counting before the work was done: what it still did after that wasn't shown. Fixes [#714](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/714). ## How to reproduce **Seen on:** v3.0.0-rc.4, reported on Discord (GPU, driver and OS not known yet). Read off the code: the path runs where programs load when the game makes them (`RX_VK_LOAD=create`, the default on GPUs with mesh shaders). **Settings and switches:** defaults **Steps:** prepare the shaders (the Builder or the launcher), then start the game: the first start after the preparation builds the noted pipelines into the pipeline cache (`precompile_warm`). **Expected:** once the bar reads 100%, the screen soon moves on to "Starting the game". **Actual:** after the noted pipelines, `precompile_warm` builds every kept compute pipeline and then writes the whole pipeline cache (a GB and more). Through both the screen shows "32,623 / 32,623 pipelines", 100%, "a few seconds left": the compute pipelines were reported as `progress(total, total)`, and the write isn't counted at all. ## What changed The compute pipelines the warm builds are now in its progress total from the start, so the bar holds under 100% while they're built and the time left covers them. Once the bar is full, the screen says what the start is still doing in place of "a few seconds left": "Saving the pipeline cache" while the cache is written, and "Getting the game ready" for anything else left (`precompile_at_create`, the threads ending). - vk (`gpu/vk/vk_draw.cpp`, `precompile_warm`): `program_cache_compute_keys()` is taken before the noted pipelines (it is an in-memory index), and progress is reported over `all_n = notes + compute pipelines`. The compute pipelines are still only built once every note is done. The forced `pipeline_cache_save(true)` is bracketed by a flag, `prepare_saving()` (declared in `vk_internal.h`), and its time is logged: `vk: precompile: the pipeline cache written out in N s`. - start-up screen (`gpu/vk/vk_progress.h`): `StartupState::saving`, and `waiting_text()` choosing the text right under the bar. `gpu/vk/vk_main.cpp`'s painter fills `saving` from `prepare_saving()`. - tests: `tests/test_startup_progress.py` checks the new texts (100% counted, saving, and the time left while there is work counted). `tests/test_warm_bounded.py` checks that the warm counts its compute pipelines in the total and flags the cache's write. ## Measurements **Verdict:** not measured yet. The wait itself isn't shortened: the same work is now counted and named on the screen. What's left to measure is that the bar now holds under 100% until the compute pipelines are built, and how long the cache write takes (the new log line). ### Flags and settings None ## Testing **Tested:** nothing yet. The change is read against the code paths. Per this PC's rules the checks aren't run here: `python -I -B tests/run_all.py` is left to the forge's CI. **Not tested:** a build on either platform; a start in the game; the `--prepare-shaders` run (the Builder's), whose bar now also counts the compute pipelines in its last part. **Must be tested:** - Linux or Windows, a GPU with mesh shaders (NVIDIA RTX, RDNA2 or newer), on a build of this PR: prepare the shaders, then start the game once. Expect the bar to stay under 100% while the log shows `vk: compute pipelines: N of M`, then "Saving the pipeline cache" under the bar, then "Starting the game". The log should have `vk: precompile: the pipeline cache written out in N s` (Test Farm: @Beanstalk the first start after preparing the shaders, watching the start-up screen at its end, and the log lines `vk: precompile:`) - Any GPU: a start with the caches already built, expecting the screen to go as before, with no "Saving the pipeline cache" (by hand or Test Farm). ## Risks **What could break:** only the start-up screen's numbers and texts, and the Builder's progress bar's last part (now larger by the compute pipelines). What's built and when is unchanged. **Turning it off:** revert the commit. **Compatibility:** Nothing changes: no file format, cache, option or `MKWVK_API_VERSION` change. ## Issues Fixes [#714](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/714) ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [ ] Measurements has a verdict, or one line saying why there is nothing to measure. (not measured yet: needs a start in the game) - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. - [x] Rebased on current `main`. - [ ] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). (not run on this PC: waiting for CI) - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### When it applies - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [ ] Screenshots of the same spot, captioned like the Measurements columns, for a change that shows on screen. (needs the run in the game above) - [ ] A game-free test added for the fix, failing on `main` and passing here. (added; it fails on `main` by reading it, since the checks look for code main doesn't have; passing here waits for CI) - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (portable C++ only, no paths; the builds wait for CI) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean added 1 commit 2026-11-15 06:16:19 +00:00

fix(vk): the start-up screen counts the compute pipelines and says when it writes the pipeline cache ... c76510c8d7

On the first start after a preparation (RX_VK_LOAD=create), precompile_warm built every
kept compute pipeline and then wrote the whole pipeline cache while the screen already
read every pipeline done, 100%, "a few seconds left". The compute pipelines are now in
the progress's total from the start, the cache's write shows "Saving the pipeline
cache", and anything else left once the bar is full shows "Getting the game ready"
in place of the time left.

Fixes #714

Co-Authored-By: Claude Opus 5.5 <[email protected]>

HumanBean changed title from WIP: fix(vk): the start-up screen counts the compute pipelines and says when it writes the pipeline cache to fix(vk): the start-up screen counts the compute pipelines and says when it writes the pipeline cache 2026-11-15 06:16:57 +00:00

HumanBean merged commit 70087604b7 into main 2026-11-15 06:17:02 +00:00

HumanBean deleted branch fix/startup-wait-at-100 2026-11-15 06:17:02 +00:00

HumanBean referenced this pull request from a commit 2026-11-15 06:17:04 +00:00

fix(vk): the start-up screen counts the compute pipelines and says when it writes the pipeline cache (#721)

HumanBean referenced this pull request 2026-11-15 06:22:28 +00:00

Game: the start sometimes sits at 100% on Loading pipelines before going on to the game #714

mooki referenced this pull request 2026-11-15 13:10:15 +00:00

fix(vk): closing the game while its shaders are prepared no longer counts as a crash #428

zeldaootr referenced this pull request 2026-11-15 13:32:26 +00:00

fix(vk): shader preparation shows progress while it builds compute pipelines #555

zeldaootr referenced this pull request 2026-11-15 16:41:53 +00:00

fix(vk): a recording without a draw stream is submitted instead of crashing #552

zeldaootr referenced this pull request 2026-11-15 17:14:44 +00:00

fix(vk): shader preparation shows progress while it builds compute pipelines #555

HumanBean referenced this pull request 2026-11-15 18:45:22 +00:00

fix(vk): the start-up bar counts the compute pipelines, not 100% through them #256

gab9281 referenced this pull request 2026-11-15 18:45:32 +00:00

fix(vk): the start-up bar counts the compute pipelines, not 100% through them #256

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area/accessibility

Barriers for people with disabilities

  

area/audio

Sound and music

  

area/input

Controllers, keyboard, mouse

  

area/install

Installing, updating, building from your game

  

area/menu

In-game menu and settings

  

area/renderer

Vulkan renderer, shaders, effects

  

area/saves

Save files

  

area/tooling

Developer tools: scripts, CI, build and release tooling

  

area/upscaling

DLSS, FSR, frame generation

  

beanstalk: approved @ 1697603

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 2c5a62e

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 4fd82b7

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 64d6d09

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 6f91fae

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 70a78f9

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 8015c9a

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 8d361dc

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ 9d8356e

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ abf2227

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ d82f202

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ e5f1e40

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: approved @ ee8ab5f

Set by Beanstalk for show; the farm's database is what counts

  

ci: approved

A maintainer approved CircleCI for this fork PR (sticky; removed after 14 quiet days)

  

good first issue

A good start for a new contributor

  

gpu/amd

AMD GPUs

  

gpu/igpu

Integrated GPUs

  

gpu/intel

Intel GPUs

  

gpu/nvidia

NVIDIA GPUs

  

help wanted

Extra hands or knowledge wanted

  

kind

bug

Something doesn't work as it should

  

kind

chore

Build, CI, dependencies, tidying

  

kind

docs

Documentation

  

kind

feature

A new feature or an improvement

  

kind

performance

Frame rate, frame time, loading, memory

  

kind

question

A question rather than a change

  

needs measurements

Waiting for before/after measurements

  

platform/linux

Affects Linux (a change for every system carries both Windows and Linux)

  

platform/macos

macOS (Apple silicon or Intel Macs)

  

platform/steam-deck

Steam Deck

  

platform/windows

Affects Windows (a change for every system carries both Windows and Linux)

  

preview

Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  

priority

critical

Crashes, data loss, or blocks most players

  

priority

high

Important: next in line

  

priority

low

Nice to have

  

regression

Worked in an earlier build, broken in a newer one: highest priority, above other bugs

  

risk

high

Broad or core change: the renderer, defaults on many systems, saves, installs, security

  

risk

low

Small, contained change: little can break

  

risk

medium

Changes behaviour in one area, or a default on some systems

  

status

blocked

Waits on something else first

  

status

confirmed

Reproduced or agreed on

  

status

duplicate

Already reported or proposed

  

status

invalid

Not a problem in this project

  

status

needs-info

Waiting for more information from the reporter

  

status

wontfix

Will not be worked on

  

testing wanted

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

  

ci: approved

No labels

area/accessibility

area/audio

area/input

area/install

area/menu

area/renderer

area/saves

area/tooling

area/upscaling

beanstalk: approved @ 1697603

beanstalk: approved @ 2c5a62e

beanstalk: approved @ 4fd82b7

beanstalk: approved @ 64d6d09

beanstalk: approved @ 6f91fae

beanstalk: approved @ 70a78f9

beanstalk: approved @ 8015c9a

beanstalk: approved @ 8d361dc

beanstalk: approved @ 9d8356e

beanstalk: approved @ abf2227

beanstalk: approved @ d82f202

beanstalk: approved @ e5f1e40

beanstalk: approved @ ee8ab5f

ci: approved

good first issue

gpu/amd

gpu/igpu

gpu/intel

gpu/nvidia

help wanted

kind

bug

kind

chore

kind

docs

kind

feature

kind

performance

kind

question

needs measurements

platform/linux

platform/macos

platform/steam-deck

platform/windows

preview

priority

critical

priority

high

priority

low

regression

risk

high

risk

low

risk

medium

status

blocked

status

confirmed

status

duplicate

status

invalid

status

needs-info

status

wontfix

testing wanted

ci: approved

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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!721

No description provided.