OpenGL 4.5 addresses some of concurrency bottlenecks. My point was not to say that OpenGL is perfect as is. But to say that any potential successor can't claim that OpenGL is bad because it aims to be cross platform, therefore better alternatives all need to be platform specific. That's a false logic. Cross platform API can be made better.
> OpenGL 4.5 addresses some of concurrency bottlenecks.
How so? It adds DSA which is just a different way to access global state. The global state is still the cornerstone of the 4.5. The only way it addresses performance issues is through "bindless" extension, which pretty much tosses away the entire OpenGL pipeline and leaves just a draw_indirect_multi call call with everything pushed into shaders. It's too extreme for many developers even it's been available on non-NVidia hardware.
> My point was not to say that OpenGL is perfect as is.
Never mind me then. I only replied to your claim it's not the OpenGL fault it's slow on consoles.
It is not the concurrency issues I meant. It's about accumulating commands in the userland and transferring them to the kernel mode driver. The concurrency that affects performance the most is inter-draw call concurrency, as I said above. Flush control is about GPU-CPU concurrency, which, btw, still has long ways to go to reach the level of the control available in native APIs on consoles.
Hopefully OpenGL-next won't be a minor modification of the current limited design but would create a new design from the ground up. So far they indicated that it's the goal.
Nobody can forbid you from hope, but JFYI there had been two major version of OpenGL (3 and 4) already in the age when all the GPUs available had been parallel. In fact, at the time of OpenGL 2 design there had already been parallel GPUs on the market and everybody involved knew it's the way of the future (companies on the ARB either design their own GPUs or have access to the pre-release designs).
I'm not really sure why previous major versions failed to redesign the API from the ground up to fix major deficiencies in it. Was it organizational flaw or lack of good proposals?
I guess now they came to a better realization of the situation or now there are more people who actually want to improve things significantly rather than avoid such issues.
It's not a mystery to me: OpenGL is a scene description API, not a real-time graphics API. It comes from the environment where frame times under 5 seconds (not milliseconds, 12 frames per minute) are considered real-time and the compatibility is much more important than performance. Apple was the only ARB member that had been pushing for the OpenGL to become game-grade real-time mainly due to lack of any other real-time 3d graphics API on their platforms (both Mac and iOS), which is not the case any more as Apple is pushing its own API now.
> It's not a mystery to me: OpenGL is a scene description API, not a real-time graphics API.
Rather it originally was such API. I'm saying, why couldn't they draft a new API from the ground up as one of the previous major versions? It looks like only now they are doing exactly that. So why wait so long? That's what I mean I'm unsure of. Probably some organizational problem or lack of some major pushers for such change in the past.
