0

I seem to have nondeterministic data in my Shader Storage Buffer.

I used apitrace to inspect the state machine and noticed the following sequence of function calls in the trace:

glBindBuffer (GL_SHADER_STORAGE_BUFFER, 3);
glBufferData (GL_SHADER_STORAGE_BUFFER, 36, NULL, GL_DYNAMIC_DRAW);
glBufferSubData (GL_SHADER_STORAGE_BUFFER, 0, 4, [binary data, size = 4 bytes])
glBufferSubData (GL_SHADER_STORAGE_BUFFER, 4, 32, [binary data, size = 32 bytes])

This appears to be correct according to the higher-level application code, it matches setting this

layout (std140) buffer Components
{
    int count;
    vec4 colour [];
}
b_components;

to a length-prefixed array glm::vec4[2].

However, apitrace shows that GL_BUFFER_DATA_SIZE is 32, not 36, at every stage in the above trace.

Also, here's an inspection of the SSBO:

enter image description here

Components.colour[0] has GL_ARRAY_SIZE=0 (shouldn't this be nonzero?) and GL_OFFSET=16 (shouldn't this be 4?)

The program is very simple, so for good measure, here's the full trace (this is for Frame 1, the glBufferData(...,36,...) was in Frame 0 and has not been repeated):

enter image description here

  1. Shouldn't the SSBO have GL_BUFFER_DATA_SIZE=36, given my call to glBufferData? If so, is this a driver bug? If its stated size of 32 is correct, can you please explain how that makes sense?

  2. Are the GL_ARRAY_SIZE and GL_OFFSET correct?

  3. Given that inspecting the glBufferSubData calls, my array glm::vec4[2] describes correct, deterministic data, is there anything in this trace which would explain why, when I read b_components.colour[i] within for (int i = 0; i < b_components.count; ++i) that I get nondeterministic results?

spraff
  • 32,570
  • 22
  • 121
  • 229
  • Why are you binding a random integer instead of a value from `glGenBuffers`? That's only legal in compatibility OpenGL. – Nicol Bolas Sep 12 '19 at 14:15
  • It **is** from `glGenBuffers`, I'm just not showing you the whole program. Also why have you marked this a duplicate? I see nothing there about unexpected `GL_BUFFER_DATA_SIZE` values? – spraff Sep 12 '19 at 14:28
  • It's easy to look up the fact that the buffer data size is the minimum size of a buffer needed for an indexed binding point, so I assume you know that. Given the correction to your misunderstanding of how `std140` layout works (which is what the duplicate supplies), that should be all you need to understand why 36 is not an appropriate minimum size for your storage block as it is defined, and why 32 makes far more sense. – Nicol Bolas Sep 12 '19 at 14:52

0 Answers0