Loaded a test render with 1 million triangles + HDRI, which also had quite complex compositing nodes. Used hybrid CPU + GPU render settings. Identical settings and file on both. 2.93 Alpha = 2mins:21secs vs 2.91.2 = 2mins:32secs.
2 Likes
Congratulations to the genius developers that manage to squeeze this free extra performance out of Blender. At a time when its virtually impossible to purchase a new gen graphics card or a graphics card that is not marked up in price.
2 Likes
… and then you look at what E-Cycles is doing and it’s not nearly as impressive any more 
There was a big discussion about E-Cyles and its manly so fast because of unfinished Patches on blender developer. I hope they catch up soon
1 Like
Ah I’ve actually been wondering why E-Cycles can be so much faster and why the Blender developers won’t do the same thing. So yeah, lets hope they do catch up soon!
im not convinced about E-cycles and they tricks they might use to speed up the renders. I heard from a pro user that he does not use Optix because it can run into rendering and shading issues in large pro scenes. Its nice when Optix does work im sure but apparently its still in some ways experimental.
Also i dont have an RTX GPU… Im sure E-Cycles does have some real speed advantages over Cycles, but its hard to ascertain what exactly because it would need to be a fair test that uses CPU + GPU and does not use Optix or other denoising… Just an Apples to Apples test not Apples to Oranges.
2 Likes
I think it is because of using scrambling distance, lower parameter of settings and better compositing denoise nodes than default Blender.
This time it is about 10 - 30 % for me.
You even have some of the tricks in default Blender. For example for interior scenes you use Simplify menu in render tab, and limit AO bounces to 1 (or 2, but the cut in render time will be less than with 1). Then in World tab you enable Ambient Occlusion and set appropriately the values there for your particular case. This could cut render time in half in some scenes.
The point is, these things should never be by default because ideally it would not limit too much bounces, nor Clamp too much lights, nor any other trick that can make the results unstable especially for animation (although these tricks can be useful in some cases)
For Scrambling Distance you can search here for BoneMaster or BoneStudio builds:
1 Like
This might be because of the tile stealing fix that was introduced about two weeks ago. Until then the CPU was not allowing the GPU to take over at the end of the rendering. For me this made quite a bit of a difference.
I think it depends on the hardware because in my case it’s much slower than 2.91.2.
I have a GeForce GTX 1050 Ti. I’ve made a small test and it was really disappointing. Even using only the GPU the render is MUCH slower.
If I don’t recall it wrong, the developer of e-cycles said that after one year he would share his discoveries with e-cycles with the Blender Foundation team (also he is part of that team, or was), so it’s expectable that the differences between both renders become more subtle.
Although i can’t imagine Blender having all the denoising, AO bounces and other tricks on by default. Those are optimizations that should be done by the user as they can result in compromises in image quality in certain scenes. Be default i think Blender Cycles should be as unbiased as possible. Im guessing that E-Cycles uses a combination of these optimizations and tricks as well as actual better code that does not introduce errors or bias into the rendered image.
1 Like
but cycles uses the apache license and the e-cycles developer only released his patches gpl licensed after a year. so he wasn’t entirely honest since he must have known that the cycles developers can’t use them like that. i think the cycles developers don’t want to have anything to do with him anymore and they also are sceptical about some of the optimizations like the scrambling distance one because they can be unstable for animations for example (very different lighting in adjacent frames).
5 Likes
Wow, that’s really not nice!
I will skip past the E-Cycles stuff as this thread is about the 2.93 Alpha build.
I downloaded it this morning and I am already in love with it. It’s amazing! I’ll be using it as my render version from hereon out.
A very heavy scene I’m building has gone from 2:45 to 1:14. Thank you to whomever got the tile stealing working. This is a godsend. Not just for general render speeds (since the CPU can give the tiles a little head start before the GPU takes over) but for being able to load heavy scenes into the system ram. This really is a massive, massive, game changer for me. No more worrying about fluid and smoke sims that are just too big for the GPU.
More Cycles development please!!! I honestly haven’t been this thrilled for an update since the initial 2.8 drop.
Again, kudos to the Cycles team. Thank you, thank you, thank you!!!
Did you get it that I love this build? 
3 Likes
I actually skipped 2.91 because I read it was actually slower than 2.90. That said 2.92 was much faster than 2.9, maybe as much as 40%, really great. (I work on enormous files that used to take hours to render (at night) and now take hour plus (lunchtime) so yes I was very happy with the Cycles improvements in 2.92. My only disappointment is that even though I downloaded the latest driver for my RTX 2070 I still can’t use Optix. There are videos saying that Optix is the fastest… Cuda GPU Compute and OpenImage node denoiser work fine but when I try Optix it will work for a couple hours then stop, give me an error message. I was actually looking for another post who had the same problem but now I can’t find it, hopefully I will figure it out sometime.
i would guess that is when it runs out of VRAM.
did you report this as a bug?
Not yet. I redid the render with the settings I had used before and got another error message. The first screen copy shows the settings I used and the other the error message.
CUDA is working great though.
Actually when I was using 2.8 and NLM I did run out of memory a few times. I prefer making final renders that can be glossy printed at 11" x 17" x 300dpi which is kind of huge. I did discover however that if I just retried a render that had just failed it would finish the second time around. I haven’t had that problem lately though unless I am misinterpreting the error message (in my other response below).
1 Like