glCopyImageSubData thows a GL_INVALID_VALUE when copying mips of a block compressed texture that are smaller than the block size in any dimension.
e.g.
GLuint tex0 = ...; // 1x1 compressed texture GLuint tex1 = ...; // 1x1 compressed texture glCopyImageSubData(tex0, GL_TEXTURE_2D, 0, 0, 0, 0, tex1, GL_TEXTURE_2D, 0, 0, 0, 0, 1, 1, 1); // GL_INVALID_VALUE
I think this is invalid behaviour. Note you also get an error if you 'align' the copy region to the nearest block size, e.g. replacing the last three parameters above with 4, 4, 1. The spec isn't entirely clear on how these mips should be treated, the language says:
An INVALID_VALUE error is generated if the dimensions of either subregion exceeds the boundaries of the corresponding image object, or if the image format is compressed and the dimensions of the subregion fail to meet the alignment constraints of the format.
So you could say that a 1x1 subregion doesn't meet the alignment constraints of the format (although I think that's intended as saying you can't copy the region from (5,5) to (6,6) on a 16x16 texture, for example). However you definitely cannot specify the lower mips as 'aligned' to the nearest 4x4 block size since those would exceed the boundaries of the image at that level. I think the only valid way that makes sense is if the subregion should be specified as the mip size in texels, regardless of if that's smaller than the block size in one dimension.
I'm on the latest AMD drivers, 14.12 Omega, on an R9 290X. Note that nvidia doesn't complain and performs the copy when specifying the 'real' mip size in texels, but whether that is spec-correct or not I don't know.
Baldur