GL_MAX_SHADER_STORAGE_BLOCK_SIZE only limits the size of the block in GLSL.

[NicolBolas]

GL_MAX_SHADER_STORAGE_BLOCK_SIZE is stated to be the limit that a storage block can be in a GLSL shader. However, because SSBOs can have variable size, it becomes possible to bind a range of a buffer that is larger than this size limitation.

So the question is, what is supposed to happen to the memory that exceeds this size? Can a shader using a runtime sized array access memory outside of the GL_MAX_SHADER_STORAGE_BLOCK_SIZE range? Should it not be a GL_INVALID_OPERATION error to call glBindBufferRange/Base where the size/effective size is larger than GL_MAX_SHADER_STORAGE_BLOCK_SIZE?

[dgkoch]

WG discussed on 2018-03-28. We believe the link error is only possible if the SSBO is statically sized to be bigger than GL_MAX_SHADER_STORAGE_BLOCK_SIZE. Ie if the last item in the SSBO is an unsized array, you wouldn't get a link-time failure for it.

We think there probably should be an error raised by BindBufferBase/Range if this size is exceeded (and perhaps similarly for some of the other buffer targets as well), but wanted to think about it a bit more.

[pdaniell-nv]

Discussed again today. We agreed that the spec does not define error checking of the bound buffer against the implementation limit for GL_MAX_SHADER_STORAGE_BLOCK_SIZE. We also noted that this is also true for other buffer bindings like UBOs where it is undefined if a buffer larger than GL_MAX_UNIFORM_BLOCK_SIZE is bound, and atomic counters, etc. A couple of IHVs looked at their implementation to confirm no error checking is done here. It's likely that the implementation caps the bound buffer range to their hardware limit and accesses by the shader beyond this limit is covered under the out-of-bounds access behavior defined in the GL spec.

This net of this is that if a buffer is bound for SSBO, where the last element is a variable-sized array, and that buffer is larger than GL_MAX_SHADER_STORAGE_BLOCK_SIZE no error is produced and accesses to the variable-sized array are only defined up to a maximum SSBO total block size of GL_MAX_SHADER_STORAGE_BLOCK_SIZE. Accesses beyond this limit are covered under the out-of-bounds access behavior defined in the GL spec.

[pdaniell-nv]

Although we decided last week that we wouldn't add new error checking to the specification, we did decided that it would be a good idea to improve this statement in the spec:

If the amount of storage required for any shader storage block exceeds this limit, a program will fail to link.

What we want to add is that if the non-variable-sized portion of the SSBO declared in the shader is larger than GL_MAX_SHADER_STORAGE_BLOCK_SIZE that should be a compile/link error since that would be easy for an implementation to check at compile/link time. We will clarify the exact wording soon.

[dgkoch]

Propose we replace the sentence (section 7.8 p149)

If the amount of storage required for any shader storage block exceeds this limit, a program will fail to link.

with:

If the amount of storage required for the fixed size portion of any shader storage block (as reported by BUFFER_DATA_SIZE) exceeds this limit, a program will fail to link.

This applies to both GL and ES specifications.

[pdaniell-nv]

Suggestion approved by the OpenGL/ES working groups. Assigned to @oddhack to apply the change to the next spec updates.

[oddhack]

Fixed internally - this will show up in the next public spec update.

[oddhack]

Fixed in the 2019-10-22 spec updates.