In the ARB's defense, for editing buffer objects there are already sme bind points that are not related to rendering: TEXTURE_BUFFER, COPY_READ_BUFFER and COPY_WRITE_BUFFER.. indeed TEXTURE_BUFFER as a binding point for a buffer object affects NOTHING.

Actually, there are quite a few more binding points that have no semantic component associated with them. All of the indexed targets (GL_TRANSFORM_FEEDBACK_BUFFER, GL_UNIFORM_BUFFER, GL_ATOMIC_COUNTER_BUFFER, etc) have actual binding points in addition to the indexed locations, but because they're indexed targets, these bind points don't have any semantic component associated with them.

Indeed, only about half of the targets actually have explicit semantics: GL_ARRAY_BUFFER, GL_ELEMENT_ARRAY_BUFFER, GL_PIXEL_PACK/UNPACK_BUFFER, and GL_DRAW/DISPATCH_INDIRECT_BUFFER.

But the ARB ain't avoiding DSA. Sampler objects have a DSA API (and they're primarily from AMD, so less of the "NVIDIA trying to push" thing because it's just not true). glProgramUniform is in core. Some form of DSA is getting there, slowly but surely, and not the very same as the GL_EXT_direct_state_access spec, but it's getting there.

"Getting there" would imply progress, the gradual decrease in new features that don't use DSA interfaces. But that's not what we see. There's no gradual decrease in non-DSA interfaces; it's completely random and haphazard. We discussed this: except for new object types, the only OpenGL extensions that are DSA only are those that originated from NVIDIA (like SSO; EXT_SSO didn't require DSA because NVIDIA already implemented glProgramUniformEXT through the DSA extension).

The ARB's policy clearly appears to be not to adopt DSA. But they don't seem willing to make changes to NVIDIA-born extensions just to make them non-DSA.

So I don't see us "getting there" here. New features are just as likely as not to use DSA interfaces.

That is a contradiction. A good API is exactly what OpenGL needs to come close to Direct3D.

Do you honestly believe that the reason OpenGL is not used as often today as D3D is because of its API?

Both had similar capabilities and could hit similar performance, but OpenGL 1.1 helped the programmer to be productive, D3D 3 didn't.

D3D v3 did not have "similar capabilities" at all. It has no software T&L, it had fewer blending modes (granted, so did the hardware, so that was a performance trap of 1.1 at the time), and so forth.

Also, we need to recognize that there is a major difference between how D3D v3's API was terrible and how OpenGL's API is poor. GL's API makes your code a bit inelegant, or requires you to be a little careful. Looking at D3D v3 code is like staring into the Ark of the Covenant. It was bad.

A good API is exactly what OpenGL needs to come close to Direct3D. As you say, it's not about performance or features.

What good is beautifully designed API if it lacks functionality, is a bitch to make fast and can only be used on a restricted range of platforms? This is not to say that Direct3D lacks functionality that's versatile enough for the mainstream market or isn't fast, it's simply to clarify that a good API is much more than simple convenience.

And what does coming close to Direct3D mean anyway? Can you do anything with Direct3D that you can't do with OpenGL? Can you port Direct3D apps to natively run on any Unix-like OS that's supported by hardware vendors? Do you recognize the importance of Android and iOS? Are you aware that the Playstation and the Wii aren't giving a damn about Direct3D? It sounds like zealotry on my part but these are aspects that are independent of API design but just as important to the potential of the API.

What I miss as an OpenGL developer is a more powerful GLSL compiler (and of course the corresponding spec) and something like XNA - something like an official set of tools for use with OpenGL that eases your everyday pain. Sure, we can gather all sorts of good third-party libs like glm, GLEW and so forth but it's much more effort than it should be. IMHO, the ecosystem of D3D's accompanying libs and tools, all official and actively developed, is where D3D shines. Still, this has nothing to do with OpenGL as an API. If you're talking about OpenGL versus Direct3Dand take them for what they are, then you will see stuff that's tedious in OpenGL and better solved in Direct3D but the result will not differ if done right and that's good enough for me.

One thing I have come to understand in the past months is that arguing how OpenGL could be better here and there doesn't get you anything unless you have proven, with working code, that a real problem exists. Have you taken any timings regarding your DSA example above? Are you absolutely sure that binding, updating and unbinding is actually slower than the single call to UpdateSubresource()? It might look logical since you save two API calls, but do you have any idea about how much time the functions actually take?

Unless you can't prove that OpenGL falls short in terms of the results you get out of it, Direct3D might be the better designed API - but it's not a better solution.

So being "official" doesn't seem to have changed the fact that if you want to make Win8 games, you're going to have to ditch your XNA-based system and use something else. Personally, I'd rather work with something open source if I don't have the money to buy/license a real engine; at least then, I can go in and work on it if the original owner decided to stop.

One thing I have come to understand in the past months is that arguing how OpenGL could be better here and there doesn't get you anything unless you have proven, with working code, that a real problem exists. Have you taken any timings regarding your DSA example above? Are you absolutely sure that binding, updating and unbinding is actually slower than the single call to UpdateSubresource()? It might look logical since you save two API calls, but do you have any idea about how much time the functions actually take?

Unless you can't prove that OpenGL falls short in terms of the results you get out of it, Direct3D might be the better designed API - but it's not a better solution.

Here's the way things work.

There are at least three main classes of functionality that are candidates for adding to OpenGL.

The first is to fix bugs in existing spec and I don't think anyone could argue against that. Not even Alfonse.

The second is to add new functionality; ditto but the form that it takes is worthy of discussion while everything is still up for grabs.

The third is what we're talking about here - general spec cleanup and usability improvements, and it seems that an argument is being made that this class has no place in any hypothetical future spec.

That's a spurious argument and seems to be advanced for the sake of having an argument rather than of furthering discussion. GL has had tons of additional functionality of this nature added. Was GL_ARB_explicit_attrib_location necessary? No, but yet it was added. Was GL_ARB_explicit_uniform_location necessary? No, but likewise. Is it necessary to (pulling a possible future example off the top of my head, please don't take too seriously) be able to provide initial/default values for sampler uniforms? No. Is it spec cleanup and a usability improvement? Yes.

Hell, even GL_ARB_separate_shader_objects doesn't provide functionality that can't be worked around otherwise (and I seem to recall that a certain someone was opposed to that idea too). That one is actually a classic example of exactly the kind of argument that is being advanced against any notion of any kind of DSA here (and is also a good example of something that involved a significant number of new entry points and a handful of new GLenums).

Again with the specific problem that DSA resolves: there is an artificial connection between state used for drawing objects and state used for creating/updating them. Doing one has consequences that the developer most likely does not intend for the other. Yet they are clearly different operations. So that artificial connection needs to be broken.

So - we're being told "come up with a compelling argument for" to which I'll respond: "come up with a compelling argument against, and you may be worth taking seriously".

Do you honestly believe that the reason OpenGL is not used as often today as D3D is because of its API?

Not at all, or I would have made the claim. I believe lack of driver quality and developer tools are more important factors, but that's not an excuse to make the lives of developers harder than necessary by ignoring the API issue.

mhagain: No one in their mind can be against fixing bugs, no one in their right mind can be against API changes that alleviate development. absence's argument was that stuff like that has to happen to raise OpenGL to be on par with Direct3D. But absence offered no substantial facts whatsoever to base the claim on.

What I'd like to see is for people to show real examples of where differences in both APIs are really significant - not only praise functionality which makes your life easier but is no more powerful.

Regarding DSA I agree. However, Alfonse has a point, there doesn't seem to be a clear direction the ARB seems to be headed in. It's the same wishy-washyness that made deprecation useless. I'd like to see DSA in core too, but if the ARB actually decides to introduce a complete and consistent DSA API they might as well revamp the whole thing and finally break backwards-compatibility.

The third is what we're talking about here - general spec cleanup and usability improvements

No, what we're talking about here is DSA, a specific usability improvement. One that has been around in extension form since 2008. One that the ARB has had 6 OpenGL spec versions to incorporate. One that the ARB has failed to incorporate in each of those 6 spec versions.

This isn't like ARB_explicit_uniform_location, where people clearly wanted it from day one, but there never was an EXT spec for it or anything. This is something that's been an extension spec for 4 years; the ARB clearly knows about it since a good half of the extension specs that make up 4.3 have EXT_DSA functions in them.

If someone has clearly been presented with an idea, and they reject that idea six times, you should recognize that they're not going to do it. They didn't put DSA into OpenGL ES 3.0. They didn't put DSA into desktop GL 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, or 4.3.

Is there some reason at all to expect them to put it into 4.4 or 5.0?

Hell, even GL_ARB_separate_shader_objects doesn't provide functionality that can't be worked around otherwise (and I seem to recall that a certain someone was opposed to that idea too).

Originally, way back when 3DLabs proposed GLSL, I was. However, I was primarily against EXT_separate_shader_objects because it didn't let you have that separation for user-defined inputs/outputs.

Lastly, I'm not "opposed to" DSA. I'm a realist: I have no faith that an organization that has refused to incorporate this through 6 versions of OpenGL will suddenly decide it's a great idea and incorporate it the seventh time. Especially when they've clearly shown that they don't want to add DSA-style APIs for many of their new features.

In short: it's not happening, so let it go already.

we're being told "come up with a compelling argument for"

No, my original question, the one you've seemed to have forgotten, was, "Besides the form of the API (which is generally a stylistic question), in what way is OpenGL lagging behind D3D?" That's what was being discussed until you shifted it into the question of why OpenGL needs DSA irrespective of D3D.

This is a feedback thread, and I provide feedback. If you don't even disagree with it, please keep the noise down. We're all disillusioned with the ARB, but keeping quiet isn't going to solve anything.