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

Closed

zeldaootr wants to merge 2 commits from zeldaootr/Longshot:precompile-warm-compute-progress into main

pull from: zeldaootr/Longshot:precompile-warm-compute-progress

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 6 Commits 2 Files changed 2 +220 -1

zeldaootr commented 2026-11-14 19:17:33 +00:00

Contributor

• Copy link
• Copy Markdown

Why

On GPUs with mesh shaders (the Steam Deck among them), the shader preparation's progress stood still for the whole compute pass, which can take minutes, so the start-up screen looked frozen and the build's --prepare-shaders watchdog could stop a run that was still working and skip preparation for good.

What changed

• vk: precompile_warm() in gpu/vk/vk_draw.cpp reports the compute pipelines as part of the progress (total + computes_done of total + computes.size()) instead of a full count that stands still.
• tests: tests/test_precompile_warm_progress.py compiles precompile_warm from the source with stand-ins for the driver and the files, and checks that the count moves through the compute pass and that the watchdog (prepare_watchdog in gpu/vk/vk_main.cpp), fed as that run feeds it, lets a slow but moving pass finish.

Flags and settings

None.

Measurements

Not measured in the game yet: this is the game-free proof only, and the PR stays WIP until the Steam Deck run (a cold preparation, the bar and the @@progress lines during the compute pass).

main: 7ff5256e (2026-11-14)
this PR: precompile-warm-compute-progress @ 8f003d46
Hardware: Linux x86-64 server (no GPU or game used)
Scene: none (game-free check)
Method: python3 -I -B tests/test_precompile_warm_progress.py --cxx g++ at the test-only commit bb480287 (main plus the test) and at 8f003d46, twice each, alternating
How to reproduce: check out each commit and run the command above

	main @ 7ff5256e (with the test, bb480287)	this PR @ 8f003d46
compute pipelines counted in the progress (both runs the same)	no	yes

bb480287: precompile_warm: the compute pipelines are not counted as progress (exit 7) / CHECK failed line 337: last_total == (size_t)(notes_n + computes_n) (both runs)
8f003d46: PASS precompile_warm: the compute pipelines move the progress / PASS precompile_warm: the watchdog lets a slow, moving compute pass finish (exit 0, both runs)

Testing

Tested: Linux x86-64, game-free. The new test fails on the test-only commit bb480287 and passes at 8f003d46, twice each, alternating (python3 -I -B tests/test_precompile_warm_progress.py --cxx g++). On land/integration 27553c83 (main 7ff5256e with this PR and twelve other fixes merged), the thirteen fixes' own tests and the checks their fix commits edit pass, 16 of 16. The full python3 -I -B tests/run_all.py has not run on 7ff5256e yet (PENDING). On the previous main, 1be60eae, it ran on an integration branch with this PR and eight of the others (under nice -n 10, with the Vulkan headers): 517 passed, 8 failed, 50 skipped, against 516 passed, 5 failed, 50 skipped on that main. The five failing on main failed on both (test_bake_portability, test_lift_cache, test_walk_key, test_pipeline_cache_save, nx2/test_texture_init_barrier); the other three were timeouts on a loaded PC that passed 3 of 3 alone (test_recorder_sync, test_fpx_sticky, test_appimage_package_retry).

Steam Deck run (a tester's, test request T-2SXU: pass): dukenheimer ran this PR's head 8f003d46 (in a build of main 7ff5256e with #550 to #558 merged) on a Steam Deck OLED, SteamOS 3.9.5, three cold starts in new game folders through Steam in Game Mode; the comment of 2026-11-14 22:48 on this PR has the table and the pictures. On a Steam Deck the programs load before the title by default, and then the first start never runs the pass this PR changes (precompile_warm); with RX_VK_LOAD=create it runs: 5.3 s and 7.3 s (the compute pipelines 1.4 s and 1.8 s), and the count keeps moving through it: 21,057 of 24,448, then the total grows to 28,506 and the count goes 24,675, 26,484, 28,329, 28,506. No STOPPED line in any start. The count's fraction steps back when the compute pass starts while the percentage shown does not (86%, 92%, 99%), and "About 4 min left" stayed up until the last second of a 7 s pass: a stale estimate, left for a follow-up. Not reproduced on the Deck: a compute pass longer than the 300 s watchdog, which is the case this fixes (the game-free test forces it).

Not tested: A cold shader preparation in the game: the bar's movement and the --prepare-shaders build's watchdog with real driver timings.

Needs other testers: None

Screenshots

The bar through the compute pass on a Steam Deck OLED, this PR @ 8f003d46 with RX_VK_LOAD=create (the tester's capture, 6 of 17 pictures); on main the count stands at its full value for the whole pass, which the game-free test shows:

Risk and rollback

The total grows when the compute pass starts, so the bar, which had reached the end of the graphics pipelines, steps back a little (to graphics / (graphics + compute)) and then moves to the end; before, it sat at full. Nothing else reads the counts. Reverting the fix commit restores the old behaviour.

Reviewer notes

None.

Issues

None filed.

Checklist

For everyone

• One topic.
• The title is a Conventional Commit (type(scope): description).
• Rebased on current main.
• python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above). Run on the combined branch (main @ 7ff5256e with this fix and twelve others merged, 27553c83): 523 passed, 6 failed, 50 skipped. Five fail on main @ 7ff5256e too: test_bake_portability, test_lift_cache, test_walk_key, test_cpm_discovery (#561 fixes it) and nx2/test_texture_init_barrier.py; the sixth, test_crash_record, is a timing check that passed 2 of 2 when run alone on that branch.
• Tested in the game, or what wasn't is named under Testing.
• Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
• Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. Game-free: the test at the test-only commit and at the tip, twice each, alternating. In the game: the tester's Steam Deck run above (this fix changes no frame rate; what was checked is the behaviour).
• 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.

If applicable

• AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
• A game-free test added for the fix, failing on main and passing here.
• Screenshots for a change that shows on screen.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Built on Linux for both, in the combined branch 27553c83: RX_VK_ONLY=1 RX_RELEASE=1 RX_TARGET=windows with llvm-mingw 20261104 linked longshot_vk.dll (sha256 25117493...), and the same without RX_TARGET linked longshot_vk.so; the changed file has no new warning under -Wall -Wextra on either platform against main.

## Why On GPUs with mesh shaders (the Steam Deck among them), the shader preparation's progress stood still for the whole compute pass, which can take minutes, so the start-up screen looked frozen and the build's `--prepare-shaders` watchdog could stop a run that was still working and skip preparation for good. ## What changed - vk: `precompile_warm()` in `gpu/vk/vk_draw.cpp` reports the compute pipelines as part of the progress (`total + computes_done` of `total + computes.size()`) instead of a full count that stands still. - tests: `tests/test_precompile_warm_progress.py` compiles `precompile_warm` from the source with stand-ins for the driver and the files, and checks that the count moves through the compute pass and that the watchdog (`prepare_watchdog` in `gpu/vk/vk_main.cpp`), fed as that run feeds it, lets a slow but moving pass finish. ## Flags and settings None. ## Measurements Not measured in the game yet: this is the game-free proof only, and the PR stays WIP until the Steam Deck run (a cold preparation, the bar and the `@@progress` lines during the compute pass). main: 7ff5256e (2026-11-14) this PR: precompile-warm-compute-progress @ 8f003d46 Hardware: Linux x86-64 server (no GPU or game used) Scene: none (game-free check) Method: `python3 -I -B tests/test_precompile_warm_progress.py --cxx g++` at the test-only commit bb480287 (main plus the test) and at 8f003d46, twice each, alternating How to reproduce: check out each commit and run the command above | | main @ 7ff5256e (with the test, bb480287) | this PR @ 8f003d46 | |---|---|---| | compute pipelines counted in the progress (both runs the same) | no | yes | ``` bb480287: precompile_warm: the compute pipelines are not counted as progress (exit 7) / CHECK failed line 337: last_total == (size_t)(notes_n + computes_n) (both runs) 8f003d46: PASS precompile_warm: the compute pipelines move the progress / PASS precompile_warm: the watchdog lets a slow, moving compute pass finish (exit 0, both runs) ``` ## Testing **Tested:** Linux x86-64, game-free. The new test fails on the test-only commit bb480287 and passes at 8f003d46, twice each, alternating (`python3 -I -B tests/test_precompile_warm_progress.py --cxx g++`). On `land/integration` 27553c83 (main 7ff5256e with this PR and twelve other fixes merged), the thirteen fixes' own tests and the checks their fix commits edit pass, 16 of 16. The full `python3 -I -B tests/run_all.py` has not run on 7ff5256e yet (PENDING). On the previous main, 1be60eae, it ran on an integration branch with this PR and eight of the others (under `nice -n 10`, with the Vulkan headers): 517 passed, 8 failed, 50 skipped, against 516 passed, 5 failed, 50 skipped on that main. The five failing on main failed on both (`test_bake_portability`, `test_lift_cache`, `test_walk_key`, `test_pipeline_cache_save`, `nx2/test_texture_init_barrier`); the other three were timeouts on a loaded PC that passed 3 of 3 alone (`test_recorder_sync`, `test_fpx_sticky`, `test_appimage_package_retry`). **Steam Deck run (a tester's, test request T-2SXU: pass):** dukenheimer ran this PR's head 8f003d46 (in a build of main 7ff5256e with #550 to #558 merged) on a Steam Deck OLED, SteamOS 3.9.5, three cold starts in new game folders through Steam in Game Mode; the comment of 2026-11-14 22:48 on this PR has the table and the pictures. On a Steam Deck the programs load before the title by default, and then the first start never runs the pass this PR changes (`precompile_warm`); with `RX_VK_LOAD=create` it runs: 5.3 s and 7.3 s (the compute pipelines 1.4 s and 1.8 s), and the count keeps moving through it: 21,057 of 24,448, then the total grows to 28,506 and the count goes 24,675, 26,484, 28,329, 28,506. No `STOPPED` line in any start. The count's fraction steps back when the compute pass starts while the percentage shown does not (86%, 92%, 99%), and "About 4 min left" stayed up until the last second of a 7 s pass: a stale estimate, left for a follow-up. Not reproduced on the Deck: a compute pass longer than the 300 s watchdog, which is the case this fixes (the game-free test forces it). **Not tested:** A cold shader preparation in the game: the bar's movement and the `--prepare-shaders` build's watchdog with real driver timings. **Needs other testers:** None ## Screenshots The bar through the compute pass on a Steam Deck OLED, this PR @ 8f003d46 with `RX_VK_LOAD=create` (the tester's capture, 6 of 17 pictures); on main the count stands at its full value for the whole pass, which the game-free test shows:  ## Risk and rollback The total grows when the compute pass starts, so the bar, which had reached the end of the graphics pipelines, steps back a little (to graphics / (graphics + compute)) and then moves to the end; before, it sat at full. Nothing else reads the counts. Reverting the fix commit restores the old behaviour. ## Reviewer notes None. ## Issues None filed. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). Run on the combined branch (`main` @ 7ff5256e with this fix and twelve others merged, 27553c83): 523 passed, 6 failed, 50 skipped. Five fail on `main` @ 7ff5256e too: `test_bake_portability`, `test_lift_cache`, `test_walk_key`, `test_cpm_discovery` (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/561 fixes it) and `nx2/test_texture_init_barrier.py`; the sixth, `test_crash_record`, is a timing check that passed 2 of 2 when run alone on that branch. - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. Game-free: the test at the test-only commit and at the tip, twice each, alternating. In the game: the tester's Steam Deck run above (this fix changes no frame rate; what was checked is the behaviour). - [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. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] Screenshots for a change that shows on screen. - [x] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. Built on Linux for both, in the combined branch 27553c83: `RX_VK_ONLY=1 RX_RELEASE=1 RX_TARGET=windows` with llvm-mingw 20261104 linked `longshot_vk.dll` (sha256 25117493...), and the same without `RX_TARGET` linked `longshot_vk.so`; the changed file has no new warning under `-Wall -Wextra` on either platform against `main`.

zeldaootr added 2 commits 2026-11-14 19:17:34 +00:00

test: precompile_warm counts its compute pipelines as progress, so the watchdog sees them move ... bb48028723

Assisted-by: Claude

fix(vk): precompile_warm reports its compute pipelines as progress instead of a full count that stands still ... 8f003d46e9

Assisted-by: Claude

zeldaootr commented 2026-11-14 19:31:09 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Filled in: the full game-free suite on the combined branch, the Windows and Linux builds, and the test request T-2SXU. Still work in progress until a Steam Deck run is in.

Filled in: the full game-free suite on the combined branch, the Windows and Linux builds, and the test request T-2SXU. Still work in progress until a Steam Deck run is in.

dukenheimer commented 2026-11-14 22:48:17 +00:00

Contributor

• Copy link
• Copy Markdown

Test request T-2SXU: pass

Hardware: Steam Deck OLED (AMD Custom APU 0932, RADV VANGOGH, 16 GB), Mesa 26.2.0-devel git-5c65d4fc31, SteamOS 3.9.5 (build
20261023.100), kernel 7.2.7-valve2.

Built from main 7ff5256e with #550 to #558 merged in order (all clean); this PR at its head 8f003d46. Built for x86-64-v3 with the
release play profile and LLVM 23.1.5. Each start was the first in a new game folder with no caches, started through Steam in Game
Mode, docked. Mesa's own shader cache was warm.

What I checked

On a Steam Deck the programs load before the title by default ("this GPU draws mesh programs through the compute fallback"), and then
the first start never runs the pass this PR changes (precompile_warm). So I made three cold starts:

start	load mode	step 1, the shader programs	step 2	start-up in all	STOPPED
1	default (start)	38,809 programs in 261.6 s	compute pipelines kept ready from the caches	267.2 s	none
2	RX_VK_LOAD=create	38,809 in 229.0 s	this PR's pass, 5.3 s (the compute ones 1.4 s)	236.6 s	none
3	RX_VK_LOAD=create	38,809 in 228.6 s	this PR's pass, 7.3 s (the compute ones 1.8 s), a picture every ~0.65 s	238.8 s	none

The bar during the compute pass (start 3, "Step 2 of 2 · Building pipelines", 6 of the 17 pictures):

• The count goes to 21,057 / 24,448 (the noted pipelines).
• When the compute pass starts, the total grows to 28,506 (24,448 + 4,058 compute programs), and the count keeps moving: 24,675,
  26,484, 28,329, 28,506 / 28,506.
• Then "Starting the game", and the title.
• The count's fraction steps back at that point (from 24,448 / 24,448 to 24,675 / 28,506), but the percentage shown doesn't: it reads
  86%, 92%, then 99% from 24,675 / 28,506 on.
• "About 4 min left" stayed up until the last second of a pass that took 7 s.

Neither of those is what this PR changes; I mention them because the request expects the bar to step back.

Log lines

vk: programs are loaded when the game makes them (create): RX_VK_LOAD=create (RX_VK_LOAD=create or start says which)
vk: prepared 38809 shader programs (46597 new, 70 failed, 9687 compute pipelines; 9691 compute variants, 775 programs with texture variants, 59 at the limit) in 228.6 s
vk: precompile: 24451 noted pipelines of 15565 programs and 9687 compute pipelines of 4058 compute programs built into the pipeline cache and let go (0 and 0 not made, 0 whose program variant is not kept), on 8 threads in 7.3 s (the compute ones 1.8 s)
vk: start-up: the shaders took 238.8 s

The default start (1):

vk: precompile: 18100 programs, 24448 graphics and 9691 compute pipelines, 2430 mesh fallback programs in 5167 ms (2232 ms of it the caches opened, the notes and programs read)
vk: precompile: compute pipelines: 9691 kept ready (9691 from the pipeline caches, 0 compiled now), 0 not made
vk: start-up: the shaders took 267.2 s

None of the three starts logged a compute pipelines: N of M pipelines progress line: the pass ended within the 10 s between them.

What this doesn't show. With Mesa's cache warm, the compute pass takes under 2 s here, far from the watchdog's 300 s, so these
starts show the count moving and finishing, not a stop avoided. I also tried a start with Mesa's cache empty as well. It reached 114
of 38,809 shader programs in about 2 minutes (the warm-cache starts were at about 18,000 by then), hours at that rate, so I stopped
it in step 1.

Test request T-2SXU: pass Hardware: Steam Deck OLED (AMD Custom APU 0932, RADV VANGOGH, 16 GB), Mesa 26.2.0-devel git-5c65d4fc31, SteamOS 3.9.5 (build 20261023.100), kernel 7.2.7-valve2. Built from main 7ff5256e with #550 to #558 merged in order (all clean); this PR at its head 8f003d46. Built for x86-64-v3 with the release play profile and LLVM 23.1.5. Each start was the first in a new game folder with no caches, started through Steam in Game Mode, docked. Mesa's own shader cache was warm. **What I checked** On a Steam Deck the programs load before the title by default ("this GPU draws mesh programs through the compute fallback"), and then the first start never runs the pass this PR changes (`precompile_warm`). So I made three cold starts: | start | load mode | step 1, the shader programs | step 2 | start-up in all | STOPPED | |---|---|---|---|---|---| | 1 | default (start) | 38,809 programs in 261.6 s | compute pipelines kept ready from the caches | 267.2 s | none | | 2 | `RX_VK_LOAD=create` | 38,809 in 229.0 s | this PR's pass, 5.3 s (the compute ones 1.4 s) | 236.6 s | none | | 3 | `RX_VK_LOAD=create` | 38,809 in 228.6 s | this PR's pass, 7.3 s (the compute ones 1.8 s), a picture every ~0.65 s | 238.8 s | none | **The bar during the compute pass** (start 3, "Step 2 of 2 · Building pipelines", 6 of the 17 pictures):  - The count goes to 21,057 / 24,448 (the noted pipelines). - When the compute pass starts, the total grows to 28,506 (24,448 + 4,058 compute programs), and the count keeps moving: 24,675, 26,484, 28,329, 28,506 / 28,506. - Then "Starting the game", and the title. - The count's fraction steps back at that point (from 24,448 / 24,448 to 24,675 / 28,506), but the percentage shown doesn't: it reads 86%, 92%, then 99% from 24,675 / 28,506 on. - "About 4 min left" stayed up until the last second of a pass that took 7 s. Neither of those is what this PR changes; I mention them because the request expects the bar to step back. **Log lines** ``` vk: programs are loaded when the game makes them (create): RX_VK_LOAD=create (RX_VK_LOAD=create or start says which) vk: prepared 38809 shader programs (46597 new, 70 failed, 9687 compute pipelines; 9691 compute variants, 775 programs with texture variants, 59 at the limit) in 228.6 s vk: precompile: 24451 noted pipelines of 15565 programs and 9687 compute pipelines of 4058 compute programs built into the pipeline cache and let go (0 and 0 not made, 0 whose program variant is not kept), on 8 threads in 7.3 s (the compute ones 1.8 s) vk: start-up: the shaders took 238.8 s ``` The default start (1): ``` vk: precompile: 18100 programs, 24448 graphics and 9691 compute pipelines, 2430 mesh fallback programs in 5167 ms (2232 ms of it the caches opened, the notes and programs read) vk: precompile: compute pipelines: 9691 kept ready (9691 from the pipeline caches, 0 compiled now), 0 not made vk: start-up: the shaders took 267.2 s ``` None of the three starts logged a `compute pipelines: N of M pipelines` progress line: the pass ended within the 10 s between them. **What this doesn't show.** With Mesa's cache warm, the compute pass takes under 2 s here, far from the watchdog's 300 s, so these starts show the count moving and finishing, not a stop avoided. I also tried a start with Mesa's cache empty as well. It reached 114 of 38,809 shader programs in about 2 minutes (the warm-cache starts were at about 18,000 by then), hours at that rate, so I stopped it in step 1.

t2sxu-compute-pass.png

43 KiB

zeldaootr commented 2026-11-14 22:51:15 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Thank you for the Deck run, dukenheimer: your result is in the description as you reported it, including what it did not cover. Marking this ready for review.

Thank you for the Deck run, dukenheimer: your result is in the description as you reported it, including what it did not cover. Marking this ready for review.

zeldaootr changed title from WIP: fix(vk): shader preparation shows progress while it builds compute pipelines to fix(vk): shader preparation shows progress while it builds compute pipelines 2026-11-14 22:51:16 +00:00

zeldaootr commented 2026-11-15 06:27:10 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main e090cc48. #404 (Intel quick compute) calls precompile_compute_quick inside precompile_warm, so the check's stand-ins get a one-line precompile_compute_quick (in the test commit); the fix is unchanged.

The check still fails at the test commit for the bug's reason and passes at the tip, with g++ and clang. The tester's Deck result still holds: #404 changes how a compute pipeline is built, not what counts as progress.

Rebased onto main e090cc48. https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/404 (Intel quick compute) calls `precompile_compute_quick` inside `precompile_warm`, so the check's stand-ins get a one-line `precompile_compute_quick` (in the test commit); the fix is unchanged. The check still fails at the test commit for the bug's reason and passes at the tip, with g++ and clang. The tester's Deck result still holds: #404 changes how a compute pipeline is built, not what counts as progress.

zeldaootr force-pushed precompile-warm-compute-progress from 8f003d46e9 to 24df1cb012 2026-11-15 06:27:10 +00:00 Compare

zeldaootr commented 2026-11-15 13:32:26 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Closing as superseded by #721, which landed the same fix on main: precompile_warm now reports the compute pass as progress(total + computes_done.load(), all_n) with all_n = notes + compute pipelines, the same numbers this PR reported, so the count moves during the compute pass and the --prepare-shaders watchdog sees it move (#721 also counts the cache write as its own watchdog part).

Checked game-free: this PR's own test, tests/test_precompile_warm_progress.py (with a prepare_saving_now stand-in for #721), run against clean main @ aa95d35f passes both parts with g++ and clang (the count moves past the notes, and the watchdog with a 2 s stall limit lets a ~5 s compute pass finish); against the commit before #721 it fails both (last_total == notes_n + computes_n, and STOPPED: nothing moved for 2 s in the noted pipelines). Nothing of this PR is left to land; thanks to #721 for covering it.

Closing as superseded by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/721, which landed the same fix on `main`: `precompile_warm` now reports the compute pass as `progress(total + computes_done.load(), all_n)` with `all_n = notes + compute pipelines`, the same numbers this PR reported, so the count moves during the compute pass and the `--prepare-shaders` watchdog sees it move (#721 also counts the cache write as its own watchdog part). Checked game-free: this PR's own test, `tests/test_precompile_warm_progress.py` (with a `prepare_saving_now` stand-in for #721), run against clean `main` @ aa95d35f passes both parts with g++ and clang (the count moves past the notes, and the watchdog with a 2 s stall limit lets a ~5 s compute pass finish); against the commit before #721 it fails both (`last_total == notes_n + computes_n`, and `STOPPED: nothing moved for 2 s in the noted pipelines`). Nothing of this PR is left to land; thanks to #721 for covering it.

mooki added the

area/renderer

kind

bug

platform/linux

platform/windows

priority

high

labels 2026-11-15 13:55:40 +00:00

zeldaootr commented 2026-11-15 17:14:44 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Closing as superseded by #721, which is on main: it reports the compute pass as progress the same way this PR did and feeds the watchdog. This PR's own test passes on main aa95d35f and fails on the commit before #721, with g++ and clang. Thanks to dukenheimer for the Deck run on it.

Closing as superseded by https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/721, which is on main: it reports the compute pass as progress the same way this PR did and feeds the watchdog. This PR's own test passes on main aa95d35f and fails on the commit before #721, with g++ and clang. Thanks to dukenheimer for the Deck run on it.

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

Some checks failed

Hide checks

PR description / Description follows the template (pull_request_target) Failing after 6s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

Guide screenshots / Guide images and local UI source review (pull_request) Has been cancelled

Details

Website / Website on Cloudflare (pull_request) Has been cancelled

Details

Third-party parts / As their notes say (pull_request) Has been cancelled

Details

Third-party parts / The same as upstream (pull_request) Has been cancelled

Details

CI / Conventional Commit title (pull_request) Has been cancelled

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled

Details

CI / Workflow lint (actionlint) (pull_request) Has been cancelled

Details

Pull request closed

Please reopen this pull request to perform a merge.

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/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 @ 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

  

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/upscaling

beanstalk: approved @ 1697603

beanstalk: approved @ 2c5a62e

beanstalk: approved @ 4fd82b7

beanstalk: approved @ 64d6d09

beanstalk: approved @ 6f91fae

beanstalk: approved @ 70a78f9

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

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

2 participants

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

No description provided.