The user asked for the release to go out as 0.11.0. No final 0.10.2 was published: only the previews 0.10.2-rc1,
-rc3 and -rc4 carry that name, and the launcher counts 0.11.0 as newer than each of them, so testers are offered it
on either update channel.
VERSION holds 0.11.0 and the notes move to docs/releases/v0.11.0.md, with a line for those on a preview. Every line
that named 0.10.2 as the release in which something changed names 0.11.0 now: comments in the runtime, the two log
lines that give a version (the removed low-end GPU mode in cfg.c, the page generations in vk_memory.c),
nx2navi.ini.example, docs/building.md, the labels of tests/tex_release_check.c and a comment of
tests/audio_params_check.c. AUDIT.md names the release 0.11.0 throughout and records the earlier name and the
previews once, in its status line. Nothing else changes.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The textures the game lets go of were kept for three minutes and could hold a quarter of the card's budget, up to
8 GiB with room. A run through Hyrule Field shows what that bought and what it cost (RTX 5090, 5120x2160 with DLSS
Performance, about three minutes of running; the game keeps 4.8 GiB of textures live and loads about 190 a second):
the released textures held 5.3 GiB on average and the video memory in use went from 11.1 to 17.9 GiB, while the
game took back 1,494 MiB of them within 10 s of the release, 171 MiB within a minute and 10 MiB later, beside 33,000
textures it loaded anew. A shorter hold alone gives nothing back: with 20 s the released textures fell to 0.5 GiB
and the free space inside the allocator's blocks rose to 4.9 GiB, since a block returns to the driver only when it
is empty. What the released textures hold at their fullest is what the session costs, so the bound is the lever.
The bound is now a thirty-second of the budget, 384 MiB to 1 GiB (vk_tex_release.h trl_cap_mb), still doubled while
the card and the commit have room, and the hold 60 s, 120 for content only the GPU made. The same run with the new
defaults: 13.2 GiB in use on average against 16.7, 13.8 at most against 17.9, 532 MiB of textures made again over
the run, 77 fps against 75. An 8 GiB card keeps 384 MiB where it kept up to 1.9 GiB.
tests/tex_release_check checks the bound by the budget and the sessions it simulates against the rule before.
Compaction (tex_compact) and 16 MiB blocks were tried on the same run and gave back 0.7 and 1.2 GiB; neither is
changed here.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The headroom thread compared a heap's use with the driver's budget alone, so a run with NX2NAVI_VRAM_BUDGET_MB kept its spare blocks where the card the cap stands for keeps none, and such a run understated a small card (the audit's F-3-07). With a cap set, the device-local use is now also compared with 85 % of the capped budget, the figure the mirrors and the textures go by. Without a cap nothing changes: each heap's own figure decides as before.
Co-Authored-By: Claude Fable 5.2 <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.
A staging buffer that does not fit the staging pool's blocks waits for the oldest upload batch with the upload lock
held, and a replay submission that sends its uploads waits for that lock. The wait cannot leave the lock: the caller
holds the open batch's command buffer and the buffer it asks for belongs to that batch. What the wait costs on an area
load was not measured anywhere, so it is timed and logged now: the first four waits, then at every doubling of their
count, with the total and the longest.
Since staging stays inside the pool's blocks every batch is submitted at 64 MiB of staging, so upload_batch_mb = 0 is
that limit and not "no limit", and the values above it (the low-end mode's 256, the menu's 128 to 1024) change
nothing; a discrete card keeps 256 MiB of staging for the run, not 128. The settings table, the menu's text,
nx2navi.ini.example, the audit's table and the comments say so.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
A start that finds the pipeline cache written by another device or driver has nothing built, and everything was
compiled beside the game: an 8-core integrated GPU drew fewer than 600 frames in its first 11 minutes. Such a start
now waits on the "Preparing shaders" screen, with counts, for every recorded pipeline, for the compute pipelines on
every core at normal priority, and, when a sample says the driver's own cache lacks the prepared stage libraries, for
all of them on every core. The memory gate still holds for the builds, and the library builds write the preparation's
journal while the start waits, so a variant the driver's compiler dies on is skipped from the next start on.
boot-warm-owed.txt beside the caches names the GPU and driver: a start closed during the warm is followed by one that
goes on with it, three at most, and "done" keeps later starts ordinary while the cache file still carries the earlier
driver's header. When the boot stops waiting (prewarm_wait_ms, or a minute without progress) the builders step down
to the background's thread counts and idle priority. prewarm_full = 0 turns the warm off.
With nothing in the driver's cache the probe took 425 s on an RTX 5090 with 16 CPU threads: 87 s for 5,775 recorded
pipelines, 19 s for 4,075 compute pipelines and 317 s for 42,231 prepared variants.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The limit was 512 MB, and a file over it starts the run empty until a play file replaces it. With the pipeline list of 0.9.1 one run builds more than that: on an RTX 2080 Ti (#722) pipeline-cache.bin held 551 MB and the play file the run then wrote 541 MB, so both were dropped at every start, 7,247 of 8,531 pipelines were built again each time (17 s of the boot) and 541 MB were written in every session. Seven of the players' logs read here have a file over 512 MB, five of them between 517 and 691 MB. At 1024 MB those are read, the play file is folded in once and the loop ends; a start that still finds both files over the limit now says so.
pipe_seed_boot (auto, 1, 0) decides whether the boot builds the pipelines of the shared list that the install has never drawn. Each is a pipeline the driver holds for the whole run: the boot's pipeline stage went from about 1.6 GB of commit on 0.8.0 to 3.9-4.4 GB on NVIDIA cards with the list (1.5-1.8 GB on AMD's driver), and 0.3-0.6 GiB of video memory. auto, the default, builds them as before except on a machine that starts with less commit free than the game takes in play, the start's own memory warning: there they are made at their first draw from the pipeline cache and recorded as the install's own. Mesh pipelines are built at boot either way. Compiled; not run in the game.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The prebuild marker fix is reproduced and verified, the missing-area report and the first Market run are checked; the other Market runs, the route and the UBSan run were still waiting for the game slot.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Eleven findings are confirmed by a run or by tool output: the save that names an area this game version lacks, three device losses at a save load, the Market's stall from a pool list that gathers duplicates, the DLSS feature created on the replaying thread, and a pipeline prebuild that stays skipped after the game is closed during boot, among them. The other 44 are suspected from reading the code. Phase 3 was stopped before its last runs; section 12 lists them.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The route reaches Kakariko Village, Hyrule Field by day and night, the Market, Death Mountain Trail and the graveyard edge from the available saves, every pause subscreen, and a save, return to the title and reload in one process; Kokiri Forest, a dungeon and a boss are not reachable. The ledger gains a confirmed crash on loading the test install's Kokiri Forest save and a confirmed UBSan report in the menu's grain texture; ASan cannot start because its shadow covers the guest's fixed windows, and TSan has no Windows target.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
