Search Issue Tracker
By Design
Votes
0
Found in
2022.3.50f1
6000.0.22f1
Issue ID
UUM-84438
Regression
No
[URP][Comp] Buffers (depth, color) are not released when the renderer in the render pipeline asset is changed
Reproduction steps:
1. Open the attached “BugRepro” project
2. Open the “Assets/Scenes/RendererDataChangeTest.unity” Scene
3. Enter the Play Mode
4. Click the “Renderer Data x” buttons in the Game view
5. Open the Memory Profiler (Window > Analysis > Memory Profiler)
6. In the “Memory Profiler“ window, click Capture
7. Open the captured snapshot on the left of the Memory Profiler
8. Go to RenderTexture (UnityObjects -> RenderTexture)
9. Check RenderTextures in the snapshot
Expected result: There should be no leftover Depth and Color Attachment buffers after switching renderers
Actual result: There are lots of Depth and Color Attachment buffers
Reproducible with: 2022.3.50f1, 6000.0.22f1
Couldn't test with: 2021.3.44f1 (there is no Memory Breakdowns feature)
Reproducible on: Windows 11
Not reproducible on: No other environment tested
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- GPU utilization increases by 20% on Meta Quest headsets when Render Graph is enabled on 6000.0.16f1 and higher
- Value on Slider (Int) control in UI Builder displays as default when saving UI Document
- Color mismatch in UI Builders Library panel when the Editors theme is set to Light Mode
- [Android ] "AndroidJNI.ToBooleanArray" returns a random non-zero value instead of "IntPtr.Zero" when the method argument is null
- Non-HDR color picker opens when selecting material color with HDR enabled
Resolution Note:
The ScriptableRenderer class allocates its own resources (i.e. per-camera attachments) whenever they're first used by a Camera (which is what you're seeing whenever switching renderers). The allocations stop as soon as all the renderers have been used at least once, so this growing memory issue is just the result of the lazy initialization of the ScriptableRenderer resources.
If you want to keep memory to a minimum, you can always call 'cameraData.scriptableRenderer.Dispose()' to make sure its resources are freed, before any further calls to 'cameraData.SetRenderer(rendererIndex)'. Just keep in mind that you could run into issues if the disposed ScriptableRenderer is being used by a different camera/system.