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

Newegg Daily Deals

Reply
 
Thread Tools
Old 05-06-03, 06:26 AM   #1
andek
Registered User
 
Join Date: May 2003
Posts: 4
Unhappy glPixelTransfer, color matrices and glCopyPixels slooow....

Hi!

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.

Regards,
Andreas Ekstrand
Systems Engineer
Saab Aerospace, Linkoping, Sweden
andek is offline   Reply With Quote
Old 05-06-03, 07:18 AM   #2
leo3000
NoWar
 
Join Date: Apr 2003
Posts: 5
Default

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

-----------------------------
glDrawBuffer( GL_FRONT);
glReadBuffer( GL_FRONT);
...
glCopyPixels(...);
-----------------------------

is much slower than

-----------------------------
glDrawBuffer( GL_FRONT);
glReadBuffer( GL_BACK);
...
glCopyPixels(...);
-----------------------------

L.

(*)
OpenGL renderer string: GeForce4 Ti 4600/AGP/SSE2
OpenGL version string: 1.4.0 NVIDIA 41.91
__________________
Leo3000
leo3000 is offline   Reply With Quote
Old 05-06-03, 07:37 AM   #3
andek
Registered User
 
Join Date: May 2003
Posts: 4
Default

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.

/Andreas
andek is offline   Reply With Quote
Old 05-08-03, 12:55 PM   #4
leo3000
NoWar
 
Join Date: Apr 2003
Posts: 5
Default

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...)


Leonardo
__________________
Leo3000
leo3000 is offline   Reply With Quote
Old 05-08-03, 01:26 PM   #5
leo3000
NoWar
 
Join Date: Apr 2003
Posts: 5
Default

Quote:
Originally posted by leo3000
Hi again,

cut

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

cut

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

L.
__________________
Leo3000
leo3000 is offline   Reply With Quote
Old 05-09-03, 01:23 AM   #6
rohitntu
Registered User
 
Join Date: Jan 2003
Posts: 5
Default

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.
rohitntu is offline   Reply With Quote
Old 05-09-03, 01:59 AM   #7
andek
Registered User
 
Join Date: May 2003
Posts: 4
Default

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 is offline   Reply With Quote
Old 05-12-03, 03:08 AM   #8
andek
Registered User
 
Join Date: May 2003
Posts: 4
Angry

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...

/Andreas
andek is offline   Reply With Quote

Old 05-12-03, 11:04 PM   #9
rohitntu
Registered User
 
Join Date: Jan 2003
Posts: 5
Default

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.

Thanks!
rohitntu is offline   Reply With Quote
Old 05-18-03, 11:14 PM   #10
rohitntu
Registered User
 
Join Date: Jan 2003
Posts: 5
Default

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

Is anybody from NVIDIA reading these forums?????
rohitntu is offline   Reply With Quote
Old 05-23-03, 09:28 AM   #11
leo3000
NoWar
 
Join Date: Apr 2003
Posts: 5
Default

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 :-)


Leo

(back to the boring report now...)
__________________
Leo3000
leo3000 is offline   Reply With Quote
Old 06-02-03, 12:27 AM   #12
rohitntu
Registered User
 
Join Date: Jan 2003
Posts: 5
Default

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.
rohitntu 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 08:17 PM.


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