Khronos Announces Next Generation OpenGL Initiative
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.