🔒 Locked

Performance of glCopyTexImage2D

Started by Woltan Jan 17, 2007 at 12:57 PM 6 replies 5.4k views

Original Post

Jan 17, 2007 at 12:57 PM

Hey folks, I know I could have tested it myself, but since I am extremly busy at work I need your quick guidance. I want to use the glCopyTexImage2D function to render four 256x256 Textures and display them as a texture on a mesh. My question is, how much the performance of the system is suffering if I do that (the texture needs to be rendered and displayed with about 30Hz). Thx in advance for any advice, link or help and i appologise for my lazyness ; ) and my english as well ; )) cherio Woltan

Eitsch

Jan 17, 2007 at 3:25 PM

1) you could use fbo which may be faster
2) if not - glCopyTexSubImage2D will help either because in this case you dont have to rebuild the texture every frame

glCopy.. will suffer performance because of:

- glCopyTexImage or glCopyTexSubImage will have to stall rendering pipe - wait until all commands are finished/everything is rastered and so on. (so it will cause an implicit glFlush)
- the framebuffer -> texture copy will eat bandwith too

so fbo is definitly the way to go.

OrangyTang

Jan 17, 2007 at 3:37 PM

glCopyTex(Sub)Image2D can be surprisingly fast - as long as you don't go to huge texture sizes (1024 and up) you can get good framerates. I'ved used it for 640x480 fullscreen effects and hit 60fps easily. FBOs would be best, but you can always add that in later and use the copy method as a fallback.

Vexator

Jan 18, 2007 at 5:33 AM

i was using fbo for my project but even switched back to glcopytex(sub)image2d - performance is absolutly the same on my ati card and the stencil buffer is supported :)

MARS_999

Jan 18, 2007 at 1:43 PM

Honestly I don't see any performance difference either with FBO vs. glCopyTexImage either. But I have the ability to go larger than the screen size with FBOs.

zedzeek

Jan 18, 2007 at 2:05 PM

yes its a common misconception which ive said a few times here
FBOs arent magically quicker (+ in fact can be slower than a copy)
the benifits of FBOs are being not restricted to the screens format (size/color/ or getting covered up etc) + not speed

Woltan

Jan 18, 2007 at 4:06 PM

Hey guys,
I just wanted to post a quick thank you post.
Now I know that it is at least possible to use that function, without a major blow in the performance. I also have the possibillity to make the textures even smaller.
Well, thanks so far!!
I might come back to you when i encounter the problems of implimentation!

Cherio Woltan

Foobar of Integers

Jan 19, 2007 at 9:21 PM

Even for larger textures, it seems to work pretty quick. I had a 1024x768 RTT and it didn't seem to drop the framerate at all (though that was on a 7800GT...), and my friend tried the same program on his GeForce FX 5-something and it ran perfectly smooth. That was also with a pretty intensive shader running.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.