Why should drivers have to assume anything about binding? The binding part can be moved to a sluggish wrapper around the DSA driver, that only gets used when an application does not request the core DSA context.
The binding part can be moved to a sluggish wrapper around the DSA driver
You can’t move the binding part anywhere, because you still need binding in order to render.
Also, what is a “core DSA context”? That sounds suspiciously like deprecation, which as previously stated, isn’t going to happen again. Indeed, notice how implementations only implemented ARB_debug_output in debug contexts, but KHR_debug is now core. That shows that the ARB doesn’t like splitting functionality between different context flags like they.
They have only one split right now: core/compatibility. They’re not going to make compatibility/core/coreDSA.
I was thinking compatability/coreDSA. People who can’t or won’t rewrite can use compatability or previous core versions, and new projects can use DSA. I do concede that such a change may be too radical for a committee to agree on, but something radical is needed if GL is ever going to come close to DX.
Besides the form of the API (which is generally a stylistic question), in what way is OpenGL lagging behind D3D?
Disregarding the source of the problem wouldn’t work. Compare:
void OpenGLEngine::Buffer::Update(PVOID data)
{
glBindBuffer(..., mBuffer);
glBufferSubData(..., data);
glBindBuffer(..., 0);
}
void Direct3DEngine::Buffer::Update(PVOID data)
{
context->UpdateSubresource(mBuffer, ..., data, ...);
}
Notice how the stylistic form of the API affects the number of API calls.
[QUOTE=absence;1242527]Disregarding the source of the problem wouldn’t work. Compare:
void OpenGLEngine::Buffer::Update(PVOID data)
{
glBindBuffer(..., mBuffer);
glBufferSubData(..., data);
glBindBuffer(..., 0);
}
void Direct3DEngine::Buffer::Update(PVOID data)
{
context->UpdateSubresource(mBuffer, ..., data, ...);
}
Notice how the stylistic form of the API affects the number of API calls.[/QUOTE]
It’s actually worse because you need to save out and restore the previously bound buffer, otherwise you’re potentially going to mess with state used for drawing (e.g. VAO state). That is the single biggest problem here - there’s an artificial connection between state used for drawing and state used for creating or updating and each can mess with the other.
Yes, we all know that this can be abstracted away in your own “UpdateBuffer” routine - that’s not the point. This point is: you shouldn’t have to. It’s putting extra work on the developer, creating bear traps for inexperienced people to get caught in, and building more points where things can go wrong into your program. A good API helps you to use it properly and helps you to avoid this kind of basic mistake.
DSA as it is will never go into core. Much of it relates to deprecated functionality, some of it has been superseded (why use glTextureParameteriEXT when you’ve got sampler objects?) and some of it is already there (glProgramUniform calls for example). What really needs to go to core as a matter of priority is buffer and texture updates; anything else needed can follow at it’s own pace.
The source of what problem? What problem are you trying to solve with this? Because I don’t see one.
The number of API calls is generally irrelevant to performance. Or if it is relevant, you need to prove that it is in some way. This is even moreso when considering that most of these API calls won’t actually touch GPU state directly.
Yes, but nobody’s saying that OpenGL is a good API. My claim is that OpenGL does not need anything to “come close to DX”. OpenGL is just as functional and performance as Direct3D. Yes, they do things a different way, and OpenGL would be better off if we could magic many of its functions out of existence and magic a bunch more into existence. But that’s not going to happen.
DSA is not a new concept. And as much as NVIDIA keeps trying to push DSA, the ARB seems just as determined to avoid DSA. It’s not going to happen, so there’s no point in wishing that it would.
DSA is not a new concept. And as much as NVIDIA keeps trying to push DSA, the ARB seems just as determined to avoid DSA. It’s not going to happen, so there’s no point in wishing that it would.
… but DSA is slowly happening, for example as you noted that glProgramUniform found it’s way into core (you can argue it was needed for SSO, but there was function to make which “sub”-program active for glUniform as well). In addition, sampler objects have a DSA interface. As you stated the big ones are buffer objects and textures… I’d also argue vao’s as well and to a lesser extent FBO’s. 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. So one can fake DSA’s for buffer objects by simply always using TEXTURE_BUFFER as the bind point for modifications… this is still worse than having DSA, but avoids all those bear traps. This might be why DSA on buffer objects is not happening so quickly… or just the ARB does not like introducing lots and lots of functions at one go.
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.
I think mhagain hit the nail on its head:
That is a contradiction. A good API is exactly what OpenGL needs to come close to Direct3D. As you say, it’s not about performance or features.
Just to be clear, I meant the concept of DSA, not the current implementation of the extension.
It’s worth noting that back in the old GL 1.1 vs D3D 3 days, the fact that OpenGL was unquestionably a better API was a very significant influencing factor. Both had similar capabilities and could hit similar performance, but OpenGL 1.1 helped the programmer to be productive, D3D 3 didn’t. So the importance of an API being good shouldn’t be downplayed; a good API lets you focus on productive and useful work that gets stuff done rather than on writing boilerplate and wrappers that should otherwise be needless. A good API lets you iterate more quickly on proof-of-concept work and lets you focus on fixing errors in and adding cool stuff to your own code rather than on dealing with bizarre and outdated design decisions.
For me at least this is nothing whatsoever to do with any concept of OpenGL coming close to D3D. Each has it’s own world-view that’s subtly different from the other (and in some ways GL 4.3 is already quite well ahead of D3D 11, so if it were to come close it would involve it getting worse). This is to do with OpenGL becoming a good API again, in it’s own right. So “just because D3D does it” is a poor reason to add functionality to OpenGL, but it’s also the case that “just because D3D does it” is also a damn poor reason to not add functionality. Ignore what D3D does, look at what OpenGL does, ask yourself “is this screwed?”, and if the answer is “yes” then ask “what needs to be done?” That’s all.
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.
OpenGL’s issues are a minor inconvenience.
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.
all official and actively developed
Except for XNA, who’s future is actively in doubt. And for D3DX, which is not being “actively developed”, though they did spin off DirectXMath.
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.
I wasn’t aware of that - maybe my narrow interest in Windows 8 is to blame. I can’t fathom why some undoubtedly useful stuff has obviously outlived its time.
[QUOTE=thokra;1242556]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.[/QUOTE]
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”.
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.
So we agree after all! They could even maintain the current API as the compatibility spec in order to avoid breaking anything. They’re already maintaining two specs anyway.