Confusion about maximum output from Geometry Shaders

The OpenGL-Wiki states on the output limitations of geometry shaders:

The first limit, defined by GL_MAX_GEOMETRY_OUTPUT_VERTICES`, is the maximum number that can be provided to the max_vertices​ output layout qualifier. […] The other limit, defined by GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS​ is […] the total number of output values (a component, in GLSL terms, is a component of a vector. So a float​ is one component; a vec3​ is 3 components).

That’s what the declarative part of my geometry shader looks like:

layout( triangles ) in;
layout( triangle_strip, max_vertices = 300 ) out;
out vec4 var1;

My vertex format only consists of 4 floats for position.
So I believe to have the 4 components from the varying “var1” plus the 4 components from the position, i.e. 8 in total.

I have queried the following values for the constants mentioned above:

GL_MAX_GEOMETRY_OUTPUT_VERTICES = 36320
GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 36321

With “max_vertices” set to 300, a total of 8*300 = 2400 components would be written. It is needless to say that this value is far below 36321 as well as the 300 of “max_vertices” is far below 36320. So everything should be okay, right?

However, when I build the shader, the linking fails:

error C6033: Hardware limitation reached, can only emit 128 vertices of this size

Can somebody explain to me what is going on and why this doesn’t work as I expected?

[QUOTE=theV0ID;1264985]I have queried the following values for the constants mentioned above:


GL_MAX_GEOMETRY_OUTPUT_VERTICES = 36320
GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS = 36321

[/QUOTE]
Those are the just values of the enumerants. You have to use e.g.


GLint max_vertices, max_components;
glGetIntegerv(GL_MAX_GEOMETRY_OUTPUT_VERTICES, &max_vertices);
glGetIntegerv(GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS, &max_components);

to obtain the actual limits.

I have queried the following values for the constants mentioned above:

No, you have instead made a common mistake. You’re looking at the value of the enumeration. What you want is to query the value for that enumeration from the OpenGL implementation. See, it’s an implementation-defined limitation; each graphics card can define a different number. OpenGL implementations have to support at least a certain number, but different cards could have higher limts.

You need to use glGetInteger for that.

Though it’s highly unlikely implementations will let you shove 300+ vertices as output from a GS. What exactly are you trying to accomplish that you need to send that many vertices from a single GS invocation?

Thanks! I need to duplicate a triangle a few hundred times. Previously I was rendering the triangle from CPU with a rendering call each time, but that was getting slow, so I though using a geometry shader might help. I think the solution to go here with is to still make a few rendering calls, s.t. each rendering call still duplicates the triangle like 128/3 times or so?

Or you could use instancing.

A good rule of thumb with GS’s is this: if performance is a problem, GS’s almost never help.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.