3.3 Core Profile minimum.
Due to OpenCL compiler bugs and discontinuation of OpenCL by Apple it was disabled on macOS platform. Other platforms still has OpenCL support
Whatever OGL status. macOS is a nogo if one uses Cycles (and on Apple hardware it is barely usable anyways due to underpowered hardware). As users may remember OpenCL has been broken for a long time. In the beginning Cycles was not available on macOS, there were those discussions with ATI where consensus was that it is not able to affect Apples broken implementation and what not until Apple devs finally spoke with ATI and did at least something. I have personally faced it by tinkering with custom Lux builds trying to get it working with D700 (see why Lux stopped maintaining macOS binaries for Blender.
if macOS / Apple deprecate openGL and openCL, we will deprecate Apple
Although I’m a satisfied macOS user, I will definitely consider a return to Windows if things will continue to worsen for 3D users on macOS. I’m disappointed by Cycles being crippled on macOS because of Apple’s ceased OpenCL support. And as OpenGL is also not supported anymore by Apple, I’m afraid Eevee maintenance will also eventually suffer on macOS if Metal support or a Metal wrapper for Vulkan will not follow in the near future.
And then there’s this quote from Ton:
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.
You could also consider hybrid setup of some GLU+Linux and MSW.
My reason for using macOS has always been having some industry standard apps that are available also on macOS and having posix shell as I do programming.
During the holidays I plan to investigate the possibility of using MSW as main OS, but with a catch - actually using it most of the time in WSL desktop mode. See 21 second of this video It shows xfce, but can be also others, such as gnome/kde, so no issues with customising it to bring together best of both worlds - Linux DE and macOS (for example setting up dock and set of shortcuts for windowing system tasks (expose functionality) in Linux DE, elementary OS (pantheon DE) would even supply most of those things OOB).
Thus after booting up MSW I would actually be in Linux desktop and use all desktop applications that are available on Linux, including Blender, there. I would have posix shell, programming (openFrameworks/libcinder, lemp, node.js n’ stuff) also is done there. I would flip back and forth real MSW desktop just because of some not-availbale-on-Linux software (Adobe CC and specific ACAD/MCAD - reasons I use macOS). Having this setup will also enable me to get rid of separate MSW box that I use currently for VisualGDB.
There is slight performance penalty in doing so as reported here.
If I will find out that the penalty is too much then switching everything to MSW is an option, except for programming needs which then can be done from MSW using WSL or simply running virtualbox.
Apple goes along its way, irrespective of developers and in the end mac os/end users, too.
If developers consider the business of publishing for the Apple platform economically sound, they will do that app / blender addon. If they don’t, no app, no addon.
If an app has already been published, and if it is not economically sound to mantain, and the app price cannot be raise, it will be dropped. There’s a long history of Mac Os developer who went to the lenght of abandoning Mac Os app store because of Apple market rules…
I think these kind of things has to be managed the way Apple itself does: in a cold, business-like way. Asking someone else (the developer, the customer) to pay for business strategy errors is, considering Apple is a 1 Trillion capitalization company, frankly outrageous.
Metal support for Blender? More important things to do before. It can wait. Unless some Apple Activist is willing to do it for free in its spare time…
And yes, sent from my (much probably last) Mac
I could actually see that happening if there was a good reason as to why creative professionals should continue using the Mac. at all (which at this point is not likely, as creators are generally souring towards the platform in general).
Now in the case of an open source game engine like Godot, there could actually be a better chance of someone putting in the work to ensure support of Metal because of the clear advantages the iOS devices have in mobile gaming (ie. more powerful hardware, little fragmentation, and graphics drivers that work). The Mac. meanwhile does not provide any hardware advantage and does not have an attractive hook to encourage developers to exclusively target the platform.
Nope. Read this.
In short no contributions for Metal in open source community. Same for other open source gaming engines which I know of, anyway. Support for Apple is costly and literally nobody is going to pay for it. In short, nobody cares about Apple.
Only chance is Vulkan/Molten, courtesy of Valve. The only sustainable in the long time. Anyway this means porting from open gl to vulkan. The road is long. Very long. In the meantime, Mac Os will wait.
Adapting something like Godot to metal is a much easier process than a DCC app as game engines are designed from the ground up to abstract the graphics layer away from the API implementations. Blender doesn’t have that luxury because until Apple pulled it’s crap, it had no need to do so because OpenGL WAS the “abstraction layer”.
This bears being repeated and highlighted. The whole point of OpenGL (and Vulkan for that matter) is to hide the vagaries of platform specific graphics drivers & requirements from the developer.
And Blender aren’t the only ones having this issue. I have a whole suite of GIS terrain rendering code in C++ that I share between iOS & Android. Been working perfectly for several years. OpenGL is scattered through-out that code because it was the graphics abstraction I needed (I don’t support Windows Mobile in this code). Now I’ve got a lot of work to do to make sure the code does what it already did but in Apple’s “special way”.
the good news about blender as far as I understand anyway is they build an abstraction API for themselves called Gawain library.
its used in blinder so it can handle draw request by sending it to the library and the library use one of the different back-end to talk to the driver .
on the negative side there is only an Open GL back-end now,
on the plus side anyone interested in writing a back end for metal or DX or Vulcan can write one without mucking about with blender itself
That is actually my commit, the project to weed out all openGL from the codebase is far far from complete, this commit was just one of many that are going to be needed to even think about supporting other backends.
even if we mange remove all openGL calls from the codebase, there still all kinds of opengl-isms like OpenGL State and tons of glsl being generated from quite a few places in blender which may (cough will cough) not be quite as easy to map on a different backend.
To say one could write a metal or DX or vulcan backend if one were to desire that, is a gross misunderstanding of the amount of work still needed to support such an endeavor. To say that you can do so without ‘mucking about with blender it self’ is just false.
I understand that this project is just beginning. Still that mean that a large part is behind us including making the decision and design choices for it which is a big deal.
right? And that project will continue anyway so in a year or so my brevios comment will be valid-ish?
I didn’t mean that this will be very easy or quick, Just that we are not that far behind either.
As far is I know Glsl is possible to convert to other formats already . I think there is converters used in game engines
Still long road ahead I know that much
I stopped working on it, afaik no nobody is currently working towards this goal. There’s some people that have shown interest but nobody actively picked it up.
That’s too bad. Personally I think if you are going to go through the trouble of porting Blender to Vulkan then abstraction should at least be on the table. If for nothing else to make porting to any future technologies easier/a possibility for the BF. Hopefully someone will pick this one up.
At the rate the standards are being upgraded, to keep FOSS projects up to date could require at least one hired developer to work just on backends. Otherwise, a given FOSS project would not be able to give their users much in the way of new features and tools because the priority is simply to make sure they work on current hardware.
This would mean a major boon for billion-dollar commercial vendors because they can throw as many devs. as needed to work on these backends and add the features and tools the userbase demands. Who knows where Vulkan and Metal will be a few years from now, perhaps because of the alleged advantages of Metal, it also becomes the standard for Windows and Linux just when the devs. finish the port to Vulkan.
Perhaps the approach to take is to just focus on making Blender’s graphics code as generic as possible so as to be ready to go in any given direction as needed (which the existing commits seem to have hinted at). I know Ton said it will require a lot of dev. time, but perhaps the time needed can be reduced, or perhaps a way will be found to even automate some of the process.
Nobody said it wasn’t on the table, I suppose if someone were to work on porting to vulkan it may very well be, but nobody is currently working on that either.
Hmm. Okay. I thought that was the plan after 2.8 (the series).
Yes and Vulkan itself has changed quite a bit since release and is still changing. Vulkan as far as I can tell won’t be like OpenGL where being able to run legacy code will be a priority they seem to be firmly looking forward and following DX. So I wouldn’t be surprised if they break compatibility at some point as they pursue they transition newer hardware. It’s one of the reasons why the OpenGL Next initiative was created in the first place. They wanted to stop vendors from adding extensions to OpenGL just to get it on par with DX. DX/MS pretty much dictates what direction the graphics industry is going to go for the most part (with input from vendors of course).