Bug(s) in NVIDIA GLSL ShaderCompiler

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:

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

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.

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 ?

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.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.