Re: geometry shader crashes GL

Hi,

    I'm playing around with OpenGL geometry shaders (through EXT_geometry_shader4) on a 2.4GHz MacBook Pro with a GeForce 8600M (256MB) with all the latest updates installed. I recently came across a peculiar situation. All the shaders compile and the program runs, but I get a crash deep inside glDrawElements that I can't quite explain. In particular, the crash goes away if I inline one of the loops in the geometry shader. If the shader is as follows,

#version 120
#extension GL_EXT_geometry_shader4 : enable

/* This geometry shader collects the eye positions of the three
   vertices after primitive assembly and passes them to the fragment
   shader, where we can use them to compute distance to edges in
   triangles.
 */

varying in vec3 NormalVP[3];
varying out vec3 eyePos;
varying out vec3 Normal;
varying out vec4 gl_TexCoord[3];

void main(void)
{
        // The following loop seems to be the culprit
    for (int k=0; k<3; k++) {
        // Texcoords 0-2 are the positions of the three vertices.
        gl_TexCoord[k] = gl_TexCoordIn[k][0];
    }

    for (int i=0; i<gl_VerticesIn; ++i) {
        // Don't change the position
        gl_Position = gl_PositionIn[i];

        // Eyepos is the eyespace coord of the point, so
        // we just emit the eyespace coord for each point and let
        // the interpolator do its job
        eyePos = vec3(gl_TexCoordIn[i][0]);
        Normal = NormalVP[i];
       
        EmitVertex();
    }
    EndPrimitive();
}

I get a crash inside glDrawElements. However, if I unroll the first loop, as follows:

void main(void)
{
    gl_TexCoord[0] = gl_TexCoordIn[0][0];
    gl_TexCoord[1] = gl_TexCoordIn[1][0];
    gl_TexCoord[2] = gl_TexCoordIn[2][0];

    ...
}

then I get no crashes and the program works fine. I get no GLSL compiler errors or GL errors on any of the versions, and if I just disable the shaders, I get no crashes. The setup for my pipeline is:

- setup 4 RGBA 32 bit render + 32bit depth targets into an FBO,
- render regular scene using deferred shading,
- final FP-only pass to shade with a screen-size quad.

Is this a bug? What I am doing wrong? I tried simple fixes like: making both loops share the "i" variable; making loops use different variables; making the first loop check on gl_VerticesIn instead of 3, which should be equal since I'm setting the geometry program's input type to be triangles. I'm also setting the maximum vertex output  count to be 3, and the output type to be triangle strips.

The entire C++ program is a little too big for me to post directly, but the shaders are simple enough that I'm attaching them here. The triple deferred.{vp,gp,fp} are the shaders active while I render the triangle mesh, while final_pass.fp does the final shading. The crash happens with the deferred.* programs active, but I'm including all of them for completeness.

For whatever's worth, if I type these programs into OpenGL Shader Builder 2.0, the version that doesn't crash GL works fine (I get some rendering close to what I expect), but the version that crashes my program sometimes also crashes OpenGL Shader Builder. Sometimes it doesn't, and sometimes it seems to just not work, with OpenGL Shader Builder reporting that the Vertex processing is falling back into software mode (fragment processing doesn't change)

Incidentally, 1) the OSX compiler for GLSL seems a lot more picky than the one in AMD64 Linux NVIDIA drivers - I had to rewrite a fair amount of the code changing things like initializer syntax and constant conversions. Is that expected? and 2) Are there tools to check the assembly output of the various programs on the mac?

Thank you very much,
-carlos

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden

This email sent to email@hidden