E-Cycles - The fastest render engine for Blender. 3.2 release available now!

Real need. I have a scene without any direct light and Strange/rough/noisy/dark surfaces. Maybe there is a better way to render it but 16k Samples and 1.5h is okay. More Samples would be better. What cause this? Can i do something to render with more Samples. Something wrong with my scene?

Ok, thanks for the explaination.
Yes, you can go manual and lower the tile size until the next build. With this high number of samples, you can go to 32x32 or even 16x16 tile size. You can also increase your TDR value to 200000.

What?! I thought it as a joke or some kind of misunderstanding. How can it be possible? Yes I know there are a lot of macOS apps using OpenCL with a great results but BI coders said OpenCL for Blender Cycles Mac make no sense. Are they lamers?

If you have CUDA cards, it will still be the best choice on Mac. In my tests, the 2080Ti is still around 8x faster with E-Cycles RTX than the Vega 64 with E-Cycles OpenCL.
But yes, it may help people get good performance back on their Mac as it will still be much faster than CPU rendering. It will require some test though to know how well it works.

2 Likes

Itā€™s a pity that Cycles OpenCL performance in Mac is so poor. Other Mac apps work great with OpenCL (FCPX, DaVinci, Houdini, LuxRenderā€¦). Whatā€™s the problem with Cycles?

While itā€™s an interesting theme, what the BF decides to do or not is best discussed with them.

The problem isnā€™t with Cycles itā€™s with OpenCL and Apple.

Apple did not fix bugs in their OpenCL drivers and compiler for years which were fixed by AMD on Windows and Linux. Apple were the lamers.

I was told by a GPU programmer that OpenCL could not create kernels anything like the size that CUDA could which turned out to be a significant limitation to those trying to write a pathtracer. The workarounds necessary to make OpenCL work meant it was a lot slower than CUDA. The kernel size limitation is irrelevant for editing 1080p, 4k and 8k video.

I understand the later versions of OpenCL have fixed a lot of these limitations but it would probably mean Cycles would have to be rewritten to take advantage of OpenCL 2.x. Again the issue is with Apple, Apple only support OpenCL 1.2.

The issues with OpenCL and 3d renderers started with Apple and ended with Apple. So far from being lamers the BI programmers deserve respect trying to get Cycles onto MacOS.

The Luxrender developer at the time called out Apple publicly for their shoddy work.
https://streamhpc.com/blog/2015-05-09/apples-dragging-opencl-compiler-problem/

3 Likes

Latest version of e-cycles 2020 Rendering everything was exposed (no light)! I use 1080ti,use the nomal e-cycles

Whatā€™s the exact name of the build you used (name of the .7z archive)?

i find this is blender self problemļ¼Œi have fix that

1 Like

For those of you with a Mac and an AMD card in it, I just uploaded a build v20191111_mac with it enabled and the optimizations to make it 2x faster. I donā€™t have such a Mac, so your tests results are welcome.

2 Likes

Many thanks for this Mac version.

One thing first and foremost: E-Cycles is the FIRST in the the history OpenCL Blender Mac version I can run in the Cycles viewport/rendering (GPU). Yes that is correct: I was not able to fire up OpenCL GPU viewport/rendering in official Blender version without a crash. Never. I didnā€™t care because I always used Nvidia/CUDA in my daily work.

On the Nvidia card (High Sierra) this E-Cycles version OpenCL works quite nice for the viewport/rendering and not so slow I expected. Unfortunately only one NVidia GPU is visible in Blender prefs. Itā€™s worse in the Catalina/Radeon Vega. Although both my Vegas are visible in Blender prefs, there are many problems. It is definitely experimental version at the moment. More details soon.

4 Likes

Hello everyone,

I have seen this topic many times since the beginning, Iā€™m looking for some specific info, unfortunately I donā€™t have time enough to go through >2730 posts, even though I just read some hundreds of them. Maybe someone (or even @bliblubli ) can have a general overview and answer to this :

Iā€™m working on big (BIG) scenes (> 20 GB of GPU Ram used), rendering about 10k images a day, but the bottleneck is texture load and BVH build (>60% of total render time)

Iā€™ve seen so far a lot of benchmarks, but itā€™s always taking into account the total render time saving (and not specific BVH part, texture load part, and actual raytracing part)
What about the current state of E-Cycles about BVH build and texture load ? How much can I hope to save, considering that for me, texture load + BVH is >60% render time ?
(Iā€™m running Blender 2.8X, Ubuntu 18.04, GPUs are RTX Titan and 2080 Ti. Just in case : Python script moves all objects between two frames, so, a pre compute BVH solution would not fit, I guess)


Also, I have some other cases where even 1 sample is fine for me, because I just want to generate some passes (obj index, vector, depth). But itā€™s still very long due to BVH construct. What about E-cycles on this specific case ?


Thanks a lot :slight_smile:
Tricotou

Hello Tricotou,

Short answer for Linux: E-Cycles will only speedup path tracing like an additional GPU would. At one sample, you are basically doing CPU rendering so to say as most of the time is spend on preparing and loading the scene. Here, a beaffy CPU like the upcoming 32 cores 64 threads Threadripper may be more adapted?

Detailed answer:

  1. for the BVH:

    • on standard E-Cycles, the new E-Cycles 2.82 version halves BVH building time on Windows in my tests, but not on Linux yet. Itā€™s done thanks to the work of @LazyDodo on TBB allocator and Clang compatibility.
    • On E-Cycles RTX, itā€™s like with buildbots+OptiX, the BVH build time are most of the time already cut by 5. Thanks to the work by P. Mours from NVidia.
  2. For the image loading, itā€™s 100% like Blender, but you can use persistent images in both, so BVH building is the main bottleneck in the end anyway.

As you say, persistent data as in E-Cycles 2.79 is only for fly-through and you move geometry with your scripts. In this specific use case, you need BVH refitting, like in viewport. Itā€™s faster for BVH building, slower for rendering, but at 1 sample the benefit of a faster BVH rebuild would be higher. Itā€™s on my todo to add fast BVH refitting in the future for final render.

Kind regards,
Mathieu

3 Likes

Hello bliblubli
Thanks for you time on your complete answer :slight_smile:


To answer to your question :

I donā€™t know about this upcoming thing, but whatever, indeed I never realized the one sample thing might be faster on CPUā€¦ So Iā€™m going to give it a try on a more CPUy machine :stuck_out_tongue:

See you :slight_smile: ++
Tricotou

1 Like

Finally got around to getting the first of my 2070 Super Hybrids in my ws, that are replacing my three 980Ti Hybrids, and just did some testing 2070 Super vs 980Ti, in my own heavy scene, and my expectations were really surpassed in my initial findings. There seems to be a sizable discrepancy between the OctaneBench scores (2070 Super vs 980Ti) and the difference I am seeing between 2070 Super and 980Ti in E-Cā€¦ A discrepancy of like 18% if my (non-mathematician) math is correct, meaning the 2070 Super is an additional 18% faster than 980Ti in E-Cā€¦ Iā€™ll need to do further testing tomorrow, and try using BMW, classroom, etc. Where do I get those?

Edit: The first time I rendered using OptiX it said something was going to take a couple minutes the first timeā€¦ Is that a one-time thing (like Iā€™ll never see it again), or does this happen each first time you open a scene and render in with OptiX?

1 Like

I Just wanted to post an overdue appreciation for e-Cycles.
Iā€™m glad I bought it, it changed my experience with Blender for the best.
I wanted to use Blender for my personal projects but I was a little concerned about render speed. Now I donā€™t have to worry anymore. Thanks, Mathieu.

3 Likes

Thanks for the feedback. Iā€™m happy you the results are above your expectation :slight_smile:

You will have the kernel compile from time to time when you update the builds for example. Itā€™s normal and much faster in E-Cycles than in Blender.
For the tests scenes, you can get those from https://www.blender.org/download/demo-files/

1 Like

Youā€™re welcome. Iā€™m really happy you took the time to even create an account to post your testimonial :slight_smile:

2 Likes

The next version of E-Cycles will have auto tile order back. It can bring some impressive speed-up. More info coming soon :slight_smile:

3 Likes