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.
That's cute and all, but you probably--deep down--don't actually want that open standard to be OpenGL. OGL is a crufty, messy API, and even now support is spotty for the different versions.
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.
There's been some progress on one already, the d3d1x state tracker from Gallium3d is an implementation of D3D 10/11 directly on top of the GPU drivers on Linux, without using OpenGL as an intermediary.
It's funny because you think technologies that are at the mercy of a company are a good idea.
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."
Dude, you say this like OpenGL isn't run by Khronos, in turn "at the mercy of a company".
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.
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.
As an avid reader of Mesa3D and a user of GL 3.3 core, I can say that much cruft was removed in so far as it doesn't resemble a modern GPU (e.g. fixed function pipeline), OpenGL still has plenty of warts to bitch about.
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.
> I can say that much cruft was removed in so far as it doesn't resemble a modern GPU (e.g. fixed function pipeline)
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.
Right, I get it. I was merely stating that the parts of OpenGL that don't resemble a modern GPU have been removed. That is a fact.
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.
The problem is that it isn't working fine for other uses.
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.
> Indeed. Hopefully it can also, finally, be the stab in the back of DirectX.
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.
Because PS3 has shaders. Sony decided to support those shaders by an agreement with NVidia to use Cg, instead of adapting GLSL to their tooling.
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.
