NV: Data read from RGBA8_snorm texture is clamped to [0.00392157,1]

[Xonar]

Symptoms:

Causes "ghost-light" when looking towards light direction since lighting is wrong when using normals that are in the negative direction (Since their clamped to 0.00392157)

Analysis:

When reading the RGBA8_snorm texture as floating point value (Through shader or glReadBuffer and glReadPixels. The value is in the range [0.00392157,1] instead of the supposed [-1, 1].

When reading the data as char's (To get byte data) with glReadPixels the values is in the range {-127, ..., 126, 127}, which should be {-128, ... ,126, 127] at it's limits according to the specification. Even though the data is in the {-127, ..., -1, 0} range it doesn't get matched to the correct range in [-1,0]. All values bellow 1 are taken as 0.00392157.

(clamping is disabled for glReadPixels)

If you query the texture type it causes a segfault. O.o This only happens when using the Nvidia proprietary driver with SNORM textures, other texture types and other drivers work fine. There are no warning or error given by the Nvidia driver beforehand and the FBO reports that it's complete. So I am now almost certain that this is a fault with the Nvida driver and not with my program.

More Info:

This is specific to Nvidia as far as I can tell. I have only my laptop to test on, but with the 331.* and 340.* drivers on both Linux and Windows this occurs. On both Windows and Linux the onboard HD4000 works as expected.

I haven't tested it on a Ati Card yet, but I suspect it will work correctly the Intel Onboard.

Confirmed with GTX675MX.

This issue has been with me since the end of January, I'm going to start working around it since I'm not making any progress in this front.

[Xonar]

After staring at the opengl specification for a while, I noticed that it is not a requirement for SNORM textures to be renderable, but if that is the case then the nvidia driver should not not return success on creating the fbo. MESA allows this. I'll still haven't run any tests on amd drivers.