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

Newegg Daily Deals

Reply
 
Thread Tools
Old 03-09-07, 04:20 AM   #1
javiersr
Registered User
 
Join Date: Nov 2005
Posts: 14
Default About bug #284530

Some time ago I reported a bug and I noticed that you didn't fix it in the new release. It seems that something has changed (writes are faster than before, although tiled writings are overwhelmingly slow yet), but the bug seems to be still there.

What I'd really appreciate is an URL where I can track the status of this bug, because I depend on it to run some tests on the 8800GTX (so I cannot use 8xxx drivers) and you don't seem to be publishing a bug status report with your releases. I've been searching for some kind of public bug tracker of yours but I didn't find it. It is frustrating not to know if someone is working on your problem and how it is evolving.

Thank you.
javiersr is offline   Reply With Quote
Old 03-09-07, 12:38 PM   #2
netllama
NVIDIA Corporation
 
Join Date: Dec 2004
Posts: 8,763
Default Re: About bug #284530

I regret that out bugs are not publicly accessible. This bug remains assigned to development. However, the latest comment in the bug is:
Possible app workaround: instead of using the pixel path to do TexSubImage, use the pixel path to do DrawPixels.
netllama is offline   Reply With Quote
Old 03-09-07, 02:36 PM   #3
bpepers
Registered User
 
Join Date: Feb 2007
Posts: 15
Default Re: About bug #284530

Quote:
Originally Posted by netllama
I regret that out bugs are not publicly accessible. This bug remains assigned to development. However, the latest comment in the bug is:
Possible app workaround: instead of using the pixel path to do TexSubImage, use the pixel path to do DrawPixels.
Its too bad that we can't see them or at least have a more detailed change log when a new release comes out. I wasted a 1/2 hour or so to download and install the latest 9755 driver to see if it fixed my slowness with KDE and finally found out that it hadn't.

Also the comment that the applications should work around this problem is not very satisfying. I "upgraded" from a 7900GTX to an 8800GTX only to find the 8800GTX seemingly *much* slower in Linux. The original bug report showed a drastic degeneration in speed in a release and something like that should be fixed and not just passed off as something applications have to work around.

There is something really wrong here. Switching to a new desktop in KDE should not take a second or two of drawing where you can watch it fill in a chunk at a time. It also shouldn't take 90% CPU utilization to just switch between desktops. I'm not sure if this problem is even related to the bandwidth problem. It seems like more of a problem with the 8800 line of cards since I had no problems with my 7900. It looks to me like something that KDE is doing commonly to draw the screen is very slow on the 8800 compared to the 7900.

Do you know if there is a bug reported for this problem? Any news on its status?
bpepers is offline   Reply With Quote
Old 03-09-07, 02:39 PM   #4
netllama
NVIDIA Corporation
 
Join Date: Dec 2004
Posts: 8,763
Default Re: About bug #284530

You're now describing a very different issue from bug 284530. I'd suggest starting a new thread for that issue.

Thanks,
Lonni
netllama is offline   Reply With Quote
Old 03-12-07, 05:56 AM   #5
javiersr
Registered User
 
Join Date: Nov 2005
Posts: 14
Default Re: About bug #284530

Quote:
Originally Posted by netllama
I regret that out bugs are not publicly accessible. This bug remains assigned to development. However, the latest comment in the bug is:
Possible app workaround: instead of using the pixel path to do TexSubImage, use the pixel path to do DrawPixels.
I don't know if I am understanding the work-around for my problem. I change:

glTexSubImage2D( GL_TEXTURE_RECTANGLE_NV, 0, x, y, w, h, GL_RGBA, GL_FLOAT, (GLvoid*)data );

for:

glRasterPos2i( x, y );
glDrawPixels( w, h, GL_RGBA, GL_FLOAT, (GLvoid*)data );

But, for some reason, all I read back is "1". Even when I write zeros, I read back "1" (so it does't seem to be because of value clipping). Am I doing something wrong?

Thank you.
javiersr is offline   Reply With Quote
Old 03-12-07, 11:51 AM   #6
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: About bug #284530

The original problem, as I understand it, is using glTexSubImage2D with a texture that's bound to an FBO. Please attach a test case for the DrawPixels case.
AaronP is offline   Reply With Quote
Old 03-12-07, 01:25 PM   #7
javiersr
Registered User
 
Join Date: Nov 2005
Posts: 14
Default Re: About bug #284530

Quote:
Originally Posted by AaronP
The original problem, as I understand it, is using glTexSubImage2D with a texture that's bound to an FBO. Please attach a test case for the DrawPixels case.
You're right, glTexSubImage2D with FBO was working perfectly with 8xxx drivers and it stopped working properly with 9xxx.

Now, I have replaced glTexSubImage2D with glRasterPos + glDrawPixels (for writing to the FB instead of writing to the texture, although they are both the same in the end), but it does not work at all. I suppose that I didn't understand what the developer means by "instead of using the pixel path to do TexSubImage, use the pixel path to do DrawPixels", because it does not work with 9xxx nor 8xxx. Probably I'm doing something wrong, but I cannot see what.

I'm attaching the same test code than before, but with glTexSubImage2D replaced.

Thank you.
Attached Files
File Type: gz GPUTransferTest.DrawPixels.tar.gz (4.3 KB, 128 views)
javiersr is offline   Reply With Quote
Old 03-14-07, 06:30 PM   #8
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: About bug #284530

I talked to an OpenGL engineer about this and he explained that the FBO extension is not designed to be fast in the case that you modify a texture while its FBO is bound, and that binding and then unbinding the FBO around the ReadPixels loop eliminates the slowdown.

The drawpixels question still needs to be investigated.
AaronP is offline   Reply With Quote

Old 03-15-07, 10:28 AM   #9
javiersr
Registered User
 
Join Date: Nov 2005
Posts: 14
Default Re: About bug #284530

Quote:
Originally Posted by AaronP
I talked to an OpenGL engineer about this and he explained that the FBO extension is not designed to be fast in the case that you modify a texture while its FBO is bound, and that binding and then unbinding the FBO around the ReadPixels loop eliminates the slowdown.

The drawpixels question still needs to be investigated.
I tried unbinding before the transference and binding back after the transference, even I have tried to unbind the texture from the COLOR_ATTACHMENT0 before unbinding the framebuffer object, but the transferences are still extremely slow with 9xxx drivers. I don't know what else I can try

Thanks for your help!

BTW: ReadPixels is quite fast (in both driver versions), it is glTexSubImage what is very slow.
javiersr 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


Similar Threads
Thread Thread Starter Forum Replies Last Post
I got a computer bug!!! sillyeagle General Hardware 16 06-05-12 02:44 AM
GLX bug? (1.0-3123) marc NVIDIA Linux 2 09-21-02 04:58 PM
athlon agp bug?? crazyowl NVIDIA Linux 17 08-28-02 10:13 PM
Antialiasing bug in 31.00 drivers? Mark_fox NVIDIA Windows Graphics Drivers 7 08-26-02 02:48 PM
TwinView & Console bug topman NVIDIA Linux 3 08-16-02 09:32 AM

All times are GMT -5. The time now is 06:35 PM.


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