Uh oh!
There was an error while loading. Please reload this page.
Fix 8 MB/frame depth-snapshot transient leak (translucent pass) - #77
Fix 8 MB/frame depth-snapshot transient leak (translucent pass)#77proggeramlug wants to merge 1 commit into
Conversation
…e leak The translucent pass acquires TWO transients when a refractive material is on screen (scene-colour + depth snapshots) but released only the colour one. The pool has no auto-reclaim by design, so every frame: - the still-in-use depth slot can never be reused, - acquire() allocates a brand-new render-res Depth32Float (~8.3 MB at 1920x1080 — ~370 MB/s of driver allocation churn at 45 fps), - the slot vector grows by one forever (linear scans slow down too). This was the round-2 audit's "translucent_pass CPU mystery" (F7): the bracket climbed 0.4 ms -> 6.7 ms over ~50 s in every session, tracking RUN TIME, not scene load. Measured with the audit's instrumented combat build, same workload, before vs after: before (leaky): 750 us at t=8, dipping then climbing to 1144 us at t=58 and still growing after (fixed): 30-46 us, flat for the entire run (~16-26x) On the 4 GB shared-memory dev iGPU the unbounded VRAM growth is also a plausible contributor to long-session instability (EN-020 heap pressure). Also: - transient pool: leak watchdog — warn at every power-of-two slot count past 64, naming the acquire-without-release failure mode. This exact bug cost a day of profiler archaeology; the next one costs a log line. - docs/tickets.md: EN-023 (GI software path — colored bounce is unreachable on non-RT adapters; measured achromatic <=2.5%).
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
proggeramlug
commented
Jul 8, 2026
Landed in main via the round-2 consolidation merge (#83). All commits from this branch are now on main; closing as merged-through-integration. |
Stacked on #75. Root-causes and fixes the round-2 audit's biggest unexplained perf item (F7).
The bug
scene_pass.rsacquires two transients when a refractive material (the shooter's water) is on screen — scene-colour and depth snapshots — but released only the colour one. The transient pool has no auto-reclaim by design, so the still-checked-out depth slot could never be reused: every frame allocated a fresh render-res Depth32Float (~8.3 MB) and grew the slot vector by one, forever. ~370 MB/s of driver allocation churn at 45 fps on a 4 GB shared-memory iGPU, plus ever-slower linear slot scans.Why it looked like a mystery
The audit measured
translucent_passCPU at 0.4 ms on the title screen, 2.8–4.7 ms at a mid-run pose, 6.4–6.7 ms in combat — it looked load-correlated. It was run-time-correlated: every measurement later in a session sat higher on the same growth curve.Before / after (same instrumented combat build, same workload)
~16–26× on the bracket, and the unbounded VRAM growth is gone (likely also relevant to EN-020's heap-pressure profile on long sessions).
Also in this PR
Suite green: 99 lib + 7 golden.