Official feedback on OpenGL 4.2 thread

[absence]

Honestly, it's not "feature parity" that interests me so much as "niceness parity".

I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

[aqnuep]

I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

Direct state access is there at AMD and NVIDIA drivers. I also agree that it would be nice to have it in core, but I'm pretty sure the issue is that additing direct state access would require a lot of language change and editorial work on the spec. I think we can expect DSA to get into core only when the promised restructuring of the whole spec happens.

[Groovounet]

EXT_direct_state_access is there but the extension have too many issues to be used in production code. Many entry points are missing so that you are stock to OpenGL 2.1. + We are supposed to bind an object to create it... erm... not good.

We need a serious update on direct state access!

[kRogue]

EXT_direct_state_access is there but the extension have too many issues to be used in production code. Many entry points are missing so that you are stock to OpenGL 2.1. + We are supposed to bind an object to create it... erm... not good.

TexStorage almost did it for textures, but still did not. Time to whine.

[Alfonse Reinheart]

Many entry points are missing so that you are stock to OpenGL 2.1.

What entry points are missing? You have full DSA control over textures and their parameters, VAOs, program uniforms (programs were DSA before outside of uniform setting), samplers, and program pipeline.

The only missing entrypoints I can think of are transform feedback objects and a couple of the newer FBO features (TextureLayer). Hardly something that stops people from using it in "production code."

Really, what we need is to make state objects for those last bits of non-object state: the post-fragment tests (depth+stencil), blending/masking, and the viewport transform.

+ We are supposed to bind an object to create it... erm... not good.

What are you talking about? The DSA extension specifically says:

Certain commands and queries provide direct state access to named objects ... and perform implicit object initialization when provided unused object names.

For what do you need to bind an object to create it?

[aqnuep]

What entry points are missing?

As an example, element buffer setting and vertex attrib divisor setting.

For what do you need to bind an object to create it?

Okay, on this point you are right, you don't need to bind an object to create it, but the object is not generated at the time you call glGen*. This *is* an issue.

What I wanted to say is that EXT_direct_state_access is acceptable for now and I can understand why DSA didn't make it into core, actually I rather go on without DSA forever than having the current EXT_direct_state_access in core because it is ill-made (of course, this is just my opinion). I would be happy to see an ARB_direct_state_access extension put into core in the near future though.

[przemo_li]

I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

Direct state access is there at AMD and NVIDIA drivers. I also agree that it would be nice to have it in core, but I'm pretty sure the issue is that additing direct state access would require a lot of language change and editorial work on the spec. I think we can expect DSA to get into core only when the promised restructuring of the whole spec happens.

I'm in favor of OpenGL 4.3 that will just be reworked specs WITHOUT any new extensions brought into core.

Then they can start on working upon this new spec architecture.

Also I think that while merging refactoring specs with letting new extensions into core may be doable, they should avoid refactoring and releasing next big OpenGL.

OpenGL 3.0 was such a mess because they wanted to do too much in too short time. I hope they have learned something.

[Alfonse Reinheart]

As an example, element buffer setting and vertex attrib divisor setting.

Fair enough. Though the divisor was more recent than DSA, there was no excuse for not having element buffer attachment in DSA.

but the object is not generated at the time you call glGen*. This *is* an issue.

Is it? What exactly is the problem? You cannot tell the difference between glGen* creating the object and calls to a DSA function doing it.

And even if it were a problem, implementations are in fact allowed to create the object at glGen* time, since there is no possible way for you to detect that this is happening. Indeed, I understand that NVIDIA's implementation does this.

[aqnuep]

And even if it were a problem, implementations are in fact allowed to create the object at glGen* time, since there is no possible way for you to detect that this is happening. Indeed, I understand that NVIDIA's implementation does this.

You cought me again
However, it would be still nice if the spec would explicitly require the object to be generated at glGen* time and to always require objects passed to modify or bind commands to be previously generated with glGen*.

[Alfonse Reinheart]

However, it would be still nice if the spec would explicitly require the object to be generated at glGen* time and to always require objects passed to modify or bind commands to be previously generated with glGen*.

It already requires the latter. Well, if you use a core context at any rate.