currently I can’t really imagine many convincing example uses that justifies introducing 2 (or 4) new APIs.
There needs to be a SubData version for clearing part of a buffer. Sometimes, that’s really what you want to do. At the same time, there should be a Data version for clearing the whole thing, without having to query its size.
Now, why they bothered with the non-DSA versions when several extensions don’t provide non-DSA versions… that’s a good question.
kRogue: BTW, the workaround could be to use glClearBuffer() on a framebuffer attachment - albeit it’s not cool but does essentially what you ask for. I can’t help but feel that naming a function glClearBuffer{Sub}Data in the presence of glClearBuffer wasn’t the wisest decision to make. Again, to the knowing developer it’s not a problem but when seeing it the first time you start thinking.
Yes, probably not the best nomenclature. But what else could you call it? glMemsetBufferData? glClearBufferObjectData?
The ARB was kinda screwed by glClearBuffer; it should have been named something like glClearFramebufferImage or glClearFramebufferAttachment. Something that has “Framebuffer” in it.
The attach texture to FBO and do clear buffer is what I do now. It just is awkward… also affects GL state and obscures what I am after: memset a texture. This clearing of a texture before use is really freaking important with respect to GL accelerated browsers. Oh well. I’ll live, for now.
It just is awkward… also affects GL state and obscures what I am after: memset a texture.
You assume that the hardware implementation would not have to do the same thing: use the framebuffer clearing mechanism to clear the texture’s data. Remember: doing an actual clear like this on texture memory is not exactly a common operation. 99 times out of 100, if you’re clearing an image, it’s because you’re about to render to it. Textures not meant to be render targets are typically uploaded to, not cleared.
Um… how to go about this. The information leak is the following for a web browser supporting WebGL:
[ol]
[li]Create texture[/li][li]Attach texture to FBO[/li][li]execute glReadPixels[/li][/ol]
OR
[ol]
[li]Create texture, but do not initialize it[/li][li]use the texture to draw contents[/li][li]glReadPixels from the framebuffer[/li][/ol]
now if a WebGL implementation does not clear the texture before it is used (as far as the user of WebGL is concerned) then a WebGL process can read image data from discarded memory, in particular previous image data held in texture be it in the same browser process or even a completely different program.
This is bad. So a WebGL implement must add additional code to either track if the texture was cleared already or all of it set, etc… which is a right pain in the rear when all one wants is the ability to memset the freaking memory when it is allocated.
Why exactly is this bad? You may be reading image data from discarded memory. You may not. It’s certainly not something reliable, and even if it were, all you get is… a picture.
Ahh… a picture… from a secure website…maybe your private chats, maybe online banking… There are already attacks of this form. It is a security risk, it leaks information. The picture can be sent to a remote sight for analysis, etc… Blackmail, forgery, etc.
Leaking information, like a freaking screenshot is a security risk.
At any rate, lets get back on target: I’d like a glClearTexture call rather than bind framebuffer, attach texture, call glClear**(). They had the chance with the “immutable texture” thing introduced, just wish those texture making functions included a memset value. Whine whine, I’d like some cheese please.
Are you doing implementaion of WebGL or something? 
There certainly is security vulnerability possible to implement, but i dont think its that of a big deal (as in, for the driver - i hope its a big deal for the browsers).
It would probabaly be best to specify context flag that would require all ‘uninitialized’ bits to be set to zero, without any API overhead.
Sorry, I seem to have missed an award:
We Can’t Be Bothered To Use A Diff File To Fix Our Spec Bugs
This one goes to whomever is responsible for maintaining the .spec files.
Some time ago, I made a .diff file available that fixes a large number of .spec bugs. Missing enumerators, wrong enumerators, etc. And yet… those .spec bugs still exist.
It’s really not that hard to run patch over the .spec files, guys. I did the hard work for you.
[QUOTE=Alfonse Reinheart;1241282]
Some time ago, I made a .diff file available that fixes a large number of .spec bugs. Missing enumerators, wrong enumerators, etc. And yet… those .spec bugs still exist.[/QUOTE]
Did you file a bug with your fixes? If not, please file one at The Khronos Group · GitHub
I think it may have been logged as this bug (2011-09-12):
Contains a link to the thread that has the fixes.
I thank the Khronos Group for the new features.
I also thank the members for the cleaner specs.
I can NOT understand their refrain on direct state access (DSA).
Are they able to understand that bind-to-edit/bind-to-use is a killer paradigm for clean, library, multideveloper environments?
Sure they are aware of this. And yes, DSA would introduce a lot of new API functions.
In my dreams, I see two options:
History told me that I have to give up on option 1.
For option 2, given the experience we had about bad naming conventions, what about defining every DSA function as glDirect<Somethig>() ? It has been already adviced, but no one on the upper floors listens to it.
Sorry, but I am very upset about the lack of a proper, well structured DSA.
And I am also worried about all the advertising on GL overtaking DX. GL catched DX, great, kudos to all, really. But WE WANT A GOOD API.
</rant>
m.
It has been already adviced, but no one on the upper floors listens to it.
Actually, GL_ARB_clear_buffer_object defines 2 APIs having the substring “Named” in them which makes senses as you identify the object being modified by its name (a GLuint) and not by its binding target. IMHO that’s ok as far as naming conventions go.
The DSA extension as it stands isn’t appropriate for promotion to core - for one thing it modifies a LOT of deprecated functionality, and any hypothetical DSA-in-core would very likely not include these parts. Existing programs will be more likely to either retain their old code or do a full port to core, new programs can start out as core-only, so it would be lot of spec work for something that wouldn’t be used.
The big win from DSA is removal of bind-to-modify but DSA as it is specifies a lot more than just that, and builds on the existing functionality (mostly by just adding an extra param to each call) rather than specifying a real new way. That means that all of the other nastiness in e.g. texture objects remains exposed with DSA just fixing up one part.
There’s a clear alternative path available here, which is to unify texture and buffer storage into a single new object type (it’s all just video RAM if you think about it, with the only real difference being how it’s used, which is a program-specific feature and doesn’t seem to justify any major API-separation), and provide DSA-only entry points for that object type. The existing non-DSA API could then be layered on top of that in the driver, in much the same way as the fixed pipeline is layered on top of shaders, and immediate mode is (probably) layered on top of vertex buffers in current implementations. In an ideal world the hardware vendors could even get together and provide a common such layer that they would all ship, but I don’t see that being anything other than a slim possibility.
That seems the sensible route, but this is the ARB that we’re talking about, so we’ll need to wait and see. After recent spec evolutions I’ve a little more faith than before, and they may yet surprise us in a nice way, but that’s just me and it’s entirely possible I may be wrong.
(As an aside: it’s nice to see the newer functionality taking a DSA-like approach so it’s obvious that this is something that the ARB do recognise the value of, meaning that it’s most likely not a case of resistance to the idea of DSA but more a case of difficulties in getting a sensible specification together.)
As an aside: it’s nice to see the newer functionality taking a DSA-like approach so it’s obvious that this is something that the ARB do recognise the value of, meaning that it’s most likely not a case of resistance to the idea of DSA but more a case of difficulties in getting a sensible specification together.
The problem is that they’re very inconsistent about it.
For example, ARB_invalidate_subdata is pure DSA. It doesn’t add a GL_INVALIDATE_BUFFER target, nor does it use buffers attached to the context. It simply takes buffer and texture objects directly. ARB_copy_image works similarly.
And yet, ARB_framebuffer_no_attachments, which adds parameters to framebuffers, works just like the standard OpenGL way. You don’t pass an FBO; you have to bind it and modify it. Similarly, ARB_clear_buffer_object isn’t DSA; you have to bind it to the context.
Both of them have EXT functions that are DSA, but the core functions are not. So you can invalidate a buffer via DSA, but not clear it.
I would say that the ARB doesn’t recognize the value of it; NVIDIA does. Just look at the Contributors section. For ARB_copy_image, you have 10 people; 9 of them are from NVIDIA and one is from Transgaming. For ARB_invalidate_subdata, 2 of the 3 contributors are from NVIDIA. The non-DSA-style extensions are credited as “Members of the Khronos OpenGL ARB TSG” or simply don’t have a Contributors section at all.
Looking at the Revision History, the DSA-style extensions seem to have been more or less done internally by NVIDIA, then presented to the ARB for editing and approval. Things like “internal revisions” and “based on NV_copy_image”. The others seem to have been formed by the ARB themselves.
Of course, this also explains why ARB_vertex_attrib_binding isn’t DSA-style (it doesn’t even add DSA EXT functions). Because the objects they would be modifying are VAOs, and NVIDIA doesn’t seem to like VAOs or encourage their use. Granted, VAB tends to work against 70% of the whole point of VAOs, but that’s another issue.
So the ARB isn’t trying to make DSA happen; NVIDIA is. That’s why we don’t have DSA in core, because only one member of the ARB actually wants it to happen.
The big win from DSA is removal of bind-to-modify
DSA does not, and never did, remove bind-to-modify. It simply provides an alternative. Removing “bind-to-modify” would require removing every function that operates on state that happens to be encapsulated into an object.
…on the other hand sampler objects are primarily from AMD and use a DSA-style API: http://www.opengl.org/registry/specs/ARB/sampler_objects.txt
And as for DSA not removing bind-to-modify, check out http://www.opengl.org/registry/specs/EXT/direct_state_access.txt and “void TextureSubImage2DEXT(uint texture, enum target, …” or “void NamedBufferSubDataEXT(uint buffer, intptr offset, …” - what’s that if not removal of bind-to-modify?
With the main object types that bind-to-modify affects in real-world code being texture objects and buffer objects, the point that a replacement API without bind-to-modify would suit this requirement more than building on top of the existing API by providing variants for every function still stands. Unless we’re going to squabble over semantics of “modify” versus “load data”, of course… 
…on the other hand sampler objects are primarily from AMD and use a DSA-style API: http://www.opengl.org/registry/specs...er_objects.txt
True. But it’s also creating an entirely new object type. Whereas the current brand of extensions are just changing what you can do to them.
And as for DSA not removing bind-to-modify, check out http://www.opengl.org/registry/specs...ate_access.txt and “void TextureSubImage2DEXT(uint texture, enum target, …” or “void NamedBufferSubDataEXT(uint buffer, intptr offset, …” - what’s that if not removal of bind-to-modify?
It’s adding the ability to modify textures without binding them. It doesn’t remove the possibility of modifying textures by binding them. Bind to modify is not removed by DSA. An individual application may never use bind-to-modify again. But because it is still allowed by the API, drivers must assume that the user can and will do it.
[ol]
[li]Mental note to self: don’t use “removal of {X}” as shorthand for “removal of the absolute need to use {X} in every concievable situation while still allowing that the ability to use {X} may be retained” because it will be taken blindly literally. Sigh. [/li][li]In any event that’s what the deprecation mechanism is for. [/li][/ol]
Mental note to self: don’t use “removal of {X}” as shorthand for “removal of the absolute need to use {X} in every concievable situation while still allowing that the ability to use {X} may be retained” because it will be taken blindly literally. Sigh.
“every conievable situation” obviously not including, “still retaining backwards compatibility with implementations that don’t implement DSA” or “we’re not going to rewrite our entire codebase just because someone came out with a new OpenGL version.” Because those are inconceivable.
In any case, without actually getting rid of bind-to-modify, I never really saw the point of DSA. Because as long as drivers have to assume that an application could be binding an object to modify it, the driver can’t do useful things like assume that when you bind that VAO, you actually mean to render with it. And so forth. Without that, it’s little more than API convenience.
A nice one to be sure. But I don’t know that convenience alone is really worth adding 100 more OpenGL functions.
In any event that’s what the deprecation mechanism is for.
Just like the ARB deprecated glUniform* when ARB_separate_shader_objects gave us glProgramUniform*. Like they deprecated the sampler object state inside of textures when they created separate sampler objects. Like they deprecated glVertexAttribPointer when they came out with glVertexAttribFormat and glBindVertexBuffer. Like they deprecated glGetActiveUniform when they made the new program querying API.
I can keep going, but I think my point is clear: deprecation is dead. They’re not doing that again.