4 Commits
Author SHA1 Message Date
Valiantsin DzerakhandClaude Opus 5.5 a1964a0c31 Free texture pin copies once no recording names them
Every texture initialization got a 128-byte host copy for recordings to point at, kept for the whole run. The game
initializes its transient targets again every frame (about 29 new copies a frame on 1.4.3), so host memory grew by
about 44 MiB per minute of play, standing still too, until the commit limit ended long sessions (#670).

Each pin now counts the recording copies whose ops name it: counted in flatten_recording, uncounted when a copy or a
per-submission clone is freed. A pin with no copy left is freed NVN_PIN_AGE (1200) submits after its last use, so a
recording still in progress keeps its pins, and never while the replay holds it as a current render target, which
carries over to the next submission and is compared by pointer. TOTK_PIN_SWEEP=0 keeps every copy.

A 300 s standing-still run on the field save: host memory without VRAM grew 5 MiB, against about 220 MiB before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-04 15:00:36 +03:00
Valiantsin DzerakhandClaude Opus 5.5 0beafeb066 Write GPU-rendered textures back when the CPU invalidates a pool range or waits for a fence
nvn_pool_invalidate was a weak no-op, so nvnMemoryPoolInvalidateMappedRange never wrote anything back. TotK
invalidates its 260x260 R16 grass maps and 1x1 targets before reading them; they now go through guest_read.

The grass system also renders a 128x128 RGBA8 cut map into a CPU-cached pool every frame and reads it with no
invalidate. Without its texels the CPU saw no cut: swings left the grass standing, with no blades and no insects.
After nvnSyncWait or nvnQueueFinish, dirty mirrored targets up to 64 KiB rendered in a submission up to the waited
fence go back to storage (cpu_synced, vk_texture_write_back_small), unless the CPU rewrote it since.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-24 10:41:54 +03:00
Valiantsin DzerakhandClaude Opus 5.5 ebdba400df Pace presents at the back edge, just before the host present
The pacer gave each frame its display time but the present thread queued vkQueuePresentKHR as soon as the game
handed the frame over, so every present shifted with the frame's replay time: at 60.0 fps mean, 17-18 ms intervals
alternated with 15-16 ms ones. The present thread now submits the blit at once (vk_present_blit, so
vk_present_drain and queue order are unchanged) and holds the host present until the pacer's slot
(vk_present_flip). Acquire keeps waiting until the image's slot plus one period, which is now the time the next
frame really goes out.

TOTK_TRACE=present logs one line per present: host interval, the game's present-call interval, wait and lateness.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-23 23:26:43 +03:00
Valiantsin DzerakhandClaude Opus 5.5 19c9b648d1 Add the recompiler, Windows runtime, tools and docs
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-23 22:27:54 +03:00