Direct State Access

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.

Maybe there is an IP issue with Direct State Access too.

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.

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

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.

:slight_smile: Fortunately that all that coffee on monitor will wipe right off.

I want to make one suggestion:

When introducing DSA to core, it is the perfect opportunity to introduce opaque object handles!

Just let the new functions accept only specially created object handles of type GLintptr. So provide new functions e.g. glGenTextureObjects() instead of glGenTextures(). The old objects then only work with the old API and the DSA EXT extension. The ARB DSA extension could clean up in the core with this.

The advantage would be that the driver saves time from the hash translations from GLuint to the internal object (much like bindless graphics does).

As a result deprecate all the non ARB DSA functions in a new deprecation round. I think this would be the perfect opportunity to have opaque handles introduced without breaking old functionality (and deprecating the latter)!

What do you think?

That would involve making more APIs. Actually, that would involve making a new API. The ARB has already shown hesitance to create new APIs to do the same thing; that’s why DSA isn’t in yet. Do you think that they’ll be more lenient to basically rewriting their object model for every object?

At that point, you may as well say, “Do Longs Peak!”

That could make AMD_name_gen_delete relevant. It removes the translation and the mutex (or kind of) in case of multithreading with multiple shared OpenGL context. Potentially using pointers implies a unified namespace for all the object names making glGenNames even more relevant.

No need to expose GLintptr it could be a typedef GLintptr GLname; so that implementation that want security (for WebGL eg) could use index instead of actually pointer.

This is my golden dream! Silver green would be to have just a ARB_direct_state_access extension that works fully and cover everything.

i don’t think its more a new API than DSA is and the more APIs to be introduced should be orders smaller than the APIs introduced by DSA. Basically the glGen* and glBind* APIs need to be adapted to the opaque handles and all the new DSA functions just take the opaque handles…

Could be so simple and beautiful :), plus it would help to get some performance bottlenecks from the drivers.

Are there any ARB members reading here, i would very much love to hear some insights into the DSA to core issues and if something like the opaque handles are discussed.

Basically the glGen* and glBind* APIs need to be adapted to the opaque handles and all the new DSA functions just take the opaque handles…

Which means all of the DSA-style functions provided by core extensions like ARB_separate_shader_objects and ARB_sampler_objects are now useless. Not to mention all of the glProgram* and glShader* functions that are already DSA-style.

How does this not constitute a new API? Any calls that don’t affect the state of an object or bind/unbind objects (which at this point is probably about 15 functions) are obsolete. You can’t use objects created with the new method with the old objects, and vice-versa.

At least with the Longs Peak method, where you make a clean API break, you wouldn’t have to specify the interaction between the old way and the new way. That’s one reason I suggested profiles, because it allows you to tell the driver up-front that you’re not going to do things the old way.

If you’re going to make this kind of radical change, you may as well go all the way and start bringing in things like immutable objects and such. At which point, you’re back in LP territory.

YOu could also add the lowest previous api version to which the current stuff is compatible too.
Can do this in drivers.

Instead of profiles.
Programs only have to add their OpenGL version number in the context creation call and everything can work exactly as expected.

we know that the ARB is unwilling to do a clean break, so we can only hope for a slow change of the API to the better. And I think opaque handles are essential for an efficient API, so the introduction of DSA to core can be a bigger step in this slow change process without a radical break of the API. Either use DSA and the opaque handles or don’t. As for existing APIs with DSA-like function, these do not interact with the functions that are currently not DSA. So this would mean no problem here, but it is also desirable to change these functions to opaque handles at some point…

If you’re going to make this kind of radical change, you may as well go all the way and start bringing in things like immutable objects and such. At which point, you’re back in LP territory.
yes. and i still hope we can develop OpenGL to the point where we have most of the great stuff Long Peaks promised.

I really don’t know if that’s such a good idea. I mean like love the Longs Peak design, but do you really want an API that’s had that much change while maintaining backward compatibility (because you know they’ll have to do that)?

IMHO I can’t see OpenGL ever getting itself out of the hole it’s dug for itself. With Longs Peaks they basically said, “the API no long reflects hardware, we need to change it” and then they didn’t for whatever reason (did we ever get the real reason they didn’t?).

So they tried to deprecate things, and that failed, with the entire deprecation mechanism itself being deprecated.

So now we’re left with compatibility and core, and while that sounds good, compatibility mode is likely to be around forever anyway, and core mode doesn’t really get us anything.

So, we’re left with an API that can’t shed itself of all the things we know are wrong with it. Just take the object handle issue. We know using an int for the handle is bad, it causes a lot of cache-misses in the worst possible place for the application (going by the bindless slides, and the Brink SIGGRAPH slides). I don’t know if an intptr for handles would solve the issue (wouldn’t the driver still have to deference that pointer to get the relevant information?)

I can only see OpenGL heading for increased complexity from now on.

What can be done? Design a new API from scratch[1], of course. OK, so I’m only semi serious about this, but after having seen some libgcm (the PS3 graphics API) examples, I’m thinking why can’t we just do this on the PC (with some slightly tweaks for cross-platform-ness and new features of course).

Feel free to ignore me, I’m likely talking out of my arse again :slight_smile:


[1] and we shall call it OpenGL Bare Metal, because that sounds awesome.

I am wondering if that could be done on top of OpenCL. Of course it would be less efficient now, but with time and more generic GPU/CPU mixed chips it might be not so stupid.

Well, if they (NVIDIA and AMD) were to expose the rasteriser as an OpenCL extension you could probably get some good performance out of it, but attempting to do it without access to all the hardware is not really going to work well enough.

I had thought of using OpenCL as the base for a new API, but it seems like we’d just be adding more complexity to another API (and we’ve all seen what that gets you).


Who cares about a couple of antique software that uses the old-school OpenGL?

Trash the compatibility profile and rewrite the specification, straight to the metal…version 4.5?

Yeah, Maya, 3Dsmax, Autocad, that just “antique software”, who cares about them?