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.

Imagination Technology say they are working on it, but talk about a “family” of OpenGL APIs. Frostbite confirm that it is about both mobile and desktop: “This work is of critical importance to get the most out of modern GPUs on both mobile and desktop, and to make it easier to develop advanced and efficient 3D applications – enabling us to build amazing future games with Frostbite on all platforms.”

The OpenGL Next Initiative is Building a Low-Level API

Frostbite also confirm the low-level nature of the API(s).

AMD seem to suggest that the next version of OpenGL is like Mantle: “AMD is tremendously excited to take a contributing role in the Next Generation OpenGL initiative as an evolution of the OpenGL standard aligned with AMD’s vision for low-overhead and multi-threaded graphics APIs.” (Raja Koduri). NVIDIA mention a new level of access for developers. Is this new level going to be higher level or lower level? It seems unlikely to be the former.

Conclusions

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.

TAGS > khronos, opengl, valve