Official feedback on OpenGL 4.3 thread

[Groovounet]

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

[aqnuep]

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.

[Groovounet]

Could the stride parameter be a variable which content would be fetched from a register file?

[aqnuep]

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)

[Alfonse Reinheart]

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?

[aqnuep]

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.

[Booner]

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.

[kyle_]

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

[mhagain]

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.

[Alfonse Reinheart]

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.