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
}
void main(void)
{
calculate();
}
Apparently the points
Thanks,
Fred
Radeon Mobility HD5470
Catalyst 10.8
Windows 7 x64
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.
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?
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).
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
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
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.
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.