Apple Ditching OpenGL?

Wow, finally something interesting to say about Apple for a change! Apparently at Apple’s recent WWDC event they announced a “competitor” to DirectX called “Metal” … as in coding DIRECT to the METAL… get it?

That only took 20 years… Aside from their usual mopping the floor with Microsoft blather this may be a hugely significant announcement because it actually heralds the end of OpenGL as a gaming API. Why? At the time that DirectX was created Microsoft also largely controlled the OpenGL standard, the success of DirectX in gaming caused Microsoft to largely lose interest in OpenGL leaving it in the hands of the 3D chip OEM’s to advance as an open standard that they could use to pressure Microsoft to implement features they wanted in DirectX. Apple’s adoption of OpenGL and subsequent active participation on the ARB breathed life into OpenGL in mobile gaming because Apple’s iPhone implementation of OpenGL became the “standard” that other mobile phone and chip vendors had to emulate if they wanted to get IOS games ported to their devices. Without some form of “standard” hardware definition, OpenGL drivers and media drivers in general are often just a grab bag of broken inconsistent functionality.   Of course in the absence of a “DirectX” like media API of their own design, Apple had little choice but to jump on the OpenGL bandwagon and ride it for gaming, but clearly it is not to Apple’s competitive advantage to be propping up OpenGL support in mobile for all of their competitors. Just as it did for Microsoft, creating their own proprietary gaming API’s is entirely in Apple’s strategic interest…. Why help Android siphon off their game developers by propping up OpenGL?

With Apple abandoning OpenGL in favor of “Metal” which they will surely promote very aggressively to their developer base, what will anchor OpenGL in other mobile spaces? Samsung?

But this isn’t just about the possible demise of OpenGL as a 3D gaming API. It’s possible that the API names will stay the same but that the 3D architectures are about to rapidly evolve away from the traditional linear CPU driven 3D pipeline. The problem is that GPU’s have become so fast and powerful that the CPU is holding back their performance in traditional 3D graphics. The need to break up the 3D pipeline and interact with it more is torturing the first generation 3D API’s because they were never meant to work that way. Their performance potential came from a very narrow definition of how 3D worked and massive linear pipelining to enable efficient hardware scalability. The way game 3D worked was actually a rather horrible perversion of the actual physics of light which are so computationally intensive we had no hope of computing them in real-time on consumer hardware without drastically simplifying the simulation. The introduction of programmable shaders were another abomination because in the absence of real light simulation we resorted to manually programming the lighting properties of every material interaction with every light source. In one respect it was a tremendous testament to human ingenuity that we could make 3D appear to work in real-time at all, but also like playing a giant game of Jenga we were stacking fragile architectural blocks precariously one atop the next and praying they didn’t all fall over. The fact that 3D works at all in modern games is probably largely attributable to a small handful of geniuses with sufficient IQ to create tools that have made it accessible to everybody else… with tremendous effort.

As 3D hardware as evolved to become vastly more versatile and the 3D graphics pipeline has become increasingly jointed and cumbersome to adapt to it, it’s little surprise to me that the market hungers to return to a programming paradigm in which the developer can interact much more DIRECTLY with the hardware without a bloated CPU bound OS or graphics API in the way. With this announcement from Apple I think we’re seeing that Jenga tower starting to topple.

  1. ATI wins all console chip deals with a common GPU architecture, OpenGL holds their chip performance back so they introduce Mantle… BUMP!
  2. Microsoft under pressure from the press and consumers over disappointing XBOX ONE performance and pressure over Mantle announce Mantle like features in DirectX 12… BUMP!
  3. Nvidia seeing the potential use of their GPU’s for supercomputing generalize their shader programming language with CUDA… BUMP!
  4. Apple realizing that their leadership with OpenGL is aiding their competition abandon it for a DirectX/Mantle like API of their own, Metal… BUMP!

Now it’s certainly possible that API’s like DirectX and OpenGL will get overhauled with time to look much more like Nvidia’s CUDA + media capabilities and still be called by the same name, but their present architecture is definitely breaking down. Although these API’s highly pipelined structure still affords tremendous performance advantages, it’s hard to ignore how much simpler and richer 3D development might become if it were practical to embrace more generalized physics and light simulation techniques such as ray-tracing. One of the tremendous benefits of unifying game physics with game graphics is of course realism. In the real-world the light we see is a byproduct of the same physics that govern everything else we encounter. The intimate link between light physics and other physics is largely broken in modern games because the graphics pipeline largely abstracts the visual elements of physics simulation from other aspects of physics forcing developers to awkwardly attempt to recouple them in the game by manually stitching them together.  Although we have largely mastered the laws of Newtonian scale physics simulation, the sheer volume of math is still illusive even on modern GPU’s, however that is not necessarily the case in a cloud based game world where almost any arbitrary volume of compute power can be efficiently deployed as needed on any given aspect of a compute problem in real-time. Cloud based games open the door to the idea that ANYTHING can now be done in real-time.  Impossible client side computations are no longer the barrier to game design, the NEW game design question will be how much did computing a given frame in 1/60th of a second cost?  Personally I’m looking forward to building games that way which is why I have been such an avid early CUDA adopter. Maybe other “open standards” or API’s will come along but at present CUDA is the only tool available to explore this new kind of game design. While the rest of the game community is trying to adopt Mantle, DirectX 12 or Metal, I’ll be re-learning my ray-tracing and quantum physics because I believe those roads all ultimately lead to a more CUDA like API for cloud based game design. It will just take the market a while to realize that.

If you think I’m exaggerating… just ask yourself… what other Apple API’s or Microsoft API’s get their own brand logo? 



“No API is an island, entire of itself; every API is a piece of the solution, a part of the market. If support for an API be washed away by Apple, the 3D market is the less, as well as if the ARB abandoned it, as well as if the game code of thy friend’s or of thine own were: any API’s death diminishes me, because I am involved in all game design, and therefore never send to know for whom the bells tolls; it tolls for OpenGL.”

–With apologies to John Donne–



  1. The quote you modified is a John Donne quote: it’s called Meditation 17.

  2. Your apologies wrt the quotation should really go to John Donne, who wrote the poem “No Man Is an Island” from which the quotation you use is drawn, and which is referenced in For Whom the Bell Tolls by Hemmingway.

  3. Nice article. Your postscript apologies should go to John Donne, not Hemingway.

  4. You meant to leave your apologies to John Donne, not Hemingway.

  5. I’ve seen a lot of hatred for OpenGL from developers recently. Apple’s partners are claiming a 10x improvement in performance with this API. If Apple is truly ditching OpenGL (and I remain unconvinced this is the case), it’s because OpenGL is failing us so badly.

    The whole point of a hardware API is to bridge developers and hardware. This one is bad for developers, and bad for hardware. Why do we cling to it?

    What’s wrong with the industry moving to Metal, if it’s so good? Has Apple promised never to open it to others? The last time Apple did something cool with GPUs was OpenCL, which they spun into an open standard, created a non-profit consortium to manage it, and got all the major hardware vendors to join. If Metal is anything like that, I truly hope (as a former OpenGL programmer) that OpenGL dies a quick death.

  6. I think the apologies are due to John Donne. Hemingway used the “For whom the bell tolls” line from a work by Donne.

  7. Physically based rendering has been making the rounds in recent games without ray tracing.

    • Interesting, you know I had only heard the term in reference to realistic ray-tracing techniques, I’ll take a look at it.

    • Interesting… did you notice the bit about the lighting having to be “static” for this to work. That’s a huge sacrafice to achieve realism. Basically the scene has to be mostly pre-rendered with characters and shadows getting projected into the scene as a final composition step in real-time. It all looks great as long as the lights don’t move and blow up the entire pre-lit scene. That’s a pretty good illustration of how constraining the existing graphics pipeline is. I’ve written previously about how the introduction of the shader model to 3D caused the death of real-time dynamic lighting in games. By emulating the movie rendering model the GPU guys broke the dynamics of real-time graphics.

  8. Without ray tracing. Too bad I can’t edit posts here.

  9. “If you think I’m exaggerating… just ask yourself… what other Apple API’s or Microsoft API’s get their own brand logo?”

    Many Apple APIs do. CoreData, CoreImage, CoreAnimation, SpriteKit, SceneKit, and on and on.

  10. Hi Alex, thanks for your post. To provide suggestions for answers to two questions you raised:

    #1: Why help Android siphon off their game developers by propping up OpenGL?
    A: Because OpenGL is an open standard. As Apple uses different companies for their mobile and desktop graphics chips it helps Apple to have a unified API for graphics, rather than have each graphics chip company create their own proprietary solution.

    #2: what other Apple API’s or Microsoft API’s get their own brand logo?
    A: OpenCL More info can be found here: &

    From my memory, Apple developed OpenCL as a cross-platform solution for GPGPU as nVidia has CUDA and ATI had their own competitor to CUDA called Close To Metal. OpenCL made sense for Apple as then they have one solution to develop against rather than two (or more). In order to get others to support OpenCL Apple licensed it to Khronus Group (which already manages OpenGL) as an open standard for industry adoption, so it made sense.


    • Yes, but Apple is big enough to define their own standards and get all the HW support they need and their marketshare is slipping against Android AND Apple is hardly shy about being as absolutely closed and proprietary as it suits them to be, so I think it’s pretty clear that Apple has decided that the OpenGL thing isn’t in their strategic interest. They can never admit that publicly of course, but they can throw their weight behind their own API.

      Again the OpenCL and OpenGL thing is a fallback strategy if you don’t have your own technology. Absent a proprietary game API strategy Apple had no other horse to ride but open standards. OpenCL was hardly strategic to any Apple business at the time they made that move, it’s not a gaming API… it’s not even a great alternative to CUDA. This smells different, I think they’ve decided to tackle Direct3D head on with their own proprietary game API’s. I think it would suit Apple at this point to see the open standards stuff languish a bit for their mobile competitors.

      Inversely, if Apple gave a damn about OpenGL… there’s a lot of work invested in Metal, you don’t think they could have just lobbied ARB to add the capability to OpenGL first? Apparently Apple didn’t think that cross-chip support was all that important to them this time, did they? I think they are deliberately making it as difficult as possible to create high-value apps for the Apple App market that can be easily ported to Android, Amazon or Microsoft app markets, that’s what this move is really about.

      • Fair enough, I made my response, and you made yours. :)

        • This is the fun part, we get to see how it plays out and compare notes later. The gambit I’m trying to predict is what do the ARB guys do to keep OpenGL relevant. Historically it was the GPU IHV’s who had an interest in keeping OpenGL current. It’s in the interest of the chip makers who support the new Apple functionality to try to get it into OpenGL knowing that their lesser competitors won’t be able to provide it. So that seems to leave the door open for OpenGL to evolve related functionality eventually. My experience however is that without rigid hardware and driver standards all the secondary market products based on open API’s end up unstable and shitty.

        • Now that you mention it Baz, does OpenCL even work on IOS? I don’t think it does… that’s interesting all by itself now isn’t it?

          • OpenCL is currently only used by the System itself on iOS, but folks have nudged around the private APIs.

            No, I don’t think it’s that interesting or telling by itself. Apple is very slow and conservative at opening APIs which could impact performance and battery life.

          • So you’re saying that OpenCL is USED on these devices but Apple won’t let YOU use it because it consumes battery life and there’s something magically LESS battery life consuming about Metal? I know you Apple developers can be real fan-boys for your platform, totally cool with that, but you do realize that Apple employs very proprietary strategies in their own interests all the time don’t you? Wait… doesn’t OpenGL which also exposes the GPU and consumes battery life work on IOS as well? (redundant question) So what you’ve just told me is that the REASON Apple put OpenCL into the open source domain is because they wanted to junk it in favor of something they liked better that they don’t plan to “share”. Good PR and it’s flushed? I think you’re making MY case Tim.

          • Whoa, whoa, whoa… I’m not an Apple fanboy developer at all. I just happen to actually know much of Apple’s history of the last 10 years and am not making wild claims, with little basis, projecting motivations onto Apple that clearly come from a perspective that has clearly been anti-Apple for whatever period of time in the past or currently.

            Yes, I’m fully aware that Apple employs proprietary strategies in their interest all the time. As does Microsoft, your former employer. What’s your point?

            I’m merely stating that because OpenCL has not been exposed as an open API on iOS over the last 5 years does not indicate to me that Apple has given up on the benefits of OpenCL to OpenGL development. It merely indicates a weighing of pros/cons and needs.

            Do I personally think Metal is the future for Apple? Absolutely. But I’m not making strongly biased presumptions that because OpenCL is not yet public on iOS that all OpenCL/OpenGL development is dead, nor am I saying completely, utterly, silly things like — it has a logo! (When 90% of Apple APIs have logos).

            I strongly appreciate your technical insight and experience. But maybe you should chill on the insults and try to mitigate your own biases and presumptions and be more accepting of commenters trying to contribute to your investigations.

          • I’ll also provide a few of my thoughts, if you’d like:

            1. Yes, Apple would absolutely love owning the leading (or even merely a competitive) 3D Graphics/Gaming API particularly tailored and even locked to their needs, chips, devices generally, and profit motives.

            2. Yes, by trying to serve all needs in an open market and through the slow progress of open consortia, the ARB/Khronos Group has likely reached a tipping point in terms of delivering Apple increased improvements at a speed that Apple can fully reap to their advantage and it be worthwhile for Apple to continue to be dependent on them for providing a graphics, gaming, or even general computing API advantage. (As occurred with KHTML, the W3C in later WebKit revisions, SAMBA, OpenSSL, likely others… This is not necessarily a bad thing.)

            3. This is is true (#2 above) in spite of the fact that Apple remains the greatest beneficiary of OpenGL and can definitely be a significant and formidable force within it.

            4. Yes, Apple likely timed this transition very well (or a year or two late) to make the move to provide a significant gaming API even if locked to their minority share of the market in terms of their own developments, processor plans, device designs, market strength, and competitive moment… They’ve probably been working on it for a while and certainly will need to continue to improve it for years, decades to come.

            5. Yes, Apple will now likely prioritize dedicating resources to Metal ahead of OpenGL.

            6. No, I don’t think it’s in Apple’s interest to deprecate and stop contributing and politicking within the OpenGL world while also trying to provide a better alternative for their platform, nor would I presume that Apple is so arrogant, controlling, foolish, and unthinking to even think they can or it would be wise to do so.

            7. No, I would not even presume that even if Apple does successfully become a force in graphics/gaming APIs, even presuming that Metal would largely serve Apple’s intentions, it would remain wholly closed or would be in “evil” stewardship. No more so than DX by Microsoft or OpenGL done openly. (Just as with WebKit, LLVM, Clang, and so on… we shall probably see sooner with Swift, but probably not for two years or so.)

            8. Apple is fully aware that the leading game engine providers, GPU developers, competing graphics API providers, developers, and users all have their own motivations (including cross-platform) that are not their own.

            9. If Apple cannot provide a competitive API or convince its partners to buy-in to a significant degree and the ARB progresses or other factors mean that OpenGL will remain a leading, parallel, or alternative development platform that is also important to Apple, they will continue to support and contribute.

            Even if Apple does succeed with Metal, even widely so, the above may stay hold true.

            10. Whether or not Apple has not supported, advanced, or contributed to OpenGL/ARB to your expectations, I see little reason to see their past or current support of OpenGL as anything but appropriate (in many ways often industry leading with occasional lags due to other priorities).

          • Hey Tim, I don’t know how much of my blog you’ve read but I AM from the evil proprietary API strategy world, I own it and try to talk about that mentality within big companies openly so people understand it. So yes, to the extent that anybody engages in “evil stewardship” that’s exactly what DirectX is and what Apple intends Metal to be. That was the gist of my point about them branding the API. Apple and most companies have tens of thousands of API’s they DON’T brand, companies BRAND the proprietary ones that are strategic to them. The WANT people to know that the API is NOT open and is CONTROLLED exclusively by them because the purpose of the API is to differentiate their platform. Thus I conclude that Apple is moving aggressively towards a proprietary graphics API strategy and AWAY form an open one. Like Microsoft and many other big companies, Apple will ABSOLUTELY continue to pay lip service to open source stuff, there is no upside associated with actively incurring the wrath of people who hate closed platforms. My point is that they have clearly chosen to go proprietary in their graphics strategy going forward… their active “use” for OpenGL has ended.

          • Of course, I know who you are. And if you read my posts, you’d see my views are not far from your own.

            Where I object to your assertions is where you seem to belittle and blame Apple for failing OpenGL where it is OpenGL that has failed Apple and itself.

            Putting the fate of OpenGL on Apple now when Apple has done more for the future of OpenGL over the last 5 years than it has largely been able to do for itself and two decades of Microsoft very actively trying to kill it (with your help) is pretty ridiculous.

          • Uh… that would be your bias that you have imputed me with Tim. I didn’t blame Apple for anything, I just observed that announcing Metal is an indication that they are ditching OpenGL and then I freely speculated about their reasons for doing so.

          • We’ll have to differ. I don’t see much reason to put your own quotes in front of you. But I could pick a handful that go way beyond what you just said and are dripping with connotation, scorn, and even further insinuation.

            As I said, I don’t disagree that Apple is moving beyond OpenGL (just disagree with you that it clearly means abandoning OpenCL — Metal isn’t even for OS X (yet)), and yet you still quickly lashed out at me as an Apple fanboy.

            Again, appreciate the responses and enjoy the engagement.

      • I think people who don’t follow Apple full-time are too quick to assume that Apple’s only goal for doing anything is some form of lockin, and this is no exception.
        The reality, I’d say, is that Apple wants best of breed SW and HW. Where they can, they adopt standards (media codecs — cf both Google and MS, ARM ISA, Thunderbolt) but sometimes what they want is just not available in a standard (Lighting, Swift). This looks like lockin IF you don’t prioritize what Apple prioritizes. If you think that worrying about how to orient a power cable when you plug it in is unimportant, Lightning looks like a lockin attempt, but not if you have actually frequently used both Lighting and USB cables.

        Here’s my analysis of Metal:
        It’s not any attempt at lockin, it’s Apple’s warning shot aimed at Khronos: “get your act together and ship — SOON — an OpenGL5 that has the following n things fixed”.
        Especially significant, I think, is that Apple did not mention Metal at all in the context of OSX, and they spoke as though it were some sort of A7 specific API. I think these are all part of “strategic deniability”.

        If Khronos comes through and delivers what Apple wants (which I assume is
        (a) a low-level API like Mantle or Metal which ONLY abstracts the GPU AND
        (b) a high-level API which manages the scene description, but which does so having tossed all the obsolete crap in GL)
        then Apple will stick to this story — Metal was a temporary expedient to get games running well on iOS devices, but we’re happy to move iOS and OSX to the shiny new OpenGL5 APIs (and BTW Metal and OpenGL before 5 are deprecated and will go away in three years, because that’s how Apple rolls — don’t look backwards, baby).

        If Khronos cannot get their act together and insist (like these committees almost always do) that it’s vastly more important to maintain compatibly with games written in 1998 than it is to improve the productivity of programmers today, THAT’s the point at which Apple tells us, look
        – we have Metal running on OSX,
        – we recommend everyone who wants to write very high level 3D code use our existing SceneKit
        – we recommend everyone who wants to write intermediate level 3D code use our new 3DKit API as a (much cleaner and more modern) replacement for OpenGL.

        Should this happen, doubtless there will be many who interpret it as more lockin, but IMHO this is NOT Apple’s preferred outcome, it’s the less desirable scenario.

        • Okay, let’s accept your premise… WHY create an entirely new API in SECRET and launch it unexpectedly nearly complete AND get Epic to port to it if your only goal is to pressure the ARB a bit? OpenGL is OPEN… why not just hack your own extensions on to it? Why not just TALK about Metal loudly without doing a ton of work, if all you want to accomplish is motivating the ARB? Why do this work when Mantle is already applying this pressure to the ARB?

          The purpose of secretly investing a HUGE amount of development effort into creating a decidedly UN-OpenGL like API and SURPRISING the world with it, nearly complete, with support from one of the worlds most legendary 3D engine companies would generally appear to look more like an AMBUSH on OpenGL intended to displace it, not a minimal effort threat to get them to cooperate… Why would Apple even need the ARB to cooperate with anything they wanted to do? This is a leap with both feet straight into displacing other graphics API’s, with apparently a lot of effort invested in keeping it a secret until it was nearly finished. That behavior would not appear to be consistent with your theory about Apple’s motives in this case. You would make lots of noise along the way hoping to avoid wasting huge amounts of engineering cycles and Epics’s time if you weren’t deadly serious.

          • Because Apple’s preferred solution (which I think most would agree is the correct technical solution) is that OpenGL5 would consists of two layers, one of which would be essentially Metal and the second of which would be a Scene Description language that’s a kind of cleaned up OpenGL.

            This is conceptually not much different to what Apple did with OpenCL. It’s less of a slam dunk because the installed base is a lot larger so the politics is different, but same idea.
            As I understand the OpenCL timeline we have
            – developed in secret at Apple
            – publicized June 9 2008
            – June 16 Khronos forms a committee
            – Dec 8, 2008 Khronos releases essentially what Apple gave them as a public open spec.

          • …Apple never enables or encourages IOS developers to use OpenCL for some reason… Never does a press launch with Epic to kick it off… just dumps it into open source while keeping almost ALL of their other media and graphic API’s closed and proprietary for some reason… yeah… Metal is EXACTLY like that… really? Actually, one can’t help but notice that Apples adoption of any open graphics API is actually kind of the exception for them. Having closed proprietary API’s as Metal appears to be is actually their NORMAL behaviour. Metal looks NOTHING like OpenGL, how can that be Apples “preferred” solution when they have gone so far out of their way to completely discard the OpenGL paradigm in Metal?

            I think you’re engaging in some wishful thinking, the evidence points pretty clearly towards Apple ditching OpenGL.

          • Well, Alex, we have the next step in the drama happening today with Vulkan (very Metal-like) announced. As far as I can tell with the blessing of Apple (they have their logo on the slides along with all the other usual suspects).
            The next step is Apple’s WWDC where we either see Apple cheering up Metal for all it’s worth and released on OSX, or we see Metal quietly sidelined with Apple cheering up how great Vulkan is (and how well SceneKit plays on top of Vulkan). My guess is that latter scenario, that we’ll never see a Metal for OSX announced, and Metal for iOS will be retired in favor of Vulkan for iOS.

            We MIGHT see earlier hints of the direction through Apple contributions to SPIR-V in LLVM, but Apple generally are pretty tight, even with their LLVM mods, until the big reveal. (And there are probably still ongoing negotiations about exactly how LLVM plays into this. Khronos seem to be playing coy about exactly how/whether their C++ front-end will be open-sourced; though some of this is presumably just delaying until after all the comments are handled and the spec goes from provisional to final.)

  11. The reason that it is to discourage people to port easily to other platform, I don’t by it totaly. I agree that it is easier to port between 2 opengl ES platform but there are differences which will make you want to have 2 completly different code base anyway. If just for good code design. I think that even now developper don’t share that much between their ios and android code base. So yes it will make it harder but I don’t see that it was that much easy to justify the move. I feel there is an other reason, maybe related to why OpenGL on OsX is so stagnent.

    • Are you referring to Apples specific implementation of OpenGL on OsX or the stagnation of OpenGL in general? What do you think that other reason would be? Why wouldn’t Apple continue to ride the open platform horse in 3D and computing, they’ve obviously previously been a leader in it… why STOP?

      • I am referring to Apple specific implementation, the fact that they stayed longer than everybody wished on 3.2 and that only last year they released 4.1, when 4.4 just got released ( i beleive). I don’t know what other reason, but to lock developper on a platform, i am not sure, it probably just mean they have to reimplement their osx ogles renderer but that was most probably already a separate code base different than their android ogles renderer.
        Maybe they beleive they can do better and are tired of the politics of OpenGL. They like to control their stuff. I beleive that next year you’ll see Metal on OsX and the death of opengl on OsX. That could also explain the stagnation of Opengl on OsX.
        I wouldn’t say they are a leader in open source, they do it partially when it suits them. By the way all of this is just a feeling, Apple are really hard to see through.

        • Well, I think your instincts are correct. I think Apple had an interest in letting their OpenGL support languish because they have other plans don’t they?

          • If Apple’s support for OpenGL is “languishing”, how would you characterize the support from the other large platforms: Microsoft, Sony, Nintendo, and Google? Sincerely curious because “languishing” seems unfair to me.

          • I should write a blog about how big companies systematically manipulate open standards to achieve particular strategic goals. Open standards suit big tech companies when they are coming from behind as Apple was in 3D innovation and are an inconvenience when they are ahead of them. Paying lip service to open standards, dumping irrelevant code bases or projects into the open standards community, feigning support for open standards as long as they are languishing is all good PR. For example Apple LOVES HTML5 while it’s immature and not widely used but BANS FLASH on IOS because Flash is robust enough to create an alternative market to Apples proprietary App store. So open browser standards are GREAT by Apple as long as they suck, and proprietary closed platforms are HATED by Apple… especially if they are competitive with their own closed offerings. Saying open standards “stuff” is always good PR and big companies often like to have representatives on open standards bodies they are strategically concerned about to specifically cause drag on the standardization process of features that are competitive with their own. So their “apparent” support is often actually for the purpose of slowing things down… In my day at Microsoft we did this by joining these bodies and just loving and supporting the dumbest ideas from the smallest participants and hating and thwarting the standardization efforts of our biggest competitors. Rest assured that Apple had those people to.

          • Yeah, completely ignoring my question and going off on Flash on mobile which is ancient history and was a good thing AND was a GREAT for the OPEN WEB… not really getting me to appreciate your perspective despite my immense respect for your technical knowledge and expertise.

            I look forward to more technical info. But hope that maybe you abstain from injecting your personal feelings from future reports because you are blinded by bias but there are many people looking to you for an early technical assessment of a difficult new technologies, and your attitude probably isn’t helping them and certainly not making you look very good. But, seriously, very much appreciate your thoughts, engagement, and time. Thanks.

          • Well Tim this is MY blog where I do nothing but biased opinions about subjects which interest me, if you feel threatened by them I would understand if you don’t choose to read them but I certainly intend to continue doing it because my particular “bias” is guided by some very unique experience that other folks benefit from learning. I’m not clear on what you’re really so upset about because I actually expressed enthusiasm for Metal… or are you upset because I believe from enormous experience with API strategy that Apple has placed a vote of no-confidence in OpenGL?

          • @ Tim F. I think the term “languish” is totally appropriate. Opengl 4.1 came out on 26 july 2010, and it came into osX last year in 2013. 3 years later, in tech years that is like a decade. Now the latest OpenGl 4.4 was last year. This year Osx 10.10 is still only Opengl 4.1. We developper rely on Apple to implement the standard and they do it at a languishing speed.
            About the other platform they don’t apply, you named console and those are frozen in time hardware, they will never evolve after their release. As for Microsoft they have been at the front of the research and implementation for several years. Only since OpenGl 4.3 that they are now about neck to neck. Still Apple doesn’t even have 4.3 which was released in 2012. And Google well they deal with OpenGl ES so not really related.
            At that point i am not frustrated at Opengl board but more at Apple for their lack of commitment in one of their tech. With, Metal i know why. Just have to wait until it come to Osx and i’ll port my renderer.

          • Alex, I’m not claiming that I have control of your blog. Write whatever you like. I asked a question, you went off on a rant, brought up Flash (which is a losing argument) and kept insulting Apple — something you are claiming you aren’t doing.

            I’m just suggesting that, while I trust you on technical matters, I don’t trust how your personal opinions affect your thinking on strategic or motivational issues, and that your response wasn’t helping to persuade me or likely anyone else.

          • I guess you haven’t seen my articles on Windows Metro UI to differentiate what my idea of “insulting” is. I thought I was being down-right charitable with Apple this week.

          • Mani, that response doesn’t make any sense to me. I’m not familiar enough with Windows support of OpenGL but as far as I am aware it’s not in Windows 8 (let me know if I’m wrong), most support comes directly from the GPU makers, and they’ve actively been trying to kill OpenGL for decades (as Alex openly admits). You completely exonerate Google because they’re concerned with ES, but Apple has been too and has clearly needed to swap resources and staff from ES to OpenGL in alternating years as attention tic tics back and forth between OS X and iOS. And where they may lag, there’s generally greater lag in the hardware and developer support. Additionally, for like the last 6-7 years, all but the last 3 years, OpenGL has largely been focused on deprecating old code and supporting DX (again, correct me if I have that wrong, that is my general understanding)… It’s good to see them progressing NOW over the last three years, but Apple carrying them for several years with little benefit, it’s not surprising Apple isn’t jazzed with OpenGL. (Again, you and Alex likely know better than I…) It’s my understanding that OpenGL is largely focused on its ZDO effort (or whatever it’s called) and I can’t imagine that has much impact or benefit to Apple.

            Alex seems to be trying to hold anyone with influence in game development to the fire (or at least particularly Apple); it’s unclear why Sony and Nintendo should only have to display effort at the beginning and ends of their console lifecycles. Hell, Metal only affects a small portion of iOS devices (and not even for several months) and will take years to have an impact on OpenGL ES, but somehow Apple is the bad apple in OpenGL world? I’m baffled.

            I understand devs being excited for new tech and wanting to adopt it, but acting as if Mac OS X platform support lag has had any impact on OpenGL, or game development in general, seems very weak from my limited knowledge.

  12. Saint! Why did you not list Google as the obvious counterpoint to Apple? And your jab at Samsung may be less spiky than you think. As an interesting corrolary, let’s think about another technology in which Apple, Google and Samsung all actively contribute.

    The Webkit project.

    Now, you seem to value Apple and it’s developers extremely highly, as evidenced by your complete dismissal of the ability for others to maintain OpenGL.

    But would it surprise you to learn that Google contributed far more to Webkit than Apple, despite it being Apple’s project? Source:

    Google actually did exactly what you discuss here: They realized that contributing heavily to a competitors advantage wasn’t for them, so they forked Webkit into “Blink”. Now, Blink is being more actively and heavily developed than the Webkit project itself. The Google developer machine is incredible, and to dismiss the Google ecosystem and legions of Google-friendly developers feels very naive!

    The other point of this comparison is to point out the #3 contributor to the Webkit project behind Apple and Google, was Samsung! They are no development slouches and command a larger ecosystem of developers than you give them credit for!

    Just some things to think about– Apple’s the minority in mobile, not the majority (in every metric but profit!), so don’t underestimate their competitors too deeply!

    • Erhm, to clarify:

      Shows that Google was the #1 contributor to Webkit, ahead of it’s owner Apple. also shows that Samsung was generally a top 5 contributor to Webkit. Shows the post split stats, and the new status of Samsung as the #2 contributor to BOTH webkit and blink.

    • Okay I’ll bite… Google has lots of “hobbies” that are often difficult to differentiate from its serious initiatives. 3D stuff has always tended to fall in that category for them. To be clear I dismiss the value of ALL developers to open source projects, in this context I believe that Apples simple USE of the OpenGL API as it’s 3D API did most of the work for them. Adopting OpenGL is what made it a gold standard in mobile, all of the associated work is the symptom of that business choice not the cause.

      Also Microsoft’s former most senior “evil platform strategist” working at the highest levels at Google on Android strategy has left the building… his name was Vik Gundotra and he came from the same strategy group at Microsoft I did. As long as Vik was there I could accurately assess how Google was thinking about these things, but now? Not so much… but I’m actually very comfortable with underestimating certain competitors. Nobody LOVES developing for Android or Windows platforms, Apple developers are a religion, it’s very powerful for Apple to choose to divert them. Without LOVE it’s very difficult for anybody to engage in API innovation and expect anybody to follow them.

  13. Metal is about making Apple’s custom A7-style chips competitive against Nvidia Tegra, Maxwell and Pascal and Intel’s increasing incursions into mobile-graphics. Nvidia’s CEO has said that Android (basically Linux) and OpenGL are the future of mobile-graphics. The point is that Nvidia and Intel both love Android. Then you have what Valve is doing and that’s another area that Nvidia and Intel are keen to dominate and developers are beginning to migrate over.

    To be honest, Apple is totally outclassed by by Nvidia there’s no way they can keep up in terms of graphics performance versus Android devices running Tegras. Metal is a desperate defensive strategy to make sure they can optimize their chips and keep “in the game” but it’s going to be a steep uphill battle the whole time. Nvidia’s OpenGL extensions on Nvidia based devices will simply eliminate any performance advantages Metal can eek out of Apple A7’s in the same way that they have with Mantle on AMD’s.

    This also only applies to mobile-graphics. Apple is still totally committed to Khronos and OpenGL on Mac OS because it allows Apple to maintain an edge in professional graphics and design fields against Microsoft Windows based workstations running DirectX. It would be insane and highly destructive for Apple to abandon Khronos given this fact. Metal is useless on MacPro’s, iMac’s and MacBooks as they all run Nvidia and AMD gear. It’s not that hard for Apple to have these companies optimize their Mac OS drivers. If anything Metal will only become some low-level optimization layer for OpenGL if Apple ever decides to use it’s own ARM chips in ultra-light MacBooks. But it will never replace OpenGL as it is so deeply integrated into Mac OS plumbing.

    Sorry but the only loser in any of this will be DirectX and in gleefully celebrating the “OpenGL killer” Metal you have glossed over this fact…

    • How can DirectX be the loser when the XBOX is the US dominant game console? Don’t follow that argument, you can’t be in the business of making MMOG’s or console games today and NOT adopt DirectX. Nvidia has no marketshare in mobile so although their chips are superior they are no threat to anybody least of all Apple. Nope, Apple just wants to ditch OpenGL and control their own low-level 3D API. Taking control of the 3D API on their platform puts Intel and Nvidia exactly where Apple wants them… as just another potential chip vendor. Your argument is a good illustration of why OpenGL is such a poor 3D standard for gaming, Nvidia’s OpenGL isn’t the same as anybody else’s… Nvidia’s OpenGL is complete and functional, everybody else’s is crippled and inconsistent in random ways, that’s hardly a standard. Just because you call that bucket of inconsistent functionality by the same marketing name doesn’t make it the same functionality.

      • The personal computer running Windows NT is the reason that DirectX succeeded at all not the XBOX which only benefits from that earlier success. Microsoft Windows NT beat both UNIX and Apple because it was a single platform that ran on commodity hardware and a variety of systems. Before open-source became a “thing” Windows was the only “open” platform of it’s day.

        DirectX was both a pioneer and a savior to so many developers because it standardized and allowed them to abstract the hardware away and just focus on their professional applications or games. That’s the power of DirectX and it made things sane. This was in contrast to the crappy consoles that had their own bizarre hardware specific drivers.

        In many ways in the mobile world Android is very similar to Windows NT and what made it successful in personal computers. Market forces are very much showing that Android is becoming the clear winner of the mobile wars. This will have some really far-reaching effects and in the end the markets will favor an open and standardized API that runs on commidty hardware and is truly cross-platform.

        “Android tops 81 percent of smartphone market share in Q3”

        “Gartner Says Worldwide Tablet Sales Grew 68 Percent in 2013, With Android Capturing 62 Percent of the Market”

        Given the variety of hardware and gpu-chipsets the only sane and economically feasible way to address this is to have a sort of DirectX for Android and the UNIX/Linux platform, OpenGL is that API. OpenGL, like DirectX, may have problems but it’s just a matter of addressing those issues. Whatever innovations come out of Metal, Mantle and DirectX it’s feasible that in future generations of OpenGL these features will be addressed. It’s in Intel, Nvidia and AMD’s as well as the various ARM companies best interests to make OpenGL strong and capable if they want to capture the growth of the Android mobile market.

        The company that takes the reigns from Intel will be the one that can best utilize OpenGL.

        + In the end DirectX will continue to dominate over the consoles with the XBOX and the huge Windows PC market, BUMP.

        + OpenGL will be the de-facto standard in the fast growing and vast Android and UNIX/Linux workstation market, BUMP.

        + Any “low-level” API that’s chip-specific and only on a single platform will lose to more generalized API’s because we aren’t living in late 1980’s and early 1990’s anymore, BUMP.

        Generalized API’s that run on commodity hardware and are cross-platform for the win, bravo DirectX and OpenGL!

        • A Well argued case, but I must dispute your conclusions. The world is moving too fast for the open standards process to keep up. Slow, bloated, ponderously evolving, consensus driven standards with a primary emphasis on backwards compatibility places enormous drag on the rate of modern innovation. Fast, targeted, rapidly iterated, market driven solutions increasingly have the edge.

          Furthermore OpenGL IS NOT a standard for 3D hardware, it doesn’t REQUIRE that anybody fully support a standard feature set of it, to a standard performance level, with a standarad appearance and to a standard level of stability. What made Direct3D successful at a time when OpenGL was ALSO available on Windows was rigerous enforcement of WHQL certification standards by Microsoft, that required chip vendors to support DirectX to a specific standard of functionality, performance, stability and rendering quality. The reliability and consistency of Direct3D drivers compared to their OpenGL alternatives was a primary reason Direct3D was adopted by game developers OVER OpenGL. They couldn’t make a real game business on such an unstable platform no matter how passionately they WISHED that they could. In the end OpenGL is just a grab bag of functionality with no standared underpinning that requires it to be consistent or good enough for commercial use. In the absence of strict quality and performance standards APPLE was the best definition of those requirements in mobile. Now that they’ve ditched OpenGL there is nothing to anchor the OpenGL mobile market… probably as Apple intended.

  14. I tried using Java3D and java once. I realized Java3D is a typical Java API… lots of objects to do simple things, and because it’s Java, that translates to a lot of code. I then moved to Jython in Eclipse to which cleaned up the code, leaving me with only the complexity of Java3D.


  1. Khichdi Linkfest 4thJune14 | KorAiran
  2. DirectX creator Alex St John says Metal announcement heralds the end of OpenGL as a gaming API (Alex St. John/The Saint) | NYC Startup News
  3. DirectX creator Alex St John says Metal announcement heralds the end of OpenGL as a gaming API (Alex St. John/The Saint) | Killer Apps TV
  4. Apple serait-elle en train d’abandonner OpenGL ? | Le Diligent
  5. DirectX Creator Says Apple’s Metal Heralds the End of OpenGL - TIME
  6. » L’arrivée de Metal chez Apple signe-t-il la mort d’OpenGL ?Connaissances Informatiques
  7. Week 23 | import digest
  8. Metal, l'equivalente delle DirectX di Microsoft? -

Leave a Reply


Get every new post delivered to your Inbox

Join other followers:

%d bloggers like this: