Mike Pan is an E-cycles user, he gets the 2x speedup in his scene and also confirm the noise is lower: https://twitter.com/themikepan/status/1120393119286145027
Tibor Nyers from Boostclock.com did an independant test: https://twitter.com/boost_clock/status/1113873881830502401
There are also many tests done by E-Cycles users in the Blenderartists thread. Here one with 2,59x faster rendering https://blenderartists.org/t/e-cycles-faster-rendering-for-cuda-gpus-and-better-ai-denoising/1139717/1105
To know if you will have good speed-ups too, look at your scenes render times. There are 3 steps:
- The first one is the pre-processing phase. It's done on the CPU, so here it will be as fast as with regular Blender builds. Only 2.79x has an option to compute it only once per video if the camera is the only animated object in the scene. All other cases will be like in normal blender.
- The second phase is the path tracing phase. This part on your CUDA GPUs is were E-Cycles show it's power. Out of the box, this phase can be between 1.5x and 2.8x faster. Using presets, you can even reach speed-ups of up to 15x faster.
- The third phase is the compositing one (optional, only if you have AI denoiser or made a compositing node tree yourself). This phase is also done on the CPU and will be as fast as with regular Blender builds.
So to know how much time you will save in your renders, you can use the following formula (using only GPU to render):
pre-processing time + path tracing time/2 + compositing time.
In the BMW scene on a i7 7700K with a 1080Ti for example and using only the 1080Ti to render, the render time on Blender buildbots is as follow: 5seconds pre-processing + 88 sec path tracing + 1.5seconds compositing = 94.5 seconds total render time. So on E-Cycles, you can guess a render time of 5+88/2+1.5 = 50.5 seconds. In fact, the overall render time is of 41seconds in this case, but some other files may also be a bit slower, 2x faster being the mean.
That mean that E-Cycles base speed-up is best when the path tracing phase is the biggest part of your render time. So the more sample you render, the bigger the overall speed-up will be. If you are rendering fly-through animations, scenes with very long pre-processing will also be dramatically faster, as this CPU computation will be only done once for all frames.
Regarding hardware configurations, E-Cycles is good when the GPU(s) are much faster than your CPU. If you have for example a 32 cores /64 threads Threadripper with a 1050Ti, E-Cycles will only speedup your 1050Ti, so the overall speedup may be very small.
E-Cycles is 100% compatible with Blender, so it will work, but your mileage may vary and only CUDA GPUs are officially supported. However, some users already use E-Cycles with CPU or OpenCL and had good results, mostly to use the new AI denoiser, the new presets and the new options like the better AO simplify, dithered sobol or scrambling distance. Here are some tips that ensure the best experience in those case:
If you want to render with your CPU too, deactivate auto tile size and use a tile size of 16x16 or 32x32. In this case, you should use the E-Cycles AI-Denoiser as it's fast with small tile size too.
For OpenCL the speed-up out of the box is around 10-20%. Users had some good speed-up using the presets. Use the AI denoiser with the fast preset and divide your sample count by 2 as the AI denoiser works well with low samples too. See here for example for a usage of E-Cycles with OpenCL. OpenCL is not officially supported.
Each Patch will be uploaded on the official patch tracker of the BF developer.blender.org one year after it's inclusion in E-Cycles. The first release was in late December 2018, so the first review would start in late December 2019, more probably in January 2020 when everybody is back from holidays. If and when the patch will be included in master is up to the Blender Foundation. As reviews take long, the plan is to offer a 2020 version of E-Cycles, with weekly updates. How many features updates it will get in 2020 still has to be decided.
If at some point enough of E-Cycles is in official Blender, the project will stop and everybody can smoothly switch back to official builds.
The image quality is the same, the mean of 2x faster rendering is achieved thanks to optimised memory access and better parallelisation of the code. The noise pattern is different because E-Cycles uses another sampling startegy, but it converges to the same results. If for some reason you need the same noise pattern as the buildbots, there is an option to do so, but it will be around 30% slower. All tricks are optional and allow further speed-up your renderings up to 15x.
You get free updates every week to always get the latest improvements made in master and there will be 1 feature or optimization added every month. Each feature, after a year, will be uploaded for review on the official patch tracker of the Blender Foundation.
If you render at least with a 70€ Cuda card supported by Blender on Windows or Linux, you get this build amortized immediately in most cases and on the long run anyway due to the electricity you spare compared to rendering longer or rendering with more cards.
Note that only CUDA GPU rendering is officially supported for now. CPU+GPU and OpenCL rendering is still working but only the tiles rendered by a Cuda GPU will be faster. AMD and CPU users can still benefit from the new AI denoiser, the preset system, Scrambling distance and Dithered Sobol. Here is a feedback by an AMD users using Cycles https://twitter.com/johannes_wilde/status/1126831723361243136
Yes, Blender is actually untouched, only Cycles was modified. So it’s 100% compatible with the official version, including assets, materials, add-ons, textures, etc.