Every report adds a line for video memory outside VMA (the driver's usage and budget per heap against VMA's blocks, and counts of pipelines by kind and by last use, stage libraries, compute pipelines, layouts and descriptor pools, with the swapchain, DLSS and FSR sizes), a line that splits the process's commit by owner (the game's heap and maps, device-local memory, VMA's host blocks, the C runtime heap with the shader caches, pipeline tables, texture cache, log queue and flight recorder in it, the driver's pipeline cache data and the rest), and a line naming what grew by more than 64 MiB since the report before and since play began. Every ten minutes of play and at exit a ranking line orders the categories by growth and marks those that only climbed; tests/mem_growth_check.py checks that bookkeeping.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
F8 now always writes a folder under logs/captures: the area, Link's position and rotation, the camera of the frame on screen and the game's own, the presented frame as a PNG, frame times around the press, the machine, the settings that differ from the defaults, the end of the log, the save, and the game's flags and texts. A note on screen names the capture. The flight recorder's F8 dump goes into the capture's folder.
NX2NAVI_CAPTURE_REPLAY starts a run on a capture's settings, teleports to its area, walks Link to where he stood and puts the free camera where the camera was; tools/capture_run.py prepares the profile from the capture's save, runs it and compares the two captures. docs/bug-capture.md has the files and the steps.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
With flight = 1 and its thumbnails kept, the recorder now also writes a dump when a frame's picture differs strongly from the frame before and the frame after while those two agree, which is what a one-frame flicker looks like. Each thumbnail is reduced to 16x9 cells of mean brightness where the present thread already sees it complete, and a frame is a flash when at least three cells are more than 24 of 255 brighter or darker than in both neighbours, the neighbours being alike in those cells, around them and over the picture as a whole. A camera cut, a fade, a pan and shapes crossing the picture are no flash, and a frame beside one without a thumbnail is not judged. The dump is the one F8 writes, named "flash" with the frame's number in its header line, at most one every 30 seconds. flight_flash = 0 turns it off; flight_flash_diff and flight_flash_cells set the two thresholds.
On the thumbnails of earlier dumps the defaults flag the frames whose scene was white once and nothing in the runs without that fault. tests/flight_flash_check.py checks the test itself on drawn pictures.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
In towns, kerb, stair and wall-top edges are drawn untextured for one frame when the game registers a round of streamed textures, and no pool entry of those textures goes to the stand-in in such a frame. A binding written into a draw's own set, and a slot that is unregistered when its marks are read, left no event until now.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
At 320x180 a frame of a 2560x1440 picture kept one texel in eight each way, and a flicker of a small object or of fine shading while the camera stands still did not show in a dump. The ring of 600 thumbnails takes 553 MB of host-visible memory instead of 138 MB while the recorder is on.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Ocarina streams its textures by detail level: while the player moves it registers about 32 pool slots with their next level every four or five frames. A pool refresh made 16 of them and wrote the stand-in into the set for the rest until its next round; the set is read as it is when its submission goes to the queue, so an object whose slot was among the rest could be drawn grey for a frame. A player's recording shows 1,525 such slots in 600 frames, each with its texture made later in the same frame. A slot whose entry in the set is a texture's view when it is looked up now has its texture made by that lookup, beside the count budget and the frame's creation time, 64 of them a present; pool_shown_first = 0 leaves them to the budget. The flight recorder also notes a slot that still had no picture when its submission ended.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
When the pool's entry of a slot goes from a texture's view to the stand-in, events.tsv gets a line with the slot and what its own texture was at that moment: finalized, released, superseded, overwritten, uploaded, its storage readable, held out. The set is written with update-after-bind, so every draw of the submission that samples the slot reads the stand-in from then on; the check at the marks' read-back comes a frame later and finds the slot resolved again.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Three more texture events for a dump's events.tsv: after each upload a hash of 64 probes of the storage and how many of them were all zero, so a second upload a frame later tells new bytes from the same ones and a first upload of unfilled storage shows; a slot registered with a CPU-written texture, with what the slot named before; and a slot a shader sampled that has no image of its own and follows none, so its stand-in was on screen. They are for telling why a texture shows wrong for one frame while the game streams textures in.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Each texture made (with how its content started), uploaded, uploaded again, released, taken back or destroyed is one line with its frame, address, format, size, layers and flags, so a one-frame flicker in the thumbnails can be matched to the textures of that frame. events.tsv is written first: the thumbnails take about five seconds, and a game closed meanwhile kept no frames.tsv.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The texture pool descriptors are now a ring of sets, one per submission, brought up to date from a change log, and the first submission of each frame waits for its GPU work before the game goes on: the GPU ran late and part of a frame read data of the next one, and distant characters drew NaN that bloom spread over the frame. The window acquire also waits for the image's previous frame. Function locals start at zero unless DLAA is on, which removes the per-warp light tiles on the Great Fairy Fountain floor and Link's dark, speckled look. Texture slots follow only live entries of their own target, so the volumetric fog gets its 3D volume. The pool refresh walks only the slots that changed.
The translator implements PRMT (patch 0021), which it only logged before; the button prompts render again. HFMA2.RELU no longer depends on it, HMMA.F16 rounds once and HMMA.F32 is lowered, checked against GPU vectors with a new Maxwell warp emulator.
The frame dump gains a re-arming white-frame trigger, a trigger on a depth target's first pass, NaN pixels in magenta, image handles and view targets, and depth copies of sampled depth textures.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
