Texture upload speed

Hi,

I have a little prototype Jogl application. Basically it creates a image in a 512x512xrgba byte[] (once), creates an opengl texture (once) and uploads this texture + renders it to a simple rectangle all the time (uploading all the time is for testing purposes only; later the texture changes and needs to be uploaded all the time). Uploading the texture gets done via:
gl.glTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGBA, 512, 512, 0, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, tex);

Without uploading the texture, I get around 700fps. When I enable the glTexImage2D call, I get around 60fps on a G4 1,25Ghz with ATI Mobility Radeon 9600 running Mac OS X 10.3. This is 60512512*4 = 60 Mb/s texture upload speed. I have no clue about how fast this should be; but somehow I think with AGP8 it should be faster. Do I miss something?

Thanks for your help!
Regards,
Ralf Ebert

I dunno what speed you should be getting but if you’re at all worried about performance then you shouldn’t be using byte[] arrays (or any kind of built-in arrays) to pass to OpenGL. A large amount of time is probably being wasted just repackaging your data.

Stick your image data in a (direct) ByteBuffer and you’ll probably notice a decent improvement.

Thanks, using a direct ByteBuffer in my example helps doubling the speed. But I’m still not sure that this works as fast as it’s supposed to be… What for is AGP/8 with almost 2gb/s bus speed when I can only reach 120mb/s? Does ByteBuffer suppress all copying of the image data or is there still something else which could be worked around maybe with a native extension? Or is this maybe a problem with Mac OS X (with Quartz Extreme using textures as well) or with jogl (and this opengl on an awt window)?
btw, the 60 / now 120fps I already reached only by using the GL_UNPACK_CLIENT_STORAGE_APPLE / GL_TEXTURE_PRIORITY tweaks…

Try glTexSubImage2D instead of just using glTexImage2D?

This is not quite how AGP RAM works. Just allocating an image with a direct byte buffer is going to give you system RAM, not AGP RAM. Every time you call glTexImage2D (and you shouldn’t by the way - glTexSubImage2D is what you want after you’ve allocated the original space with glTexImage2D) it’ll have to copy all that image data to the AGP staging area first and then copy it up to the card’s texture RAM. Unless it’s one of those horrible shared memory chipsets in which case it isn’t copied up to the card’s texture RAM.

Cas :slight_smile:

Thanks princec, but is there any alternative to creating the texture in main memory and uploading it with glTexImage2D? I mean, currently I’m quite happy with the speed of my application and it doesn’t feel slow at all, just trying to get sure that I didn’t miss any major optimization possibility :slight_smile:
btw, glTexImage2D works considerably faster for me (with 2d textures and with rectangular textures as well) than glTexSubImage2D and I couldn’t find a drawback with using glTexImage2D all the time…

Regards,
Ralf