Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 6 of 10 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 96

Thread: Official feedback on OpenGL 4.3 thread

  1. #51
    Senior Member OpenGL Pro sqrt[-1]'s Avatar
    Join Date
    Jun 2002
    Location
    Australia
    Posts
    1,000
    I think it may have been logged as this bug (2011-09-12):
    https://www.khronos.org/bugzilla/show_bug.cgi?id=529

    Contains a link to the thread that has the fixes.

  2. #52
    Junior Member Newbie
    Join Date
    Jun 2006
    Posts
    9
    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:
    1) completely rewrite the GL API (!!!)
    2) put into core specs the DSA functionalities

    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.
    Last edited by Marco Di Benedetto; 08-11-2012 at 07:29 PM.

  3. #53
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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.

  4. #54
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,198
    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.)
    Last edited by mhagain; 08-12-2012 at 05:29 AM.

  5. #55
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

  6. #56
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,198
    ...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

    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?

    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...

  7. #57
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    ...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.

  8. #58
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,198
    1. 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.
    2. In any event that's what the deprecation mechanism is for.

  9. #59
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

  10. #60
    Junior Member Newbie
    Join Date
    Jun 2009
    Posts
    18
    Quote Originally Posted by Alfonse Reinheart View Post
    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.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •