Does this mean that macOS users have to choose CPU in the preferences? And will any Cycles features work differently, apart from maybe lower rendering speed? In other words, what were the real advantages of OpenCL versus CPU rendering? I assume OpenCL made it possible to combine CPU + GPU power?
Thanks.
OpenCL means you can get a renderer in less time using the GPU. But since Apple is discontinuing OpenCL and they won’t fix their existing bugs in the current implementation, Blender devs decided to drop openCL for apple machines.
Thanks, @stargeizer. I guess this is not a big deal for me personally, because OpenCL on macOS renders random black buckets when you activate the Denoiser while GPU-rendering. So I was already mainly rendering using the CPU.
I do hope Metal support will follow soon, in the shape of a Metal wrapper for Vulkan if necessary. In the mean time, Radeon ProRender offers a very capable GPU rendering alternative to Cycles.
Considering that OpenCL support already not that great and AMD basically had to revive it to compete with Nvidia CUDA, i don’t see devs supporting Metal which will have even smaller base. Mac and AMD basically “no” for working with 3d in general…
Radeon ProRender is also OpenCL
… and RPR on macOS uses Metal2.
Cycles to me looks more like a privileged underdog.
Apple were first to implement OpenCL (they invented it) and are first to deprecate it too, in favour of Metal, which has a number of technical advantages.
Vulkan and Metal have a lot of overlap in approach, so it’s not outside the realm of possibility to support both, while perhaps fully dropping OpenCL.
Speaking of different renderers, I really hope Eevee will keep supporting AMD GPUs on macOS.
This is probably a stupid question, but if you set the render preferences from OpenCL to None, will this also affect Eevee? Maybe Eevee only uses OpenGL?
Eevee uses OpenGL, the decision to drop OpenCL on Mac only affects GPU rendering on AMD cards in Cycles.
Thanks for clarifying that, @lukasstockner97, appreciated. It’s a pity that Apple also stopped supporting OpenGL though. I hope that will not eventually result in issues similar to the OpenCL issues in Cycles.
Ton warns that Mac. users will likely see a degraded experience due to Apple not being supported of FOSS, as well as the huge overhead of creating and maintaining yet another graphics backend if the long-term goal leads to Vulkan (as Apple phases out OpenGL on their machines).
https://lists.blender.org/pipermail/bf-committers/2018-December/049718.html
Ton also is of the opinion that Apple is actually trying to make it more difficult for the Mac. to even have FOSS options for its users as evidenced by this final thought.
Last thing for everyone to know: Apple took back our Mac Pro dev system loan last summer. My contacts within Apple can’t manage to get approval for sending us another system. Blender Foundation has to pay for the Apple developer program (to sign binaries).
Apple is clearly not interested in supporting open source or cross platform openness in any way. If they would, they’d work with the industry on getting decent Vulkan support for their systems. If they were, they would give open source coders access to updated hardware.
This could change though if Apple decides to have a Vulkan implementation based on Metal, which Ton has hope for.
That said, I recently got an iPad for mobile gaming and in my opinion, that’s the one area where Apple has a serious advantage over the competition thanks to iOS and their high-powered CPU designs. FOSS is not as critical in that area when the apps. top out at just 10 bucks at most.
Don’t forgot FOSS isn’t just about free as in beer. The apple app store is subject to topdown approval. I could get a super nintendo emulator running on my android devices, but no such thing for apple.
The end goal for Blender may indeed be Vulcan but for apple, it’s been and will continue to be Metal. Which I personally believe is conceptually better anyway. It includes features of both GL and GP-GPU. So, deciding not to use it is really the death-knoll for Blender on OSX. I seriously doubt Vulcan will come to OSX officially. I understand that there are issues at the moment with Metal but eventually Blender should at least give it a go. Obviously, it’s easier said that done though.
The problem then is that the BF would need the resources to manage two different backends for graphics, which is a difficult thing to obtain and would lock most FOSS projects out of Apple’s hardware.
The only way to keep Blender going on MacOS would be to either have a dedicated developer work a year or two on Metal integration (followed by keeping him around for maintenance and updates), or Apple embraces open standards like Vulkan.
I get the desire here. I’m primarily an OSX user here myself (more because I work on iOS apps than due to preference). I have a sweet little MacBookPro that I’d love to keep using as my primary machine but, as a developer, I completely get the Blender Foundation position here. Apple are rejecting open-standards for more of their walled-garden @#$% and Blender doesn’t need to follow them down the rabbit hole.
And why should they? Apple represents a small fraction of their user-base compared to the OpenGL/Vulkan crowd and if Apple do decide to change their mind (it wouldn’t be the first time), any effort done to cater to the Cupertino’s whims will be wasted.
(note these opinions are my own and not of my company)
Is the cuda backend of cycles not also following a company down a walled garden rabbit hole when there is an open source alternative out there?
Regardless. This whole discussion is about replacing the opengl code all over blender with metal? It seems there is a better solution in all this to me. QT. Given their re-emergence of embracing open source, why does blender write all its entire UI in custom opengl when there is a industry standard and mature alternative out there? Obviously viewports are a different matter as well as rendering back ends but it seems unnecessary to have to worry about how UI is drawn when there’s a good abstraction layer that is cross platform.
QT devs are not keeping up with Linux very well. I’m currently having a lot of problems with QT applications including Octane, Substance, and Davinci Resolve. 
I have never had the same issues with Blender, anecdotal as that is. 
Not really. CUDA, when first implemented, came with benefits that the open source alternatives did not. There are graphics cards using their CUDA drivers that can do things it is hard (or impossible) to replicate using GLSL or similar. There is a reason that open-source projects like Torch, TensorFlow, and other deep learning frameworks still implement CUDA back-ends after all.
From a project management standpoint… QT isn’t better. There is already a UI library in place. If completely rewriting the UI level frameworks was an option, it wouldn’t be as much of a chore (proportionally speaking) to have a generic Vulkan/Metal backend. Outside the desire for a Metal backend, there isn’t a need to redo the UI level of code.
When it comes to large software projects, a good rule of thumb is to not fix what isn’t broken. The UI code isn’t broken. At worst, the Apple change “breaks” Cycles as a GPU supported renderer.
If Apple do not embrace open standard Vulkan then they should be labeled as company that wants to control everything, people in future will avoid Apple more too. Actually open your eyes, Apple is already creating a cult.
I would be curious as to your setup. As I understand it Qt is probably more developed on Linux than any other platform. I am running on a Qt based Linux desktop, I run Substance, Houdini, Resolve and Photoscan of which only the last one has given me qt based issues (based on wanting to mix the bundled Qt libs with System Qt libs).
On the other hand, I don’t have a real desire to see Blender switch from what it is doing. The only real upside in migrating to Qt would be making it easier for python plugin devs to design ui elements more easily.
The subject above and Ton’s message was about a Metal backend for UI, not Cycles.
As someone who actually manages large projects, I’d actually disagree on that “if it ain’t broke don’t fix it” mentality. If it takes a bunch of work to rewrite something which makes it more maintainable and capable in the future, that is a good investment. How much the tradeoff is there is certainly up for debate. However, I would cite as evidence’s Ton’s original message that
Blockquote
The amount of work (since 2014) to move old OpenGL in Blender to OpenGL Core Profile was huge. Multiple person years of work. A decent generic wrapper to support other APIs than OpenGL (Metal, or Direct3d) is going to be even more work than that. Everything in Blender draws with OpenGL. Every button, every editor uses it. It means you can only work on graphics apis when all developers/contributors to Blender agree on it and will help out.
This is the part that is “broke” in that it took person years to maintain. Why not make this use an abstraction layer so QT maintainers are the ones to worry about OS compatibility?