E-Cycles - sales coming on 4th of April and Mac 2.8 version available


(DDB) #507

you should work for blender institute

(Jason van Gumster) #508

I have merged your most recent thread with this one. You already have an active thread for E-Cycles. You don’t need a new thread to announce updates to it, no matter how dramatic.

(mathieu) #509

It’s was a separate product actually. But I merged it back also on Gumroad now. So there is only 2.7 and 2.8 version again. Note that CUDA remains the focus of E-Cycles for now, the speedups in OpenCL and CPU rendering are bonuses.

Dithered sobol is fixed, new builds are coming soon.

(Redfirm) #510

i need to know if you are deciding to continue splitting up the plugin because that is a huge red flag for me, i expect to pay for it and get everything in one package. its kind of a bad move to have a separate product instead of raising the value of your current one.

(mathieu) #511

It was a split only for people not needing the cuda improvements. All the improvements to OpenCL were already from the begining in E-Cycles, just not used by anybody because the small 10-20% speedup was not worth the price for many. With the new denoiser, some asked for a lower price for those only needing a part of the features. So it was just intended to make it more accessible for low budgets. For CPU, their is a separate beta build also already available on the product page. Anyway, the splitting is over. So everything like before :slight_smile:

By the way, since release, E-Cycles got:

  • about 5% faster rendering
  • a new sampling algorithm to reduce the needed samples by about 20%
  • a new denoiser.
  • an optional beta cpu build.
    And that although I said there is only one feature update per month. So I indeed raise the value of E-Cycles regularly, you got the double of what was planned until now :wink:

(David Mikucki) #512

Wow. Thanks for your work on this. It’s blazingly fast and I’m happy to be able to support your efforts.

Some things I’ve noticed / questions I have:

  • Auto-tile size seems a bit off with the denier turned on. I’m using CPU/GPU to render. When I turn on auto-tile, it wants to do 256x256. That leaves a lot of tiles still rendering on my threadripper, waiting to denoise, all while the GPU sits doing nothing. I set it to 32x32 and I get much better performance (even then GPU only at 256x256).
  • Octane just got a pretty big performance boost by using RTX cores for ray tracing. Any chance you’ll be implementing anything similar?
  • Any chance for a Mac version? I have a couple Macs that it would be great to throw into the mix via Crowd Render, though I can always set up boot camp.

Thanks again.

(mathieu) #513

You’re welcome :slight_smile:

  • Auto tile size is optimized for pure GPU rendering. CPU rendering only likes 16x16 max 32x32, so it doesn’t really need a smart decision, you can just leave it at 32x32 to be more gpu friendly and forget about the tile setting. Note also that their are beta builds for cpu on the product page. They are not supported yet, but bring good speedups on ryzen (17% on the BMW scene in my case using a ryzen 2200g).
  • RTX is on my todo list indeed, but I prioritize optimizations that work on older generations to benefit everyone.
  • I’m working on a mac version. But indeed, Macs are dropping all APIs but Metal, so if you can boot Linux on it, it’s the best way to go on the long term anyway.

(yfile) #514

Do you think it would make sense to start crowdfunding to hire a few developers to make a Metal version of Cycles/E-Cycles at reasonable timeframe?

(mathieu) #515

For it to work you would need:

  • devs who know Cycles and have time free (I don’t know any personnaly) and are willing to invest time learning an API that work on a single platform where 10% of the user base is and are ok dealing with graphic driver that were barely debugged because few applications use metal. You can also take a random guy, but then chances that it fails or takes much longer are high.
  • at 5K/dev/month, if you find 100 mac users who want to donate to port cycles, it’s still 500€/month/donator for one dev. If you want it to be done faster (like Eevee has about 3 devs for 2 years?) you multiply that by the number of devs.
    Even if it succeed, the code base has to be updated regularly, so even after commit (if it’s accepted), you would still have to pay as it’s otherwise more maintenance work for the core devs, which is unlikely to be welcome given all the pending changes for 2.81, 2.82, etc.
    So it’s a rough guess, but I see like 1% chance it happens.

Or with all that money, you could buy a very good Linux render farm with 4 gpus and give some money to current effort to make Cycles faster on Linux and Windows. That would also motivate your brand to support cross platform APIs.

(yfile) #516

Thank you for your comprehensive response.

Regarding another systems - If I used only Blender I’d have been working on Linux for a long time. But there is no sensible alternative for Apple Motion, Logic, FCPX, Affinity, Tumult Hype and a few more on Linux. The only option is Windows. Unfortunately.

(mathieu) #517

Then Windows, it supports cross platform API :slight_smile: The only thing they understand is money. If people buy product from other vendors, they will think twice before trying to lock their customers.


it’s a common misconception that the market share of MacOS is small, or even neglected compared to iOS. The reality is quite different.

MacOS market share nowadays is 12.3%

it has been around 5% over 10 years ago with the famous quote by Steve Jobs even after the massive success of iPhone “we cannot hope for more than 4.5% market share”. If only he knew :smiley: And is increasing non stop. But even that is probably a bit low taking into account how popular Bootcamp is among mac gamers. So the actual market share should be around 20-25%.

Blender wise I think I have seen somewhere statistics that pretty much the same (around 10%).

When it comes to developers the market share for MacOS is around 26% according to the 2018 stack overflow survey.

So finding a developer should not be a problem. iOS is basically MacOS so there are a lot of devs familiar with Metal. But the vast majority like in all platform is avoiding such APIs via a game engine, mostly Unity and Unreal.

(mathieu) #519

http://download.blender.org/institute/2016Analytics.pdf for the Blender stats. It was 12% in 2015, 9.9% in 2016 and many switched since because OpenCL and CUDA are being dropped and/or had crappy driver for years. There is a pretty big difference between coding a game or web app (which most of the time uses a bunch of frameworks or nearly ready to use engines) and porting a full fledged path tracer to work on both AMD and Nvidia hardware.
But I may be wrong and I corrected my percent in the mentioned post. If it’s easy to find a metal dev wanting to port and maintain cycles, please do it :slight_smile:


2017 was 10% as well

Could be much less now for the reasons you explained, I do not disagree , although I am more inclined to the idea that are not because lets face it, we don’t buy macs for their GPUs :smiley:

Also what convince me even more is the lack of reaction from the mac community. At least for me GPU support is not important, my GPU cannot handle Cycles render anyway. If it was a real problem even a 10% is enough to set the forums on fire. But maybe I am wrong, without actual data its all assumption.

I am definetly willing to support this even though I do not benefit from it directly, finding a Metal developer should not be hard but yeah as I said and you already mentioned it wont be a walk in the park because devs rarely use OpenGL, Vulkan and Metal. I still remember the shock of trying to find a proper tutorial for OpenGL 3 few years ago, the lack of documentation was mind blowing. But then when I learned OpenGL I was no longer surprised why people choose to use game engines instead or other graphic engines :smiley:

On the other hand a Metal dev maybe uncessary it seems MoltenVK can allow blender devs once they port to Vulkan to support macos with minimum amount of rewrites. I am willing to assume that this is going to be their option because having Vulkan for all Platforms makes it much easier code to maintain. Performance wise VulkanVK is very promising and has almost full support for Vulkan and is very actively maintained. Not to include that is officially supported by Khronos, the board that created Vulkan and OpenGL.

(yfile) #521

On the one hand you’re right of course. But on the other hand I don’t want to shoot myself in the foot to spite Apple. I’ll switch to Windows when I’ll have completely no other choice. I hope I will not have to…
For now it is just a matter of Nvidia CUDA drivers for Mojave. OpenGL and OpenCL is walking dead anyway.

(giacometti777) #522

Change of subject (and possibly a stupid question):

Is it possible to make tessellation a multi-core operation? I think this would be monumentally significant!

(mathieu) #523

As far as I remember, it’s the BF plan to use opensubdiv for that and it supports even the GPU to do that, which should be even faster. Sergey is working on Opensubdiv again, so I guess it will come soon?

(mathieu) #524

The new builds are up, with all the OpenCL improvements made in master, plus E-Cycles one on top. Dithered sobol is also working better now :slight_smile:

(giacometti777) #525

Thanks for the info! I thought it wasn’t a priority and could be an E-Cycles target (probably very ignorant and naive for me to think so).

(mathieu) #526

How high of a priority it is for the BF is unknown, so I’m also partly ignorant and naive, but it is planned. So I first work on making other parts faster so that you can benefit from both the BF improvements and E-Cycles one on top.