PDA

View Full Version : Problem writing to SBO in geometry shader



urhere
08-06-2013, 08:35 AM
Hello all,

I am working on a project that defines PN triangles in a tessellation control shader from gridded elevation data. The associated tess eval shader evaluates the surface correctly and the fragment shader produces a good rendering. However, I would like to provide the fragment shader with information both about the 3D triangle from which a given fragment was rendered and information about adjacent rendered triangles, kind of replicating what a geometry shader could get if it was using triangles_adjacency primitives. Since that's not compatible with the patch primitive necessary for the tessellation shaders, I would like to write 'triangle' data from a geometry shader to a shader storage buffer object. But right now I get a GLSL compilation error when I add a line of code that writes to any SSO in the geometry shader. The specific error is:

ErrorLog = 0x0050c1f0 "Geometry info
(0) : error C5133: multiple outputs associated with semantic "SBO_BUFFER[0]"


I have been able to write to SSOs in fragment shaders just fine so I'm guessing I've got the syntax wrong or something here is illegal. Here is a pass-through geometry shader that highlights the problem. If I include the line that assigns v to vertex[], I get the compilation error above. Please let me know if there is something else I need to do to get SSOs to work with geometry shaders. Thanks!

Jim
// Geometry shader that tries to write to a SSO
#version 430 core


struct Vertex { // vertex generated by tess eval shader and stored by geometry shader
int m_vertexID;

float easting;

float elevation;

float northing;
};
layout(triangles) in;
layout(triangle_strip, max_vertices = 3) out;

layout (std430, binding = 2) buffer gVertexBuffer { // backing store in application buffer
Vertex vertex[];
};

void main()
{
for (int i = 0; i < gl_in.length(); i++) {

Vertex v;

// Assign various things to v...

vertex[gl_PrimitiveIDIn] = v; // CAUSES GLSL COMPILATION ERROR

gl_Position = gl_in[i].gl_Position;

EmitVertex();

}

EndPrimitive();

}

aqnuep
08-06-2013, 10:34 AM
Have you checked the value of GL_MAX_GEOMETRY_SHADER_STORAGE_BLOCKS using glGetIntegerv? If the returned value is zero it means your hardware doesn't support SBOs in the geometry shader stage.

urhere
08-06-2013, 02:02 PM
Have you checked the value of GL_MAX_GEOMETRY_SHADER_STORAGE_BLOCKS using glGetIntegerv? If the returned value is zero it means your hardware doesn't support SBOs in the geometry shader stage.

Thanks for the tip--I'll give it a try tomorrow.
Jim

Alfonse Reinheart
08-06-2013, 02:34 PM
Note that this is entirely possible. SSBO/Image Load/Store is only required for fragment and compute shaders. Other shader stages may allow them but don't have to.

urhere
08-07-2013, 06:10 AM
Checking with:

glGetIntegerv(GL_MAX_GEOMETRY_SHADER_STORAGE_BLOCK S, params);

this morning, params[0] returned 16.

At this point, the shader is only using 1 SSO. Any other thoughts? In the meantime, I'm going to build an app with nothing but pass through shaders and see if there is some weird side effect from something in my big app. Thanks again for the ideas.

Jim

urhere
08-07-2013, 08:20 AM
Adding the existing shader code to one of my small sample projects created the same error output as in my full program. However, I'm able to get the geometry shader to compile if I change the array of Vertex objects in the storage buffer to an array of int like this:

layout (std430, binding = 2) buffer gVertexBuffer {
// Vertex vertex[];

int vertex[]; // try a simple integer array
};

and then assign to it like this in main():

vertex[gl_PrimitiveIDIn] = gl_PrimitiveIDIn; // no deep meaning here--just a test

By the way, I made comparable changes to the buffer allocation code in the app to work with an array of int instead of an array of Vertex objects.

Although I'm glad this works and that I can use it as a work around, I still don't know why assigning to an element in an array of struct was a problem. Before I'm arrested for more compiler abuse, any thoughts on why I got these results? Thanks.

Jim