我像这样将shader storage buffer
绑定到shader storage block
GLuint index = glGetProgramResourceIndex(myprogram, GL_SHADER_STORAGE_BLOCK, name);
glShaderStorageBlockBinding(myprogram, index, mybindingpoint);
glBindBuffer(GL_SHADER_STORAGE_BUFFER, mybuffer)
glBindBufferRange(GL_SHADER_STORAGE_BUFFER, mybindingpoint, mybuffer, 0, 48);
glBufferSubData(GL_SHADER_STORAGE_BUFFER, 0, 48, &mydata);
mydata
指向包含 4 个glm::vec3
对象的std::vector
。
因为我绑定48 bytes
作为缓冲范围,我希望lights[]
保持48/(4*3) = 4 vec3s
.
layout(std430) buffer light {
vec3 lights[];
};
我的std::vector
索引 1
处的元素保存数据x=1.0, y=1.0, z=1.0
。
但是通过执行来查看输出
gl_FragColor = vec4(lights[1], 1.0);
我看到黄色(x=1.0, y=1.0, z=0.0
)像素。这不是我加载到缓冲区中的内容。
有人可以告诉我我做错了什么吗?
编辑
我只是将着色器存储块更改为
layout(std430) buffer light {
float lights[];
};
和输出
gl_FragColor = vec4(lights[3],lights[4],lights[5],1.0);
它有效(白色像素)。
如果有人能解释这一点,那仍然很棒。
这是因为人们不接受这个简单的建议:永远不要在 UBO/SSBO 中使用vec3
。
vec3
的基本对齐方式为 16 个字节。总是。因此,当它被排列时,数组步幅(从一个元素到下一个元素的字节数)始终为 16。与vec4
完全相同.
是的,std430
布局与std140
不同。但这并没有什么不同。具体来说,它只能防止数组元素的基本对齐和步幅(以及结构的基本对齐)向上舍入到vec4
的对齐和步幅。但是由于vec3
的基对齐总是等于vec4
的基对齐,所以它不会改变它们。它只影响标量和vec2
。