Did some tests !
i tested the new cpu+gpu rendering with the new blender gpu benchmark and i got this very intresting results
so
gpu only:6min and 27sec with amd rx460
cpu only:3min and 27sec with amd ryzen 1600 stock speed
cpu+gpu rendering:2min and 12sec!!!with 64x64 tiles wich in my case its the best value for amd hardware
overall the speed up its really amazing ,thank you all blender developers that make blender so amazing software
Cycles is an engine that allows imitate how things look in real life. In real life we see a lot of SSS, transparencies, translumency, volumetrics. The Blender 2.79 benchmark scene in this forum contains all that, and that usually stresses more than normal the GPU (render better on CPU). So the scene is designed in this way so that no one takes surprises when it comes to buying hardware.
That’s why in that kind of scenes a good CPU can contribute a lot to the final render time.
By the way, I’m really not sure if denoiser has yet to be modified to work properly with CPU+GPU, or I’m the only one having the problem. Could you check if in this scene the resulting image ends with some tiles showing noise?
Ok, thanks for testing!
I have the same problem with my own scene here. Did you already report this bug, YAFU?
I have had the same issues with some tiles not being denoised properly. I could only notice it when using 1616 tiles though, using 3232 was fine.
CPU+GPU is great, one of my scenes rendered almost 35% faster with the latest build compared to the official one.
New GPU/CPU build is awesome.
Just rendered the BWM benchmark scene using a combination of my GTX 980TI, GTX480 and Core i-7 5930k
16x16 tiles took 33 seconds!
With samples reduced to 75, denoising on and simplify AO bounces to 3 - 64x64 tile size - I can get a passable render in 14 seconds (for some reason - denoising doesn’t like smaller tiles and renders slower.)
I’m going to report it now just in case. Being all this fairly new, I guess developers already know the limitations that implementation are having for now.
Edit:
confirming, noisy tiles (at least one) left using tile sizes < 25x25
Appears only while using CPU + GPU
CPU+GPU with Denoising now fixed. Thanks Brecht!
I think it will be available on Wednesday 25 buildbot builds.
I can’t get what am i missing in the AO bounce feature (simplify panel). I can’t get any useful result with it, just overbright scene unless i use a very high count for bounces (5 and more), and still something seems wrong.
It would be perfect if used the World AO settings and skip n bounces from there, from those settings, instead it does not.
Anyone used it successfully? Lets forget the Blender classroom demo scene BTW.
Do you have a file to reproduce your problem?
This feature was originally intended for viewport rendering with a low value like 1 or 2 bounces, to get some basic lighting for tweaking things without having to wait a long time for things to converge. Using it for final renders is a big approximation, and in general it can be quite far from the correct result.
Currently it uses lighting from the background, which makes sense in exterior scenes, or interiors with e.g. big windows where a lot of light is coming from outside. It’s a trick that similar to what Eevee and other realtime renderers do. For other interiors you could indeed get closer results if it used a fixed color from the world AO settings that you could tweak.
Here is a simple test file + some renders to explain what I mean.
- No AO at all (no World AO, no Simplify panel)
- World AO, settings are Factor=0.1 Distance=10cm
I’d expect the bounce AO feature would take this setting (World AO) and skip bounces from there, to make it less fake-ish.
But never worked like that, here it’s a render with Simplify panel enabled:
- AO bounce = 1 (0 is disabled)
- AO bounce = 2
- AO bounce = 3
- AO bounce = 4
…so… what am i missing? It seems it always uses the AO with a Factor of 1.00, which is unusable and incredibly high, and ignores the Factor set by the user in the World panel.
It’s a feature with great potential but unusable at the moment IMHO.
Sorry we posted at the same time. I can see what you mean, though i don’t find it “useful” in its current state, maybe i’m missing something.
Can you ensure it is supposed to work like my post above? Why is it using AO at a fixed Factor? (extremely high BTW), wouldn’t make sense to respect the setting the user choose in the World AO panel?
AO settings in World panel are respected.
But there is Indirect lighting by default in Cycles.
Simply, enabling AO will not be sufficient to have an idea to what will replace last bounces of beauty render.
You need to set light bounces to 0 or look only at AO pass.
Your scene is made of big planar surfaces.
The fact that they are a little bit lighten but on a big area means that the effect will be spread on a big part of render.
Your AO test result should be almost entirely black with little discrete areas areas of light that could coarsely replace light bounces.
The idea is just to fake Global Illumination at last bounces for crowded scenes. But if AO of scene does not fit to expected light bounces, it can’t work.
Your scene just don’t have enough geometry. Primary bounces are too much essential to be skipped.
It’s supposed to work that way, but clearly is not good for all scenes. It’s using the world background, which in your test scene is a bright white. If you have an exterior scene with a HDRI background, that’s a pretty decent approximation for the average illumination in the scene.
In your scene, the interior is much darker than outside the window, and so the bright background is not a good approximation for the average illumination inside the room. In that case it would indeed be more useful to be able to manually specify this average illumination separately from the world background.
While we’re on the subject of AO approximation, is there any chance that the general AO shading in Cycles can be enhanced with color-bleeding functionality (I’ve seen a few images of that over the years and it really does make the result feel closer to real GI)?
I think it would make this shortcut feel far more realistic while keeping the same boost in rendertimes.
I don’t know what the difference is between color bleeding and actual GI, doesn’t sounds like you would keep the same speedup. But regardless I don’t think that’s the direction we want to take Cycles in.
This is a nice little feature for faster viewport rendering, and if there’s some simple tweaks to make it work better for other cases that’s ok, but beyond that Eevee is the better choice.