0
votes

I'm experimenting with geometry shaders on a Macbook Pro with Intel HD 4000 graphics running Mavericks. I'm noticing some odd behavior from an EndPrimitive() call. Here's my geometry shader:

#version 150 core

layout(points) in;
layout(triangle_strip, max_vertices = 512) out;

void main() {
    vec4 start_pos = gl_in[0].gl_Position + vec4(-0.5, -0.5, 0.0, 0.0);
    vec4 bottom_vertex = start_pos;

    for (int i = 0; i < 17; ++i) {
        bottom_vertex = start_pos + vec4(float(i) * float(1.0 / 16.0), 0.0, 0.0, 0.0);
        gl_Position = bottom_vertex;
        EmitVertex();

        gl_Position = bottom_vertex + vec4(0.0, 1.0/16.0, 0.0, 0.0);
        EmitVertex();
    }
    //EndPrimitive();
}

The program uses glfw and requests an OpenGL 3.2 core context. I only draw a single vertex at [0, 0] and my goal is to ultimately have my geometry shader output a square grid made of multiple triangle strips. The shader, as-is, outputs a single row of the grid. Here's the result:

apparently correct output

At that point I want to end the current triangle strip primitive and start a new one for the next row. However, simply uncommenting the EndPrimitive() call in the shader above screws up the result:

broken output

Am I misunderstanding something about EndPrimitive()? My understanding is that it should end the current triangle strip and start a new one. Since I'm not doing anything after my loop, my shader's result should be the same with EndPrimitive() or without it.

Also, I can't test on a different implementation right now, could it be that mine is buggy? Is there anything I can try to pinpoint this issue?

1

1 Answers

1
votes

Turns out the mistake was in my host code. I was calling glDrawArrays() with the wrong value as the last parameter. This is probably undefined behavior as I issued the call to draw more points than my array buffer contained. Fixing that issue makes EndPrimitive() work as expected.