Page MenuHome

2.78b became slower on render and more vram consuming
Closed, ResolvedPublic


System Information
Debian testing, Nvidia GTX 780

Blender Version
Broken: 2.78b
Worked: 2.78a

Short description of error
2.78b became slower on render and more vram consuming in comparison to 2.78a

Exact steps for others to reproduce the error
Take any scene with textures and representative render time (not too small). I've tested it without motion blur, but with hair and sss shader.
Some other guys confirm that as well
I'm not sure if I should report it here or you already know this.

Event Timeline

Sergey Sharybin (sergey) lowered the priority of this task from 90 to 30.Feb 13 2017, 9:32 AM

This is not a valid bug report: please follow bug report guidelines and include all information requested there. Especially be as detail as possible about your exact system configuration (exact CPU, memory, whether it's CPU or GPU render). Make sure you test on some known file (like official benchmark file).

We can't fix issues which we can't reproduce and as far as speed comparison goes on our machines here we do not experience any slowdown in scenes with representitive render times:

Oh man, after digging a while, i've found it!

If object has a custom split normals data and auto smooth enabled, 2.78b gives a big gap in memory consumption and a small one in render time in comparison to unchecked "auto smooth" or cleared custom split normals data. 2.78a does not!

Tell me if it's a bug or not.

The way how we handle auto-split in Cycles indeed changed now. There might be some issue there, but hard to tell without a file.

Once again, please attach file which demonstrates issue for you.

Sorry about that. Here's the file{F485171}

Did some tweaks in rBaf1e48e and the memory usage should be lower now. It is still higher due to the fact that auto-split now happens on Blender side, but this is likely as low as we can have without rolling back to an old behavior when we were not sure about match between Cycles and Blender.

As for render time, synchronization time might take some more time, but there should not be affect on the actual render time. Please test timing with lots of samples using nightly build which will include that commit.

Sergey Sharybin (sergey) raised the priority of this task from 30 to Normal.Feb 15 2017, 1:02 PM

Found a bug in the optimization commit. Gonna to re-iterate over the fix.