Khronos Call for Participation in the Next Generation OpenGL Initiative
So the big news in OpenGL land is that Khronos are working on a radical redesign of the API to ditch the legacy and make something that lets a real-time graphics developer harness the full power of a modern GPU, driving it efficiently from multiple threads on a multi-core CPU. Read the press release here: https://www.khronos.org/news/press/2014/08. Summarising the press release, we can pull out a few themes and infer some conclusions: It seems that this may be the API for SteamOS and is certainly an API for that platform. According to Valve’s Gabe Newell:
We are … create a high-performance rendering interface for SteamOS and future Valve games.
Crossing the mobile / desktop, OpenGL / OpenGL ES Barrier With the Next Generation OpenGL Initiative
There is a story about crossing the mobile / desktop, OpenGL / OpenGL ES divide with the Next Generation OpenGL Initiative which emerges from the press release. Arm say it will work on mobile.
Jem Davies“Mobile APIs must evolve and the Next Generation OpenGL Initiative will enable developers to get even more value from ARM’s energy-efficient technology.”
Tony King-Smith“We welcome the Next Generation OpenGL Initiative, and have committed significant resources to help Khronos ensure that future generations of the OpenGL family of APIs continue to deliver outstanding capabilities for developers across our extensive PowerVR Insider community.”
The OpenGL Next Initiative is Building a Low-Level API
Frostbite also confirm the low-level nature of the API(s).
Johan Andersson“We are super excited to contribute and work with the Next Generation OpenGL Initiative, and bring our experience of low-overhead and explicit graphics APIs to build an efficient standard for multiple platforms and vendors in Khronos.”
It seems as though Mantle, Metal, and D3D 12 have given Khronos something to think about and spurred them on to take a bold step with a low level, clean slate, design for the next version of OpenGL. How much they are they sacrificing in ease of use to get the performance is yet to be revealed and somewhat of a worry. This press release hints that the design of the next version of OpenGL is being driven by a committee composed of GPU driver writers and AAA rendering engine programmers with little input from the wider ecosystem of OpenGL users.
OpenGL has long been taught in second and third year undergraduate graphics courses. This wide exposure gave it disproportionate mindshare among generations of Computer Science graduates and led to a large number of programmers having some level of familiarity with it. Will this new library be suitable for such courses? If not, what will happen to OpenGL’s place in the hearts and toolkits of the next generation of programmers? If only 100 engine programmers around the world and the driver architects ever get to grips with it, the danger is that it becomes less relevant to a broad audience of programmers and less suitable for dropping in to many classes of interactive applications that need a good level of GPU acceleration but not to push huge geometry rates through complex shaders with multiple passes and high output resolutions at 60 fps like a AAA game is required to. Where will casual games, modelling applications, and GUI renderers go for a clean, simple API that won’t kill the user’s system if they prod it the wrong way because it is a thin layer over user-mode-mapped registers and memory buffers with little validation of application inputs?
Will there be a validating, safer layer on top of the core api? Maybe even something like a display list builder – record this geometry / play this list – wrapping the lower levels? It could even be valuable to have a standardised glBegin()/glEnd() style of wrapper or a stateful immediate-mode canvas api shipped with every driver but built from the same open source with a backend targeting this new low-level, shoot yourself in the foot OpenGL. Certainly, beginning programmers will need a gentler slope to climb into programming this new GL, and many users will never need the performance that it offers. An interesting question is whether the new standard for programming real-time to interactive graphics, trading peak performance for safety and ease of use, will come from Khronos and ship under the brand of OpenGL or if it will emerge as a defacto standard on some opensource repository like github and relegate the standard GL-Next to a role as a backend target for it and for the big game engines.