nV News Forums


nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   glPixelTransfer, color matrices and glCopyPixels slooow.... (http://www.nvnews.net/vbulletin/showthread.php?t=11337)

andek 05-06-03 06:26 AM

glPixelTransfer, color matrices and glCopyPixels slooow....

We are porting our visualization software for flight simulators from IRIX to Linux. So far, NVIDIA's Quadro cards really produce astonishing results.

Now we have bumped into a real show-stopper though. Our sensor (IR) view is accomplished using a color matrix and glCopyPixels to apply a scale and a bias. As soon as we apply a color matrix or try to accomplish the same results with glPixelTransfer, the glCopyPixels call takes about 1,5 seconds! The same call on an SGI Octane2 takes about 1000 times (!) less time. I guess this can only mean that color convolution with this technique is not hardware accelerated by the Quadro card?

Is this really the case, and is there any other accelerated way of accomplishing the same results?

This matter has high priority since many of our costumers are looking for a cheaper alternative to the expensive SGI machines and a PC with a Quadro card running Linux would be a competative alternative.

Andreas Ekstrand
Systems Engineer
Saab Aerospace, Linkoping, Sweden

leo3000 05-06-03 07:18 AM

Are you using the same buffer to glCopyPixels?
On my GeForce4 (*) the following code :

glDrawBuffer( GL_FRONT);
glReadBuffer( GL_FRONT);

is much slower than

glDrawBuffer( GL_FRONT);
glReadBuffer( GL_BACK);


OpenGL renderer string: GeForce4 Ti 4600/AGP/SSE2
OpenGL version string: 1.4.0 NVIDIA 41.91

andek 05-06-03 07:37 AM

It doesn't matter if I use the same buffer or not, I'm afraid. Still the same bad performance...

For a 1280x1024 sized window, each glCopyPixels takes about 1.5 seconds if I use e.g. glPixelTransferf(GL_RED_SCALE, 0.0f) before calling it.


leo3000 05-08-03 12:55 PM

Hi again,

I'm making some simple tests with glCopyPixels:
copying to a NON-overlapping destination is WAY faster (but I'm not copying big areas as yours...)


leo3000 05-08-03 01:26 PM


Originally posted by leo3000
Hi again,


***but I'm not copying big areas as yours...***)


you did not say the size of the processed areas actually. I meant that I'm trying on 256x256 and 128x128 blocks only....


rohitntu 05-09-03 01:23 AM

I also see extremely poor performance with glCopyPixels when copying from GL_BACK to GL_FRONT, especially when I apply a zoom of anything other than 1. This is on my Quadro 580 XGL. Sizes are of the magnitude of 256x256 or so. I don't if Quadro 980 XGL will make it any faster.

I see a really really slow response, 2-3 seconds if I use a transformation matrix. Something is surely wrong.

These are definitely too slow. Our application works way better on IRIX with V6/V12 graphics.

andek 05-09-03 01:59 AM

Yes, it seems that whatever transformation (pixel transfer, zooming, color matrix, ...) you apply before glCopyPixels, the performance is really bad.

This suggests that these kinds of transformations are not hardware accelerated on the Quadro chip. However, an SGI Octane2 is supposed to use pretty much the same graphics hardware. But as I mentioned, the Octane2 presents much better performance.

Perhaps it's a driver issue? Maybe the Linux driver doesn't know about these transformations being accelerated and relies on a software implementation? Just a thought...

Has anyone tried this in Windows?

andek 05-12-03 03:08 AM

FYI, I tried it in Windows and it resulted in the same bad performance. So if it's a driver problem, it's not only the Linux driver that's causing it.

I have sent a mail about this to NVIDIA a couple of days ago, but I have not recieved any answer yet. Not good...


rohitntu 05-12-03 11:04 PM

Can somebody from NVIDIA please look into this? This is a very high priority issue for us. It is pretty much crippling the performance of our app.


rohitntu 05-18-03 11:14 PM

So we purchased a 980 XGL, and turns out that glCopyPixels is equally slow.

Is anybody from NVIDIA reading these forums?????

leo3000 05-23-03 09:28 AM

Hi again....
I havent been looking into this issue recently BUT
maybe there is some concurrency broken i.e.
this kind of operation breaks parallelism somewhere
somehow.... just a random thought ....

NV engineers give us the hw layout please :-)


(back to the boring report now...)

rohitntu 06-02-03 12:27 AM

Even the Quadro FX 2000 has the same problem. We tried the ATI FireGL X1 256 and this works great both for matrix transformations, and glCopyPixels performance.

Time to switch back to ATI, and let NVIDIA do some catching up meanwhile.

Support from NVIDIA has been very poor regarding this.

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

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