AMD is effin' weird, they own 33% of GPU market, yet it's driver development division and support feels like some tiny indie company of 5-10 enthusiasts that just started it's life.Originally Posted by thokra
Anyway, subscribing to epic thread. Glad to see OpenGL evolving. I hope those extensions gonna be available for every major GPU vendor in a finite time to be any useful for mainstream development.
The Second Annual Unofficial OpenGL Feature Awards!
I hereby hand out the following awards:
We (Finally) Did What We Said We Were Gonna Award
The conformance test suite.
I'll just quote Tychus Findley, "Hell, it's about time!"
One Little Mistake Award
ARB_multi_bind
This was good functionality, until I saw glBindImageTextures. I can't really think of a more useless way to specify that. It applies the "defaults", based on the texture target. Which means that an array texture will always be bound layered.
OK to be fair, you can use texture_views to effectively create single textures who's defaults match what you would pass to glBindImageTexture. And then you just bind them all in one go.
3D Labs Is Really, Really Dead Award
ARB_enhanced_layouts
So, not only can we specify uniform locations in the shader, we can even specify packing behavior. To the point that we can steal components from other vectors and make them look just like other variables.
That one must be a nightmare to implement. I hope the ARB has a really comprehensive conformance test for it...
Oh, and this also wins Most Comprehensive Extension Award. It lets us steal components from other interface elements, specify the uniform/storage block layout, define locations for interface block members, and define transform feedback parameters directly in the shader.
Is OpenGL Still Open Award?
ARB_bindless_texture
So. NVIDIA comes out with NV_bindless_texture. And unlike bindless attributes and pointers in GLSL, they actually patent this.
And now it's an ARB extension. It's not core... but it's not a proprietary extension. Yet anyone who implements it will almost certainly be stepping on US20110242117, and therefore must pay whatever NVIDIA says they have to pay. Unless NVIDIA has some agreement with the ARB, granting anyone a license to implement ARB_bindless_texture without paying a fee.
The really disconcerting part is that the patent encumbrance issue... isn't mentioned in the spec. Other extensions like EXT_texture_compression_s3tc mention their patent issues. But not this one.
Last Kid Picked for Baseball Award
EXT_direct_state_access
When bindless texturing gets the nod from the ARB, and this doesn't, something interesting is happening behind the scenes. How much does the ARB not want this in core GL, for them to deal with sparse and bindless textures first?
Then again, apparently NVIDIA wants to support DSA so badly that they may be updating the DSA extension with new stuff... and not telling anyone else who's implementing it. If true, that's not playing fair, guys. There's clearly some kind of huge fight happening around this functionality within the ARB.
So I hope nobody's holding their breath on this one.
Fragmenting The World Award
ARB_compute_variable_group_size
I understand why ARB_bindless_texture and ARB_sparse_texture aren't core. That reason being (besides the patent issues) that we don't want IHVs to have to say that <insert hardware here> can do 4.3, but not 4.4. There are lower-classes of 4.x hardware that just can't do this stuff. So we leave them as extensions until as such time as the ARB decides that the market penetration of higher-end hardware is sufficient to incorporate them.
Or until we finally decide to have 5.0 (ie: when Microsoft decides to go to D3D 12).
But compute_variable_group_size really seems like something any 4.x-class hardware should be able to handle. Something similar goes for ARB_indirect_parameters.
Hey, That's Actually Useful Now Award
ARB_buffer_storage
This extension adds functionality to glFlushMappedBufferRange, one of the more useless functions from ARB_map_buffer_range. Now, you can effectively keep a buffer mapped indefinitely and simply synchronize yourself with the server by flushing written ranges.
You Were Right Award
Um, me. Admittedly, it's old, but I still called it: immutable buffer object storage, with better, enforced behavior. I even called the name (which admittedly is derivative and therefore obvious). Though to be fair, the whole "render while mapped" was not something I predicted.
I was going to say that it seemed odd that not specifying GL_DYNAMIC_STORAGE_BIT still allowed you to map the buffer for writing. But I did see a notation that glBufferStorage will fail if you use GL_MAP_WRITE_BIT without also specifying GL_DYNAMIC_STORAGE_BIT. And of course, you can't map an immutable buffer for writing without GL_MAP_WRITE_BIT.
It doesn't have all of the bits I would have liked to see. But it has all the bits the IHV's wanted (they even said so in the "issues" section). So I'll call that "good enough."
Oh, and as for the complaints about GL_CLIENT_STORAGE_BIT being a hint... then don't use it. Remember: the problem with the current buffer object setup isn't merely that they're hints (that contributes, but that alone isn't the full problem). It's that the hints don't really communicate what you are going to do with the buffer. Buffer Storage lets you do that.
You describe exactly how you intend to use it. The bits answer the important questions up-front: will I write to it, will I map it for reading or writing, do I want OpenGL to access it while it's mapped, etc. And the API enforces every single one of these methods of use.
I have no idea why they even bothered to put GL_CLIENT_STORAGE_BIT there, since that doesn't describe how you will use the buffer. But as the issue rightly stated, drivers will ultimately just ignore the hint.
So encourage them to do so by ignoring it yourself.
Yeah, that's what happens when your company is slowly imploding thanks to their failing CPU division. Whatever profits might have been made off of GPUs are eaten by the CPU division.
You probably want to read http://www.khronos.org/members/ip-framework
Your logic for the former extensions applies to the later ones as well.
Here's the relevant paragraph:
It states very clearly that Khronos members only agree not to sue "other Khronos member"s. That doesn't sound very "open" to me. It sounds more like "pay Khronos money (by becoming a member) or you can't implement our specifications."
Are the people behind Mesa a "company" who can afford the "nominal price" of membership?
I'm not concerned about just whether AMD or Intel could implement it. It can't rightly be called an "open specification" if you have to join an industry consortium to implement the specification.
My point was that they don't seem like it. Bindless texture support requires something very substantial from the hardware, which is only found in the more modern shader-based systems. The ability to get compute dispatch and rendering call parameters from arbitrary locations seems like something that every 4.x piece of hardware ought to be able to do.
My 2 thingies on the DSA shenanigans, and other thoughts off the top of my head.
Right now DSA is not really needed any more (it never was from a purely technical perspective; I'm talking API cleanliness here).
Most of the functionality covered by the DSA extension is dead functionality in modern OpenGL. The only really relevant areas where this actually matters anymore are texture objects and buffer objects, and with vertex attrib binding, buffer objects don't really need it (PBOs are a special case that can be passed over here). DSA as it stands will never be fully implemented in modern OpenGL because modern OpenGL doesn't need all of it; the ARB can pick the best bits (as they have done before with the glProgramUniform calls) and respecify elsewhere to avoid the requirement for it.
I'm slightly disappointed that buffer storage didn't specify a DSA API in core, but it's not a big deal.
I would have liked to have seen glBindMultiTextureEXT go core, but it hardly seems worth it for a single entry point. GL_ARB_multi_bind covers the needed functionality anyway.
It's unclear how GL_ARB_multi_bind interacts with a subsequent glTexImage/glTexSubImage/glTexParameter/etc call, or even a subsequent glBindTexture call. It seems obvious that since the original active texture selector remains unmodified, that's the one that gets used. The resolution to issue #10 makes it clear for buffers, and it would have been nice to see similar for textures. This just makes texture objects even messier, and to be honest it's looking as though junking the whole API and specifying a new GL_ARB_texture_objects2 (or whatever) from scratch may have been a better approach. That's my prediction for OpenGL 5.
This could be something that could be improved, the OpenCL 2.0 announcement has a mention of a 6 months feedback window. Too bad the OpenGL 4.4 does not seem to mention such a thing. Could be a good thing to do this for OpenGL too.Issue #9 for GL_ARB_buffer_storage makes for fairly grim reading, unfortunately...
It's a pity as this could have been the kick up the jacksie that GL's buffer object API really needed, and the issue in question should really have been resolved by just saying "this is client memory, full stop, using incompatible flags generates an error, here are the flags that are incompatible and the vendors will have to just live with it", but it seems another case of shooting too high and missing the basic requirement as a result.
The reason the issue for buffer objects needed clarification is because buffer objects have a separation between an indexed bind point and the target bind point. Binding with glBindBufferRange binds to both the target and the indexed bind point, while glBindBuffer only binds to the indexed bind point. So it's not clear whether glBindBuffersRange would bind to the target bind point the way glBindBufferRange does. Hence the clarification.It's unclear how GL_ARB_multi_bind interacts with a subsequent glTexImage/glTexSubImage/glTexParameter/etc call, or even a subsequent glBindTexture call.
Textures have no such dichotomy; there is no "target bind point". There are only texture image unit binding points. So there's nothing that needs to be said about them. glBindTextures binds the textures to those texture image units, period.
This topic actually makes me curious about some of active posters here and this forum in general.Those new functions get a lot of discussion. What are you using this recent(4.2 and above) functionality for? What is the scope of application? Because this functionality is barely supported, it means you either target really specific hardware or have time to maintain additional code paths.
Boo hoo. Perhaps you have millions of dollars and are willing to build the standards body wherein all hardware manufacturers come together and build specs, all for free gratis. Have at it.
Becoming a member is chump change.
