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
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution 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.