Bug(s) in NVIDIA GLSL ShaderCompiler

OpenGL
1

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.

2

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 ?

3

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.

4

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