nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels (http://www.nvnews.net/vbulletin/showthread.php?t=120860)

kwvtk 10-09-08 03:56 PM

Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels
 
1 Attachment(s)
Hello,

The test provided (requires glew and glut) shows that there is bug in the way
the colorbuffer or depth buffer are passed to a texture with
glCopyTexSubImage2D or to client memory with glReadPixels. It fails with
a nVidia Quadro FX 3600M (177.80).

The first line of the comment in the source code shows how to compile it.

This test passes on a nVidia GeForce 6800 (169.12).

Everything happens in draw().


[DESCRIPTION OF THE TEST]
The test first clears the color buffer with a red color. This is the back
buffer because the window is initialized with double buffer.

It copies a subpart of it into a 2D texture. I made the size odd intentionally.

It copies the the same subpart of the back color buffer to client memory
with glReadPixels(). But sometimes (which make me thing there is some
uninitialized values in the driver side), not all the rgb values are equal to
(255,0,0).

The texture is then also copied to client memory. Same thing, not all the rgb
values are equal to (255,0,0).


Then the back buffer is cleared again but with a blue color. This time
instead of copying a part the framebuffer starting at (0,0), the subpart starts
at (10,10) for the texture. The ReadPixel sill copies from (0,0).

Checking the values dumped to client memory shows that some values are not blue.


The code is then done on depth buffer. First by clearing at 1.0 and then by
clearing at 0.5. Some values dumped to client memory mismatch (some of them are
0.0).


[CONFIGURATION]

The machine with the Quadro FX 3600M is a laptop (nvidia-bug-report.log attached):

Dell Precision M6300
CPU: Intel Core Duo 2 T9500
RAM: 4GB
nVidia Quadro FX 3600M (512MB)
The OS is GNU/Linux Debian x86_64 "testing".
The driver is 177.80 installed manually :
# /etc/init.d/gdm stop
# export CC=/usr/bin/gcc-4.1
# sh ./NVIDIA-Linux-x86_64-177.80-pkg2.run
# ...

The machine with the GeForce 6800 is a desktop:

Dell Dimension 8400
CPU: Intel Pentium 4 630 HT (3Ghz)
RAM: 2GB
nVidia GeForce 6800 256MB
The OS is GNU/Linux Ubuntu x86 8.04LTS
The driver is 169.12 (package provided by Ubuntu)


Regards.


--
François Bertel, PhD | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
| Clifton Park NY 12065, USA

AaronP 10-13-08 04:59 PM

Re: Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels
 
Thanks for reporting this. I reproduced the depth portion of the problem and filed a bug. However, I'm not seeing the color values read incorrectly. Can you clarify exactly what you mean by "sometimes"? Note that if the unified back buffer is enabled, your application cannot draw to pixels in the back buffer (or the depth buffer) that are covered by another window.

kwvtk 10-13-08 09:06 PM

Re: Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels
 
Quote:

Originally Posted by AaronP (Post 1807721)
Thanks for reporting this. I reproduced the depth portion of the problem and filed a bug. However, I'm not seeing the color values read incorrectly. Can you clarify exactly what you mean by "sometimes"?

Forget about the color values: the only way I can reproduce it right now is when I move part of the window a little bit off the screen. In this case, it makes perfect sense to have some "undefined" values because of the pixel ownership test.

Note that since I reported the bug, some xorg package has been updated on my debian (then I reinstalled the nvidia driver as usual because the xorg package erases the symlink on glx).
At the time I reported the bug I didn't pay attention if it was only happening in this little-bit-off-the-screen case, but there is a good chance it was the only case.

Quote:

Originally Posted by AaronP (Post 1807721)
Note that if the unified back buffer is enabled, your application cannot draw to pixels in the back buffer (or the depth buffer) that are covered by another window.

Thanks for the unified back buffer (UBB) note, I was aware of this pixel ownership issue. However, in the nvidia-bug-report.log I sent, I found:
Code:

(WW) NVIDIA(0): UBB is incompatible with the Composite extension.  Disabling
(WW) NVIDIA(0):    UBB.

So, I guess I'm not falling in this case anyway. In addition, when I run the test, its window pops up on the top.

Plagman 01-06-09 04:44 PM

Re: Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels
 
I looked into the depth reads problem you reported and on my end, the resulting value is actually 0.50000005960464477539, not 0.0 as you reported (your test case wrongly casts the floating point value to integer before printing the comparison mismatch, so I'm assuming that mislead you). 0.50000005960464477539 being the correct result from packing 0.5f into a 24-bit fixed-point depth buffer, I don't think this qualifies as a bug. Did you notice any problems other than those depth readbacks and occluded color readbacks?


All times are GMT -5. The time now is 10:33 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.