cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

fred_em
Journeyman III

Local variable vec4[256] driving my shader crazy?

Hi,

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 = px;
}

void main(void)
{
  calculate();
}

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

Thanks,
Fred

Radeon Mobility HD5470
Catalyst 10.8
Windows 7 x64

0 Likes
7 Replies
nou
Exemplar

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.

0 Likes

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?

 

0 Likes

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).

0 Likes
frali
Staff

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?
Thanks
Frank

0 Likes

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);
else
  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.

Fred

 

 

 

0 Likes

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.

 

0 Likes

We are happy that the problem is resolved. For the random crash in the geometry shader, you could send it to me if you could reproduce it stably. My email address is frank.li@amd.com.

0 Likes