ARB_texture_non_power_of_two

Now that we have this extension, is there any reason to still use glTexSubImage2D with texture streaming ?

For instance if we do texture streaming with PBO can we do this:

pboMemory = glMapBuffer(PIXEL_UNPACK_BUFFER_EXT, WRITE_ONLY);
memcpy(pboMemory, texData, texsize);
glUnmapBuffer(PIXEL_UNPACK_BUFFER_EXT);
glTexImage2D(GL_TEXTURE_2D, 0, 0, 0, texWidth, texHeight, GL_BGRA, GL_UNSIGNED_BYTE, BUFFER_OFFSET(0));

instead of glTexSubImage2D ?

In other words: is the mandate of glTexSubImage2D’s solely to support changing a portion of a texture or does it also give you a better performance for streaming over glTexImage2D ?

glTexSubImage is faster because it simply overwrites the texture pixel data while glTexImage recreates the whole texture, everything from allocating memory, setting dimensions etc etc and then writing pixel data.

I dont understand why ARB_texture_non_power_of_two brings up this question, i assume it would act the same except that the power-of-two size restriction is relaxed, But correct me if im wrong because i only have a GF FX5900XT and i dont have the extension.

Well the old trick to support non-power-of-two (NPOT) textures was to define a bigger POT texture and then use glTexSubImage2D to only replace the portion of interest at every frame.

The answer you gave is also what I was guessing but I wanted to confirm as I dont see anywhere in the doc of glTexSubImage2D that it will always be faster than glTexImage2D with the same texture object and same dimensions etc…

You should still use TexSubImage for the reason that Twixn points out. However, np2 textures should still be a win. Replacing a whole texture gives the driver the option of orphaning the old one rather than copying it in-band into the old texture.

Thanks -
Cass

The answer you gave is also what I was guessing but I wanted to confirm as I dont see anywhere in the doc of glTexSubImage2D that it will always be faster than glTexImage2D with the same texture object and same dimensions etc…
It’s not an explicit part of the spec (as you can’t specify performance), but it is an outgrowth of implementing the spec. glTexImage2D, as defined by the spec, must do what glTexSubImage2D does, but also more. Indeed, it’s not too unreasonable to see glTexImage2D calling glTexSubImage2D (or something that they both call) as part of its functionality.

thank you all

I will then assume that glTexSubImage2D will always be the way to go with texture streaming.