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 2 of 10 FirstFirst 1234 ... LastLast
Results 11 to 20 of 96

Thread: Official feedback on OpenGL 4.3 thread

  1. #11
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935
    Quote Originally Posted by Alfonse Reinheart View Post
    ... how? Attribute format conversion is free; doing it in the shader would be not free. How is "not free" faster than "free"?

    Furthermore, attributes are fast, with dedicated caches and hardware designed to make their particular access pattern fast. Shader storage buffers are decidedly not. Specific hardware still beats general-purpose code.
    First the stride parameter needs to be a binding parameter. It allows to reusing the same vertex formats but data that is dispatched into various number of buffer. Typically we can expect cases where a vertex format will be used for a perfectly packed buffer which interleave all the data. We can however imagine that the same vertex format can be reused without switching for a data that are stored into two buffers: One static and one dynamically updated.

    Second, attribute format conversion is the same cost when done in the shader because it is effectively already done in the shader behind or back. GPUs no longer use dedicated hardware for that, it takes space that can't be reused for something else. That will be more and more the case.

  2. #12
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by Groovounet View Post
    First the stride parameter needs to be a binding parameter. It allows to reusing the same vertex formats but data that is dispatched into various number of buffer. Typically we can expect cases where a vertex format will be used for a perfectly packed buffer which interleave all the data. We can however imagine that the same vertex format can be reused without switching for a data that are stored into two buffers: One static and one dynamically updated.

    Second, attribute format conversion is the same cost when done in the shader because it is effectively already done in the shader behind or back. GPUs no longer use dedicated hardware for that, it takes space that can't be reused for something else. That will be more and more the case.
    Exactly, shaders do perform the fetching and attribute format conversion internally, so they have to know the stride in order to create the appropriate fetching and conversion code, thus despite we have now separate format and binding, considering that the stride is coupled with the binding, there can be still internal re-compiles of vertex fetching code even one only changes binding (as we had it with the old API), thus it defeats the purpose.

    But, of course, this all depends on hardware and driver implementation.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  3. #13
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    935
    Could the stride parameter be a variable which content would be fetched from a register file?

  4. #14
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by Groovounet View Post
    Could the stride parameter be a variable which content would be fetched from a register file?
    Maybe, it all depends on the hardware and driver implementation, though I suppose that not all existing hardware can do it that way, but maybe I'm wrong. However, that means an additional indirection which might not be good performance-wise for some applications. I still believe that for new applications programmable vertex fetching is the way to go, especially having something like shader storage buffers in place.

    However, shader storage buffers have their problems too:
    1. They have to be writeable, thus they cannot be supported on GL3 hardware
    2. GL4.3 only requires a max of 16MB for storage buffers which may be too small for some use cases (of course, implementations are free to allow larger buffers, but still, it just sounds too small for me)
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  5. #15
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    First the stride parameter needs to be a binding parameter. It allows to reusing the same vertex formats but data that is dispatched into various number of buffer. Typically we can expect cases where a vertex format will be used for a perfectly packed buffer which interleave all the data. We can however imagine that the same vertex format can be reused without switching for a data that are stored into two buffers: One static and one dynamically updated.
    What good is that? The assumption with this is that the non-stride part of the vertex format is the performance-limiting issue, rather than the buffer binding itself. Bindless suggests quite the opposite: that changing the vertex format is cheap, but binding buffer objects is expensive. At least for NVIDIA hardware.

    Second, attribute format conversion is the same cost when done in the shader because it is effectively already done in the shader behind or back. GPUs no longer use dedicated hardware for that, it takes space that can't be reused for something else. That will be more and more the case.
    Do you have evidence of this? And for what hardware is this true?

  6. #16
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Quote Originally Posted by Alfonse Reinheart View Post
    Bindless suggests quite the opposite: that changing the vertex format is cheap, but binding buffer objects is expensive. At least for NVIDIA hardware.
    What makes you think that? Please give a reference to where did you read that because I would be also interested.

    From bindless, I feel that NVIDIA thinks two things to be expensive:
    1. Vertex format change
    2. Mapping buffer object names to GPU memory addresses

    Maybe I'm wrong, so please disprove my assumptions.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  7. #17
    Junior Member Newbie
    Join Date
    Aug 2009
    Location
    Ottawa, Canada
    Posts
    5
    Quote Originally Posted by Alfonse Reinheart View Post
    Most Comprehensive Extension Award

    ARB_internalformat_query2

    This is something OpenGL has needed for ages, and I generally don't like giving props for people finally doing what they were supposed to have done long ago. But this extension provides pretty much every query you could possibly imagine. It's even a little too comprehensive, as you can query aspects of formats that aren't implementation-dependent (color-renderable, for example).
    Thanks!
    Definitely agree that this was long overdue. As for the 'too comprehensive' aspect -- my desire is that this will become widely supported across GL and GLES versions. In this usage, the properties that aren't implementation-dependent for a specific version of GL, then do have value.

  8. #18
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    Quote Originally Posted by Groovounet View Post
    GPUs no longer use dedicated hardware for that
    So when can we expect fully programmable vertex pulling (with right performace) extension from AMD?
    I think its a little bold to assume that over significant amount of hardware out there.

    I know of at least some recent that cant do that (without silly amount of shaders recompilation before batch submition).

  9. #19
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,213
    Quote Originally Posted by Alfonse Reinheart View Post
    What good is that? The assumption with this is that the non-stride part of the vertex format is the performance-limiting issue, rather than the buffer binding itself. Bindless suggests quite the opposite: that changing the vertex format is cheap, but binding buffer objects is expensive. At least for NVIDIA hardware.
    In D3D at least, when using IASetVertexBuffers (slot, num, buffers, strides, offsets), changing the strides and/or offsets alone is cheaper than changing everything. Since the buffer part of the specification is not changing the driver can make use of this knowledge and optimize behind the scenes.

    With GL this is now explicit in the new state that has been introduced. VERTEX_BINDING_STRIDE and VERTEX_BINDING_OFFSET are separate states, so they are the only states that need to be changed on a BindVertexBuffer call where everything else remains equal.

    Where this functionality is useful is when you may have multiple models packed into a single VBO, or multiple frames for the same model in a single VBO, or for LOD schemes. You can jump to a different model/frame/LOD with a single BindVertexBuffer call, rather than having to specify individual VAOs for each model/frame/LOD, or respecify the full set of VertexAttribPointer calls for each model/frame/LOD (worth noting that stride is not really a big deal here and is unlikely to change in real-world programs; offset is the important one).

    The decoupling of buffer from layout introduced here is useful functionality on it's own. Your VertexAttribArray (VertexAttribFormat) calls are no longer dependent on what the previous BindBuffer call was, which introduces extra flexibility and reduces potential for error. Getting rid of such inter-dependencies is also some nice cleaning up of the API and it's a good thing that GL has finally got this, the only seeming bad part being (and I haven't fully reviewed the spec so I may have missed something) that BufferData/BufferSubData/MapBuffer/MapBufferRange haven't been updated to take advantage of the new binding points.

    I recommend sitting down and writing some code for non-trivial cases using this API; you should soon see how superior this method is to the old.
    Last edited by mhagain; 08-06-2012 at 07:35 PM.

  10. #20
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    You can jump to a different model/frame/LOD with a single BindVertexBuffer call, rather than having to specify individual VAOs for each model/frame/LOD, or respecify the full set of VertexAttribPointer calls for each model/frame/LOD (worth noting that stride is not really a big deal here and is unlikely to change in real-world programs; offset is the important one).
    Welcome to my entire point: if the stride isn't going to change in any real-world system, why is the stride not part of the vertex format?

    There's a reason I gave it the "one little mistake" award: the only thing wrong with the functionality is that the stride is in the wrong place for no real reason. Or at least, the only reason is because "Direct3D does it that way." It doesn't actually make sense; that's just how they do it.

    the only seeming bad part being (and I haven't fully reviewed the spec so I may have missed something) that BufferData/BufferSubData/MapBuffer/MapBufferRange haven't been updated to take advantage of the new binding points.
    There aren't new binding points. glBindVertexBuffer does not bind the buffer to a binding target the way that glBindBufferRange does. That's why it doesn't take a "target" enum. It only binds it to an indexed vertex buffer binding point; it doesn't bind the buffer to a modifiable target.

    This was almost certainly done to allow glVertexAttribPointer to be defined entirely in terms of the new API. glVertexAttribPointer doesn't change GL_ARRAY_BUFFER's binding, nor does it change any other previously-visible buffer binding state. Therefore, glBindVertexBuffer doesn't either.

    Personally, I don't have a problem with the minor API inconsistency.

Posting Permissions

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