The future of OpenGL

OpenGL
1

I’m asking this question here directly because I haven’t seen a clear answer anywhere. Speculation aside, does anyone have any kind of concrete information they can share or direct me to which indicates what the future plans for the OpenGL specification are? I’m talking working group papers, timelines, roadmaps, etc. Anything published, presented at conferences, or insider knowledge from people “in the know”?

Some background for why I’m asking this. I’m not a beginner starting out. I work in a company with multiple large commercial 3D packages, and I’ve developed an API abstraction layer which gives me pluggable back-ends for OpenGL 3/4, Direct3D 11/12, Vulkan, and we could easily spin up a Metal one if we ever care to. I have no emotional attachment to OpenGL, and frankly I think it’s horrible to use when you start trying to build a real application beyond your comfortable “Hello World” level. At the same time, I’m trying to determine where to direct future efforts, and estimating how much work we need to invest in maintenance of what we’ve done to date. I have a current stake in OpenGL support, and it helps me to understand where it might be a year, two years, five years from now.

Now I can easily speculate. These are the facts I have at hand:
-Vulkan was developed to replace OpenGL (It was titled “glNext” afterall)
-Both OpenGL and Vulkan are maintained by Khronos, so they’re not really competing. Behind closed doors, there’s certainly a unified approach.
-OpenGL ES is will have no new versions, as stated in a 2017 Siggraph presentation from Khronos group. Vulkan is stated as the replacement.
-Apple has deprecated OpenGL support, and given their aggressive approach on issues like this will almost certainly remove it entirely in the near future.
-OpenGL has had only one release since 2014, which was OpenGL 4.6 in 2017. It really just promoted some extensions to core, of which the SPIR-V promotion in particular really seems to have been geared around making transitioning from OpenGL to Vulkan easier.
-Nvidia has stated it has no plans to expose its raytracing features to OpenGL

From all that, it seems fair to assume that OpenGL is basically dead, and that 4.6 might be the last release. Since my assumptions can be wrong however, does anyone else here have anything concrete they can share in terms of scraps of evidence I might have missed? Can anyone who’s connected to Khronos group, or has inside knowledge from someone who is, share anything about what is or is not happening around the OpenGL specification? If there’s an OpenGL 4.7 actually possible on the horizon, or perhaps even an OpenGL 5.0, that’s something I’d very much like to know.

So, does anyone here have any more information to share, or are we all guessing?

2

I’m not sure if glNext and Vulkan were the same beasts at start. I believe Khronos was starting to think about glNext and then AMD gave Vulkan to Khronos. However I couldn’t find anything that could clear this up.

They do not compete because they do not fight in the same arena. I don’t like to say that but it’s like comparing java and C.

Apple has specific policies and interests. AFAIK they won’t support Vulkan either but only their Metal API.

Vulkan had has been added ray-tracing functionalities. Obviously new functionality had been added to GLSL for this support. See this for example. However, nothing came up for the OpenGL API.

As you stated, GLES was explicitly told to be dead while this hasn’t been for OpenGL.
You didn’t wanted speculation but you did quite a lot in your topic. So here is my two cents. Vulkan is a young API, which might bring new functionalities (apart from raytracing). These new functionalities might translate to OpenGL. As an example, if something new and important like shaders, VBO were arise, there’s hope for them be added to GL.
Also, and this is not speculation, apart from raytracing, new extensions seldom arise to GL (see for example nvidia mesh shaders). You can have a look at this page to see what’s coming up.

Apart from this, the forum section about ideas for future releases of OpenGL has been removed while the forum was moving from opengl.org to khronos.

Finally, are there any reasons why you target both OpenGL and Vulkan ? Do you have to support older hardware ? If that’s the reason, then all future hardware will support Vulkan, so there’s nothing much to worry about any GL 5 or so. You already support OpenGL for older hardware and Vulkan for newer and future ones after all.

3

Thanks for your reply. I’ll go through some of your points below.

I disagree. They’re both APIs for driving the same 3D graphics hardware. They seek to solve the exact same problem. They may have different syntax and conventions, but so do Vulkan and Metal, and I think it’s hard to argue they’re not competing APIs.

Yep, Apple aggressively pursue vendor lock-in, so they want to force people to Metal. That said, Khronos themselves support MoltenVK to open up the platform to Vulkan anyway. There’s no equivalent for OpenGL, even though Khronos could do it if they wanted to. This might seem easy to dismiss, but consider that one of the main compelling reasons to use OpenGL “back in the day” was that it could run “anywhere”. Now it can only run on Windows and (non-Mac) Unix-based environments. They forked the whole spec as OpenGL ES to chase emerging platforms, but they’ve officially canned that. WebGL is slated for replacement by WebGPU. OpenGL’s status as a cross-platform API is dead. That’s a major thing to note IMO, as that was one of the central tenants of the API from day one.

And yet if there are plans to bring anything new to OpenGL, there’s total radio silence from Khronos about it. As I said, can you find any single comment about anything being worked on or discussed for the future of OpenGL? Hope is one thing, but with Nvidia ignoring OpenGL for their most important new feature (raytracing), and Khronos themselves not seeming to be talking about OpenGL’s future publicly, it doesn’t seem like there’s anything coming down the pipeline. You’d expect at least one speaker at one conference somewhere in the last 18 months to be saying something if there was. All I can see in that time is when Khronos gave a total of 10 minutes to talk about OpenGL (and OpenGL ES) in the 2019 Siggraph. They mentioned few new extensions added, only one of which was from Khronos and was brought over from Vulkan (presumably to aid interop), and the rest of the time they talked about how you should use Vulkan interop if you want to use raytracing features. They didn’t speak about OpenGL or OpenGL ES in different terms at all either, which is significant to me as they’ve stated in the past OpenGL ES won’t have anything new added (vendor extensions notwithstanding).

I’d add that to the list of evidence that leans in the direction of OpenGL being dead.

I want to avoid getting bogged down in a “why do you need it” line of questioning. There are answers to that question which I’ve alluded to in my first post, but really it’s irrelevant to the question at hand.

4

Point of order: there are several such wrappers. Even ANGLe apparently has such a wrapper.

I don’t recall seeing any statement from Khronos that GL ES is being “officially canned” or anything to that effect.

5

What you wrote later on your last post, talking about the silence of Khronos about OpenGL could also be interpreted as a wish to avoid a competition between both APIs. Also, when DirectX 12 came up, OpenGL had major issues to compete with the performances of the Microsoft API. Before DirectX 12, the OpenGL board was mainly just adding new functionalities borrowed from DirectX 11 (and also some of DirectX 12). You have to go far up to the early 2000s to see OpenGL being leading and/or competing loyally with Direct3D.

That parenthesis said, I can also disagree with your statement. While this is true in appearance, those new APIs were not devised to add concurrency. They were added to solve issues programmers were facing (mostly in the game industry) - performance issues mainly, due to the lack of flexibility high-level APIs were obviously offering. This is just the same with java and C or anything high-level compared to low-level. It’s more easy for example to create and run threads with a thread-pool API, but once you’re facing performance issues, you won’t be able to overcome this, since generic thread-pool APIs have to provide secure interface, sync, management… that will inevitably lead to performance issues. I had been facing this some times ago. Doing it by hand increased drastically the performances. This is just the same with low-level 3D APIs.

You can make everything compete: companies want to make everything compete, in order to make a choice. But from my humble and low-level point of view, OpenGL and Vulkan don’t deal into solving the same things. One gives easy mean for someone to reach very good performance whereas the other one gives more means, less easy ones in order to have the possibility to reach even higher performances.

Concerning the fact that they run on the same hardware, this is (a bit) wrong: older hardware might not be able to see any Vulkan drivers, just like a Geforce FX will have no chance to have GL 4.5 drivers.

There is the Zink project. It’s not a Khronos project though. And I believe this is better that Khronos stays away from this. That would otherwise mean the death of OpenGL: why keeping an OpenGL standard if everything could be made up on top of Vulkan ?
Concerning Apple, they really have aggressive policies and a very close system. Vulkan could easily be supported on Apple, provided that Apple agrees. After all, this is “just about writing a driver”, and Metal-based hardware has nothing special other hardware don’t. And in order that Vulkan could remain this “OS-independant” graphics API, there’s this need for such a project, from the point of view of Khronos.

Low-level APIs like Vulkan and DirectX12 allow to gain a noticeable performance boost compared to the higher-level APIs like OpenGL and DirectX11. This is all about the 3D world: make things very fast and as beautiful as possible. The game industry was dictating this. And this becomes even more important with VR / AR / MR. Therefore, this is where competition has a mean to exist. OpenGL and DirectX 11 have lost this battle.

OpenGL is now mainly used for industry only. Most CAD software have their 3D done around OpenGL. OpenGL has to be kept alive here. For the rest, it is being used for most games on Android (with OpenGL ES) and Linux, even if more and more are obviously transiting to Vulkan. There is no reason to kill it for the moment.
Some months ago we had the possibility to discuss if we will move our app to DirectX 12 or Vulkan. We decided to stick with OpenGL as we’re not facing performance issues despite of the fact that we are rendering meshes with more than 10M triangles (could sometimes reach 80M). That might change in a future, once our devices will create even finer meshes. But that would also mean for the company to give lessons to their 3D programmers, including hiring a good lead Vulkan / DirectX 12 programmer (and this won’t be easy).

That was just my two cents about this weather talking.

6

That’s one way to describe it. An alternate way to describe it is that OpenGL was exposing features that were available to the hardware. That is, it’s reasonable to assume that these things would have happened whether D3D existed or not.

In fact, while OpenGL did expose more “DirectX 11"” functionality, it didn’t typically do it by mirroring D3D 11’s API. Image load/store, SSBOs, and atomic counters are much more low-level than the equivalent D3D11 functionality. They weren’t copying entirely from another API; they were just exposing what the hardware could do.

But here’s the thing. If you don’t need the low-level control Vulkan provides, why would you bother with the idiosyncracies of OpenGL when you could just use a graphics engine that itself uses Vulkan? It would make it so much easier to get stuff working. It would have asset conditioning pipelines, resource managers, and so forth that would take a huge amount of the grunt work out of making your application. If you’re going to go high-level, you may as well stop messing around and go high-level already.

What’s the benefit of this “not-low-level, not-high-level” API? If you need performance and control, use Vulkan. If you’re happy with merely good-enough performance and prioritize ease-of-use, use Unity or Unreal or any other engine that’s readily available to you.

It’s not so much that OpenGL is competing with Vulkan. It’s that OpenGL is not low-level enough to provide the performance of Vulkan but also not high-level enough to provide the ease-of-use of a proper graphics engine. It is therefore fit for neither user.

The only people left who would continue to use it are those with code investment in OpenGL or those who want to learn but find Vulkan way too fiddly to deal with.

This is (part of) the reason why functionality like ray tracing isn’t coming to GL. Building a ray-tracing-based engine requires rebuilding significant parts of your engine. And if you’re going to do that, you may as well just switch over to Vulkan, or at least employ Vulkan/GL interop.

Vulkan recently gained a line rasterization extension that seems specifically intended for CAD developers. So it would seem that even CAD developers can read the writing on the wall.

What would it mean to “kill it” anyway? Even if Khronos declares that they’re not going to be updating the OpenGL spec anymore, all of those implementations will exist. The OpenGL specifications will exist. And all of those code bases that are built on OpenGL will continue to exist and need to work.

This question is about whether the OpenGL specification is actually going to be updated and kept current with hardware capabilities. And thus far, all evidence points to this not being the case.

7

That’s true. But hardware capabilities are nothing without their API interface counterpart. I’m not really sure about this, but I believe that these OpenGL implementations came after the DirectX ones, probably due to the fact that, as you said, they were not simply dumb mirrors of their DirectX versions.

TMO this is not false. Vulkan is a chance to make engines not be DirectX focused either, which could also help engines be viable on non Windows OSes.
Also Unity or UE might not fit all needs, and specially in the non-game industry despite of their current efforts. For what we are doing in our company (and I believe we are not the only ones), we would have to (re)write a lot of code over the engines. This could also implies to hire people having enough experience with an engine. This is also unthinkable to have an editor (UE not to mention it) using most of the GPU/CPU ressources just to start, needed 4 hours to build, and to depend on living code that might change more often that we would need. We already studied this, and the conclusion we got was clear on all the technical line.
But for sure, I believe these engines (or maybe future ones) will go more in the right direction. This is not just the case for now.
There is however a big drawback for this vision. Companies will need less OpenGL / Vulkan / DirectX programmers for the profit of UE / Unity… programmers.

That’s a way to see the things. OpenGL and engines did exist before Vulkan.

It’s a clear statement. But I know off some companies starting new projects with OpenGL. I also know companies that choose do-it-all engines (like UE) and now transiting to creating their own engine (most often on top of OpenGL, not Vulkan) because they met too many issues with the third-party engine. And I’m still talking about global industry, not gaming.
This is less easy to find good Vulkan programmers now. One of the reasons why is that Vulkan is young. Another one is that Vulkan requires more skills than OpenGL.

Good point.

True, but that would help nvidia or such to decide to stop updating their drivers sooner.

You’re right, I went far beyond the subject.

8

Companies need fewer assembly programmers today than they did decades ago too. The shift from low-level graphics skills to high-level skills would be similar.

What’s the drawback?

No, it would not; market forces will dictate that. That’s how open standards work, for good or for ill. If Khronos said that they’ll keep the OpenGL specification up-to-date with hardware, but not enough people are actually using OpenGL to make writing such implementations worthwhile, then there will be no such implementations. Similarly, if Khronos says that they’re not bothering to add more features to the OpenGL spec, but if the market still wants new hardware features exposed through OpenGL, then individual vendors will start writing extensions for those new features.

For example, NVIDIA exposed mesh shaders through OpenGL but not ray tracing. If they thought OpenGL was dead, why bother with mesh shaders? And if they thought OpenGL was viable, why not bring ray tracing to the API?

It has to do with what OpenGL is. Ray tracing needs the structure of an API like Vulkan, one where synchronization is something you ask for and one which has queues and command buffers and the like. By contrast, mesh shaders are just a drop-in replacement for the basic vertex processing pipeline of regular rendering. It doesn’t require a whole new way of looking at the rendering process.

Regardless of what Khronos thinks, NVIDIA is going to support OpenGL to the extent that it finds it reasonable to do so. Just like all other vendors.

9

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.