As our regular readers have already seen, 2013 and 2014 has been one of the most significant periods for graphics APIs in years. While OpenGL and Direct3D have not necessarily been stagnant over the last half-decade or so, both APIs have been in a mature phase where both are stable products that receive relatively minor feature updates as opposed to more sweeping overhauls. Since reaching that stability there has been quite a bit of speculation over what would come next – or indeed whether anything would come next – and in the last year we have seen the answer to that in a series of new graphics APIs from hardware and software vendors alike.

In all of these announcements thus far, we have seen vendors focus on similar issues and plan to enact similar solutions. AMD’s Mantle, Microsoft’s Direct3D 12, and Apple’s Metal all reflect the fact that there is a general consensus among the graphics industry over where the current bottlenecks lie, where graphics hardware will be going in the future, and where graphics APIs need to go in response to these issues. The end result has been the emergence of several new APIs, all meaningfully different from each other but none the less all going in the same direction and all implementing the same style solutions.

That common solution is a desire by all parties to scrape away the abstraction that has defined high level graphics APIs like Direct3D and OpenGL for so much of their lives. As graphics hardware becomes more advanced it has become more similar and more flexible; the need to abstract and hide the differences between GPU architectures has become less important, and the abstraction itself has become the issue. By removing the abstraction and giving developers more direct control over the underlying hardware, these next generation APIs aim to improve performance, ease API implementation, and give developers more flexibility than ever before.

It’s this subject which brings us to today’s final announcement from Khronos. At 22 years old OpenGL is the oldest of the 3D graphics APIs in common use today, and in 2014 it is facing many of the same issues as the other abstraction-heavy APIs. OpenGL continues to serve its intended purposes well, but the need for a lower level (or at least greater controlling) API exists in the OpenGL ecosystem as much as it does in any other ecosystem. For that reason today Khronos is announcing the Next Generation OpenGL Initiative to develop the next generation of OpenGL.

The Next Generation OpenGL Initiative

For the next generation of OpenGL – which for the purposes of this article we’re going to shorten to OpenGL NG – Khronos is seeking nothing less than a complete ground up redesign of the API. As we’ve seen with Mantle and Direct3D, outside of shading languages you cannot transition from a high level abstraction based API to a low level direct control based API within the old API; these APIs must be built anew to support this new programming paradigm, and at 22 years old OpenGL is certainly no exception. The end result being that this is going to be the most significant OpenGL development effort since the creation of OpenGL all those years ago.

By doing a ground up redesign Khronos and its members get to throw out everything and build the API that they will need for the future. We’ve already covered the subject of low level APIs in great detail over the past year, so we’ll defer to our past articles on Mantle and Direct3D 12. But in short the purpose of OpenGL NG is to build a lower level API that gives developers explicit control over the GPU. By doing so developers will be able to achieve greater performance by directly telling the GPU what they want to do, bypassing both the CPU overhead of abstraction and the GPU inefficiencies that come from indirectly accessing a GPU through an API. This is especially beneficial in the case of multithreading – something that has never worked well with high-level APIs – as it’s clear that single-threaded CPU performance gains have slowed and will continue to be limited over the coming years, so multithreading is becoming functionally mandatory in order to avoid CPU bottlenecking.

With that said however, along with the common performance case OpenGL NG also gives Khronos and its members the chance to fix certain aspects of OpenGL and avoid others, typically legacy cruft from earlier generations of the API and times where the hardware was far more limited. For example OpenGL NG will be a single API for desktop and mobile devices alike – there will not be an ES version of OpenGL NG, the desktop and mobile will be unified. As mobile GPUs have nearly caught up in functionality with desktop GPUs and OpenGL NG is a clean break, there is no need to offer separate APIs on the basis of legacy support or hardware feature gaps. There will be just one modern OpenGL: OpenGL NG.

Khronos will also be using this opportunity to establish a common intermediate representation shading language for OpenGL. The desire to offer shader IRs is a recurring theme for Khronos as both OpenGL and OpenCL were originally designed to have all shader programs distributed in either source form or architecture-specific binary form. However for technical reasons and IP protection reasons (avoiding trivial shader source code theft), developers want to be able to distribute their shaders in a compiled IR. For OpenCL this was solved with SPIR, and for OpenGL this will be solved in OpenGL NG.

Finally, the clean break afforded by OpenGL NG can’t be understated. At 22 years old OpenGL is huge; between its Core and Compatibility profiles it covers the history of GPUs since the beginning. As a result a complete OpenGL implementation is incredibly complex, making it difficult to write and maintain a complete OpenGL implementation and making it even more difficult to do conformance testing against such an implementation.

OpenGL NG’s clean break means all of that legacy cruft goes away, which is something that will be a significant boon over the long run for hardware vendors. Like Mantle and Direct3D 12, OpenGL NG is expected to be a very thin API – after all, it doesn’t need much code if it’s just acting as a shim between the hardware and software developers – which means OpenGL NG will be much easier to implement and test. The sheer size of OpenGL has been a problem that has been brewing for many years and previous efforts to deal with it have faltered (Longs Peak), so finally being able to do a clean break is a very big deal for the consortium.

Building a Consortium and a Consensus

Of course the fact that this is a consortium effort is going to be the final piece of the puzzle, as this means the development of OpenGL NG will have to be approached in a different manner than any of the other forthcoming APIs. Microsoft for their part works with their hardware partners, but at the end of the day they still have the final say in the development of Direct3D. Meanwhile AMD specifically developed Mantle on their own so that they could develop it to their needs and abilities without the compromises and politicking that comes from a consortium effort. Khronos on the other hand is the consortium – the organization’s goals to offer open, cross-vendor APIs means that they need to take into consideration the technical and political considerations of all of their members on both the software and hardware sides.

Because OpenGL NG is still in early development, from a technical perspective it’s impossible to say just what the final API will look like. However one thing that Khronos is making clear early on is that because they’re going to be cross-vendor and cross-platform, they expect that OpenGL NG won’t be quite as low level as some of the other APIs we’ve seen. The goal for OpenGL NG is to offer the explicit control benefits of a low level language and maintaining the broad reach of an Open standard, and that means that whatever form OpenGL NG takes will require it to be a bit higher than the other languages (e.g. Mantle). Khronos for their part is confident that they can still deliver on their desired goals even without being quite so low level, so it will be interesting to see just how OpenGL NG, Mantle, and Direct3D 12 compare and contrast once all of those APIs are released.

This focus on portability means that OpenGL NG will also be a more tightly defined specification than any OpenGL before it. Poorly defined or undefined aspects of OpenGL have led to slightly inconsistent implementations in the past, and even though this has improved in recent versions of the API, even the stripped down OpenGL ES still has areas where there are compatibility issues due to differences in how the standard is interpreted and implemented. With a clean break and a much smaller API overall, Khronos has made it a goal for OpenGL NG to be fully portable and the specification completely unambiguous, so that all implementations implement all functions identically. This is something Khronos has been able to do with WebGL, and now they tell us that they believe that they have to do the same for OpenGL NG in order for it to succeed.


Recent Timeline of OpenGL Releases

But perhaps more daunting than the consortium’s technical considerations are the consortium’s political considerations. Khronos has attempted to overhaul OpenGL once before in 2007’s failed Longs Peak initiative, with the consortium ultimately unable to come to a consensus and Longs Peak being put to rest in favor of the more iterative OpenGL 3.0. There are a number of reasons for this failure including technical disagreements and concerns over backwards compatibility with existing software, but at the end of the day Khronos can only move forward when there’s a consensus among its members, something they didn’t have for Longs Peak.

Learning from Longs Peak and desiring to avoid another failure this time around, Khronos is being far more inclusive on development of OpenGL, working to include as many software and hardware developers as they can. This is why OpenGL NG is still an initiative and is in all likelihood some time off – design by committee projects will always take longer than solo efforts – so today’s announcement is as much an invitation to additional developers as it is Khronos describing a new API. Khronos has made it clear that they want to get it right this time, and that means getting all of the major players invested in initiative.

At this point the single hardest sell for Khronos and the members backing the initiative will be the clean break. This is a large part of what doomed Longs Peak, and Khronos admits that even now this isn’t going to be easy; even a year ago they may not have been able to get consensus. However as Mantle, Metal, and Direct3D 12 have made their own cases for new APIs and/or clean breaks, Khronos tells us that they believe the time is finally right for a clean break for OpenGL. They believe there will be consensus on the clean break, that there must be genuine consensus on the clean break, and have been passionately making their case to the consortium members.

To that end the OpenGL NG participant list is quickly becoming a who’s who of the graphics industry, both hardware and software. NVIDIA, AMD, Intel, ARM, and more of the major hardware players are all participating in the initiative, and on the software side members include everyone from Google to Apple to Valve. Khronos tells us that they have been especially impressed with the participation from software vendors, who haven’t always been as well represented in past efforts. As a result Khronos tells us that they feel there is more energy and excitement than in any past working group, even the burgeoning OpenGL ES working group.

Ultimately OpenGL NG will be a long and no doubt heated development process, but Khronos seems confident that they will get the consensus they need. Once they can sell the clean break, developing the API itself should be relatively straightforward. Due to its direct-access nature and the relatively few functions such an API would need to provide, the biggest hurdle is at the beginning and not the end.

POST A COMMENT

22 Comments

View All Comments

  • edzieba - Monday, August 11, 2014 - link

    "Khronos is seeking nothing less than a complete ground up redesign of the API"

    It's happening!
    Reply
  • nevertell - Monday, August 11, 2014 - link

    Why can't they use the same IR OpenCL will be using ? The things the GPU will be calculating in essence will not be all that different, so why duplicate the effort ? Reply
  • mczak - Monday, August 11, 2014 - link

    My guess would be is that since they are just at the beginning they didn't want to prematurely decide on this. Might still be possible it looks a lot like SPIR (which is essentially llvm ir) in the end. Reply
  • bobvodka - Monday, August 11, 2014 - link

    I find this funny on a couple of levels...

    First of all lets start with the OpenGL track record of two failed redesigns; GL2.0 and Longs Peak which was scrapped and replaced with GL3.0.

    Secondly, for all the yelling about AZDO, talking down Mantle and D3D12's new APIs and claiming that 'OpenGL is fine' and we 'don't need another api" we finally get this.

    The natural result is that we either get;
    - new features tacked onto OpenGL which goes against the 'ground up' API design they are talking about
    OR
    - a whole new API and model which then makes the yelling about OpenGL being fine just crazy.

    The result of 1 is yet more confusion in an API littered with multiple ways to do the same thing already OR existing OpenGL apps won't be able to take advantage of it without a significant rework and that's going to sit badly in the mouth of anyone who has been reworking for the, apparently good enough, AZDO feature set.

    Although having lived through two failed API redesigns, one of which got scrapped at the last moment, I'll believe it when I see it.
    Reply
  • iwod - Monday, August 11, 2014 - link

    Well I think there is a few different this time around. ( Not saying it is definitely going to happen but.. )
    No CAD, or No more professional baggage to hold out to. Of course the new API will still cater for those application. But compatibility for them wont be one. Previously this was diffcult because they were the majority of users who are using OpenGL, and gaming on Windows was shifting to Direct X. Apple was a niche and Linux had no market share. Now with iPhone / Android Smartphones and tablet, Valve working on Linux Gaming / Stream, the market share has completely shifted, these companies can finally do what ever it takes to get there. ( Assuming politics dont get in the way )
    They have the experience with Open GL and ES as well as CL. LLVM project to leverage which will definitely be a big help compared to their two previous tries. And Oculus VR! I am sure Johh Carmack will have a few words to say there :)
    Reply
  • bobvodka - Monday, August 11, 2014 - link

    Fun fact; CAD didn't kill Longs Peak.

    Around the time the forum was blowing up with the disappointment of GL3's release I had a short PM conversation with one of the people behind the GL3 push and he stated to me it wasn't the CAD companies that killed it despite what everyone (outside of the ARB was yelling) and I have no reason to doubt his word.

    Unfortunately, for whatever reasons, this never made it out into the public consciousness and so CAD gets that blame for it.

    The chance is stronger this time, I'm just very disappointed that they/IHVs spent a year yelling that 'new APIs aren't needed' and that 'opengl is good enough, look what we can do' only to turn around and say we are looking at a new API.

    As a programmer I find that very annoying (fortunately I didn't hop on the AZDO is the solution! hype train, although I did agree it was part of the solution); if they had admitted there was a problem instead of trying to stone wall any discussion on GL's faults then things would have been better.

    Honesty is better than the PR smoke screen which we had to put up with... and they have lost a degree of respect in my eyes because of it.

    (Fortunately my day job does not depend on desk top graphics APIs any more so this won't impact me directly but still it is disappointing in that regard.)
    Reply
  • mavere - Monday, August 11, 2014 - link

    AZDO is essentially "let's improve our API by not using our API."

    I doubt anyone seriously thought of it as anything more than a stopgap.
    Reply
  • bobvodka - Monday, August 11, 2014 - link

    Well, yeah, anyone with any experience on the consoles of at least the last generation knew this but the line coming from the OpenGL focused IHV reps was "OpenGL is fine, look at these extensions, we don't need another API"... of course what they meant was "don't need another API which isn't from us".

    In the various twitter discussion which came up about this, when the idea of multi-thread command list generation came up an rep for an IHV said (and I'm paraphrasing slightly as I don't have a complete quote to hand) "we can saturate the command process from one thread, we don't need to support this"... That was May/June time if memory serves.

    So, you are right, anyone who wasn't so Pro-GL they couldn't be pragmatic about the situation could see AZDO was only 50% of the solution at best, but the noise from the IHVs was very much 'nope, this is it...'.

    (All of which ignores the major caveats which came with AZDO functions with regards to functionality and requirements.)
    Reply
  • Krysto - Monday, August 11, 2014 - link

    Will this new API include in any way support for ray/path tracing? Because it should...Hybrid or pure ray/path tracing hardware is the future. This would be a good opportunity to include it. Reply
  • monstercameron - Monday, August 11, 2014 - link

    isnt that usually done in software? couldnt it be done with compute via opencl? Reply

Log in

Don't have an account? Sign up now