Direct State Access

[Groovounet]

I want to make one suggestion:

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

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.

[Chris Lux]

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!"

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.

[Alfonse Reinheart]

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.

[Gedolo]

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.

[Chris Lux]

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.

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.

[elFarto]

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

Regards
elFarto

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

[ZbuffeR]

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

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.

[elFarto]

I am wondering if that could be done on top of OpenCL.

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

Regards
elFarto

[glfreak]

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?

[Groovounet]

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

...