OpenGL done us good for a long time. Khronos (the standards maintainer) refused to advance the standard in any meaningful way since the API was based around a stateful glBegin/glEnd model.
modern graphics hardware does not work well in this model. they’re really much closer to whole other systems. you want to push the triangle data into the card in a single (or few) API calls, then submit as few draw calls as you can manage.
fun fact, OpenGL 3, originally code named “longs peak”, was supposed to upend the stateful model, and advance the API ahead of its proprietary counter part(s) - DirectX. for what ever reason this completely fell apart, and OpenGL just sort of.. stopped improving :/
we have Vulkan now basically thanks to AMD opening their more modern GPU oriented Mantle API, and valve for running with it.
Vertex arrays have been part of OpenGL since 1.1, released in 1995. VBOs since 2.1 (with extensions available earlier). glBegin/glEnd aka "immediate mode" has been "legacy" for a LONG time and were even removed in the core profiles with OpenGL 3.2.
The biggest problem with OpenGL for is/was the context model that made multi-threading almost impossible. And yes, it being stateful is a big part of it. Plenty advances and low level functionality was available in OpenGL before vulkan was released.
Vulkan also reduces overhead since its abstractions better match today's hardware and it allows excplicitly moving more calculations up front that had to be done just in time with OpenGL.
Also, it's not like Khronos (a standards body made up of industry participants) "refused to advance" but rather that different interests had different ideas - e.g. some care more about backwards compat - so that they can tell their clients that their legacy software runs on the latest OpenGL - than getting the last edge on performance so having a separate 100% performance-oriented API was probably an eventuality anyway.
Also, remember that Microsoft and Apple are/were part of Khronos too and giving these two comanies' incentives and past behaviors it would not be entirely surprising if they did their part to hold back the standard.
OpenGL direct state access (DSA) is actually part of OpenGL 4.5! You still need to set up a lot of state for draw calls, but changing little pieces of state has changed from (pseudocode, and I'm showing a worst case for pre-DSA here):
const int oldTexture = currentTexture();
switchToTexture(myTexture)
setTextureData(myRgbImage);
switchToTexture(oldTexture);
eh honestly i don't think extensions are really all that bad. it's a standard and extensible way for third parties to advance the API, and - presuming the extension is rationalized into the API appropriately - allows for clean evolution & progression.
on the other hand, i'm not so sure that i agree with the approach of advertising even basic functionality (e.g. swapchain) through extensions. i understand vulkan has uses outside of graphics. i think that could have been better exposed with hard profile boundaries or something..
Most people that talk about how portable Khronos APIs are, versus the proprietary alternatives, never really used them in anger across multiple systems and graphics cards.
You end up with several code paths, where you have an architecture similar to multiple APIs middleware, but actually it is only using OpenGL, or Vulkan, and jungling among all possible cases.
At least now they got why proprietary APIs use profiles.
modern graphics hardware does not work well in this model. they’re really much closer to whole other systems. you want to push the triangle data into the card in a single (or few) API calls, then submit as few draw calls as you can manage.
fun fact, OpenGL 3, originally code named “longs peak”, was supposed to upend the stateful model, and advance the API ahead of its proprietary counter part(s) - DirectX. for what ever reason this completely fell apart, and OpenGL just sort of.. stopped improving :/
we have Vulkan now basically thanks to AMD opening their more modern GPU oriented Mantle API, and valve for running with it.