Page MenuHome

Animation render seemingly not freeing up memory (2.90.0 Regression)
Closed, ResolvedPublicBUG


System Information:
Operating system: Linux-5.4.0-7634-generic-x86_64-with-debian-bullseye
CPU: Ryzen 9 3900X

Blender Version:
Broken: 2.90.0 rBfdfe85c616d2 (2020-06-22 15:41)
Worked: 2.83.0, 2.90.0 rBe079bf6996fc (2020-06-17 20:49)

Short description of error:
When I render an animation in Blender 2.90.0, Blender's memory usage continues to climb as each frame is rendered. Even when the animation is finished or canceled, the increased memory consumption is still there almost as if information from previous frames isn't being freed (It seems like it's probably BVH information). This issue does not occur in Blender 2.83.0 and older versions of 2.90.0.

Memory consumption when rendering a single frame when comparing 2.90.0 and 2.83.0 are very similar. This only really seems to affect animations.

For example, after rendering 20 frames from the animation file listed below, this is the memory usage of Blender:


Exact steps for others to reproduce the error

  1. Create a scene with lots of geometry (You can download a scene below)
  2. Set the render engine to Cycles with CPU rendering. (CUDA doesn't show this issue from my tests)
  3. Render an animation and monitor the memory (RAM) usage of Blender 2.90.0 compared to 2.83.0 using an external program like system monitor or top in the command line. Blender 2.90 should see the memory just continue to increase while 2.83 does not exhibit this behavior.

Bisecting points to a commit between rB99436acde8fb and rBf9d138be51e6 but I can't pin point it.
Testing with BVH2 (to avoid Embree) still shows the increased memory consumption.

Event Timeline

Alaska (Alaska) updated the task description. (Show Details)

Bisecting points to something around the TBB adjustments and Embree implementation is causing issues.
Somewhere between rB99436acde8fb and rBf9d138be51e6
I can't pin point the exact commit as I experience build issues around this area and weird rendering bugs. So all I know is the bug is from that area.

Testing Blender with BVH2 in these later builds still experiences issues. So probably TBB? I'm not sure.

Playing around with a few more scenes, I have been unable to replicate this bug.

So their's something in that file which causes issues. I've tried getting rid of the instanced meshes, didn't help.
I might start an investigation into individual objects and modifiers to try find the cause. But that will have to be delayed to tomorrow.
Maybe someone with a debugger attached to Blender would have a better time trying to figure this one out.

Brecht Van Lommel (brecht) changed the task status from Needs Triage to Needs Information from User.Jun 23 2020, 1:21 PM

How are you measuring memory usage?

The number reported by Blender? Virtual, resident or shared memory reported by the system?

Alaska (Alaska) added a comment.EditedJun 23 2020, 1:32 PM

@Brecht Van Lommel (brecht) The memory usage reported by Blender seems to stay at a constant 4GB while rendering and drops down to 2GB after rendering.
However, monitoring memory used by Blender using the system monitor bundled with Gnome shows Blender using the 17GB after rendering 20 frames and total system RAM consumption at ~19GB with 2.90.0.
This does not occur in 2.83 or older versions of 2.90.

Alaska (Alaska) added a comment.EditedJun 23 2020, 1:52 PM

I'm most likely monitoring resident memory with the system monitor.

Brecht Van Lommel (brecht) changed the task status from Needs Information from User to Confirmed.Jun 23 2020, 2:04 PM
Brecht Van Lommel (brecht) triaged this task as High priority.
Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Bug".
Alaska (Alaska) added a comment.EditedJun 24 2020, 6:44 AM

After testing a bunch of different scenes and being unable to reproduce the bug, I tore apart my original scene to find the culprit object or modifier or whatever.

Having an object with lots of geometric detail (whether naturally high poly or through modifier) seems to cause this bug. I'll update the original report to reflect this.