I thought glCopyPixels was a fast way to copy the contents of the current read buffer to the current draw buffer at the current raster position.

For some reason I am getting way better performance with glDrawPixels, with an image in host memory, than I am from glCopyPixels, where the from and to are both in AGP mem. That is completely the opposite of what I expected.

A quick review of the docs says that glCopyPixels is changing each pixel color component to float during the transfer, which I'm guessing is the cause the slow down.

Is there any way to turn off this conversion to float and just make a fast pixel copy (BLiT) from/to the same buffer in the same format?

I noticed the pbuffer extension spec conformance test lists a step as "Blit from one buffer to the other" so I'm hoping this blit-like copy exists and I'm just missing something obvious.

Thanks.

[This message has been edited by robosport (edited 03-03-2004).]

Relic

03-03-2004, 03:04 AM

CopyPixels is fast if there's no bias, scaling, depth buffering, or something which is not a 1-to-1 copy, that is, if it's a simple color blit.
There won't be a conversion to float for such case, that'd be silly.

>>where the from and to are both in AGP mem.<<

http://www.opengl.org/discussion_boards/ubb/confused.gif _and_ is impossible. At least one buffer lies in video memory. Using glDrawPixels, the destination, using glReadPixels the source, using glCopyPixels both.

Ysaneya

03-03-2004, 03:16 AM

I think you'd have a better luck creating a temp. texture, doing a glCopyTexSubImage2D, and then creating a 2D quad with this sub texture where you want to display it.

Y.

Relic

03-03-2004, 04:45 AM

I don't think so.
A simple 1-to-1 glCopyPixels from back to front for example should be faster than a glCopyTexSubImage from back and glBegin(GL_QUADS);... to front.

Ysaneya

03-03-2004, 07:10 AM

In theory it should be faster, but as i don't think it's a code path frequently used by developers, it might not be super optimized by some drivers. To be safe you should test both.

Interesting. Is that pure copyteximage performance or was the texture actually used afterwards?
If not, what remains at the end if the texture is used to draw the exact same rectangle the copypixels blitted?

Adrian

03-03-2004, 08:42 AM

Originally posted by Relic:
Interesting. Is that pure copyteximage performance or was the texture actually used afterwards?
If not, what remains at the end if the texture is used to draw the exact same rectangle the copypixels blitted?

It's pure copyteximage performance.

robosport

03-03-2004, 12:51 PM

Thanks for the quick replies. That glCopyPixels benchmark is exactly the kind of performance I was expecting (and have seen in the past) from glCopyPixels.

Unfortunately on my Quadro4, with one of the latest drivers, it is really slow (multiple times slower than glDrawPixels).

Am I using glCopyPixels incorrectly? Here is the code for a back buffer to back buffer blit:

Running NVidias readpixels benchmark with FSAA initially showed normal performance. I compared their benchmark and mine and the only difference was that they run in windowed mode. When I Added glutFullScreen() and switched on FSAA the performance was as slow as with my benchmark.

[This message has been edited by Adrian (edited 03-04-2004).]

robosport

03-04-2004, 10:12 AM

Clarification... this isn't just slowing down when FSAA is turned on via driver settings.

This glCopyPixels slow down happens when the context is pragmatically using multisampled antialias as well. i.e. WGL_SAMPLE_BUFFERS_ARB with GL_MULTISAMPLE_ARB enabled.