We are experiencing an issue with this function: glCopyTexImage2D
We make a square viewport and draw some figures, than read the square inside a previously created texture. Setting the viewport/texture size to 32 or 64 or 128 or 256 or 512 everything goes fine but when we use a viewport/texture size of 1024 only the lower left quarter of the texture is painted (the rest is full of stretched hor & ver lines that start where the painting is interrupted).
Are you using this in combination with a framebuffer object? If you’re drawing straight to system provided framebuffer it’s possible that the pixel ownership test fails for some pixels.
When texture size is smaller than your application window, then you can copy from screen to texture, but when you need bigger texture, then you have no choice, but to make an offscreen render buffer.
That would be FBO, but in this case you will no longer need glCopyTexImage2D, because with FBO you can render directly to texture.
Using glCopyTexImage2D only makes sense as a fallback, when platform does not support FBO (lot’s of hardware support it, as long as drivers are relatively new).
Some performance hints:
-when changing viewport use scissor test, too
-use glCopyTesSubImage2D instead of glCopyTexImage2D
Just remember about scissor test if you only need part of the texture area.
For example, if you need 640x480, then you can use:
-640x480 texture rectangle
-640x480 texture (non-power-of-two)
-1024x512 texture
Which one you choose depends on hardware you design your application for.
Using 640x480 pixels of 1024x514 texture means you use less than 60% of actual texture area. Everything, even glClear, will be a lot faster if you enable scissor test.
This is a bit off topic, so excuse me, but I’ve read that using glScissor/glViewport often can hurt SLI performance. Is it safe to say that nobody really develops specifically for SLI? I can’t imagine having to avoid glViewport when rendering to an FBO…
That’s what happens when you use SLI using an API meant for a single GPU and assumes everything will be done sequentially In particular, having a single set of states for more than one GPU definitely will slow down, because whenever there’s a state change, GPUs may need to wait. It really depends how it’s implemented internally, because normally the delay happens because the driver wants to change the states of all GPUs at once. If you add it the capability of change states when working GPUs end their job, probably it’ll work faster.
But, not like it’s as easy to do. There’re timing issues and such, and must be implemented in such a way that is backwards compatible with non-SLI and without imposing any extra limitations, which is the main cause of slow downs.
The Nvidia recommendation which talks about glScissor and glViewport in relation with SLI explicitly mentions that they should be not used to render into part of the render target. If you always set them to match entire area of the render target, they are likely to be safe.
In particular, having a single set of states for more than one GPU definitely will slow down, because whenever there’s a state change, GPUs may need to wait. It really depends how it’s implemented internally, because normally the delay happens because the driver wants to change the states of all GPUs at once. If you add it the capability of change states when working GPUs end their job, probably it’ll work faster.