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.
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.
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.
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.
Then Windows, it supports cross platform API 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 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.
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
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
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
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.
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.
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?
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.
the “master today” and “latest E-Cycles” both have the latest optimizations. Anyway, the times are without compile time (not even BVH building, it’s pure path tracing time)
so under 4 seconds to get an acceptable noise level in full screen on a single 1080Ti, if you use viewport render in normal conditions (a small preview screen at about DVD resolution), it cleans in around a sec:
As you can see, it even works with glass and reflections.
PS: you can download the video with right click, the forum blurs it a lot, it’s better played with mpc-hc for example.