Too Slow -> glCopyPixels, glCopyTexSubImage2D

[AGL_Music]

Setup:
Windows Vista (Installing XP shortly)
Intel GMA-X3100

I'm designing an interface in OpenGL, and it requires drawing to a large texture regularly (the size of the window, to be exact). As a side note, the interface is meant to run on fairly low quality Laptop GPU's...so no Intel bashing.

Unfortunately, the performance of the two functions in the Subject of the post are terrible. After a bit of googling, I found a few hints that perhaps Intel GFX has bad CopyPixel performance for no apparent reason.

I've set the program up to only use those functions when absolutely nessessary, which makes me feel like I'm coding around Intel GFX, which is annoying, and I'm sacrificing CPU time for this workaround.

To clarify, using glCopyTexSubImage2D on an entire window that's 800x600 drops the framerate to about 5 fps, from 30. Drawing the resultant texture back on to the screen incurs no performance drop whatsoever.

Two Questions:
1. Is this normal for most graphics cards, or just Intel?
2. Is it in any way related to Windows?

Any other info helps as well,
Thanks.

[Stephen A]

Abnormally slow CopyPixels smells like a driver issue to me. Different drivers may perform differently, even from the same vendor. You cannot really know what the result will be unless you test.

To answer your questions:

1. 30->5 fps doesn't feel normal - I don't think this can be accounted for by bandwidth limitations. There are sporadic reports of slow CopyPixels on AMD and Nvidia, but nothing this severe.

2. This is unlikely to be an OS issue. However, different OSs use different drivers and may perform differently. (For example, Intel generally has better OpenGL support on Linux and Mac OS X than on Windows).

Not very helpful, I'm afraid, but there's too little information to go with here. If you could provide a small test case, I can measure performance on Nvidia and Ati cards for you.

One suggestion: try to disable the compositor (Aero) and see if performance improves. Rather unlikely, but you never know with Intel.

[ZbuffeR]

Yes normally glCopyTexSubImage2D is very fast, but I never owned an Intel card.

Maybe you hit a software emulation path.
You may try to play with the different parameters for format and internalFormat when creating the texture which receives the Copy : GL_RGB8 versus GL_RGBA8, GL_RGBA versus GL_BGRA, this sort of things.

Do you need mipmaps ? Do you have automatic mipmap generation ? Maybe switching it off can help.

[AGL_Music]

You're right 30 -> 5 doesn't seem normal. The interface is limited to 30 fps, and never really goes below that, even on intel. I found that the reason there was such a huge drop was because calling glCopyTexSubImage2D @ 30 FPS causes a spike of about 30% of my CPU. Now that I've optimized a good deal, the CPU doesn't max out and the framerate holds.

So, at that much of a spike, I'm guessing that it is a software emulation problem, and that perhaps my workaround is saving CPU cycles instead of wasting them..

I'll keep messing around with texture modes, but I'm not too hopeful. No mipmaps or anything, it's just a way of blitting a rectangle to and from the screen, no tranformations.

I know I shouldn't ask this, but is there such thing as a reference in regards to software/hardware emulation/support, which lists OpenGL functions and their relation to various chipsets? Or drivers, I suppose. That's laughable, isn't it..

Basically, what tricks help in finding the accelerated alternative?

No hope for new drivers either, my chipset is quite outdated already.

Thanks. Oh, and Aero was already off in the first place. I'll have to test with it back on, perhaps.

[Alfonse Reinheart]

Basically, what tricks help in finding the accelerated alternative?

I think you're on your own, I'm afraid. I'd guess that most people who tried getting OpenGL to work on Intel chipsets gave up on it before they could tell anyone their tricks.

[AGL_Music]

:)