Memory leak with GPU subdivision on rendering #100969
Operating system: Linux-5.15.0-47-lowlatency-x86_64-with-glibc2.35 64 Bits
Graphics card: NVIDIA GeForce GTX 980/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.141.03
Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-09-09 22:58, hash:
352d55b1c8 and older versions after 3.02
Worked: (3.01 and older)
Short description of error
While rendering an animation on a blender version newer than 3.0.1, GPU Subdivision causes
blender to leak the memory and crashes while rendering significantly slower.
I found this out after stripping down my project to this test file and removed almost everything unrelevant.
The shrinkwrap-modifier of the "Dress"-object, targeting the animated "Body"-object seems to cause the error.
The shrinkwrap-type doesn
t seem to make any difference. It seems to happen only on animated targets -like this*"Body"*-object. However, the other shrinkwrap-modifier on the*"Belt"*-object doesnt cause any problem......
Here are some Compairison, rendering up to frame 100 between:
... and 3.30 LTS
(Rendertimes on top of the images)
On my computer, it crashed after overflowing both virtual (swap) and physical memory (around frame200).
Exact steps for others to reproduce the error
*2. Select Menu Render-Render Animation (Ctrl-F12)
*3. Open you taskmanager and watch the memory usage. Let it render for some time. The memory shoud go linear up, until it crashes.
*4. (after crash..) Re-open blender and the file.
*6. Disable shrinkwrap-modifier on realtime and rendering.
Now it shoud work.
Note. if you don`t do step.4 and re-open Blender, there is a change that the memory is not cleared up. However, it shoud not go lineary up like the first time.
*8. Try the same with the "Belt"-named Object. It shoud not make any differences..
Thats It. I hope, this was helpfull.
Changed status from 'Needs Triage' to: 'Needs User Info'
I can't reproduce the memory leak myself after rendering 100 frames, also can't detect the leak through memory tracing.
If I understand correctly, this only happens when rendering, not playing the animation or doing anything else.
Does this happen for EEVEE only or also Cycles?
Yes. It only happens during the rendering process. Not during the preview.
It primary happens on EEVEE, and as I found out on WORKBENCH to. (the Rendering-Resolution doesn
t make a difference) On Cycles, however, it doesnt seem to happen as far as i coud test (The Memory doesn`t seem to go up).
Again. It happens on every Blenderversion that I`ve tested, newer than 3.01 - Including the 3.4.0-alpha that i have downloaded a few minutes ago;)
Note: I only have 16GB RAM. Depending on you Memory-Size, you may not notice the Memory-increase during the first 100 frames.
During my tests. The memory increases linear about 7.6GB after rendering 100 frames on both EEVEE and WORKBENCH.
Hope this helps.
I can't replicate on either EEVEE or Workbench.
Could it be that your
/tmp directory is mounted on RAM? Does changing the output directory resolve the issue?
No. It doesn`t.
I changed everyting in the "File Pahts" to a path on my harddisk. It changes nothing.
I also tested everything on a different Machine with Windows10 -also with 16GB RAM- .
I downloaded the latest build of Blender 3.4.0-alpha from there and loaded the file.
The results where the same as on my ubuntu (Memory goes linear up during the rendering):
During this evening, i managed to create a more simple testfile just using the default objects after testing and trying a lot.
It produces exactly the same issue, but even more efficient.
Just open the file and select "Render Animation"
On blender 3.41Alpha and 3.30LTS. It crashes around frame 15
And if you brake up the rendering -like I did here on frame 13- the memory stays high and doesn`t go back immediately.
at least on my 16GB RAM- Machine...
If you don`t see anithing on you one, try to increase carefully the first Subsurf-modifier on the Suzanne-Object.
Again, Good luck.
I hope this helps.
I feel like this might be due to GPU Subdivision, which I don't have enabled. Can you try if the issue still happens with
Preferences > Viewport > Subdivision > GPU Subdivision disabled?
Thanks so far:)
Changed status from 'Needs User Info' to: 'Needs Triage'
Good to hear. My GPU doesn't support GPU Subdivision, that's why I couldn't reproduce, so I will leave this to someone with the needed hardware.
Changed status from 'Needs Triage' to: 'Confirmed'
I can confirm the constant increase in memory (resembling a leak) and consequent crash.
In fact it seems to be related to the GPU subdivision (although without this option there is also a very slight progressive consumption of memory).
I just encountered this bug as well. Here is a minimal blend file which reproduces the leak (with GPU subdivision enabled).
However I have found a strange workaround, the bug only occurs when the target object has the subdivision modifier in the last slot. If there is another active modifier after the subdivision, the bug does not occur. In the attached blend file I have put an array modifier in the last slot of the object that is the target of the shrinkwrap and I have left it disabled, but if you enable it and render animation, the bug disappears.
@Jacob9 that is expeceted. GPU subdivision only kicks in when the subdivision modifier is the last modifier.
I will check with ASAN if I can find anything.
Unassigning for now as my linux system needs to be reinstalled.
@Jeroen-Bakker, I quickly investigated, the leak is because we garbage collect the subdivision caches, but the caches are only freed at the end of the animation render (via
DRW_cache_free_old_subdiv()). We would need to free the caches at the end of each frame, but I am not really sure where would the best place for that be.
@kevindietrich thanks for looking into this. In the viewport this is done just after drawing a single view.
For viewport animation and final render we could do it at the time the results are downloaded.
This issue was referenced by
This issue was referenced by
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?