Indeed. Hopefully it can also, finally, be the stab in the back of DirectX. While DX is good and all that, I would much prefer to see an Open Standard prevail in this space.
For a very long time, for example, OGL 2.1 was the only thing supported by Apple, despite numerous extensions to bring it up to feature-parity with modern OGL. Vendor extensions made programming code a mess, and many of the core concepts as embodied in the API are minefields for developers.
Don't hate on DX just because it's from Microsoft--an open re-implementation would actually help everyone.
It's not my area of expertise but it does ring true to me - whenever I see people complain about OpenGL they always seem to be confusing API surface with implementation details. I.e. the "legacy" parts can be shimmed to the "modern" parts without harming anyone very much.
The GL 3.3 samplers, e.g., are great. It does not require you to bind a sampler object in order to change the properties of it. However, the rest of the GL objects follow bind-change-unbind and a lot of implicit state which makes writing OpenGL libraries that can be reused highly weird because you never know what state some moron left the GL machine in.
Now GL 3.3+ is in an interesting position. They've got old functions that operate in a specific bind-change-unbind and new function that operate directly. So not only has the API not yet been fully "modernized", it's in the halfway state and it looks like it won't be pushed in one direction or the other -- just stuck in limbo for something like 3-4 revisions.
So I guess what I'm saying is, until the inconsistencies are ironed out, OpenGL still has some cruft that directly affects even the most modern GL 4.x programs.
Please read this again:
> they always seem to be confusing API surface with implementation details.
It does not have to work like a modern GPU. An API is an abstraction.
If you want to introduce a new API that is a better abstraction for current hardware that's fine, but that's not an argument to remove the earlier abstraction which is working fine for other users.
It's slow and ugly, and very nearly cannot peacefully coexist in the API. And maintaining it requires developer resources that don't easily exist for these companies.
Look, if you want to run off and create libAncientGL and do all of the book-keeping yourself and call to the most recent GL API, go nuts, and godspeed. That doesn't mean that we should hold companies to that requirement.
EDIT: I would also like to add that only in the strictest and most painful sense was the legacy OpenGL "just an abstraction". Before, it was a simplistic cross-platform layer over actual hardware and while abstract to a degree, hardly attempted to shield the programmer from hardware details. It's notable that the features that OpenGL "happened" to include as the "core abstract GL state machine" mapped pretty much 1-to-1 onto SGI's tiered hardware offerings at the time. In other words, what made the cut was very much based on real hardware, hence, the evolution of the API was not based on random abstractions that seemed like a good design [cough]. The legacy-GL-on-modern-hardware -- we refer to it as "fixed function emulation", since the abstraction is so far removed from actual hardware nowadays. Perhaps this isn't a "good reason" to change the abstraction, but it is notable that if the entire legacy API can be emulated using the newer API, then the legacy API may not deserve to be part of the driver (which takes a lot of time and effort to develop) so much as another library. That is to say, if one were to change it into terms of "computability", there are some things that cannot be computed using the FF, but the reverse is not true, i.e. FF can compute a proper subset of the programmable pipeline. In fact, this is pretty much the exact idea that Gallium takes in Mesa -- and why you can implement D3D / GL ES / core GL / legacy GL on top of it.
Now, on to the real issue that I raised, which is a purely API design choice. Direct state access vs bind-modify-unbind. The consequences of bind-modify-unbind have been lamented by developers for _ages_. As a response, the newer GL sampler objects do not use that. However, the old style API (you know, the thing we've been lamenting over for ages) does not have a modern equivalent. Please tell me how this has ANYTHING to do with GPUs? It's pure and simple API cruft. The API is _not_ consistent with itself.
There was a post here a few weeks ago (some dude dug up some old content of a 3D mesh of a cow in a Java viewer). And the old OpenGL and Java code "just worked".
"... and in their death throes, they gave onto us, technologies to last more than 2 years at a time. Sights and wonders never before seen only told, far outreaching the merciless grasp of the Holder of Shares."
RIP - SGI Vpro.
CAD vendors were what fucked over OpenGL for a long time, and it was only the fourth-quarter ill-fated kick by 3dlabs that gave it a programmable shader pipeline, and in turn set back the API development by another half-decade at least.
Look, "open" is not some magical fucking pixie dust you sprinkle over an abortion of an API to make it breathe life and grow up and change the world. If it was, audio in Linux wouldn't be such a shitshow, and neither would X, and neither would any number of other open APIs that everyone hates.
I do agree with you, though: rest in peace, Silicon Graphics.
EDIT: Derp on 3dfx vs 3dlabs.
I am hoping that if OpenGL becomes the most sensible choice, something else will grow out of it. Or if the reigns were handed over to FSF.
I don't think it's a very good comparision, but javascript is doing great out there in the wild. As is Linux, even with so many chefs.
There are plenty of reasons developers go to DirectX, support and tooling being two of them.
On the game consoles, outside Microsoft, regardless what is spread around, game consoles don't support OpenGL, just variations thereof or similar APIs.
For example the PS3 has OpenGL ES 1.0 combined with Cg, not GLSL. In the end most developers use Libcgm anyway.
As for the other consoles they are also other type of APIs.
In the end, the best approach is to have an API agnostic middlelayer and be independent of the underlying API.
Later on, it was asked at one GDC event if developers cared about GLSL, but since almost everyone that cares about performance on the PS3 uses Libgcm anyway, the update never happened.