2.8 Branch update with Cycles CPU/GPGPU rendering together

I do not understand much of technicalities, but maybe it’s because thinking about the future (adaptive sampling for example):
https://wiki.blender.org/index.php/User:Lukasstockner97/GSoC_2016/Proposal
https://wiki.blender.org/index.php/User:Lukasstockner97/GSoC_2016/Documentation/Updated_workflow_proposal

I’m not sure what you mean with single frame. A single tile?. Denosing on GPU consumes a lot of vRAM with large tiles.

there is my test 2.79.1 (4.12.2017). pc intel 3820 - 3.6ghz + gtx960 2gb. 500 sampling + denoise - 11m33s (tile 32x32). same picture rendered only gtx960 (tile 128x128) - 18min (2.79)


@equilibrium: Nice render! Did you use 16x16 tiles or somthing else?

Thank. for cpu+gpu mode used 32x32 tliles. for gpu only - 128x128

We have tested the hybrid (CPU+GPU) rendering mode on our machines.
We used the stable Blender version 2.79 and the 2.8.3 test release for comparison.
There are some notable improvements in rendering times for 2.8 as well as some surprising results.
You can see the results in our in-depth article complete with pictures and charts.


You could have compared master (ie a nightly build) and 2.79 , master has all the cycles improvements 2.8 has, with the added bonus of all scenes rendering correctly.

We wanted to test the 2.8 branch, not 2.79a. There’s a possibility that the two versions are not identical at engine level (which can explain the rendering differences), so there may be performance differences as well.

Master is not 2.79a. For example, in 2.79a will not have cpu+gpu as master does… Maybe rendertime in 2.8 is very similar to master

The tests were made using the builds published here: https://builder.blender.org/download/ and not the nightlies. We consider these builds are better suited for a repeatable test because the nightlies are potentially more unstable.

the builds at https://builder.blender.org/download/ ARE the nightlies :slight_smile:

The nightlies are these ones: https://builder.blender.org/one_line_per_build :smiley: Plus, not sure whether the master changes are pushed daily into the 2.8 branch or not.

In conclusion, we took the most stable available version of 2.8 when the tests were made. Which performed as described in the article, including the issues related to rendering quality.

Could I ask a laymen question here because I’m confused. And, less assume the speed ups in the 2.79 nightly builds are pretty close to what 2.8 might deliver with respect to CPU - GPU rendering. Prior to this much appreciated feature picking a graphics card was a relatively simple choice.

I have a fairly decent i7 Intel CPU and knew a 1060 card would be slower and by how much simply checking out some of the benchmark spread sheets on this forum. But, it seems to me that has all changed. Now you can see a significant uptick in render times with an animation in mind having a decent CPU and a bottom feeding graphics card. Whereas I have a German friend with both a decent CPU and GPU who isn’t seeing any speedup using both so he is simply using the GPU as he always has.

Maybe I’m not wording this right. But, with this new feature now it’s a combination of two components. A whole new dynamic in my old mind. What CPU with what GPU and trying to figure out the maximum effect for your money. It seems to me what was once a clear cut choice is now somewhat a venture into the unknown when considering a upgrade in the GPU.

///

It is very new, so we don’t really know this yet. It is not unlikely that further adjustments on the development side are going to take place which are going to change that.
Of course, the CPU becomes more important and with that the speed of the RAM. The motherboard’s bus system may also get a more prominent role.

If you care about buying the best hardware to render in Cycles, right now is likely a pretty bad time. It would try to push the decision and wait until people try to understand the importance of the individual hardware components better.

Thanks @Dantus. Pretty much what I figured with a few more considerations and interesting observations.

Is there already a consensus what the fastest bucket size is for CPU + GPU rendering? 16x16? 32x32? Maybe even 8x8? Or a division factor, like 1/100th of the x and y res?

Thanks,

Metin

as far as I’ve seen it’s around 32x32 but it still can depend on the scene

Thanks, Isscpp. Do the other Cycles render experts agree? :slight_smile:

There is no absolute best setting anyways. The developers tried to find a suitable default setting.
In reality it depends as mentioned on the scene. But also on your hardware and on your drivers. There is no universal best setting.

Fair enough. So far I’ve read that smaller bucket sizes yield faster render times for the CPU + GPU combination. I’m just wondering if there’s a more or less general treshold somewhere, where a smaller bucket size doesn’t improve rendering times anymore, maybe because of bucket initialization time.

@Metin Seven I just tested a interior scene with glass and gloss using the denoiser. 32 and 64 rendered in the same time with more CPU fan activity using 64. 16 was noticeably slower through. But, it might also depend on your hardware. However for me the default is the way to go.