So I have a scene that is pretty heavy on memory, it´s rendering perfectly fine in 2.79.6, latest daily build, but in current Beta (Beta from today, December 2nd) it giving me an out of memory error.
Here you can see an screenshot of the console error, I tried to render it three times.
I want to send you the full project when we finish it so you can investigate with that kind of project, because it also hangs Blender when I try to go to look&dev mode, I´m not sure if it hangs up to the infinite or if it recovers at some point, but the thing is that it beyond something workable, but right now I´m not able to share the project, to many GB.
Is there a way for me to send you something to give you a bit more information related to this?
BTW this is with CPU rendering, no GPU involved.
I have a bit more info.
The scene is making heavy use of adaptive tesselation, so in the phase of “coying patches” it fills the system memory, the whole 64Gb, and after a while it crashes saying “out of memory”
This does not happens in 2.79.6, I think this has to be related to this, since subdiv has been reworked completely with OpenSubdiv, hope this helps a bit.
And now I can say that something weird is going on, after lowering the dicing quality up to 8px and max subdivisions to 5, it also crashed (not Blender crash, but cycles) to Run out of memory in the “Copying Patches” phase, hope this helps a bit, tell me if I can do something more.
And now some more news:
After disabling adaptive subdivisions and limiting the amount of subdivisions it renders, but in Peak Memory Usage Blender says 34Gb, while my sistem has 60Gb of RAM filled up.
I´ll upload the same scene from Blender 2.79.6, but the peak memory there is around 24Gb of RAM, and the system ir around 45 or something similar, I´ll post it later, but something is going pretty bad with memory in Blender 2.8 because Cycles is eating A LOT more RAM, and also there is some trouble with subdivisions, specially with adaptive ones for sure.
Tesselation is SO MUCH faster in 2.79.6!!!
That picture is just after doing the adaptive tesselation, the time is less than 7 minutes in total, while in 2.8 this happens after 20 minutes!!
Also, here is the system snapshot while doing the actual render:
As you can see render is starting after just 8 minutes!!!
Also Blender peak memory is aroung 24Gb as I said, and the system memory is at 55Gb of usage.
Why is this difference happening?
Why is Blender taking so much more memory in 2.8 than 2.79.6, and also Cycles?
Hope this helps!
Tessellation in 2.8 is not working well yet. It should disable the subdivision modifier, but that is not happening currently. Right now it applies the tessellation onto an already subdivided mesh, which is slow and memory hungry.
Ok, but does it happens to when I disable the Adaptive Subdivisions?
Because my last test, the one I managed to render, is eating a lot more memory than 2.79.6 anyways.
Cheers and thanks for answering!
quickly looking at the tessellation code in cycles shows, it uses OpenSubdiv if that option has been enabled in the CMake settings. My further finding with OpenSubdiv was, if it additionally was enabled for the Subsurf modifier, it drastically slows things down. For example a simulated scene with 2x subsurf modifier in the stack ran with 14-15 fps without opensubdiv, and at 1 fps with opensubdiv. Probably a lot of unnecessary / intense calculations happen there, which not also might be slow, but also memory intensive.
I am not exactly sure whether adaptive tessellation in cycles actually works without “WITH_OPENSUBDIV” enabled in cmake, but quickly glancing over the cycles tessellation code lets me assume this.
So my suggestion would be to build 2.8 without “WITH_OPENSUBDIV” enabled and test your scene or a similar setup with it.
Btw, WITH_OPENSUBDIV is now enabled by default in the release config, which the buildbot actually should use to produce its builds.
I have my build VM in a bad state right now, but I´ll find some time to put it up and running again and I´ll test this, but in any case, since 2.8 will run over OpenSubdiv always, this should be tackled down, because people won´t know this at all, but thanks for the idea, this could help me to start using 2.8 even with this project.
Sigh, just found out the older (faster, Working!!!) subsurf modifier code was Removed here
https://developer.blender.org/rB9abcf56fa88dd849bf0f83fafe5d4666d3531cd2 and replaced by a stutter-lagfest (for now) . This is not ok from users perspective. Atleast the replacement should be equally well working before actually removing the original. And imho the user perspective / experience is the only thing that matters. Since this is supposed a software from the community for the community !
Same really bad decision as with carve boolean, but thats another story…
Dunno whats with the cycles adaptive tessellation without opensubdiv as well…
So the point is, maybe switching off WITH_OPENSUBDIV is not producing something useful anymore in the regard of subsurf mod and / or tessellation in cycles.
I seem to be having a similar issue. Everything’s fine in 2.8 (version downloaded a few weeks ago) until I introduce displacement to the material, at which point the adaptive subdivision promptly takes up my computer’s entire memory, usually getting stuck on “copying patches to device.” Does anyone know if a fix is coming? Or did it already come and I just need more RAM? I can send my project file if you want.
I think this is something in the @sergey playground, maybe he can clarify something.
Definitely get a new 2.80 download and try it again. If you’re seeing this issue when doing Rendered display mode in the 3dview, then that problem has been fixed!
… and replaced by a stutter-lagfest …
Yet it behaves 2x faster on a character rigs for Spring. Can’t say this is a good presentation of things.
… at which point the adaptive subdivision …
I think part of the issue here is that there is no API yet for Cycles to temporarily disable subdivision surface modifier. So, effectively, subdivisions are applied twice. This is a high-priority issue to be addressed and reported as T63483 (the report is not specifically about Cycles, but is about API used by it and addons).
There are other sources of increased memory usage, for example T58251. All such issues will be addressed, no worries with that.
Do you have linked objects in your scene?
@DanielPaul, I do (it’s a landscape scene with grass and rocks strewn about). However, the main problem seems to be with the displacement modifier on the ground mesh itself. It renders just fine in the preview with dicing at 9px (multiplier=1), but in the actual rendered image, I have to increase the dicing to ~15px in order to not crash. @Zoot, I will try downloading the latest version.