PDA

View Full Version : Bug(s) in NVIDIA GLSL ShaderCompiler



ScottManDeath
05-31-2005, 12:48 PM
I'm doing GPGPU (using GLSL, FBO, ARB_texture_rectangle and NV_float_buffer) stuff for my thesis at the moment and made some unpleasant experiences.

I use a GeForce FX 5600 Go and a GeForce 6800 GT as my dev / test machines.

I think I found two bugs:

1.

gl_TexCoord[0] = gl_MultiTexCoord0.xyxy + vec4(-0.5,-0.5,0.5,0.5);should be equivalent to?


gl_TexCoord[0].x = gl_MultiTexCoord0.x - 0.5;
gl_TexCoord[0].y = gl_MultiTexCoord0.y - 0.5;
gl_TexCoord[0].z = gl_MultiTexCoord0.x + 0.5;
gl_TexCoord[0].w = gl_MultiTexCoord0.y + 0.5;But after comparing the compiled shader assembler code (using nvemulate) of both snippets, the output interpolants were initialized differently from the constant register.

So I sticked with snippet 2

2.
Using the GeForce FX 5600 Go, my algorithms run with the same results as my CPU reference implementation.
Then I switched to the GeForce 6800 GT and got shocked that the results differed!
So I took nvemulate and disabled the NV4X GLSL features... and it run as it should have run. So I think that the GLSL output for the NV4X profiles has some bug.

As I have my deadline nearing quite fast, I don't have the time to locate the bugs more ecactly, so I'm using the workarounds instead.
But I would be willing to provide a test app.

execom_rt
06-01-2005, 03:05 AM
Cg convert your code in that way (using ARB output) :

PARAM c[5] = { program.local[0..3],
{ -0.5, 0.5 } };
ADD result.texcoord[0], vertex.texcoord[0].xyxy, c[4].xxyy;

So, there is no bug ?

Using VP20 target :

#const c[4] = -0.5 -0.5 0.5 0.5
ADD o[TEX0], v[8].xyxy, c[4];

Still OK ?

ScottManDeath
06-02-2005, 09:28 AM
One of the NVDIA engineers contacted me. I sent a demo and he confirmed both of my findings.
Both bugs got fixed in one of their internal driver releases.