Fast reading/writing of compressed textures

OpenGL OpenGL: Advanced Coding
1

does anyone know functions which work faster then glGetTexImage() and glTexSubImage2D()? i use hardware compression of the textures and then try to change them. simple test shows that inversion of the 64x64 pixel block works 10 times faster on uncompressed 1024x1024 texture.

2

So are you you uploading uncompressed data into a compressed texture? If so, it will be slow as the driver has to compress the texture data (on the CPU typically) before loading into the image.

Use the methods to supply already compressed data if you want speed uploading to a compressed texture.
(glCompressedTexSubImage2D)

glGetTexImage will also be slow as it has to uncompress the texture data(probably CPU work) before giving it back to you.

I don’t know what you are doing with the textures, but perhaps you can do what you want in a shader after doing the texture lookup. (so you don’t have to read it back/modify/reupload)

3

sqrt[-1]:
Use the methods to supply already compressed data if you want speed uploading to a compressed texture. (glCompressedTexSubImage2D)

Related question: can you subload only a portion of a single MIPmap level for a compressed texture, or entire MIPmap levels only?

4

I see no reason why you could not upload a portion of a single mip-level.

Not that I have ever tried.

5

This is well defined in the spec :

(3) Should TexSubImage support all block-aligned edits or just the minimal
    functionality required by the ARB_texture_compression extension?

    RESOLVED:  Allow all valid block-aligned edits.

…

CompressedTexSubImage2D will result
in an INVALID_OPERATION error only if one of the following conditions
occurs:

    * <width> is not a multiple of four or equal to TEXTURE_WIDTH.
    * <height> is not a multiple of four or equal to TEXTURE_HEIGHT.
    * <xoffset> or <yoffset> is not a multiple of four.
6

Originally posted by sqrt[-1]:
[b] I see no reason why you could not upload a portion of a single mip-level.

Not that I have ever tried. [/b]
Updating a part of a compressed image may not be a trivial opration. What if the compression scheme used requires the entire texture to be decompressed, updated, and then recompressed?

Originally posted by arekkusu:
This is well defined in the spec :

Keep in mind though that sub-edits are only well defined by the special compressed format extension specification. The general compressed texture interface (ARB_texture_compression) onyl allows edits starting in the lower left corner, but leaves the unedited area undefined. Basically, you can only safely upload a complete image, unless the specification for the particular format says otherwise.

In the case or S3TC, only block aligned (usually 4x4) updates are allowed, but not arbitrary alignments, as in the example you posted.

So in order to safely do a subedit of a compressed texture, you must first verify that the internal format is a compressed format that actually supports subedits, and if it does, you must also ensure the subedit is performed according to the specification for that particular format.