Why not compress the texture using NTC, VAE-VQ or some neural codec into a general embedding space of uint8 and then just expand and create mipmaps and similar using the target hardware standard?
Aside from the fact that these formats were developed decades ago (S3TC evolved into DXTn compression, which became BCn compression), there's the fact that these formats are designed to be decompressed on the fly. Hence the block-based, fixed rate compression: the GPU can compute the memory address of a block directly from a texture coordinate without knowing anything but the format and dimensions.
What looks like complex addressing in software is fairly simple on the GPU side. Swizzling is just interleaving address bits. Various block schemes are likewise just simple bit shifting on the address. The block compression just takes a weighted average of two colors (with various storage schemes) and uses a small index per texel to look up the color.
There are a lot of combinations but it's designed to be very gate efficient to implement, so it can be decoded on demand. It's even stored compressed in the cache (usually).
augment_me · · focus · HN ↗
SyzygyRhythm · · focus · HN ↗
What looks like complex addressing in software is fairly simple on the GPU side. Swizzling is just interleaving address bits. Various block schemes are likewise just simple bit shifting on the address. The block compression just takes a weighted average of two colors (with various storage schemes) and uses a small index per texel to look up the color.
There are a lot of combinations but it's designed to be very gate efficient to implement, so it can be decoded on demand. It's even stored compressed in the cache (usually).