2.78b became slower on render and more vram consuming #50662

New Issue

Yegor · 2017-02-12T17:16:54+01:00

Yegor commented

2017-02-12 17:16:54 +01:00

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 https://www.blendernation.com/2017/02/10/blender-2-78b-brings-10x-cycles-speedups/
I'm not sure if I should report it here or you already know this.

**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 https://www.blendernation.com/2017/02/10/blender-2-78b-brings-10x-cycles-speedups/ I'm not sure if I should report it here or you already know this.

Yegor commented

2017-02-12 17:16:54 +01:00

Changed status to: 'Open'

Yegor commented

2017-02-12 17:16:54 +01:00

Added subscriber: @YegorSmirnov

Sergey Sharybin was assigned by Aaron Carlisle

2017-02-13 00:03:46 +01:00

Sergey Sharybin commented

2017-02-13 09:32:37 +01:00

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:

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: ![Blender278b.png](https://archive.blender.org/developer/F484577/Blender278b.png)

Yegor commented

2017-02-14 01:24:01 +01:00

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.

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.

Sergey Sharybin commented

2017-02-14 09:53:28 +01:00

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.

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.

Yegor commented

2017-02-14 11:29:08 +01:00

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

Sorry about that. Here's the file{[F485171](https://archive.blender.org/developer/F485171/benchmark.blend)}

Sergey Sharybin commented

2017-02-14 17:12:44 +01:00

Did some tweaks in af1e48e 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.

Did some tweaks in af1e48e 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 commented

2017-02-15 13:02:54 +01:00

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

blender-admin commented

2017-02-15 15:21:15 +01:00

This issue was referenced by efbe47f9cd

This issue was referenced by efbe47f9cdb60761ade99094af3cb8f997c3255d

Sergey Sharybin commented

2017-02-15 16:25:00 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2017-02-15 16:25:00 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.78b became slower on render and more vram consuming #50662