Search Issue Tracker
By Design
By Design in 6000.0.X
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
- VFX Graph Documentation dropdown button does nothing when clicked on the right side
- Required SpriteMask class (ID 331) is stripped when "Strip Engine Code" is enabled
- “Maximized serialized file backup not found” error is thrown when minimizing a window in a newly opened project
- Build stack trace contains invalid lines when building with IL2CPP using scripts with delegates containing generic types in the signature
- Entities Systems window has a “Show Full Player Loop” dropdown which does nothing when clicked after enabling “Show Full Player Loop”
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.
Resolution Note (6000.0.X):
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.