I got rid of the out of memory problem in the Intel case (was using RGBA_INTEGER render target, changed to R32I to save memory). The out of memory error is gone and enables further testing.
Here are my conclusions so far.
Intel hardware:
- I can read from a 2GB-16 bytes (2147483632 bytes) buffer successfully.
- I cannot read from a 2GB (2147483648 bytes) buffer. Attempting to access the SSBO, regardless of which location is accessed, raises a 1282 error when calling glDrawElements
- this limit matches the limitation advertised by GL_MAX_TEXTURE_BUFFER_SIZE, set to 134217728 elements (134217728 * 16 bytes per element = 2147483648 bytes)
- I am nearly sure Intel has mistakenly set GL_MAX_SHADER_STORAGE_BLOCK_SIZE to 134217728 instead of 2147483648. GL_MAX_SHADER_STORAGE_BLOCK_SIZE is indeed expressed in âbasic machine unitsâ, not âtexture elementsâ. It would not make sense to be able to create larger texture buffers than SSBOs. So itâs a small mistake from Intel here I am sure.
nVidia:
- attempting to read from a 5GB buffer works but results in erronerous data being read beyond 2GB. The 2GB limit matches the GL_MAX_SHADER_STORAGE_BLOCK_SIZE value of 2147483647 for this vendor (itâs weird the value ends with 647 and not 648âŚ). It also matches their GL_MAX_TEXTURE_BUFFER_SIZE value of 134217728 texels.
- reading from a 3GB works fine from the shader, with or without robustness enabled in the GL context.
I donât see any logic about this. - there is a minor GLSL compiler bug whereby the compiler crashes with super-large fixed-size SSBO array definitions.