Fix 8 MB/frame depth-snapshot transient leak (translucent pass)#77
Closed
proggeramlug wants to merge 1 commit into
Closed
Fix 8 MB/frame depth-snapshot transient leak (translucent pass)#77proggeramlug wants to merge 1 commit into
proggeramlug 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 |
Contributor
Author
|
Landed in main via the round-2 consolidation merge (#83). All commits from this branch are now on main; closing as merged-through-integration. |
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
1 participant
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.
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.