Repository navigation
Release 0.12.0 - #35
Merged
Merged
Conversation
…inds no longer leaves its CPU-written textures at zero Kokiri Forest's ground in Ocarina of Time was missing wherever only the terrain covers it: aCidcOde traced it in seedds#1326 to the ten 260x260 R32F height tiles, all zeros on the host with data in their storage, as tex_cpu_content refused any uncompressed texture in a pool with gpu_written set, and the terrain's 202 MB pool (flags 0x24) also holds textures the GPU writes. Each tile lay flat far below the player and the sky showed through. mtl_tex_gpu_written now records the storage range of each render target, clear, copy destination and image store, and an uncompressed texture is refused, or dropped by cpu_unc_drop, only where its own storage overlaps a range. This is aCidcOde's patch from seedds#1326, checked against this tree, with one change: ranges go with their pool (gpuw_drop). They never shrank in the patch, so a pool made later at those addresses would have counted as written, where pool_t.gpu_written starts at 0. t_cpu_tex: a texture beside a GPU write is taken and one over it is not, a write over its storage ends that, ranges merge and split, a pool that goes takes them along, no range means the whole pool. t_cpu_storage passes unchanged but for the name.
…d of freezing the Mac A session of Ocarina of Time ended in a GPU out-of-memory and a stuck game, and seedds#1326 reports a Mac frozen until the power button: GPU memory is wired, IOGPUScheduler's freeToWireMemory fails at recommendedMaxWorkingSetSize, and the submit thread then waits in the kernel where the process cannot be killed. Nothing in the host looked at the working set. res_commit now reads the larger of the set's allocatedSize and the device's currentAllocatedSize before it commits; the set's size leaves out what was never committed (measured: a new 64 MB texture adds 0 to it until the commit), the device's counts it from its creation. From 80% of the working set the submit thread lets go of what can go: idle sharing entries nothing holds, finished deferred releases, spares and the upload slots' staging. From 95%, if that was not enough, the game stops with a [RED] report of what the set holds, by kind. A commit that adds to the set is not made at the working set itself. A 100 ms timer reads the sizes too, as a stuck submit thread never comes back to look. The stop reaches the launcher as a normal exit: the Mac app closes the graphics gate, leaves full screen, shows an alert and quits as Cmd-Q does, the path PucaVaz's PR seedds#1332 takes for a revoked GPU (front_stop_alert is written so front_gpu_lost can call it); without a window the host takes its graceful exit. DM_NVN_RES_LIMIT_MB and the report's distinct pages and texture formats come from JioChoi's PR seedds#1319, moved from after the commit to before it. iOS only evicts unless the switch sets a limit: no iPhone has tried the stop. t_res_guard covers the levels, the commit refused and removals passing, what stays (a live object, the parent of a live sRGB view, a recent lookup), the second look at the stop level, and the timer with the lock held.
… the likely cause of the freeze after a window switch Ocarina of Time out of focus went from 11 to 20 GB of GPU allocated in 12 s with the residency set flat, and swap grew 6.7 GB in 20 s until boot.sh killed the run. Out of focus the game's main thread waits in oe::PopNotificationMessage (main+0x3bc0354) and submits nothing, while its streaming threads remake a run of about 10 MB of a virtual pool 70 times a second. Each old buffer went to the deferred queue behind a fence no submission would pass, and only a submission's feedback drains that queue: 770 MB a second, 881 buffers at the end of the log. A user's session froze for good at a window switch, frames not back at focus 1, audio on, no GPU error: past the working set the next commit is what the driver refuses, and DM_FOCUS_KEEP=1, which keeps the game submitting, avoids it. It also fits the sawtooth of GPU allocated noted in earlier logs. A pool's buffer retired with no submission open now waits only for what was committed, as none can reach it once it left the table, and the guard's 100 ms timer drains the queue while no feedback is due (defer_idle). The timer runs with the guard off too. The guard also counts what res_add added since the last commit, as the set's size leaves that out and the device's size could lag it. DM_CTL "focus <n>" sets the focus state, which a windowless boot needs to test this. t_res_guard: a retired pool buffer goes at the next tick between submissions, and behind the submission with one open.
…uffer address in: every pool was wired for it, which slowed Ocarina of Time's frames to 60-65 ms A shader with raw global memory reaches any address it loads from memory, so its pool table (gmem_map_gpu) listed every memory pool and made each one resident, and a zero-copy buffer in the residency set is wired whole. Ocarina of Time (0400486024DEC000, profile in seedds#1299) makes over 4,500 pools, most of them holding only textures. In Link's house the residency set reached 11.7 GB on a 16 GB Mac, against Metal's 12.1 GB working set, and frames took 60-65 ms. The pool walk's storage check (tex_storage_live) also went through mtl_addr, which puts the pool it finds into the residency set, for every registered texture. A shader can only reach an address the game wrote into memory, and the game gets a GPU address only from nvnMemoryPoolGetBufferAddress, nvnBufferInitialize or nvnTextureGetTextureAddress. Those now mark the pool's range (mtl_pool_buffer_addr), and the table lists and makes resident only the pools that meet a mark; a large pool is taken whole only then. Other pools still come into the residency set when a binding addresses them. The storage check only asks whether a pool maps the storage (mtl_addr_mapped), and a texture upload from an unlisted pool reads it through a buffer of its own that the upload batch retires (up_big_src), as for a large pool. nvn_replay marks every captured pool. A full mark table lists every pool, with a red line, and DM_NVN_GMEM_ALL=1 lists every pool, as before. On our stack: Link's house from 60-65 ms to about 26 ms a frame, and the residency set from 11.7 to 9.5 GB. t_gmem_marks covers the table, the residency set, the storage check, the upload and DM_NVN_GMEM_ALL; t_pool_chunks takes a large pool whole only once it is marked. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… ID the dummy instead of making its texture again, which ran Ocarina of Time out of GPU memory at a scene change A pool table for handles traced to no slot (pool_gpu) resolves every registered texture ID. At a scene change Ocarina of Time (0400486024DEC000, profile in seedds#1299) finalizes the old scene's textures and leaves their IDs registered: mtl_tex_release dropped their views, and the next table rebuild made a Metal texture for each of them again from its storage. At the house-to-forest change that was about 1,500 textures and 2.5 GB held only through retired IDs, as much again in deferred release, 16 GB of GPU memory allocated against Metal's 12.1 GB working set on a 16 GB Mac, and command buffers failed with kIOGPUCommandBufferCallbackErrorOutOfMemory. With pool_skip_retired on (DM_NVN_POOL_SKIP_RETIRED=1 / 0 overrides it), a retired ID that holds no view gets the dummy texture in the table; the table log counts them. It is a key, off by default: on the console a handle to a finalized texture still reads its storage while that is there. With it, Ocarina of Time played 25 minutes in Kokiri Forest with no out-of-memory, GPU memory peaking at about 12 GB and frames from 44 to 31 ms. t_pool_retired checks a live and a retired ID in one table, with the key and without; it fails without the change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…INC and DEC AGlobalAddress added the uniform register in every uniform form; nvdisasm names desc[URb][Ra.64] (bit 76 of LDG / STG, bit 71 of ATOMG / RED), where URb is a memory descriptor and the address is Ra.64 alone. [Ra.64+URb] (Unreal Engine 5.4's bounded read) is unchanged. ATOMG.CAS (0x3a9) was not registered; INC / DEC had no case in EmitAtomicOp: a compare-and-swap loop. New GlobalMemory tests in test_dmsh_ampere_alu.py (three fail on main). A GPU cross-check of 300 global accesses through a gmem_map built as the host does, production options: 135 identical to 300. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…rial that left the CPU-written set while its NvPkg stayed made tex_mtl return the NvPkg and tex_by_id throw WOB2020's report on PR seedds#1299 (M3 Max, 412 s into Kokiri Forest, right after a save commit): NSInvalidArgumentException "-[NvPkg buffer]: unrecognized selector" in tex_by_id, under pool_entry, pool_gpu and a mesh task draw; no GPU error. tex_mtl_ takes the packaged path only while tex_from_storage holds (has_layout, tex_cpu_written(serial), or a virtual sparse pool). For a texture with an entry in the texture table its last step returned the entry as it was; when the entry is an NvPkg and the serial has already left the set, that is the wrapper, and tex_by_id's base.buffer throws. tex_made and the packaged branches unwrap it. The last step now unwraps it as tex_made does (view, else tex) and prints a [RED] line once with the serial. What takes the serial out of the set first is not known and not fixed: cpu_unc_drop deletes the serials from the sets and puts each entry's texture in the table only after it has let go of the set's lock, and mtl_tex_release deletes before serial_del; neither was shown to be it. t_cpu_tex --metal packaged_entry_outside_the_set deletes the serial of a packaged texture from the set and asks tex_mtl for it: before the change it returns the NvPkg ("-[NvPkg width]: unrecognized selector" in the test), after it the entry's texture. t_cpu_tex 64 checks, 0 failed; t_cpu_storage 32; test_docs, docs_symptoms.py --check; lint_c.py tidy on nvn_mtl.m and t_cpu_tex.m: 0 file/check pairs above the baseline.
… and pass over IDs of another type: Ocarina of Time's residency commits 12 times fewer pool_gpu wrote every rebuilt table into a new buffer, 8 bytes per registered ID (264 KB at Ocarina of Time's 33,000), so each rebuild was an allocation, a residency-set addition and, behind the fence, a removal: the table's line led the residency report with thousands of additions every 300 frames. A replaced table now becomes one of 64 spares and a later rebuild writes it again once the submission that could still read it has completed (pool_buf / pool_buf_retire, against g_done); spares stay in the residency set, and argument blocks holding an old address are not reused past a rebuild (g_psnap_gen). A walk also looked every registered ID up before checking its type, so a 2D-array table made the views of retired 2D registrations again, which go at every submission end, only to turn them away. A registration now keeps the Metal type tex_by_id gave it (treg_t.tt, cleared when the ID is registered again) and a walk passes over an ID of another type. Ocarina of Time (with PR seedds#1299), Kokiri Forest, M5 Max, two runs per host: residency commits per 300 frames 664 and 678 -> 56, additions 3,136 and 2,500 -> 276; 1,487 table buffers made and 81,333 reused; 74 million lookups passed over. t_pool_table: a walk over 20,000 2D IDs with dropped views in a 2D-array table takes 0.08 ms instead of 3.2 ms. Frame times did not change beyond the runs' noise. The reference entry also records what is still open: the table holds a Metal texture for every registered ID of its type (1.56 GB that nothing read in Kokiri Forest), and marking reads from shaders cost 22 % of GPU time. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…offset; ATOMG.CAS; ATOMG / RED INC and DEC Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…handed out as the texture: a serial that left the CPU-written set while its NvPkg stayed made tex_mtl return the NvPkg and tex_by_id throw Its RED_ONCE key becomes 155 (153 is the present anti-aliasing line here); t_cpu_tex --metal runs both finalized_bindless_pool and packaged_entry_outside_the_set. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…act with native mesh pipeline prewarming Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g # Conflicts: # dm/gfx/tests/t_pso_skey.m
… skip matched reconstruction Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…es, so a pool that holds both kinds no longer leaves its CPU-written textures at zero Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g # Conflicts: # dm/gfx/tests/t_cpu_tex.m
…cy commit stops the game instead of freezing the Mac front_mac.m: seedds#1332's front_gpu_lost now goes through this pull request's front_stop_alert; alias_let_go keeps the submission's finalized serials (g_ghost_active); the memory line keeps NXForge's GPU allocation by kind. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
… piles up retired pool buffers, the likely cause of the freeze after a window switch Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g # Conflicts: # dm/gfx/nvn/nvn_mtl.m
…bles give a finalized texture's ID the dummy instead of making its texture again (Ocarina of Time out of GPU memory at a scene change) Its retired-ID check goes into pool_entry, which the table patch and the full build share here (the patch passes no counter); Ocarina of Time's profile turns the key on, as upstream f3ac5ea does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…nly the pools the game took a buffer address in: every pool was wired for it, which slowed Ocarina of Time's frames to 60-65 ms Its marks go into the pool table that seedds#1360 sized to the pools (gmem_map here); t_pool_chunks checks the mark, then the chunk hints. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…arina of Time's texture ID 906 tex_fit made no view for a shader that declares a 2D array where the texture is a cube or a cube array, so the cube was bound as is: a type mismatch whose reads are undefined on Metal. The Legend of Zelda: Ocarina of Time (Switch 2) binds texture ID 906 (an NVN 2D array descriptor, target 4, format 0x3f, whose Metal texture is a cube) to slot 7 of pixel shaders 9b310b3349825e9a and 09ab31c69af710c9, which declare a 2D array. Maxwell keeps a cube's faces as six layers, so the view takes them as the array's layers, six to a cube. New Metal test t_tex_fit_cube_layers (a cube and a cube array of two, read layer by layer). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…ts regions past the iPhone-sized profile value; heap and stacks now sit before it in the guest block A profile's mem_alias is sized for an iPhone, which gives a process one reservation of at most 6 GB. Games lay their regions out for a Switch's 64 GB, so on the Mac Trails in the Sky 1st Chapter crashed at launch (sig=11 addr=0x1 at sdk+0x15576c, after an 11.27 GB region at alias +1.00 GB) and Just Dance within a minute. The region is address space, not memory: the application pool still bounds what is mapped. - mem_init_once reserves the larger of mem_alias and 64 GB on the Mac; an iPhone keeps the profile's size. DM_ALIAS_SIZE still sets another size. - The block is now heap, stacks, alias, on both platforms. macOS 27.2 reserves 0x1000000000-0x7000000000, which leaves exactly 64 GB below 2^39 with two ~12 GB reservations at random addresses in it, and the block is larger than 64 GB, so it always crosses 2^39, which a Switch's addresses never do. With the alias region last that is usually past the heap and stacks. It lowers the exposure and does not remove it: over 600 launches of a bare process a 68 GB block started 0-33 GB below 2^39 (median 13.5), so heap and stacks cross it in roughly 10-15% of launches, which a [mem] line reports. A game mapping far into the alias region crosses too. No game is known to break on this. - Cheat region 2's check follows the order: its base has to be in the guest block. - The NSP script's heap check passes the profile's mem_alias, as its keys are for an iPhone's layout. Not reproduced: no Trails or Just Dance dump here, so those two are not run. seedds#639 stays open: an alias high-water mark near the top is not exhaustion, and its cause needs a long session. Not run on a phone: the new block order there. Checked: memory SVC tests (16K ASan, TSan, real dirty tracking) and t_cheats; the memory tests with guest files forced on at 64 GB in 1, 65 and 1,013 files, and at 256 MB and 2.875 GB alias regions, anonymous and in files; 171 tool tests; the Mac host builds and hle_svc.c compiles for the iPhone SDK. regress.py on 7550be1, before the rebase over 865cc35: Tears of the Kingdom fps 57.4 -> 57.3, peak 4986 -> 4994 MB, first frame 6.5 -> 4.9 s, no new RED, flagged on screenshots that show the same cutscene at another moment; Super Mario Bros. Wonder PASS, 58.5 fps. NieR could not run: its chain folder held only a shader pack. Diagnosis and the Trails 2nd Chapter finding from PR seedds#1276. Co-authored-by: Nochul Park <5128030+maceopark@users.noreply.github.com>
…tics let one renderer's thread rewrite blocks queued on another's output (issue seedds#1336)
…0 passes a frame stay open in Ocarina of Time fb_prepare took every draw with pool handles or dynamic tables as a depth reader, because only the GPU knows what the handle names, and the next draw writing depth ended the pass. Ocarina of Time's material shaders are pool shaders that write depth, so each draw ended the pass the one before it opened. PucaVaz found the rule and the cost in Link's house (issue seedds#1385, PR seedds#1396), and that asking the pool tables doesn't help: the game registers its depth textures in the pool those shaders read. A draw that writes depth itself is no longer taken as a reader: sampling the attachment it writes would be a feedback loop, undefined on the console too. In Kokiri Forest the reader wrote depth in 67,730 of 67,739 splits. Pool draws that leave depth alone still count, as do real slots and TEXU handles. This is an inference from the API, not a proof about any shader. DM_NVN_FB_DSELF=0 counts them as before; ab alternates with DM_AB. On the author's stack (M5 Pro, 1280x720, game upscaler, encoding thread off, A/B over 6 paired phases): 183 to 112 passes a frame, attachments 286 / 316 to 244 / 273 MB, GPU p50 20.3 to 16.5 ms, frame p50 20.7 to 16.8 ms. Not run on this commit, on main, or on another game. Check: check_t_feedback, with a new case: 176 checks, 0 failed; with the change taken out, 3 of them fail. test_docs, test_env_switches, test_gfx_tests_makefile, docs_symptoms.py --check; lint_c.py tidy on nvn_mtl.m and t_feedback.m: 0 file/check pairs above the baseline.
… the clock again, and the clock is the guest's A picture over a second late started the movie clock again. That suits a pause, but on a stall in the host (a pipeline built on first use, a long GPU wait) the game's sound goes on, and the picture then stayed that far behind the narration until the next stream (reported on an M2 Pro). Now the clock starts again only when the game held the movie: it presented 6 frames or more without taking a picture (a pause menu, a load screen), or its window lost the focus meanwhile. Otherwise the late pictures are skipped until the movie is back on its clock. The clock is guest_ns, which does not run while the Mac sleeps, an iPhone app is in the background or DM_DETCLOCK steps it. The log says when the clock starts again and why, and when a stall is caught up. t_codec_video adds a pause, a stall and a focus change. DM_CV_LATE gets its row in docs/env_switches.tsv (test_env_switches listed it as a switch without a meaning), and docs/reference/movies.md an entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017WLejRwCykjPcsPU4Hdenf
…, as patch_recipe() does Three more rule['cuts'][0] = ... lines in test_nso_match.py (dd6ce5b) took pyright's reportIndexIssue past the baseline; the annotation clears all six, and the baseline shrinks by three. Co-authored-by: enjoyerofslop <281774948+enjoyerofslop@users.noreply.github.com>
…file's alias region out of the heap region: Ocarina of Time's 6.20 GB request got 0xb8000000 (issue seedds#1361) heap_signals grew mem_reserve as if the alias region were 1 GB but set only mem_reserve, so the 4.375 GB Switch 2 guess came off the heap region. The block now grows by max(mem_alias, 1 GB). The real host's memory code with the old keys logs the reporter's OOM and with the new ones gives the whole request; no game was booted, and on main the boot is reported to stop later at the nn::diag abort that seedds#1299's eventfd change addresses. Co-authored-by: enjoyerofslop <281774948+enjoyerofslop@users.noreply.github.com>
…s shape, so Galaxy 2's 5:4 cutscene crop fills a 16:9 screen again (issue seedds#949) Galaxy 2 draws its storybook cutscenes anamorphically into 1200x960 of a 1920x1080 swapchain (800x640 handheld) and crops the layer to that; the Switch's compositor stretches the crop to the layer. The present used the crop for both the texels and the shape, so the scene came out squeezed with bars at its sides, and the front ends laid out and mapped clicks on 5:4. present_shape gives the shape for every graphics API: the display's 16:9, a sized layer's, or under DM_SCREEN_ASPECT the taller shape for a texture that has it. Both encoders, MetalFX, the screen-sized captures and front_picture_shape use it. Checked by t_present_crop only; the game's cutscene was not reached on this build, and BotW at DM_SCREEN_ASPECT=1.43 and iOS were not run. Co-authored-by: zatteogit <64840342+zatteogit@users.noreply.github.com>
…sured on Ocarina of Time (iPad GPU out of memory at 8,259 of 8,192 MB) poolstat logs the resident memory pools and the texture storage inside them, with the largest pools. texstat logs the host textures by kind: those made from guest memory by frames since their last use (NvPkg gets a last-use frame), and render targets by shape, with how many distinct guest storage addresses, over what span, and how many live serials name them. Each host texture is counted once. docs/reference/memory.md records the Ocarina of Time measurements they gave (12.1-12.5 GB on an M4 Pro Mac in handheld mode against the iPad's 8 GB: 5.9 GB of pools the raw table keeps resident, 2.6 GB of it texture storage also held as Metal textures; 2.36 GB of guest-memory textures all used every second; 2.4 GB of render targets with transient ones duplicated at shifting offsets) and three experiments that did not help.
…carina of Time in a 1920x1080 window on a 1440p Mac screen Docked, QueryDisplayBufferMaxResolution and ListDisplays answer the largest of 720p / 1080p / 1440p / 4K the Mac's screen holds, and Ocarina of Time sizes its window to it: 2560x1440 on a 1440p-class screen, rendering up to 2048x1152 there. Upstream's locked 60 fps measurement is at 1536x864 in a 1920x1080 window. DM_DISPLAY_MAX=1080p answers as the console on a 1080p TV: 44 % fewer pixels for the same picture. It only lowers the answer; an unknown value logs once and keeps the display's own. t_vi_display: 6 new checks (cap docked and handheld, any case, never raises, unknown value). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
…splay size The in-game run with DM_DISPLAY_MAX=1080p made the same 2560x1440 window: the game makes no QueryDisplayBufferMaxResolution or ListDisplays call and sizes its window from the docked mode itself, so the setting and its documented Ocarina example were wrong. The change stays on branch claude/oot-display-max (54b6966) for games that do ask. The tested app (9133c0f) ran with it unset, where it changes nothing. This reverts commit 9133c0f. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
Starts release-0.12.0 from claude/project-thread-27ja4m at 3143f65. That branch merged upstream main 88c7e03 onto 0.11.0, taking upstream's landed versions of the Ocarina pull requests it closed. It compiles on the Mac, passes the gfx and host tests there, and its 10-minute Kokiri Forest check measured 22.0 ms median frames (was 26.1) and 10.1 GB peak (was 14.2). Linux dm/tools tests: no new failures against main except test_nlg4 and test_dmsh_pool_arrays, which fail on upstream 88c7e03 too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK4T7SLBnbRPXQUVaNR
A damaged NARC is a red line instead of a cra.Error out of scan_blob (the
nightly fuzz failure on main, run 42206964336). The NDSR probe conflicted with
this branch's 16-byte record reader, which has the same bug: iter_unpack('<4I')
on a slice that is not a multiple of 16 when the file ends mid-table. The probe
reads whole records only now. 5 more minutes of atheris on shader_split after
the merge: no findings; test_split_narc, test_split_ndsr_entries and the fuzz
corpus pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016qteK2vBp7we64AHXiwhHD
Upstream main up to 88c7e03 (Ocarina of Time from upstream's landing), the fuzz crash fix in shader_split.py. seedds#1464 and the HMMA title-movie speed-up wait for the next rebase. scripts/release_check.py check 0.12.0 passes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
github-actions
Bot
added
host
Owner
Author
|
What it found:
clang-tidy here needs the macOS SDK, so the fix is being made on the Mac with CI's LLVM 23.1.4: real fixes or Generated by Claude Code |
… is marked Upstream b1d7c70 made pool_arrays wrap each texture read in dm_pool_mark (shaders report which textures they read through a pool) but left this case expecting the bare bounded index, so the test fails on upstream main as well (88c7e03, 04df08d). The texture read now expects the mark and the sampler read the plain index. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016qteK29T18U8p1c9LsVY8g
Owner
Author
|
The fix is in 1550f95 on this branch. The case now expects the marked texture read and the plain bounded sampler index, and the test passes locally (7/7). The clang-tidy fix from the Mac follows on top of it. Generated by Claude Code |
1 task done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
NXForge 0.12.0. It brings in nxnative's
mainup to88c7e03, where upstream landed The Legend of Zelda: Ocarina of Time (Switch 2). NXForge now uses upstream's landed code for the game and drops the bring-up pull-request copies it had merged ahead of upstream. The open upstream pull requests stay merged, including seedds#1414 (ATOMG.CAS), and so do NXForge's own features. The release also carries the fuzz crash fix inshader_split.py(a damaged NARC or NDSR pack is now a red line, not a crash). The CHANGELOG 0.12.0 entry has the full notes.Tom asked to ship now. seedds#1464 and upstream's HMMA title-movie speed-up landed after this merge and wait for the next rebase.
Checked
make -C dm/gfx/tests runandmake -C dm/host/testspass on the Mac withGAME=0400486024DEC000, at d23cb67 / 9133c0f. 3143f65 only reverts 9133c0f'sDM_DISPLAY_MAX.scripts/release_check.py check 0.12.0passes, and so doestest_release_check.053e94e1fda9): 42,853 of 42,854 shaders translate, and the one failure is the known 0x481 data. It played a 10-minute Kokiri Forest route on the same save as the 0.11.0-based app. Results against that app:Docs
dmsh_chain.hregenerated in 1c32f68Generated by Claude Code