Since d9429b0c, vk_pipeline.c cache_save_one stores the cache data sizes in P.held for the memory report, and the
check, which builds cache_save_one against a stand-in P, failed to compile ("no member named 'held'"), so the exit
save's snapshot rules went unchecked. The stand-in has the field now; vk_pipeline.c is unchanged.
The check passes again with the ucrt64 clang: builds held back and waited for, autosave unchanged, timeout, failures,
merges and the size limit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The limit was only checked when a file was read, all or nothing, so a run could write a file the next start then
dropped whole. On an RTX 5080 (0.9.2) pipeline-cache-play.bin reached 524.9 MB in one session and the next start began
empty; pipeline-cache.bin grows 14-28 MB at each fold and crosses 512 MB within a few sessions. Now a fold is made only
when its result fits, and a cache past the limit is not saved again, so the file keeps its last save under the limit.
Unset, the limit is the RAM / 32 between 512 and 4096 MB (512 on 16 GB as before, 2048 on 64 GB), which on that PC
took boot hits from 14 to 84 % and left no pipeline to background builds.
Taken into the 0.10.0 line with its conflicts resolved: the line had raised the limit to 1024 MB and says why in
the comment above cache_data_read, in nx2navi.ini.example and in AUDIT.md; those texts keep that reason and give the
RAM-based default, whose floor the next commit raises to match.
The save at exit now copies the cache only once the builds already in the driver have finished, with new ones held back meanwhile, as it already did on other drivers. Intel's driver crashed copying a cache while builds ran into it, and when the window closes the game's save is written after the pipeline cache, so a crash in that copy would lose it. The case the save at exit missed, a window closed while the boot's prewarm workers built pipelines back to back, is covered by holding new builds back: a build from the file takes about half a millisecond. The prebuild's comment keeps why its default is two threads, with the measurements of one thread for the rest of the list.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
