E-Cycles - up to 2.5x faster rendering for Blender 2.79 to 2.82

Ok for anyone else wondering, this is a custom Cycles build, see here :

Interesting to say the least !!

1 Like

amazing work ! continue like this this is just mind blowing !

1 Like

Wow, awesome stuff. Please put this in the course and anything/everything that improves render speeds. Thank you very much. :slight_smile:


One more vote to added to the course. What I like the most is that you have avoid doing the cycles pre-processing when rendering a new frame. The next step is to add the intel denoiser at the end of the viewport rendering like LuxCore render has done. Check this video. Luxcore render ODIN integration.

Merged threads.

a test with DOF and the upcoming viewport enhancements in E-Cycles:

It’s done as usual with a single 1080Ti.

1 Like

Amazing result here !
I amazed by the result of your work ! I just bought your product for a month to try out, the very 1st render I tried seemed to work well, but after this one i can’t achieve another render, I got the " Cuda error : Launch failed in cuCtxSynchronize(), line 1740" message. I am working on a 1070 maxQ design. Do you have any idea where it can come from ?
Thanks !

Will buy after that viewport enhancement is in, looking good! What you have here is looking a lot like Octane speeds. Does micropolygon displacement still work and all other general cycles features? Have you been able to make any improvements to compiling the scene? I have mega slowdown if say in a mil poly scene I try to create a cube, it takes so long to “update scene BVH” and “update lights” in my 2.8 cycles so curious if you also have solved that. Looks great!!!

1 Like

Make sure you check the “Readme first windows” file on gumroad. I’m not sure thats causing the issue you are having but I wanted to be sure you saw it.

Yes, indeed, it happens on some windows configuration, so I guess you are on windows? Their is a readme file explaining how to solve the bug called “Readme first windows”, it should be the first file at the top of the download page. Tell me if it solves your problem :slight_smile:

All the features work, it’s 100% compatible with master.
Regarding scene preparation time, 2.8x has still some big changes pending in the depsgraph department (the part of Blender responsible to gather and trigger modifications and decide how to update the scene, not directly bound to cycles), so I’m waiting for 2.8 to stabilize before porting it there. But their is a beta 2.7x version already available which avoid recalculating the BVH to much, based on an old patch from Lukas Stockner. Actually for fly-through, it’s even computed once per video, so I render my archviz video at about 20-40sec per frame for Full HD :smiley:

1 Like

A new test on another scene, with DOF, glass, reflections, plants and still very fast clean image around 1-2 seconds on a single GPU:


So all the E-cycles goodness is ported to the viewport preview? Wow!
I’m thinking how much gain would an Adaptive Sampling implementation would add to all this. Did you ever think to work on such a hard feature?

Yes, I am on windows !
I have already set a TdrDelay of 60s as I am using substance painter for texturing.
I did some other tests, I tried multiple size of bucket. The bug appears when I have 256256 tiles, and I had no issues with 6464. Once the crash happened, I can’t relaunch any render until I force blender ( by changing a parameter in my shading network and restart blender ) to recompute my textures.

If it happens at 256x256 and not with 64x64, it still sounds as it would be a driver timeout problem. Windows 10 has a new tdr variable which is undocumented (to make it more fun I guess?), which produces the driver reset even if the set delay isn’t reach for some (reported, I’m still on 7).

This is on of the reason auto tile size is on by default, normally, using auto tile size you normally don’t even have to use the TdrDelay key. Normally, the best performance is reach with auto tile size anyway. If you want, you can also send a file per PM or Email to reproduce.

1 Like

Another dev is working on adaptive sampling. As we are still only a few devs working on Cycles compared to other render engine, I prefer to work on features that stacks with other’s work. BF work on OpenCL, I on CUDA, other on CPU, denoising, adaptive sampling, etc. It makes an awesome product in the end :slight_smile:
Actually, the viewport is perfect fit for adaptive sampling as it samples the whole image at once, tiled rendering is trickier to get right. Maybe making progressive final render work faster would allow to use the same simpler adaptive sampling implementation for both.
But anyway, waiting 1 to 2 sec to see my scene makes me already happy with the current state :slight_smile:


Another test with loads of lights, takes a bit more time. Still about 3sec to clear the noise with complex materials and reflections.

Does anyone know a good screen capture soft? I first used OBS studio, image quality is good but it cripples viewport perf. Then Licecap, very lightweight so the viewport perf is ok, but it makes banding/noise due to GIFs limitations. Or do you find the videos ok?


wow !
any differences with pre-rendering times ?

You don’t need any additional screen recording software. Quicktime on every Mac does it very well - just click REC button and mark screen area. All you need is E-Cycles for Mac. :slight_smile:

Shadowplay from Nvidia is very high performance and built into GeForce Experience. Don’t know if thats the type of solution you are looking for, though.

1 Like