tried a quick test before i read this post
Win 10, I5 Skylake, GTX970
500 samples @ 1280*720
GPU: 2m:01
GPU+CPU: 1m:49s
didn’t mess w/ the tile size, it’s whatever’s defaulted on your builds.
so yeah, the RTX version works fine on this GTX970 too.
Great. The speedup with CPU is in the range I got from other users until now, around 10%. Compared to a doubling in power usage, it’s low, but if you are on a deadline, it helps.
A thing I noticed is that the frequency of the CPU core managing the card has an important impact on the GPU perf. As most cpu overclock (boost) when only 1 thread is used, it may also be a factor. So if you are to buy a new computer, it may make sens to buy a CPU with a low core count but a high frequency. It would also help when using Blender itself, as most operators and modifiers don’t use multi-threading much yet. If the pre-processing phase is the biggest part (building BVH, etc.), a high core count is then more important.
Unfortunately I don’t get any speedups with the new RTX build in my test scene.
Even worse, this build is very unstable. I tried to render this scene 5 times, and only two times he was able to finish the render, the other times blender just closed itself at about 50% progress.
The render time was about 31:02.35 for both successful renders.
ok, it’s not very logical at first that the 970 are ok and the 980 get such an impact from newer Cuda SDK. But then I’ll continue to provide cuda 9 kernels for 9xx cards. 
i’ll chip in here and say i had a couple of closures on my 970 too. i’m rendering a different scene now, one w/ fire/smoke sims in so maybe that’s a place to start looking ~ i’ve rendered about 200 frames on the scenes previous to this, both w/out fire sims, so this may logically be the culprit. however, i’ve asked elsewhere on this site about 2.8 fire sims and my baked data was misplaced;
so maybe this is a contributing factor?
Didn’t have time to look into it, but i’ll try and give it a run on the 980 tonight and run it via CMD so i can see any error messages.
cheers
I did some more tests and got some interesting results.
Since the first measurements on Dec 31, I’ve updated my graphics card drivers and now the render time increased for the Scene. It went up from 25:13.23 to now 28:54.86. the new RTX build is at 31:26.29.
I always do multiple measurements to ensure that the results are correct, but now I cannot recreate the 25:13.23 anymore.
GPU+GPU is faster in theory because some tiles are rendered (slower) by the CPU and so, GPU will have less tiles to render in order to complete the task. But most of the times the last tiles to be rendered are taken by CPU, so they render slower, and it can happen that these last tiles take such time to finish that all the advantage is lost, and goes negative, resulting in an overall slower render
Interesting. If you can give me the driver version that gave the best times, that may help other user of the 9xx series. Luckily on Windows, it’s pretty easy to roll-back to the previous version in the hardware manager.
Sorry, I was wrong it is still possible.
If you open Blender and start rendering it is always slower than if you render it the second time.
The render time with the RTX version is indeed only a tiny bit slower than the old build (~1min).
I’ve also fixed the Crashes for the RTX version with your registry trick.
Sorry for the confusion 
everything ok So the RTX version on 980 takes 26minute instead of 25 (about 4% slower) right?
I also have a bug in 2.8. Sometime it spends a very long time (about 1 minute) on the synchronization/shader compile phase. It’s already reported on the bug tracker. But E-Cycles+ this bug is faster than 2.79 so
The new weekly update is available for Windows and Linux. All the latest fixes from official Blender are in, plus an improvement of the denoising performance when using auto tile size.
I had the opportunity to test E-Cycles on a freshly packed scene, to have a margin of comparison.
I must admit that the results are amazing.
Here the Thread.
The main scene, calculated at 2500 samples, 2400px, previously used almost 3 hours for the calculation.
With E-Cycles we are at 1h 20 … Less than half.
Same with the other scenes.
Before we were on 2h and over, now with E-Cycles on the 16 minutes at the end of the calculation (2400px, 2000 samples).
Obviously in terms of performance I believe the data speak for themselves.
On 8 images, 2h one I lost a day of calculation.
With E-Cycles, in just over 2 hours I solved everything.
Surely, by making some improvements to the settings, I could gain more time.
Calculations made with a “simple” pc i7-7700 + gtx1080.
Your welcome, I’m happy to see a very good example of how E-Cycles default performance go even much further with a little tweaking
Tnx to you and your awesome work!
We are on CGChannel http://www.cgchannel.com/2019/01/e-cycles-speeds-up-blender-renders-on-cuda-gpus/
This is so frustrating, i’m desperately wanting to run E-Cycles to render my animation files that have fire sims in them but it seems this is a problem w/ 2.8? AS per my link above, i’ve been trying to get it to work but even baking the sim in 2.8 messes up, the fire renders but the flames are mis-placed 
given i have 6 or 7 shots involving fire, and they’re doing about 65m a frame on 2.79…this sucks.
I could add a 2.79 build as an extra product with year membership (same price as for 2.8). People who already have a paid year membership for 2.8 could get it for free.
Everyone interested can add a like to this post.
That would be very generous, and i think it would be a very good move, given 2.8 is still some time away, and there are doubtless quite a few people who will be sticking w/ 2.79 for some time for whatever their reasons.
thank you.
Is there an easy to access list of the patches/improvements made with this build I see?
Here it is:
