macOS is deprecating openGL


(Ace Dragon) #219

I don’t know if Windows as a platform is as rock solid as it used to be.

People on the Home Edition and have new machines get auto-upgraded early on to a new major release version (and that has led to tremendous headache when the April update gave them bug after crash after regression).

I have the Pro Edition partly for this reason, deferring the major upgrade intervals by a few months is the only way to ensure good stability in the age of Microsoft ditching their QA team in favor of the insider program. That is then followed by many Home Edition users feeling like beta testers.

(BeerBaron) #220


In other words, Windows is catching up to Linux and Mac OS in terms of brittleness. Yet, the market share advantage remains.

(numen22) #221

Some more information from an (apparent) insider why Autodesk took the decision to stop supporting the upcoming MacOS version with Alias & VRED.

` I worked at Autodesk from 2007 - 2011 and on Alias / Alias-related things for a good chunk of that. I was part of the team that ported Alias to MacOS. Alias development started back in the late 80s and was written for (I think) SGI machines. Back then, the company was Alias (merged with Wavefront and ultimately acquired by Autodesk in 2006) and the software was called Studio. OpenGL formalized in the early 90s and Alias (the company) ported Studio to support this nascent API. That meant that Alias could run on any OS that supported OpenGL.
This was a fantastic strategic decision because it allowed Studio to port to various flavours of Irix, HP Unix, Windows, Mac OS, and even Linux. The Linux build was/is internal. It was a little janky to use as a modeller 8 hours a day, but good enough for a development workflow.

Porting to Mac OS occurred in 2008 (I think) and was a reasonably sized project. Alias renders all of its own UI in OpenGL, so in theory, it was as simple as “Get a GLContext, and render to that”. Of course, there were other things to deal with:

  • Cocoa specifics like windows / events

  • Various filesystem differences

  • IPC (Alias launches a subprocess to open new files to insulate a bad .wire file from crashing the main process)

  • Performance issues caused by various aged code (e.g., still a few places using display lists).

I don’t have any specifics for why Autodesk invested in porting Studio to MacOS back then. Apple was on the upward trend in terms of design and market share. I can speculate Apple was demanding a Mac OS version of Alias for its own use since, as others pointed out, Apple is a pretty big Autodesk customer.

Back then, the team had 10 - 12 developers. Today, it’s 4 or 5. That’s enough of a skeleton crew to keep the lights on, but not enough to undertake a migration to a Metal backend in addition to other maintenance work. It could be done in theory, but it’d need an extra few devs working full time for a few months.

I agree with the other points made here that the decision was likely made that the ROI of maintaining the Apple port wasn’t worth it. Sure was fun to write though. `

(Ace Dragon) #222

More potential bad news for Mac users, Apple reported a sharp drop in MacOS machines.

That said, they still had record revenue, but it is clear that they are increasingly the iPhone company as much of their growth was stuff related to that product (Apple Care and Apple Music, which are common products used with those devices).

In a way, MacOS doesn’t seem so important to Apple’s bottom line right now (so they can afford to try some radical changes to the system in an attempt to position it for the future instead of the present, even if it means forcing a rewrite of every single application and losing a lot of them in the immediate term).

(BeerBaron) #223

That “sharp drop” is 13% less units and 5% less revenue (and probably 0% in lost profits). If Apple was desperate to sell more units, they’d just put out a sub-1000$ machine (that isn’t garbage like the current Macbook Air). Instead, they’d rather maintain the customer expectation that 1500$ is where a Macbook starts.

Apple just doesn’t care about the market where there is no money to be made, where all the PC manufacturers fight over scrap. If that means having only 5% market share, so be it.

Conversely, that means that if Apple isn’t currently catering to your niche of the market, that niche is deemed unprofitable by them. It’s a signal for you to move on to other platforms.

(apoclypse) #224

Yes but it also shows that MS is more willing now to break things and to deprecate things than the MS of yore. Just because something works now doesn’t mean it will work in future versions and MS has said as much since Windows 10 was released.

I personally I don’t think it would be smart to tie yourself to one platform specific api just because it’s popular now. We don’t know what the future holds, it makes more sense that if you are writing an app now an abstraction layer should be top priority.

Considering modern software like Affinity etc, are doing just that, I think most developers are on the same page. Not only does this let them move to other platforms (like the iPad) with pretty much the same codebase, but if DX13 comes out tomorrow and is drastically different than DX11, DX12, then you have options. Yes it’s more overhead for the developer but they gain more than they lose imo.

(Stefan Werner) #225

Which was the hole purpose of OpenGL to begin with.

(BeerBaron) #226

To put that into perspective, they are still shipping IE11 with Windows 10, they are still supporting win32 API, they have backpedaled on Store-Only Apps and their Metro UI and they are even adding x86 emulation to their ARM devices.

Is it going to be like that forever? No, but no other platform comes close and despite all the nonsense that Microsoft has pulled lately, their market share on the Desktop is as solid as ever. Mac OS is slowly giving up the market and the Linux Desktop isn’t gaining any traction either. Tablets haven’t taken over. If there’s any fundamental change on the horizon, I certainly don’t see it.

Top priority should be shipping an actual product, supporting fringe platforms from the start is a really bad idea. If you don’t know what the future holds, then you also don’t know whether an abstraction layer is the best decision. It’s a big upfront investment for a vague profit in some possible future.

You always have the option to implement support for another renderer backend when you actually need it. Modern graphics APIs need application-level encapsulation anyway, it’s not like OpenGL 1.1 which you could use like a drawing library and therefore spill it all over the codebase (which is what happened with Blender’s UI code).

If DX13 is drastically different, then chances are that your abstraction layer isn’t going to work well either, because you can’t predict what the right level of abstraction should be ahead-of-time. That’s why so many DX11 games that add Vulkan/D3D12 backends don’t really profit. The whole architecture can’t take advantage of the new API.

No matter what you do, there’ll be extra work, the question is whether you do it now or later.

(John Forde) #227

Which was the hole purpose of OpenGL to begin with.

Yes. But it is too old now. To keep compatibility with earlier versions means that its architecture is compromised. It needs to be replaced.

(John Forde) #228

Then Blender should pull support for Linux. However, with 13% of the market, macOS is not a fringe platform.

(dracoroot7) #229

I think one of the reasons that so many open source programs support Linux is because the majority of the devs that contribute use it along with the cross platform toolkits. Even now the ones that support windows have very few actually Windows core developers. I guess we can throw open source philosophy in the mix.

(Ace Dragon) #230

To further the point, most of the communities around FOSS software tend to have a disproportionate percentage of users who are on Linux (so Blender becoming Windows only would guarantee the project being forked and taking key developers with it).

If anything, MacOS seems to get the short stick in both development and build availability more than any other OS due to Apple’s rules and practices (no mixing of modern OpenGL code with older code, can’t use OpenCL beyond 1.2, AMD having no control over GPU drivers, ect…). Now they are pushing for MacOS apps. to be partially rewritten to make use of Metal, and it’s still not clear as day as to whether MoltenVK will fit the bill for Blender if Mac remains a target.

(John Forde) #231

Blender needs to have an abstraction layer between its renderers and OpenGL/Metal. That way you can use either OpenGL or Metal. This is what the game engines like Unity and Unreal have done. I’m not convinced that MoltenVK (or Vulkan) is a good fit for this abstraction layer.

(BeerBaron) #232

I was giving the example of an app newly written today by a business, not an old codebase. Blender should just stick with OpenGL for now, because all that code is written already and will continue to work.

If OpenGL really stops working on Mac OS, then the situation can be re-evaluated with the information available at that point in time. Maybe some decent abstraction library will be available then, supported by some larger entity. Maybe that’ll be something like MoltenVK. Or maybe the answer is that Mac OS support isn’t feasible, because no FOSS developer wants to develop for it anymore in the first place.

Whether you consider 13% “fringe” or not, it’s a small share and there’s little benefit to go the extra mile to support it. Just think of all the large companies that don’t ship software for Mac, they’re all convinced going multi-platform isn’t worth the investment.

Well no, Blender doesn’t need to. Blender can keep running on OpenGL on Windows and Linux. Users can install either of these operating systems on their Macs, or switch to other software.

Creating such an abstraction layer is a lot of upfront work and an ongoing maintenance burden, which means the majority of users need to give up on other features, just so that a minority of (presumably affluent) Mac users aren’t inconvenienced. I don’t think that makes sense. That’s of course unless Apple (market cap approaching 1 billion $) or someone else sponsors that development.

Okay, but it’s not you who needs convincing. MoltenVK at least is supported by Valve, who seem to have some minor interest in keeping the Mac alive/undead as a gaming platform. Vulkan is already a somewhat low-priority development target for Blender. There are converging interests here, so it’s the most likely thing to actually happen, even if it’s not the best solution that your imagination can conjure.

(sundialsvc4) #233

Quite frankly, I suspect that “Let’s just deprecate OpenGL”" is not something that “even Apple” can actually pull-off …

… nor that it will, eventually, find “business(!) necessary” to actually do.

"Stay Tuned.™"

(John Forde) #234

No. Now is the time to evaluate the situation. Apple have said that OpenGL is going to be deprecated at WWDC 2018. Now is the time to act.

13% is a not a small share. The share of Linux desktops is a small (< 2%), yet Blender supports Linux. By actual numbers alone, Apple sells 20 million Macs a year. This makes it absolutely essential to support it.

Not really. The upfront work is not trivial, but not large either. Maintenance for Metal support is likely to be trivial (like OpenGL now) and actually Blender will improve their architecture at the same time, so a net benefit.

My guess is that Blender will absolutely embrace Metal - if only because all the developers in the Blender Institute use Macs. :wink:

(dracoroot7) #235

According to blender stats you have more win32 users than mac users and they are willing to axe win32, but I think most would agree the abstraction is a good Idea; just no one to fund it at the moment. Linux stats for blender are hard to get accurate because of package manager distributions, but like I said before you have more linux contributors. Linux support is also not just about users , but also distributed rendering, open free software supporting an open free os, ect… (Arnold aslo supports linux)

(I too would love blender to keep healthy mac support, multi-platform is one of the reasons I love blender)

(Stefan Werner) #236

It was replaced, with newer versions of OpenGL that dropped compatibility, starting with OpenGL 3.1. That was done exactly for that purpose, to drop old functionality that held things back, such as the fixed function pipeline and immediate mode drawing.

And lots of work has been done by Blender developers to ensure that none of that old functionality gets used. Blender 2.8 runs in the OpenGL 3.2 core profile, where none of those deprecated calls are available.

OpenGL 1.0 is from 1992, but today’s OpenGL looks nothing like it except for the name.

(Stefan Werner) #237

When Apple announces something, it’s absolutely not the time to act. Apple has reversed their stance so many times before. Remember, no iPhone SDK, you were supposed to build web pages instead? No stylus? 9.7" being the perfect size for an iPad?

Or look at Cocoa: Yes, that all new modern API we all needed to switch to. Carbon was a dead-end and supposed to die right after MacOS X was introduced, right?
Fact is, on today’s macOS 10.13.6, I can launch and use 32bit Carbon applications with full functionality - Retina support included. However, every 64bit Cocoa application using garbage collection, which was the all new great thing in 10.5, stopped working two years ago with 10.12.

If you were a Mac developer starting with MacOS X 10.0 and had jumped on every latest trend, you’d have ported your code to ProjectBuilder, to Xcode, to MachO, to Objective-C, to Cocoa, to Altivec, to headless 64 bit, then to full 64 bit, to the G5, to Objective-C 2.0, to garbage collection, to ARC, to Intel, to more modern Cocoa, to Swift.
If you’re a developer with a bit more patience, then you can skip some of the intermediate steps and go right to the end. Skip ProjectBuilder, skip headless 64 bit, skip garbage collection, skip microoptimisations for the G5, maybe even skip some Objective-C and go straight to Swift.

To the user it would make no difference at all - do you know what compiler Blender was built with? Do you care if its OS calls go through Swift or Objective C? Could you even tell if it had secretly switched from OpenGL to Metal in 2.79b?

Not really. The upfront work is not trivial, but not large either. Maintenance for Metal support is likely to be trivial (like OpenGL now) and actually Blender will improve their architecture at the same time, so a net benefit.

Are you saying that from first-hand experience in writing and maintaining platform abstraction layers?

To be honest, I think if one were to write a library that serves as an abstraction of Vulkan, Metal and maybe DX12 too, one would end up with something that resembles modern OpenGL. C based, state encapsulated in objects, bindless direct manipulation, shaders represented using an intermediate language…

My guess is that Blender will absolutely embrace Metal - if only because all the developers in the Blender Institute use Macs. :wink:

So many Macs there. :lying_face:

(Kramon) #238

affinity just released their apps on ipad pro. i mean they run on ios and oh boy that looks dope! If we would be able to near future run blender on ipad pro… that would be so nice… imagine sculpting imagine greace pencil! imagine compositing lying on sofa just chilling while for example rendering happens on renderfarm… that would be so nice. i am in personally…

apple is going to ditch bove. not only open GL but also open CL… but open CL is a bit secret.