WIP: fix(macos): start renderer threads with a 16 MiB stack #651

Closed

mooki wants to merge 3 commits from mooki/Longshot:mac/thread-stack into main

pull from: mooki/Longshot:mac/thread-stack

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 1 Commits 3 Files changed 33 +600 -74

mooki commented 2026-11-15 02:17:38 +00:00

Member

• Copy link
• Copy Markdown

Type: fix · Risk: low · Tested on: macOS 26.7.1, Apple M4 Max (MoltenVK 1.4.2), arm64 and x86_64 under Rosetta · Needs: Windows, Linux (build and start)

Why

On a Mac the game crashed during its first start's shader preparation: start #6 of the macOS port died with SIGILL (exit
132) at about 93 s, 253 programs in. A thread the renderer starts on macOS gets a 512 KiB stack, where the same thread gets
8 MiB on Linux (RLIMIT_STACK) and on Windows (longshot.exe's /stack). On macOS, MoltenVK converts each shader to Metal's
language with SPIRV-Cross on the thread that creates the pipeline, and SPIRV-Cross recurses once per block along a program's
control flow (CFG::walk_from, 80 bytes a level in MoltenVK 1.4.2): one of the game's programs ran a preparation worker out of
stack. This PR starts every renderer thread on macOS with 16 MiB. It is part of the macOS port. See #420.

How to reproduce

Seen on: macOS 26.7.1, Apple M4 Max, MoltenVK 1.4.2 (main does not run on macOS yet: seen on the macOS port's integration
build f32adfa2, which carries the open macOS PRs)
Settings and switches: defaults, a first start (RX_VK_LOAD=start), the program cache carried from the start before
Steps: start the game and let the shader preparation run.
Expected: the preparation goes on to the precompile and the title.
Actual: the process ends with SIGILL inside the preparation (run #6, reports/2026-11-14-mac-startup-05.md; the crash
report's stack is SPIRV-Cross's CFG::walk_from on a prepare_run worker; analysis in reports/2026-11-14-thread-stack.md).

What changed

A new one-header helper, thread_stack::thread, starts a thread with 16 MiB of stack on macOS and is std::thread itself
everywhere else; every thread the renderer starts goes through it. Linux and Windows compile exactly the std::thread code
they compiled before.

• gpu/vk/thread_stack.h (new): on __APPLE__ a std::thread-like class started by pthread_create with
  pthread_attr_setstacksize(kBytes), kBytes = 16 MiB. It keeps std::thread's contract (decay-copied function and
  arguments, an exception out of the thread ends the process, joinable/join/detach/native_handle, moves,
  std::system_error on failure, std::terminate on destroying a joinable one). Elsewhere using thread = std::thread;.
• Every thread start under gpu/vk: 58 lines in 15 files (vk_draw.cpp 18, vk_replay.cpp 10, vk_texture.cpp 5,
  vk_main.cpp 4, vk_progcache.cpp 4, vk_memory.cpp 3, vk_menu.cpp 3, vk_jobs.cpp 2, vk_recorder.h 2,
  warm_bounded.h 2, and one each in vk_bug_report.cpp, vk_framegen.cpp, vk_fsr4.cpp, vk_hangdump.cpp,
  vk_programs.cpp): the type name at the creation line, its std::vector<…> and for (… & t : threads) lines, and one include.
  The inventory of the 36 kinds of thread and which reach the driver's compiler is in reports/2026-11-14-thread-stack.md.
• mkwvk_init (gpu/vk/vk_main.cpp) logs once per start on macOS: vk: the renderer's threads start with 16 MiB of stack (thread_stack.h; a macOS thread's own is 512 KiB).
• tests: tests/test_thread_stack.py + tests/thread_stack_test.cpp (new): a source check that no file under gpu/vk starts
  a thread another way (std::thread, std::jthread, std::async, pthread_create, CreateThread, _beginthread), and a
  fixture that runs a 2 MiB-deep recursion on each kind of thread (detached, joined pool, pool left running, named, moved
  arguments, member) through the real header; a -DCONTROL build starts the same kinds as std::thread, each of which must
  overflow on macOS (caught on an alternate signal stack, so no crash report). Seven source checks that matched the old
  std::thread( spellings now match thread_stack::thread( (test_framelog_sink, test_gpl_library_cache,
  test_pipeline_share, test_png_publication, test_predicted_check, test_startup_progress,
  test_texture_staging_publication), and eight checks that compile cut-out renderer code see the real thread_stack.h
  (test_capture_copy_helpers, test_gpu_hang_watch, test_jobs_failure, test_jobs_wait_runs_queued, test_pipeline_cache_save,
  test_prepare_stall, test_present_source_crop, test_recorder_sync). None was weakened.

Measurements

Verdict: fixes the crash: with this change the next starts (#7 cold and #8 warm on arm64, #9 cold on x86_64 under
Rosetta) logged the 16 MiB line and ended cleanly with no crash report, and #8 went from the 255 programs it inherited to
1,011, well past the program at 253 where #6 died. Not a performance change: nothing timed.

Baseline: main does not run on macOS yet, so both columns are the macOS port's integration builds, arm64, MoltenVK 1.4.2.
Before: integration f32adfa2 (run #6), without this change. After: integration a7711f3c (runs #7 and #8), with these three
commits. One run each.

Hardware: macOS 26.7.1, Apple M4 Max (40-core GPU), MoltenVK 1.4.2, 16-core CPU, 64 GB
Scene: the first start's shader preparation, windowless, defaults, 180 s each
Method: the runner's receipt (exit code), the crash-report folder before and after, and the game log's vk: lines
How to reproduce: a first start on a macOS build without this change, then with it

	Before: integration @ f32adfa2 (run #6)	After: integration @ a7711f3c (run #7, cold)	After: integration @ a7711f3c (run #8, warm)
end	SIGILL (exit 132) at about 93 s	clean exit (0) at 180 s	clean exit (0) at 180 s
programs reached	253 (died there)	243	1,011 (from 255 carried)
crash reports	1 (CFG::walk_from)	0	0

#7, #8: vk: the renderer's threads start with 16 MiB of stack (thread_stack.h; a macOS thread's own is 512 KiB)

Run reports: reports/2026-11-14-mac-startup-05.md (#5, #6), -07.md (#7, #8), -09.md.

Flags and settings

None.

Testing

Tested: on macOS 26.7.1, Apple M4 Max, at this head (main 6c9edffe plus this PR):

• tests/test_thread_stack.py --arch arm64 --arch x86_64: pass. Each kind of thread ran 2 MiB deep on both arches through
  the helper, and each std::thread control overflowed (SIGBUS, caught: exit 3). On main 6c9edffe (--source, an archive of
  its gpu/vk): fails on both arches, 58 thread starts without the helper and no thread_stack.h. Logs:
  reports/PubWave-files/PubPrep/p31-head-thread_stack.*, p31-base-thread_stack.*.
• Every check that reads one of the 15 changed renderer files (288 checks) through tools/ls-suite.py: 271 pass, 17 fail.
  14 of the 17 fail on main 6c9edffe on macOS too (reports/Baseline-files/main-6c9edffe/), among them
  test_pipeline_play_cache and test_pipeline_cache_save (posix_fallocate, fixed by the macOS PR #476); the other 3
  (test_precompile_compute_guard, test_shader_module_guard: "Windows structured exceptions required";
  test_present_aspect_vulkan: no Vulkan library to link on this Mac) are skipped on macOS in a full run and only fail here
  because they were named. Every updated check and the new one pass. reports/PubWave-files/PubPrep/p31-related-01/,
  p31-related-01-compare.txt.
• The 13 changed .cpp files compiled whole for arm64 and x86_64 with the renderer's flags (vk_menu.cpp with build.py's
  imgui flags, vk_fsr4.cpp with LONGSHOT_FSR): 9 files build on both arches at this head; the other 4 (vk_draw.cpp,
  vk_menu.cpp, vk_progcache.cpp, vk_programs.cpp) stop on Linux-only calls with the same errors on main 6c9edffe, and
  build on both arches with the macOS compile pieces of #476, #490 and #492 applied. reports/PubWave-files/PubPrep/p31-tu-head/,
  p31-tu-base/ (main), p31-tu-stack/, p31-tu-stack-menu-02/.
• git merge-tree of this head with each open macOS PR's head (#431, #437, #438, #479, #480, #490, #491, #492): no conflict,
  and none of them adds a thread start under gpu/vk.
• In the game (integration builds carrying these commits): runs #7 and #8 on arm64 and #9 on x86_64 under Rosetta, above.

Not tested: the game at this exact head (main does not run on macOS without the other macOS PRs; the runs above were on
integration builds), and Windows and Linux (no change in behaviour there: thread_stack::thread is std::thread; not built
or run on them: its test request covers the build and a start).

Must be tested:

• Windows and Linux, any GPU: build this PR (head 7707c634) and main 6c9edffe the same way, start each to the title and play
  a minute, expecting the build to succeed (off Apple every renderer thread is still a plain std::thread) and the log to
  match main's with no new vk: line (by hand: test request T-XXXX)

Risks

What could break: on macOS each renderer thread reserves 16 MiB of address space instead of 512 KiB: about 1-1.5 GiB in
all at the peak (16 preparation workers, the job workers, the replay and presenter threads; up to 64 precompile workers on a
64-CPU Mac). [INFERENCE] Only touched stack pages are committed, so the memory footprint does not grow by it; not measured.
A thread start that fails now throws std::system_error as std::thread does. Windows and Linux: nothing (the same type).

Turning it off: revert the PR.

Compatibility: Nothing changes for players: no shader stamp, cache format or MKWVK_API_VERSION change. On macOS one new
log line.

Reviewer notes

• Review f0a62f7b..7707c634 (3 commits): the helper and the 58 converted lines, one overflow message in the fixture, and
  the eight checks that compile renderer code given the header.
• Based on main 6c9edffe; no dependency. The three commits were cherry-picked with -x from macos/thread-stack, which was
  made on the integration branch. Conflicts in the pick, all context only, resolved by keeping main's lines and converting the
  thread starts in them:
  • gpu/vk/vk_draw.cpp (4 blocks): the integration branch's context carried the per-worker pipeline caches (#650); main
    has none of it, so only the include and the thread_stack::thread lines were kept.
  • gpu/vk/vk_main.cpp: the integration branch's #if defined(__APPLE__) block also held the Metal cache check (#653);
    only the stack line is in this PR's block.
  • gpu/vk/vk_memory.cpp: include lines beside #250's sparse_mirror.h (cf605c85); vk_recorder.h: beside #162's
    longshot_env.h include (98e2d95f); vk_replay.cpp: beside #238's readback_late.h (ba700f58), and #588
    (82886e89) renamed the replay thread "the render thread" in its log line: main's text with thread_stack::thread.
  • tests/test_recorder_sync.py: #60 (41421d48) copies gpu_wait_stats.h beside vk_recorder.h where this PR copies
    thread_stack.h: both kept.
• Main's own thread starts since the topic was written (#588's render thread among them) are all converted: the source check
  finds no thread start without the helper under gpu/vk (there were 58 on main 6c9edffe).
• Sibling macOS PRs: #650 (per-worker pipeline caches) and #652 (the precompile behind the title) start threads in the same
  vk_draw.cpp functions; #652's branch merges this one. #653 (Metal's cache folder) adds its check to the same
  #if defined(__APPLE__) block in mkwvk_init: keep both lines.
• Conflicts with main: none. With the open macOS PRs (#431, #437, #438, #479, #480, #490, #491, #492): none (git merge-tree).

Issues

See #420

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.
• Testing names what was tested, what wasn't, and what must still be tested, where and how. (Test requests not open yet.)
• Rebased on current main (main e090cc48).
• python -I -B tests/run_all.py passes (any failure that also fails on main is named). (On the wave's merge of every macOS PR built with this one, 453eb678: 553 passed, 32 failed, 18 skipped against main 6c9edffe's 531/32/17 on this Mac; the failures are main's own except test_split_ub_flush, which #658's tree at the time broke and its head fixes; test_collect_wide now passes; the new tests pass, test_thread_stack among them, and test_darwin_audio_service, Darwin-only, is skipped by the runner; reports/PubWave-files/waveA/.)
• 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.
• A game-free test added for the fix, failing on main and passing here.
• A check under tests/ that reads changed source updated in this PR, not weakened.

**Type:** fix · **Risk:** low · **Tested on:** macOS 26.7.1, Apple M4 Max (MoltenVK 1.4.2), arm64 and x86_64 under Rosetta · **Needs:** Windows, Linux (build and start) ## Why On a Mac the game crashed during its first start's shader preparation: start #6 of the macOS port died with SIGILL (exit 132) at about 93 s, 253 programs in. A thread the renderer starts on macOS gets a 512 KiB stack, where the same thread gets 8 MiB on Linux (RLIMIT_STACK) and on Windows (`longshot.exe`'s `/stack`). On macOS, MoltenVK converts each shader to Metal's language with SPIRV-Cross on the thread that creates the pipeline, and SPIRV-Cross recurses once per block along a program's control flow (`CFG::walk_from`, 80 bytes a level in MoltenVK 1.4.2): one of the game's programs ran a preparation worker out of stack. This PR starts every renderer thread on macOS with 16 MiB. It is part of the macOS port. See #420. ## How to reproduce **Seen on:** macOS 26.7.1, Apple M4 Max, MoltenVK 1.4.2 (main does not run on macOS yet: seen on the macOS port's integration build f32adfa2, which carries the open macOS PRs) **Settings and switches:** defaults, a first start (`RX_VK_LOAD=start`), the program cache carried from the start before **Steps:** start the game and let the shader preparation run. **Expected:** the preparation goes on to the precompile and the title. **Actual:** the process ends with SIGILL inside the preparation (run #6, `reports/2026-11-14-mac-startup-05.md`; the crash report's stack is SPIRV-Cross's `CFG::walk_from` on a `prepare_run` worker; analysis in `reports/2026-11-14-thread-stack.md`). ## What changed A new one-header helper, `thread_stack::thread`, starts a thread with 16 MiB of stack on macOS and is `std::thread` itself everywhere else; every thread the renderer starts goes through it. Linux and Windows compile exactly the `std::thread` code they compiled before. - `gpu/vk/thread_stack.h` (new): on `__APPLE__` a `std::thread`-like class started by `pthread_create` with `pthread_attr_setstacksize(kBytes)`, `kBytes` = 16 MiB. It keeps `std::thread`'s contract (decay-copied function and arguments, an exception out of the thread ends the process, `joinable`/`join`/`detach`/`native_handle`, moves, `std::system_error` on failure, `std::terminate` on destroying a joinable one). Elsewhere `using thread = std::thread;`. - Every thread start under `gpu/vk`: 58 lines in 15 files (`vk_draw.cpp` 18, `vk_replay.cpp` 10, `vk_texture.cpp` 5, `vk_main.cpp` 4, `vk_progcache.cpp` 4, `vk_memory.cpp` 3, `vk_menu.cpp` 3, `vk_jobs.cpp` 2, `vk_recorder.h` 2, `warm_bounded.h` 2, and one each in `vk_bug_report.cpp`, `vk_framegen.cpp`, `vk_fsr4.cpp`, `vk_hangdump.cpp`, `vk_programs.cpp`): the type name at the creation line, its `std::vector<…>` and `for (… & t : threads)` lines, and one include. The inventory of the 36 kinds of thread and which reach the driver's compiler is in `reports/2026-11-14-thread-stack.md`. - `mkwvk_init` (`gpu/vk/vk_main.cpp`) logs once per start on macOS: `vk: the renderer's threads start with 16 MiB of stack (thread_stack.h; a macOS thread's own is 512 KiB)`. - tests: `tests/test_thread_stack.py` + `tests/thread_stack_test.cpp` (new): a source check that no file under `gpu/vk` starts a thread another way (`std::thread`, `std::jthread`, `std::async`, `pthread_create`, `CreateThread`, `_beginthread`), and a fixture that runs a 2 MiB-deep recursion on each kind of thread (detached, joined pool, pool left running, named, moved arguments, member) through the real header; a `-DCONTROL` build starts the same kinds as `std::thread`, each of which must overflow on macOS (caught on an alternate signal stack, so no crash report). Seven source checks that matched the old `std::thread(` spellings now match `thread_stack::thread(` (test_framelog_sink, test_gpl_library_cache, test_pipeline_share, test_png_publication, test_predicted_check, test_startup_progress, test_texture_staging_publication), and eight checks that compile cut-out renderer code see the real `thread_stack.h` (test_capture_copy_helpers, test_gpu_hang_watch, test_jobs_failure, test_jobs_wait_runs_queued, test_pipeline_cache_save, test_prepare_stall, test_present_source_crop, test_recorder_sync). None was weakened. ## Measurements **Verdict:** fixes the crash: with this change the next starts (#7 cold and #8 warm on arm64, #9 cold on x86_64 under Rosetta) logged the 16 MiB line and ended cleanly with no crash report, and #8 went from the 255 programs it inherited to 1,011, well past the program at 253 where #6 died. Not a performance change: nothing timed. Baseline: main does not run on macOS yet, so both columns are the macOS port's integration builds, arm64, MoltenVK 1.4.2. Before: integration f32adfa2 (run #6), without this change. After: integration a7711f3c (runs #7 and #8), with these three commits. One run each. Hardware: macOS 26.7.1, Apple M4 Max (40-core GPU), MoltenVK 1.4.2, 16-core CPU, 64 GB Scene: the first start's shader preparation, windowless, defaults, 180 s each Method: the runner's receipt (exit code), the crash-report folder before and after, and the game log's `vk:` lines How to reproduce: a first start on a macOS build without this change, then with it | | Before: integration @ f32adfa2 (run #6) | After: integration @ a7711f3c (run #7, cold) | After: integration @ a7711f3c (run #8, warm) | |---|---|---|---| | end | SIGILL (exit 132) at about 93 s | clean exit (0) at 180 s | clean exit (0) at 180 s | | programs reached | 253 (died there) | 243 | 1,011 (from 255 carried) | | crash reports | 1 (`CFG::walk_from`) | 0 | 0 | ``` #7, #8: vk: the renderer's threads start with 16 MiB of stack (thread_stack.h; a macOS thread's own is 512 KiB) ``` Run reports: `reports/2026-11-14-mac-startup-05.md` (#5, #6), `-07.md` (#7, #8), `-09.md`. ### Flags and settings None. ## Testing **Tested:** on macOS 26.7.1, Apple M4 Max, at this head (main 6c9edffe plus this PR): - `tests/test_thread_stack.py --arch arm64 --arch x86_64`: pass. Each kind of thread ran 2 MiB deep on both arches through the helper, and each `std::thread` control overflowed (SIGBUS, caught: exit 3). On main 6c9edffe (`--source`, an archive of its `gpu/vk`): fails on both arches, 58 thread starts without the helper and no `thread_stack.h`. Logs: `reports/PubWave-files/PubPrep/p31-head-thread_stack.*`, `p31-base-thread_stack.*`. - Every check that reads one of the 15 changed renderer files (288 checks) through `tools/ls-suite.py`: 271 pass, 17 fail. 14 of the 17 fail on main 6c9edffe on macOS too (`reports/Baseline-files/main-6c9edffe/`), among them test_pipeline_play_cache and test_pipeline_cache_save (`posix_fallocate`, fixed by the macOS PR #476); the other 3 (test_precompile_compute_guard, test_shader_module_guard: "Windows structured exceptions required"; test_present_aspect_vulkan: no Vulkan library to link on this Mac) are skipped on macOS in a full run and only fail here because they were named. Every updated check and the new one pass. `reports/PubWave-files/PubPrep/p31-related-01/`, `p31-related-01-compare.txt`. - The 13 changed `.cpp` files compiled whole for arm64 and x86_64 with the renderer's flags (`vk_menu.cpp` with build.py's imgui flags, `vk_fsr4.cpp` with `LONGSHOT_FSR`): 9 files build on both arches at this head; the other 4 (`vk_draw.cpp`, `vk_menu.cpp`, `vk_progcache.cpp`, `vk_programs.cpp`) stop on Linux-only calls with the same errors on main 6c9edffe, and build on both arches with the macOS compile pieces of #476, #490 and #492 applied. `reports/PubWave-files/PubPrep/p31-tu-head/`, `p31-tu-base/` (main), `p31-tu-stack/`, `p31-tu-stack-menu-02/`. - `git merge-tree` of this head with each open macOS PR's head (#431, #437, #438, #479, #480, #490, #491, #492): no conflict, and none of them adds a thread start under `gpu/vk`. - In the game (integration builds carrying these commits): runs #7 and #8 on arm64 and #9 on x86_64 under Rosetta, above. **Not tested:** the game at this exact head (main does not run on macOS without the other macOS PRs; the runs above were on integration builds), and Windows and Linux (no change in behaviour there: `thread_stack::thread` is `std::thread`; not built or run on them: its test request covers the build and a start). **Must be tested:** - Windows and Linux, any GPU: build this PR (head 7707c634) and main 6c9edffe the same way, start each to the title and play a minute, expecting the build to succeed (off Apple every renderer thread is still a plain `std::thread`) and the log to match main's with no new `vk:` line (by hand: test request T-XXXX) ## Risks **What could break:** on macOS each renderer thread reserves 16 MiB of address space instead of 512 KiB: about 1-1.5 GiB in all at the peak (16 preparation workers, the job workers, the replay and presenter threads; up to 64 precompile workers on a 64-CPU Mac). [INFERENCE] Only touched stack pages are committed, so the memory footprint does not grow by it; not measured. A thread start that fails now throws `std::system_error` as `std::thread` does. Windows and Linux: nothing (the same type). **Turning it off:** revert the PR. **Compatibility:** Nothing changes for players: no shader stamp, cache format or `MKWVK_API_VERSION` change. On macOS one new log line. ## Reviewer notes - Review `f0a62f7b..7707c634` (3 commits): the helper and the 58 converted lines, one overflow message in the fixture, and the eight checks that compile renderer code given the header. - Based on main 6c9edffe; no dependency. The three commits were cherry-picked with `-x` from `macos/thread-stack`, which was made on the integration branch. Conflicts in the pick, all context only, resolved by keeping main's lines and converting the thread starts in them: - `gpu/vk/vk_draw.cpp` (4 blocks): the integration branch's context carried the per-worker pipeline caches (#650); main has none of it, so only the include and the `thread_stack::thread` lines were kept. - `gpu/vk/vk_main.cpp`: the integration branch's `#if defined(__APPLE__)` block also held the Metal cache check (#653); only the stack line is in this PR's block. - `gpu/vk/vk_memory.cpp`: include lines beside #250's `sparse_mirror.h` (`cf605c85`); `vk_recorder.h`: beside #162's `longshot_env.h` include (`98e2d95f`); `vk_replay.cpp`: beside #238's `readback_late.h` (`ba700f58`), and #588 (`82886e89`) renamed the replay thread "the render thread" in its log line: main's text with `thread_stack::thread`. - `tests/test_recorder_sync.py`: #60 (`41421d48`) copies `gpu_wait_stats.h` beside `vk_recorder.h` where this PR copies `thread_stack.h`: both kept. - Main's own thread starts since the topic was written (#588's render thread among them) are all converted: the source check finds no thread start without the helper under `gpu/vk` (there were 58 on main 6c9edffe). - Sibling macOS PRs: #650 (per-worker pipeline caches) and #652 (the precompile behind the title) start threads in the same `vk_draw.cpp` functions; #652's branch merges this one. #653 (Metal's cache folder) adds its check to the same `#if defined(__APPLE__)` block in `mkwvk_init`: keep both lines. - Conflicts with main: none. With the open macOS PRs (#431, #437, #438, #479, #480, #490, #491, #492): none (`git merge-tree`). ## Issues See #420 ## 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). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [ ] Testing names what was tested, what wasn't, and what must still be tested, where and how. (Test requests not open yet.) - [x] Rebased on current `main` (main e090cc48). - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). (On the wave's merge of every macOS PR built with this one, `453eb678`: 553 passed, 32 failed, 18 skipped against main 6c9edffe's 531/32/17 on this Mac; the failures are main's own except `test_split_ub_flush`, which #658's tree at the time broke and its head fixes; `test_collect_wide` now passes; the new tests pass, `test_thread_stack` among them, and `test_darwin_audio_service`, Darwin-only, is skipped by the runner; `reports/PubWave-files/waveA/`.) - [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. - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened.

mooki added 3 commits 2026-11-15 02:17:39 +00:00

fix(vk, macos): the renderer's threads start with a 16 MiB stack, not macOS's 512 KiB ... f0a62f7ba0

macOS starts a std::thread with 512 KiB of stack, where Linux starts one
with 8 MiB and Windows with longshot.exe's 8 MiB. On macOS MoltenVK
converts each shader with SPIRV-Cross on the thread that creates the
pipeline, recursing once per block of a program's control flow, and a
prepare_run worker overran its 512 KiB there (CFG::walk_from under
vkCreateComputePipelines from seed_compute, start #6, 2026-11-14).

gpu/vk/thread_stack.h: thread_stack::thread is std::thread itself off
macOS; on macOS a std::thread-like thread (construction with decayed
arguments, joinable, join, detach, native_handle, moves) started by
pthread_create with thread_stack::kBytes (16 MiB) of stack. Every
thread the renderer starts goes through it: the preparation's pools
(prepare_run, state_list_prepare, warm_libraries, precompile_at_create,
precompile_run, predict_run, warm_bounded::run), the job workers and
the serial builder, the replay, parallel-replay, presenter and
frame-generation threads, the program cache's loaders and the rest.
mkwvk_init logs the size once per start on macOS.

tests/test_thread_stack.py: no file under gpu/vk starts a thread any
other way; each kind of thread runs a recursion 2 MiB deep through the
helper, and on macOS each overflows as a std::thread (caught, no crash
report). Seven source checks follow the new spelling.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 48b49054b1c64851b3e8c974e64dc0b757b2ced3)

test(macos): one overflow message from thread_stack_test, however many threads overflow at once ... ea4081d942

The first thread whose stack overflows says so and ends the process;
the others wait in their handlers, so the message is not interleaved.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 62d0991e0cfb5402202f8f14e9eb799d5c20d262)

test: the checks that compile renderer code with its threads see thread_stack.h ... 7707c63433

Eight checks cut renderer functions that start threads (or copy
vk_jobs.cpp and vk_recorder.h) into fixtures of their own; they now
build with gpu/vk/thread_stack.h beside them: test_capture_copy_helpers,
test_gpu_hang_watch, test_jobs_failure, test_jobs_wait_runs_queued,
test_pipeline_cache_save, test_prepare_stall, test_present_source_crop
and test_recorder_sync.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit fd46ff431f9f62b1125582a4a3434a8cc92c551e)

mooki referenced this pull request 2026-11-15 02:18:08 +00:00

WIP: perf(vk): per-worker pipeline caches, every CPU and no saved pipeline cache for shader preparation on MoltenVK #650

mooki referenced this pull request 2026-11-15 02:18:11 +00:00

WIP: fix(macos): let MoltenVK's precompile go on behind the title and name slow compiles #652

mooki referenced this pull request 2026-11-15 02:18:12 +00:00

feat(macos): RX_VK_METAL_CACHE_DIR keeps Metal's shader cache in a chosen folder #653

mooki referenced this pull request 2026-11-15 02:55:02 +00:00

WIP: fix(macos): leave MoltenVK's compute pipelines to the precompile and bound its giant compiles #664

mooki referenced this pull request 2026-11-15 02:55:05 +00:00

WIP: fix(macos): hold MoltenVK's giant compiles behind the game until its first frame, at a lower QoS class #665

mooki referenced this pull request 2026-11-15 02:55:09 +00:00

WIP: fix(macos): put a dispatch's compute pipeline ahead of MoltenVK's giant compiles and retry it alone, not fail it for good #666

mooki referenced this pull request 2026-11-15 02:55:17 +00:00

WIP: feat(macos): RX_VK_METAL_ARCHIVE_DIR keeps MoltenVK's pipelines in Metal binary archives #667

mooki referenced this pull request 2026-11-15 03:11:01 +00:00

WIP: fix(macos): start MoltenVK's giant compiles behind the game only while memory allows, and say a lost device as one #669

mooki referenced this pull request 2026-11-15 03:11:09 +00:00

fix(vk): a timeline wait that comes back device-lost is said as a lost device, not as a timeout #670

mooki force-pushed mac/thread-stack from 7707c63433 to 01ffd9a938 2026-11-15 07:25:29 +00:00 Compare

mooki referenced this pull request 2026-11-15 11:56:02 +00:00

WIP: fix(vk): heavy compiles run alone under Metal's compiler service; the first giant behind the game no longer waits for 16 GB #784

mooki referenced this pull request 2026-11-15 11:56:08 +00:00

WIP: fix(macos): KosmicKrisp's compiles go through the compiler service's precompile, as MoltenVK's do #785

mooki force-pushed mac/thread-stack from 01ffd9a938 to a7c1f493de 2026-11-15 13:10:09 +00:00 Compare

mooki added the

area/renderer

area/upscaling

kind

bug

platform/macos

priority

high

labels 2026-11-15 13:57:08 +00:00

malon referenced this pull request 2026-11-15 15:11:03 +00:00

Game: Keeps on crashing in death mountain #817

mooki referenced this pull request 2026-11-15 17:40:00 +00:00

WIP: fix(macos): MoltenVK's precompile and pipelines on Metal #849

mooki commented 2026-11-15 18:08:24 +00:00

Author

Member

• Copy link
• Copy Markdown

Folded into #849 (fix(macos): MoltenVK's precompile and pipelines on Metal)

Folded into #849 (fix(macos): MoltenVK's precompile and pipelines on Metal)

mooki closed this pull request 2026-11-15 18:08:25 +00:00

Some checks failed

Hide checks

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

Details

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

Details

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

Details

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

Details

Website / Website on Cloudflare (pull_request) Has been skipped

Details

PR description / Description follows the template (pull_request_target) Successful in 5s

Details

CI / Conventional Commit title (pull_request) Successful in 4s

Details

CI / Workflow lint (actionlint) (pull_request) Successful in 7s

Details

Guide screenshots / Guide images and local UI source review (pull_request) Failing after 6s

Details

Third-party parts / As their notes say (pull_request) Successful in 11s

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

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

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

No description provided.