I'm surprised I didn't find anything in this forum on Direct State Access. Everyone seems to want DSA included in the core, and I haven't heard a good reason that it's not included.
At the very least, the additional DSA methods in NV_texture_multisample really need to be included in some EXT extension. It's a big pain that those few methods have no DSA version outside of the Nvidia extension.
EXT_texture_compression_s3tc will never be in the core OpenGL spec because of some patent issue.
Maybe there is an IP issue with Direct State Access too. I don't know, just speculating here.
The multisample thing is actually surprising. Usually, you can tell which extensions NVIDIA worked on closely by whether or not there are any DSA interactions. ARB_texture_storage and ARB_separate_shader_objects are good examples of this. Maybe that's just a more recent thing, though.
I imagine that the ARB is hesitant on this because it doesn't actually change anything. That it provides an alternate mechanism for doing stuff. And with 3.1, we had that whole "get rid of alternate mechanisms for doing stuff" thing.
Plus, you don't really get anything from DSA (besides API annoyances being removed). The driver cannot assume that binding something means you intend to use it, because those old functions still exist. Which means that we would have to have yet another round of deprecation and removal; the last one was painful enough. Especially since NVIDIA didn't seem to care much for it, saying that it wouldn't help drivers and so forth.
Perhaps this is a place where the ARB could employ profiles to greater effect. We already have core vs. compatibility. We also have debug contexts. We could therefore have DSA contexts. Basically, they are a way of saying, "I will not call glTexParameter, glVertexAttribPointer, or any other state change functions." Of course, by "I will not call," I mean "these functions will fail and throw a GL_INVALID_OPERATION error". That way, the driver knows that you will not be calling old-style functions, so it knows that if you bind a texture, you're serious about using it.
Also, there are many context values are aren't bound up in objects. The viewport transform, rasterization settings, blending, post-fragment tests, etc. If we're going to have DSA, we need to basically have an object-based API. It makes no sense to have some things be objects and other things not be objects.
That seems unlikely. The S3TC extension has an IP section specifically mentioning the issue. The DSA extension does not. Also, I imagine that AMD wouldn't have bothered with DSA if they had to pay money to implement it.Maybe there is an IP issue with Direct State Access too.
There is no divisor DSA function either. Actually there is a LOT of issues still with them but I am confident that sooner or latter we will have proper DSA and maybe something better that just a fixed version of the EXT extension.
We need to keep screaming our love for DSA!
We've been screaming it since July 2008, that's 3 years ago, it doesn't seem like the people we need to convince are listening.
We need to keep screaming our love for DSA!
3 years? Please.
How long did it take to get buffer objects? From NV_vertex_array_range to the first publication of the ARB_vertex_buffer_object spec was a good 2 years.
FBOs? From the initial GL 2.0 proposal from 3D Labs to final spec was a good 3 years. And that was *just* the EXT version; we didn't get a core version for years after that. Oh, and it still took months to get necessary functionality like blitting and multisample.
How long did we wait until we finally got rid of that 3D Labs nonsense of linking programs? From the first ARB_shader_objects spec to ARB_separate_shader_objects, it took seven years. And you have to understand: nobody liked linked programs. The people clamoring for DSA are nothing compared to the hell raised over that. I was pretty much the only one who stood up for it, and even I look back on that opinion with shame.
The ARB takes a long time to do things that are obvious. Especially if they go against what they've done in the past.
NVIDIA clearly wants it to happen. I'd guess that Apple would probably be their biggest foes in this, as Apple is a very conservative member (consider how long it took to get even rudimentary GL 3.x support on Macs). They spend a lot of time writing part of the GL implementation; they wouldn't want to change their whole driver model just to accommodate DSA. To accommodate a way of doing exactly what you can do now.
You would have been such a great WWE wrestler.
Posting Permissions
