nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   About bug #284530 (http://www.nvnews.net/vbulletin/showthread.php?t=87832)

javiersr 03-09-07 04:20 AM

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.

netllama 03-09-07 12:38 PM

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.

bpepers 03-09-07 02:36 PM

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?

netllama 03-09-07 02:39 PM

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

javiersr 03-12-07 05:56 AM

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.

AaronP 03-12-07 11:51 AM

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.

javiersr 03-12-07 01:25 PM

Re: About bug #284530
 
1 Attachment(s)
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.

AaronP 03-14-07 06:30 PM

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.

javiersr 03-15-07 10:28 AM

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.


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

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