3 ms·

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

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.

asveikau 13y ago
> 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.
- angersock 13y ago
  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.
- figglesonrails 13y ago
  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.

asveikau 13y ago

> 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.

angersock 13y ago
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.
figglesonrails 13y ago
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.