7 Replies Latest reply on Nov 2, 2010 11:20 PM by frali

    Local variable vec4[256] driving my shader crazy?



      I have the following code in my application:

      #version 120
      #extension GL_EXT_geometry_shader4 : enable

      void calculate()
        vec4[200] points;

        // [...]

        // The code below runs in a loop, which I have omitted here
        vec4 px;
        // The code runs fine with the line below
        px = vec4(pt.x / a, pt.y / b, pt.z / c, 1.0);

        // The code crashes when I attempt to write data into points[]
        // If I remove this line, there is no crash. I do stay within the bounds of the array.
        points[n] = px;

      void main(void)

      Apparently the points[n] assignment statement makes the driver crash. What is wrong with this line? Is my array too big?


      Radeon Mobility HD5470
      Catalyst 10.8
      Windows 7 x64

        • Local variable vec4[256] driving my shader crazy?

          yes 256 long array is IMHO way too long. try download GPU shader analyzer and past that shader into it. and look at GPR and Scratch Reg column.

            • Local variable vec4[256] driving my shader crazy?

              Thanks for your reply.

              I tried GPU ShaderAnalyzer but I can't get a geometry shader to compile.

              So to analyze my calculate() function I pasted the code and analyzed it as a vertex shader, instead.

              In the results I get in the Compiler Statistics window, GPR is always 0, so is the Scratch Reg column. What shall I conclude?

              I don't see how the size of a local variable can influence the execution of the shader, as long as the shader compiles correctly.

              What do you mean exactly?


                • Local variable vec4[256] driving my shader crazy?

                  if you do not assing any value to out variables then compiler will optimize out all of the code. so thats why 0 GPR.

                  slow to this big array because GPU do not have this much registers. it must then spiil to the main memory aka scratch registers. and access to the main memory is magnitude slower than registers (~10000GB/s vs ~100GB/s).

              • Local variable vec4[256] driving my shader crazy?

                This shader works fine on my side. It maybe not caused by the big array. Could you please paste the whole shader to let me have a look?

                  • Local variable vec4[256] driving my shader crazy?

                    The problem most likely doesn't come from the large vec4[] array.

                    Filling the array with vec4(0,0,0,0)'s works fine.

                    I changed the GLSL version to

                    #version 150 compatibility

                    so that I can use the isnan() function. I thought one of my values could have been NaN, making the driver crash when, for instance, a division is performed. But it does not seem to be the case (?)

                    The following code works:

                    vec4 px = vec4(pt.x, pt.y, pt.z, pt.w);

                    points[m*numPathV + n] = px;

                    The following code crashes the driver:

                    vec4 px;
                    if (isnan(pt.x) || isnan(pt.y) || isnan(pt.z) || isnan(pt.w))
                      px = vec4(0.0, 0.0, 0.0, 1.0);
                    else if (pt.w != 0.0)
                      px = vec4(pt.x / pt.w, pt.y / pt.w, pt.z / pt.w, 1.0);
                      px = vec4(0.0, 0.0, 0.0, 1.0);
                    points[m*numPathV + n] = px;

                    With the code above the compilation seems to take a long, long while.

                    I'm stuck here as to what to do now.





                      • Local variable vec4[256] driving my shader crazy?

                        I upgraded to Catalyst 10.10, then realized I had one of my uniforms not correctly initialized.

                        After the upgrade, the driver is no longer crashing. The is just not doing anything.

                        There isn't any delay now when running my application. I'm not sure whether the delay was because of the compilation or a runtime delay because the shader was coded incorrectly.

                        Update: everything now works as expected, I mean my code does.

                        Bottom line is that the new driver is working better and therefore allows me to fix bugs a lot faster than if I had kept working with Catalyst 10.8.

                        Thanks for your assistance.

                        UPDATE2: I do get occasional crashes with the new driver when running my (rather complex) geometry shader.