PDA

View Full Version : VBO and compute shader



__bob__
04-08-2015, 03:36 AM
hi!

I try to access to vertex list and face index.



glBindBufferBase(GL_ARRAY_BUFFER,10,((ModelGL*)(n->getModel()))->getVertex());
glBindBufferBase(GL_ARRAY_BUFFER,11,((ModelGL*)(n->getModel()))->getFaces());


and in my compute :


layout (std430,binding = 10) readonly buffer Vbuffer
{
vec3 vertex[];
};

layout (std430,binding = 11) readonly buffer Fbuffer
{
face faces[];
};


It doesn't work.
Any idea?

__bob__
04-08-2015, 05:42 AM
Solution : bind vbo as GL_SHADER_STORAGE_BUFFER

Now, i've a second problem, it seems do deal with padding.
My vertcies are vec3 and my faces are 3 int. I try std140 and std430 without good results...

Alfonse Reinheart
04-08-2015, 09:42 AM
My vertcies are vec3 and my faces are 3 int.

Even in std430 layout, 'vec3's use the base alignment of 'vec4's. So each array element is 4 values.

Also, the term "VBO" (to the degree that you should use that term) only applies to a buffer object that is bound to GL_ARRAY_BUFFER. Buffers can be bound to many targets, but they're all still just buffer objects, no matter how you use them.

__bob__
04-09-2015, 01:22 AM
To avoid thos f***ing padding issues, i tweak my acces to the VBO from

layout (std430,binding = 10) readonly buffer Vbuffer
{
vec3 vertex[];
};

layout (std430,binding = 11) readonly buffer Fbuffer
{
face faces[];
};
to

layout (std430,binding = 10) readonly buffer Vbuffer
{
float vertex[];
};

layout (std430,binding = 11) readonly buffer Fbuffer
{
int faces[];
};
To acces the data, the solution is simple :


vec3 readVertex(uint index)
{
return vec3(vertex[3*index],vertex[3*index+1],vertex[3*index+2]);
}

ivec3 readFace(uint index)
{
return ivec3(faces[3*index],faces[3*index+1],faces[3*index+2]);
}


Thanks!

Alfonse Reinheart
04-09-2015, 09:00 AM
It should be noted that the vec3 alignment thing was something specifically put into the API. Probably for a good reason. Which means you probably shouldn't bypass it like this unless you have a good reason to do so. The compiler could easily turn your memory usage into 3 separate memory access operations, rather than a single one in the case of a vec3 (even padded to a vec4).

So this could be more of a memory/performance tradeoff.