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
- Out-of-bounds memory access with multiple CanvasRenderers under a Canvas when using Mesh API
- Inspector tries to access file after it was deleted when the file was locked in Inspector window
- Changing Transform values in Search window Inspector loses focus while dragging and stopping mouse without releasing dragging action
- Saving changes on the dirty VFX Graph during the Play mode throws "The referenced script (Unknown) on this Behaviour is missing!" warnings
- VFX Graph Debug Info overlaps the "Initialize" block debug info by default
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.