E-Cycles - 2.83 stable available now with very fast viewport, new AO/Clay Kernels and more

Are you bringing Cycles OpenCL for Mac back to life?! If so, you’ll have glory forever and ever.

1 Like

As you know, Unfortunately, Apple abandoned OpenCL as well as CUDA. The support ended two years ago, and I don’t see any hope. Better wait for Blender to support Metal. (or Vulkan? I have no idea.)

And as far as I know, there is no developer who’s currently polishing Blender Mac version now(after Ton switched to Linux). My humble advice is that it is better for you to move to a PC to use Blender.

1 Like

I use the rtx 2019 version. is there a sample cap? if i try to use samples above round about 16k samples i got an error. something like line 713?

1 Like

While OpenCL will stay officially unsupported in a first phase in E-Cycles, I can do that, yes.


E-Cycles can render as much samples as vanilla Cycles. I think I know what may cause this, so I can probably fix it. Is there a real need behind this or was it more a “what happens if …?” experiment?

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.


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.


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.


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.


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:

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,


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: ++

1 Like