If you have an image that's 128 x 64 the mips are:
Mip 0: 128 x 64
Mip 1: 64 x 32
Mip 3: 32 x 16
Mip 4: 16 x 8
Mip 5: 8 x 4
Mip 6: 4 x 2
Mip 7: 2 x 1
Mip 8: 1 x 1
Now, with block compressed formats they have to be a multiple of 4. So how are you supposed to make the mip levels with a block compressed format like BC1?
I can't believe how hard something like this is to find out. The Vulkan spec only mentions mip sizes with respect to non-block formats.
Two LLM's I asked said you STOP generating mipmaps when you reach 4x4.
DirectX says:
Sampling hardware uses the virtual size; when the texture is sampled, the memory padding is ignored. For mipmap levels that are smaller than 4×4, only the first four texels will be used for a 2×2 map, and only the first texel will be used by a 1×1 block. However, there is no API structure that exposes the physical size (including the memory padding).
So you continue generating the mips that are smaller than 4x4 of the original image, but then you have to pad up to 4x4 before you block compress. But how is this even done? What am I supposed to pad the extra part of the 4x4 block with?
You need to pad the input images out to the next block size before compression, so you end up with an integer number of compressed blocks.
The texture compressor will (probably) just look at the whole block and compress it as normal, so it's best to fill the pad region with colors that match the real data (e.g. extend the last real pixel edge color into the pad region). Check your compressor documentation because a lot of compressors will do the padding for you, so you may not need to do it manually.