The review of the hang watch found that kernel.c kern_wait_report called rt_log for up to 16 lines while it held the
kernel lock G. When the log queue is full and the log thread is stuck holding its write lock, one of the stalls the
watch reports, the put that drains the queue waits there with G held, which turns a log stall into a freeze of every
guest thread. wait_watch (NX2NAVI_WAIT_WATCH_S, off by default) had the same pattern.
wait_pass now formats its lines into a buffer of the caller's (WAIT_LINE_CAP bytes a line, room for the 16 or 24 lines
asked for), and kern_wait_report and wait_watch log them with the new wait_lines_log after unlock. A line that finds
no room ends the pass unmarked, so wait_watch logs it at its next pass. The lines read as before.
Not reproduced before the change (it needs a stalled log thread beside a report). tests/hang_watch_check.py checks
statically that wait_pass logs nothing and that both callers log only after unlock; the check fails on the code
before this change and passes after it, and the program's cases pass. The compile check of kernel.c passes with no
-Wall warnings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A present, a submission or a completion that never came back (a deadlock, a driver wait that does not return, a
GPU hang without a reset) left a log that just stopped: kernel.c wait_watch covers guest lock and thread-end waits
only and is off by default, and nothing watched the present, submit or completion threads.
hang_watch.c runs a thread of its own in a game run (main.c starts it before the boot; never in the tool modes).
Once a second it reads, without a lock, gfx_counters.frames and the submissions issued and done (the new
vk_sync.c vk_sync_progress, no device call). It reports a stall of the frames while the guest runs, the window is
in front and not minimized (gfx_window_in_front) and no orderly end has begun (rt_exit_started): the game stops
presenting without the focus, so a focus change starts the count again, and the boot screen is not judged. It
reports submissions issued and not done, "done" unchanged for N s, whatever the focus. One report per stall, a
new stall needs progress, at most 3 a run. A report names the stall with the counts, the focus and the world
clock; who holds the present, queue and window-start locks (gfx_present.c gfx_lock_holders, read from
PlatRMutex.owner and depth); the guest threads' lock and thread-end waits (kernel.c kern_wait_report, wait_watch's
walk factored out as wait_pass, run with limit 0 under ten 10 ms trylocks of the kernel lock); and then writes the
log out with logq_flush, never rt_log_sync, which would put every later line on the thread that logs it in a run
that may recover. It never ends the process and adds no wait to a drawing thread. The per-thread wait sites and
lock owner wrappers are left for a later change.
NX2NAVI_HANG_WATCH_S sets the seconds (default 20, 0..600, read at start, 0 off): a metas row, a known[] name, a
diagnostics sections[] entry and an nx2navi.ini.example entry.
Not reproduced before the change (a diagnostic). The new tests/hang_watch_check.py drives hang_watch.c's decisions
on made-up readings: no report while things move, unfocused, minimized or ending; one per stall of the frames with
the window in front and one again after progress; one for submissions not done whatever the focus; none for an
idle GPU; at most 3; logq_flush called and logq_sync never. tests/cfg_rows_check.py (0 problems), the scratchpad
rows check ("missing []") and the compile checks of every runtime file pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The review of the system-event change (Ev-1) found the table still filling. Entries in host memory now count as live
for good in the full-table scan, but their objects are freed: ov_movie2.c ov_dtor freed the Video with in_ev and out_ev
still bound, so each decoder left two dead entries that nothing reclaimed (AUDIT F-1-08 measured about two entries per
reload of a save, which E-4's verifier tied to the decoder pair), and their four kernel handles stayed open. A long
session would end with "kern_bind_system_event: table full" once no dead guest entry was left to take.
kernel.c gains kern_unbind_system_event(c, ev). On a guest thread it calls the SDK's nn::os::DestroySystemEvent, which
zeroes the state byte and closes both handles, and then removes the entry under g_se_lock (the last entry takes its
place). The destroy comes first, so a signal still in flight finds the event destroyed or its handle no longer naming it
and skips it, rather than finding no entry and binding again on a host thread. Off a guest thread, or when the SDK lacks
the function (logged once), only the entry goes. ov_dtor calls it for each bound event after finalize has joined the
decoder and convert threads, then frees the Video. net_offline.c frees its HostTask with a bound event in the same way;
that file is outside this change and is handed to the coordinator.
Not reproduced before the change in a game run. tests/system_event_check.c fills the table with live guest events and
the movie's two host-memory events, unbinds one: it leaves the table, its handles are closed and its state byte is 0,
the other keeps its entry, and a second unbind changes nothing; with the table full again and the last host entry
unbound, a new guest bind succeeds where it would have ended with "table full". The check passes in both modes,
movie_planes_check passes, and the compile check of every runtime file (host.h changed) passes, adding no warnings in
kernel.c or ov_movie2.c with -Wall -Wextra.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gfx_vsync_bind kept every SystemEventType address the game ever passed to GetDisplayVsyncEvent, never dropped one, and
called rt_fatal on the 17th distinct address. A destroyed event also stayed on the list the vsync thread signals 60
times a second. kernel.c now exports kern_system_event_live (mapped guest memory with a nonzero state byte), and with
the list full gfx_vsync_bind gives the first slot whose event is no longer live to the new one, which also takes the
destroyed event off the vsync thread's list; it stays fatal only when all 16 are live. Each new listing logs
"gfx: vsync event ... bound in slot N, M listed", so a long session's log shows how often new addresses come.
Not reproduced before the change: the fresh 0.10.0 session's system event count stayed at 9-10 across its area loads,
and no log here covers returns to the title. tests/vsync_bind_check.py cuts gfx_vsync_bind from gfx_present.c with a
stub liveness check: a 17th event takes the first destroyed slot, an 18th the next, and with 16 live events the 17th
still ends with the fatal. system_event_check now also checks kern_system_event_live. The compile check of every
runtime file passes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SendSyncRequest looked the session up with kern_handle_get, which holds the kernel lock only for the lookup, and then
dispatched to the handler with no reference. A CloseHandle of the session's last handle on another thread meanwhile
reached ipc_handle_closed, which ran the close callback and freed the session while the handler still used it; for
the audio renderer, renderer_close joins the render thread and frees the renderer a RequestUpdate is reading.
OpenAudioRenderer read the transfer memory the same way, and a CloseHandle frees that object at once.
kernel.c gains kern_handle_hold, which runs a hold callback under the kernel lock after the lookup (handle_close
clears the slot under that lock before it calls ipc_handle_closed, so a close either comes first and the lookup
fails, or comes after and finds the extra reference), and kern_handle_copy, which copies an object under the lock.
ipc_svc takes the session with kern_handle_hold and drops the request's reference through ipc_handle_closed after the
answer, so the close callback runs on whichever thread drops the last reference; the request thread holds no service
lock by then. audren.c copies the transfer memory into a local IpcTransferMemory. Domain sub-objects are not freed
yet (IpcSession.objects), so their lookups are left for the domain object change.
Not reproduced before the change in a game run (no log shows a renderer closed during play). tests/ipc_session_check.py
builds ipc.c with kernel.c linked: a request whose handler blocks while another thread closes the session's only handle
must leave the close callback until the handler returns, and a closed transfer memory handle must copy nothing.
Against the previous ipc.c it fails with the close callback run while the handler was blocked. system_event_check,
sync_wake_check and the compile check of every runtime file pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kern_signal_system_event read the table entry and the state byte without the kernel lock, then kern_event_signal took
the lock and ended the process when the kept writable handle was no longer an event. A host thread (the vsync thread
signals every bound vsync event 60 times a second) racing the guest's DestroySystemEvent, which zeroes the byte and
then closes both handles under the kernel lock, hit that fatal; a probe built on kernel.c reached it after 437
destroy and bind rounds. A stale entry whose byte reads nonzero again ended the process at once, and since h_new hands
a closed number to the next new object, a stale entry could also signal or clear an unrelated event.
Each Event now gets a serial number, and kern_bind_system_event records the serial of the Event its writable handle
names. The new system_event_set reads the entry again under the kernel lock and sets or clears the event only while
the handle still names that same Event; a stale entry is skipped and logged once. kern_clear_system_event goes through
it as well. The lock order is G before g_se_lock; the binder never holds both.
The full-table path of kern_bind_system_event took any entry whose object mem_readable did not know, which includes
the live events host services keep in their own memory (ov_movie2.c Video.in_ev/out_ev, net_offline.c
HostTask.event). The service's next signal from its host thread then found no entry and tried to bind there, which is
fatal. Entries now record whether the object lies in guest memory, and only guest entries that were destroyed or
unmapped give their slot.
tests/system_event_check.py builds kernel.c with stubs and checks a destroyed event with its byte nonzero again, a
closed number taken by an unrelated event, two seconds of a host thread signalling and clearing against a guest
thread destroying and binding again, a full table with the movie's two host-memory events, and the "table full"
fatal with every entry live. Against the previous kernel.c it ends with "kern_event_signal: 0x1001 is not a writable
event handle". sync_wake_check and thread_end_check pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A session of 2026-11-13 grew from 683 to 1095 OS handles in 11 minutes, rising at every area load and never falling,
while the guest's own handles stayed at 116-122 and the threads flat; the VMA block count fell back while the handle
count did not. The log could not show it: the 600-frame "mem: sizes" line had only the guest's handles, and nothing
told which kind of handle grows.
kernel.c kern_sizes now adds "process handles" (plat_handle_count, one system call every 600 frames under trace=perf)
beside the guest's "handles". platform.h gets plat_handle_census: on Windows the system's extended handle table
filtered by our process id, with the type names from NtQueryObject's ObjectTypesInformation; on Linux the
/proc/self/fd links grouped by kind. It never opens, duplicates or names a handle (a name query can block on a pipe).
With NX2NAVI_HANDLE_CENSUS=1 (default 0, read at start) and trace=perf, perf.c starts one long-lived thread that the
600-frame report wakes; when the count grew by 16 or more since its last census it logs "mem: handles frame N: T in
all (+D since the last census): Event a (+x), ...". The census reads a few MiB of the system's table in 2-5 ms, off
the drawing threads; one thread for the run keeps a new thread's own handle out of what it counts. New cfg rows:
HANDLE_CENSUS in known[], sections[] (diagnostics) and metas[] ("0", "0|1", restart), and an nx2navi.ini.example
entry.
New tests/handle_census_check.py builds the platform layer alone: 20 events and 5 sections show as Event +20 and
Section +5, the total stays within 2 of GetProcessHandleCount, the figures return once they are closed, and kinds
past the room given go into the last entry; docs/building.md describes it. Not reproduced before the change (the
growth needs a game run). handle_census_check, sync_wake_check and the cfg row check pass; every runtime file compiles
with the dev flags, and perf.c, kernel.c, win32.c and cfg.c add no -Wall -Wextra warnings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The watch's thread takes the kernel lock every two seconds to look at every guest thread; a release does not need it running, and wait_watch_s = 10 turns it on again for a hang report.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A game that stops with nothing in its log leaves no clue to which threads wait for which. A thread of its own now
looks every 2 s for guest threads blocked that long on a lock (ArbitrateLock) or on another thread's end
(WaitSynchronization on a thread handle) and logs each such wait once: the waiter, the lock's holder or the thread
waited for, and whether that one is itself waiting and on what. Waits on condition variables, events and addresses
are left out, since idle worker threads wait on them for good. At most 24 lines a run. NX2NAVI_WAIT_WATCH_S sets the
threshold (10; 0 off). The wait's start is now kept for every blocking wait, not only under the sched trace.
Checked: the runtime compiles and tests/sync_wake_check.py passes. A 90 s run with WAIT_WATCH_S=1 logged one chain
during an area load ("thread 0x102d has waited 3 s for the lock ... held by thread 0x105a, itself waiting 2.6 s"),
and nothing in steady play; with the default of 10 s, earlier runs log nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Verified by runs in the audit: the Market's periodic stall (a pool slot was listed once per refresh pass instead of once; the list fell from 160,385 entries to at most 3,192 and no frame over 20 ms remained while standing), orderly exits delete the pipeline prebuild's running marker (left behind, the next start wrote a skip file and every later start skipped the prebuild), the log and crash report name an area a save asks for that the game does not have, and the menu atlas hash no longer overflows a signed multiply. The other fixes compile and pass the regression route but their faults were never reproduced: see AUDIT.md section 13 for each.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
With fewer than six virtual cores a thread pinned to a core at or above the count runs on core (c mod count), and GetCurrentProcessorNumber told it that virtual core's number. The game keys per-core data by the number without locks, so with four cores a thread pinned to core 5 used core 1's data in turn with core 1's own threads, and the game died within seconds of the first frame in play. The Steam Deck profile sets four cores, so this was every start under that profile (issue #445). The call now answers with one of the thread's own cores that fold onto the virtual core it holds, its ideal core first; with all six cores the answer is as before.
The kernel probe gets a test with two threads pinned to each of the six cores: with 6, 4, 3 and 1 virtual cores no thread sees another core's number and no two see the same at once.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Four "mem: sizes" lines give the entries and bytes of what no other line counted: the guest heap, physical maps, kernel region, lazily written ranges and the fixed kernel, setjmp, save-file, RomFS and zstd tables; pool records, mirrors, deferred destructions, upload and staging buffers, the device address table and the texture, sampler and slot caches; image views, descriptor spares, the completion queue, uniform snapshot arenas, recording copies and pins; and pipelines, layouts, stage libraries, job queues, the shader memory cache and the translator processes. Each subsystem reads its own counters under its lock; settings now count the replaced values they keep. Segment and scene lines say "-" for the world clock before it starts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A signalled kernel event, or a thread that ended, woke every thread blocked in WaitSynchronization. Each woken thread
takes a virtual core before it looks at its handles, asking a running thread of lower priority for its core when all
are held, finds nothing signalled and blocks again. The audio renderer signals its event 200 times a second, so every
thread that waits for a message, a timer or another thread's end did this 200 times a second at the cost of the
threads that were working.
A wait now records its handle list, and a signal wakes the waits that hold a handle of the signalled event or thread.
NX2NAVI_SYNC_WAKE_ALL=1 (or ab) wakes them all as before, and the sched line counts the waits woken and left asleep.
tests/sync_wake_check.py builds kernel.c with the rest of the runtime stubbed and checks the wakes, the timeouts, the
cancel and that none of 4,000 signals to eight looping waiters is lost, in both modes.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
- The mesh stage's storage table starts 0x90 bytes before the end of the 2 KiB constant bank, and all sixteen slots
were written: 0x6C bytes past a stack buffer on every mesh draw. It holds the nine slots that fit.
- The prebuilt runtime is compiled without AVX, so its preemption stub saved only XMM0-15 while the lifted code of
an AVX2 processor keeps data in the upper YMM halves, which the stub's callees may clear. Both bodies are built
now and the one for the processor is chosen at the start.
- After an FSR 3.1 frame generation error the window's swapchain was still AMD's object but went to the plain Vulkan
calls. Swapchain calls follow whose swapchain it is, and a failure takes it down as a switch in the menu does.
- A movie is paced at its own 60 fps under a lower limit too: at 40 fps it ended 25 s behind its sound.
- A lost device left the wait for an upload spinning for good; it ends the run with the device's report.
- The compute pipeline key had four bytes of padding that were hashed and compared, so a prebuilt pipeline could be
missed and built again.
- A thread's TLS pointer was published before the TLS was allocated, so the slot was always 0.
- A fatal exit puts RivaTuner Statistics Server's profile back, and an ini saved as UTF-16 is read.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Found by profiling a play session and reading the kernel and the command recording:
- nvn_api_cmd.c: a released recording copy had its pins uncounted (a walk over every op) and was freed while copy_lock was held exclusively; the main-loop thread waited for that lock 2.8% of its time. The copies are now chained under the lock and freed after it. The walks over a recording's records test a mask of the five op kinds that name pins before calling op_pins.
- kernel.c: SleepThread(0) took the kernel lock and computed the caller's inherited priority, a scan over every blocked thread, also when no thread waited for a core, which is nearly always. It now yields at once then. A wait without a timeout no longer reads the clock.
- nvn_api_obj.c sleep_until: the wait for a paced frame's slot slept coarsely and left the last 1 to 2 ms to a yield loop; the high-resolution wait now takes all but its own margin.
- input.c: the keyboard scan (a system call per key) is reused for reads within a millisecond.
- nvn_api_core.c: the read-lock observer's commit-point address is 1.2.1's and is now only compared there.
- kernel_probe.c: the probe expected three virtual cores and wait type 3 to be refused; the kernel has six cores and implements the 64-bit wait. It now checks both as they are, counts a core number past the cores as a clash without unbalancing core 0, and --probe-kernel passes again.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
(cherry picked from commit a3dbd63878d7d6de096ceb4c25988192b4bce738)
Large compute shaders that no cache holds are built on one background thread after the boot prebuild, smallest first, so their first dispatch no longer compiles them on the replay thread. NX2NAVI_BIG_BUILD_MAX_MB stops that builder once the process has grown by that much: on a 31 GB machine one of these shaders took the process up by 12.8 GB and the game stuttered while Windows paged. The builder takes the queue under its lock and copies each entry out before compiling it, so a shader queued meanwhile cannot free the arrays under it. The same change reports what pipeline-cache.bin gives back, and starts over when the file grows past NX2NAVI_PIPELINE_CACHE_MAX_MB.
A tensor-core program is now tested before its shader is asked for, in both dispatch paths. It runs the stand-in while NX2NAVI_NATIVE_TENSOR is off, and translating it anyway recorded four AI-upscaler shaders of 0.87 to 4.4 million SPIR-V words that this game never dispatches natively. Process memory went from 29.3 GB to 24 GB and the multi-gigabyte builds during play are gone.
The frame-time summary says which part a slow frame went to, and with NX2NAVI_REPLAY_TIME how the replay splits between draws, binds and transfers; NX2NAVI_SVC_SLOW_MS logs the kernel services that block, with the thread they blocked on. prof_report.py reads the map this build writes and adds the image base to a runtime Rip, so a profile resolves to function names instead of question marks.
build_xlate.py applies the patches with GIT_CEILING_DIRECTORIES set to the build folder's parent. Inside a checkout git read 0021-prmt-byte-permute.patch's paths from the repository's top, skipped every file of it and still exited 0, so PRMT was missing from locally built translators and every byte permute was a no-op. A Skipped patch line now fails the build. The note in AmpereLowering.cs that said the translator emits nothing for PRMT is corrected.
- An empty NX2NAVI_SPIN or NX2NAVI_VRAM_HEADROOM in the environment stopped the game: both read the key with
cfg_bool, and an empty value falls back to the settings table, where these keys have no row. Empty now means unset.
- find_ini checked for 10 bytes after the exe folder's separator where "nx2navi.ini" and its NUL take 12, so an exe
path just under 1024 bytes wrote two bytes past the buffer.
- The performance overlay read the clock before taking the lock, so a frame pushed in between was newer than "now",
the unsigned age wrapped and the overlay showed 0 fps for that refresh.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Crashes: the render-target heap (HeapDef DynamicTextureAllocatorMem and its parent) grows with the widescreen
picture, so the pause menu no longer reads a null block at 5120x2160; texture uploads keep the game's memory mapped
while they copy it, so UnmapPhysicalMemory no longer pulls it away mid-copy; DLSS Frame Generation no longer crashes
in Streamline's set-up (physical devices and the window surface go through its proxies, its swapchain images are
counted first, resources are tagged per frame); a stale core-wait target is cleared before its thread is freed.
Freezes and races: a resize during a swapchain rebuild is kept, a failed frame generation swapchain is retried
instead of replaced by a plain one, three acquire timeouts in a row rebuild the swapchain, device waits take the
queue lock, a translator child that stops answering times out, an in-flight compute pipeline builds at normal
priority, a save Commit started before the window closes finishes and none starts after, a settings change just
before closing is saved, and a movie sample taken before a flush is dropped.
HDR: Enhanced HDR extends the game's own tonemap so highlights go above the picture's white (the hue slider,
which no longer applies, is gone from the menu); frame generation gets a HUD-less picture, the HDR flag and the HDR10
metadata under HDR too.
Memory: ASTC textures are encoded to BC3 unless the PC has 20 GiB of VRAM and 48 GiB of RAM, as Windows charges video
memory to the commit charge (a long session held 17 GiB of RGBA8 textures and 45.7 GiB of commit on a 32 GiB PC).
Shaders: the translator lowers spill-mode programs with more than eight uniform register groups in a wider spill
layout, and local loads and stores with a uniform-register address (36029 of the game's 36031 variants translate,
20 failed before).
The launcher release ships the shader tools and AMD's FidelityFX library (make_launcher.py --ffx); windres there gets
the toolchain on PATH.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each file that contains copied code names its copyright holder and license and points at THIRD_PARTY_NOTICES.md; zlib code keeps its full notice and the mark that it was altered. Comments and probe text only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Comments say what the code does and why, docs/maxwell.md keeps the Maxwell facts, and fetch_refs.sh clones only the checkout the build reads. Code is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The NVN2 front end and the SM86 to Maxwell shader lowering (tools/xlate/AmpereLowering.cs, mesh and task stages,
bindless texture pools, BRX jump tables, the NVN2 compute c0 layout) with four translator patches (0017-0020) bring the
opening of the game to 58-60 fps on the Vulkan renderer.
This round fixes the haze: SM86 IPA is lowered as a plain Maxwell IPA.PASS (texture coordinates were corrected for
perspective twice); LDSM, TXD, both F2IP byte forms, HMMA, MOVM and HFMA2.RELU are lowered and spill mode has eight
uniform register groups; conditional rendering keeps the newest counter report per address and treats a report as
pending until its value is in guest memory, so occlusion tests and the depth clears around the depth copy behave; and
the upscaler stand-in decodes the post pass's sRGB picture before writing the linear target. Tensor-core programs keep
the stand-in unless NX2NAVI_NATIVE_TENSOR=1, because their lowering does not match the hardware yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
