Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 10-09-08, 03:56 PM   #1
kwvtk
Registered User
 
Join Date: Oct 2008
Posts: 17
Default Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels

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
Attached Files
File Type: bz2 bug_nvidia_texsubcopy_not_starting_from_fb_origin.tar.bz2 (66.1 KB, 120 views)
kwvtk is offline   Reply With Quote
Old 10-13-08, 04:59 PM   #2
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default 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.
AaronP is offline   Reply With Quote
Old 10-13-08, 09:06 PM   #3
kwvtk
Registered User
 
Join Date: Oct 2008
Posts: 17
Default Re: Bug in 177.80 with glCopyTexSubImage2D, glGetTexImage, glReadPixels

Quote:
Originally Posted by AaronP View Post
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 View Post
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.
kwvtk is offline   Reply With Quote
Old 01-06-09, 04:44 PM   #4
Plagman
NVIDIA Corporation
 
Plagman's Avatar
 
Join Date: Sep 2007
Posts: 254
Default 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?
Plagman is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 05:43 PM.


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