Speeding up glTexSubImage2D?

I have a 16bit RGB565 texture already allocated. I have pixel data in the same format, same color depth that I want to copy to the texture.
(512 x 512)

Doing this:
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, width, height, GL_RGB, GL_UNSIGNED_SHORT_5_6_5, data);

takes .08 to .1 seconds(!) just to copy a 400 x 300 pixel area.

This seems to be incredibly slow. Is there a trick I’m missing? Is a different format or a different way of doing this that is faster?


Texture uploads are usually costly. The Texture might be locked when you are trying to update it.
Since you are updating the entire texture, Have you tried generating a new texture id each time and using it, instead of updating the existing texture (and then deleting the old one)?

I havent tried this myself. Just a suggestion.

Thanks for the reply.

The texture being updated is not in use at that time through the display pipeline.

Generating a texture is even more time consuming because memory has to be deallocated and then allocated. Since it has to deal with the full size of the texture rather than a subarea for the copy it takes longer as well.

Either the chip deals with only a specific (unknown?) format efficiently or just the process of touching an unused texture causes the GPU to stall.
I’m taking a look at pixel object buffers but OpenGL ES seems to lack some of the things such as mapping.

Sorry to bring up an old topic.

First, it would be good to try what nishantkumar suggested. Even if strictly speaking the texture is not being used by the GPU at the moment you are calling TexSubImage, the driver may still act conservatively and cause the call to take longer than needed. Create a new texture object and pass the data with TexImage, then measure again.

Second, calling TexSubImage even when the texture is not in use (locked) is not as straightforward as simply doing a memcpy. Drivers will often reorder the texels inside a texture to improve data locality and thus make better use of the texture caches. That reordering takes some time but it pays for itself after you use the texture a few times.

It might be worth trying to create a brand new texure, but I would expect glTexSubImage2D() to be faster than glTexImage2D() with a newly created texture (just as you said).

It is possible that your HW does not support RGB565. You could try the same with a RGBA UNSIGNED_BYTE texture and see if it is faster.

Otherwise it may just be a limitation of your HW.

Actually glTexSubImage2D tends to be much slower than creating a new texture.

Is TexSubImage always slower than creating a new image or only when the area you update is smaller than the whole texture? Does it happen only with RGB 565 or also with RGB8888?

You may want to contact your hardware vendor and ask them directly.