🔒 Locked

Slightly unusual performance question

Started by Nemesis2k2 Mar 4, 2007 at 4:15 AM 1 replies 1k views

Original Post

Mar 4, 2007 at 4:15 AM

I've got what is effectively a performance question, but with a bit of a twist. I've got a mathematical algorithm that is generating an image at 60 FPS, which is being rasterized and output to a buffer. Effectively, it's a texture that completely changes between each frame. The calculations involved in generating this image are quite CPU intensive. I'm wondering what the least CPU intensive method would be to render this image to the screen at full framerate using OpenGL, so as to take away as little processor time as possible from the actual generation of the images. As the image is constantly changing, using basic textures I would effectively have to destroy and re-create the texture each frame as I understand it, because the texture is copied into video memory when it is created. I need to know the most efficient method to render from a texture, which does not buffer the data in video memory between frames. My OpenGL is quite rusty, and I'm not familiar with a lot of the newer features, so I'm finding it hard to determine which method would be the most efficient, and there's no way for me to certain without trying each one. The rendering of this image is quite incidental to the purpose of my program, but right now it's a frustrating performance barrier. I would appreciate any suggestions as to what rendering method to use. Sample code would be geatly appreciated, as all my reference material is from OpenGL 1.2. Thanks.

Brother Bob

Mar 4, 2007 at 4:29 AM

If you absolutely have to avoid anything that stores the image in video memory at some point, I guess glDrawPixels is your only choise. But even then, can you guarantee that the command isn't buffered and the image stored in some intermediate buffer before actually being written to the frame buffer?

But no matter what method you pick, it has to be transferred to thed video memory at some point; either to an intermediate storage or to the frame buffer. If it's to an intermediate storage like a texture, it's still only one copy that your part of the program will see. Once it's in the texture, you're not suffering anyting for the copy from intermediate storage to the frame buffer in such a simple case like this.

Have you even tried using a texture? glTexSubImage updates texture data without recreating the texture object. Match the output format from the algorithm and the texture's internal format and the copy should be quite fast.

There are probably more efficient ways, but since I get the feeling you didn't even try textures, I think you could start with the simplest method to at least see what's happening. Using moders extensions, it really can't get any worse at least, only better.

Nemesis2k2

Mar 4, 2007 at 5:02 AM

It's not a requirement that video memory not be used, only that whatever method is used is efficient even when the source data changes each frame.

Quote:
glTexSubImage updates texture data without recreating the texture object.

Aha! Thank you, that was something I was looking for.

Quote:
There are probably more efficient ways, but since I get the feeling you didn't even try textures, I think you could start with the simplest method to at least see what's happening. Using moders extensions, it really can't get any worse at least, only better.

I tried textures, but I was having to create them, use them once, then destroy them again. It took me hours just to get that working, as I was having a fight with the API. In the end I just gave up in frustration. I decided to seek some advice this time to avoid a similar outcome.

Thanks for your advice, you've already been a big help. I'll try a few methods and see how it goes. If anyone else has any other ideas, feel free to chime in though.

Topic Locked

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