It is recommended to continue to launch OPENGL 5.0 and make it fully support multi-core CPUs

It seems clear to me that Khronos’s job is to solve problems. Specifically, problems that their members need solving.

In the early-to-mid 2010s, one of the biggest problems game developers and graphics card makers alike had was that the existing graphics API paradigms did not adequately conform to the needs of their hardware. This left a lot of performance on the table, and it made users’ increasingly multicore CPUs increasingly less useful for games.

So they started to develop a solution for that problem. And since there were a bunch of other problems that large game studios also needed solving with regard to graphics (graphics memory allocation being hidden behind drivers, etc), they decided to fix them too.

Thus, Vulkan was born. Vulkan serves the needs of Khronos’s members adequately.

That’s not to say that the Khronos Group is invulnerable to criticism. Vulkan 1.3’s dynamic rendering functionality is a concession to a large number of people who wanted to avoid having to use render passes to render things. But overall, Khronos’s job is to design standards that their members (IHVs and large developers) need.

OpenGL no longer serves the needs of the Khronos Group. Some individual members of the Khronos Group want to keep their implementations going and even add more functionality for GL users. But as a body, they’ve pretty much decided that OpenGL is a dead-end technology.

Khronos’s job is not to keep supporting a technology past the point where they feel that it is worthwhile. You obviously disagree that OpenGL is past its time. But that’s where things appear to stand.

So if you want them to reverse the direction of their development, you are going to need something more than what you’ve posted here. Because all you’ve really said can be summed up as, “I don’t like Vulkan because it’s verbose and lower-level than I want to work, but I need OpenGL to do some of the stuff Vulkan does, so make a new version of OpenGL that’s more like Vulkan but without the parts I don’t like.”

You may not want to engage with those questions. But if you want other people to do something for you, you need to justify why they specifically have to do that. If you need someone to clean up your house, you need to explain why they need to be the ones to clean it up instead of yourself.

Nobody is obligated to continue supporting something past the point where they feel that such support is worth the effort.

1 Like

This is a very instructive discussion. Thanks for your patience.

It is fully understandable that gaining performance is achieved by building more subtle and refined hardware units, which will pull lower level and more complex API. I understand the purpose of Vulkan and why it is more verbose.

The major part of 3D development is working for the gaming industry and need these improvements. Other -like me- work for less demanding topics : in the area of scientific visualization, we definitely need to build 3D engines, but they are far simpler than those in the video game industry. In this regards we have no reason to go for lower level APIs - OpenGL 1 being already a satisfying API.

What should we do?

  • Can we stick on OpenGL 4.6 and consider manufacturers (except Apple) will continue shipping it with the computer and OS they distribute? If no, is there an “end of life” for OpenGL?
  • Does Vulkan propose an OpenGL like API implementing the equivalent of OpenGL? If no, are there frameworks that offer an OpenGL API on top of Vulkan? A bit like MoltenGL offers OpenGL on top of Apple Metal?

Thanks in advance!

1 Like

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