GPU Texture Compression Explained: BC1–BC7 and VRAM

A game can contain large collections of color maps, normal maps, masks, material data and other textures. Storing every texel as an ordinary uncompressed RGB or RGBA value would make those resources much larger in memory and increase the amount of texture data that must move through the graphics memory system. The BC family addresses that problem with fixed-size compressed blocks designed for graphics hardware.

Microsoft describes BC formats as runtime-oriented texture formats that modern GPUs can use directly rather than requiring the application to expand the whole image into an ordinary uncompressed texture before sampling it. That is the key distinction from thinking of compression only as a smaller download: block compression changes the representation used by the GPU itself.

The Direct3D BC formats encode texture data in 4×4 blocks. Sixteen texels therefore share one fixed-size encoded block instead of each texel carrying a full independent set of uncompressed channel values. BC1 uses 8 bytes per 4×4 block, while BC2, BC3, BC5, BC6H and BC7 use 16 bytes per block. BC4, like BC1, uses 8 bytes.

Those fixed block sizes give useful storage arithmetic without inventing a game-specific VRAM claim. BC1 and BC4 represent 4 bits per texel for complete 4×4 blocks; the 16-byte formats represent 8 bits per texel. By comparison, an uncompressed four-channel 8-bit RGBA texture is 32 bits per texel. Actual resource memory also depends on dimensions, mip levels, array layers, alignment, residency and other engine/API choices, so the per-block ratio is not a promise that a game will save a particular number of gigabytes.

BC1 corresponds to the familiar DXT1 family. Microsoft documents it as an 8-byte block format built around two reference colors and per-texel indices, with an optional one-bit alpha case. BC2 and BC3 use 16-byte blocks and add more alpha information; they correspond to the older DXT2/DXT3 and DXT4/DXT5 naming used by Direct3D 9.

Khronos exposes the same S3TC lineage through formats named DXT1, DXT3 and DXT5 in its texture-compression extensions. The API names differ, but this is not evidence for a separate class of PC texture compression. It is historical naming around related block formats.

BC4 stores one component and BC5 stores two. That matters because many renderer resources are data textures rather than photographs: masks may need one channel, while two-component fields can use two channels without spending a full RGB or RGBA representation. Microsoft lists BC4 as an 8-byte 4×4 block and BC5 as a 16-byte block, with both unsigned-normalized and signed-normalized variants available in DXGI.

Normal maps are a common example of data that can be represented using two stored components when the third component is reconstructed by the shader, but that is an engine technique rather than a rule that every normal map must use BC5. Format selection depends on the authored data, required range, quality target, platform support and renderer pipeline.

Direct3D 11 extended the BC family with BC6H and BC7. Microsoft documents BC6H for three-channel high-dynamic-range source data represented with half-precision floating-point components, while BC7 is intended for high-quality RGB or RGBA compression. Both occupy 16 bytes per 4×4 block.

These formats are more flexible internally than BC1. Microsoft documents 14 encoding modes for BC6H and eight for BC7, allowing an encoder to choose different representations for different blocks. Khronos exposes the corresponding BPTC family in OpenGL/WebGL specifications. More encoder choices do not mean the GPU stores a variable number of bytes per block: the runtime block size remains fixed.

Keeping a texture in a block-compressed GPU format reduces the bytes required for that texture compared with an otherwise equivalent higher-bit-rate uncompressed representation. That can reduce its storage footprint and the amount of encoded texture data fetched through the memory hierarchy. It is one reason texture compression is relevant to both capacity and bandwidth.

Total VRAM use is broader. Games also allocate render targets, depth buffers, geometry, acceleration structures, shader resources, transient buffers, caches and other data, and they may stream only selected mip levels or texture sets at a given moment. Mipmaps themselves add levels beyond the base image. A BC format therefore gives deterministic block storage for a particular texture resource, not a universal prediction for the VRAM counter shown by a game or monitoring tool.

A conventional image or archive format can be useful for distribution, authoring or disk storage, but the GPU generally needs a representation compatible with its texture sampling path. Microsoft explicitly describes BC DDS assets as runtime-optimized and notes that block-compressed images can be loaded for GPU use without first expanding the entire texture to an uncompressed image.

Khronos makes the layering especially clear with KTX2, whose specification can carry GPU texture formats and can also use supercompression schemes for distribution. A smaller package on disk and a compact GPU-native texture are therefore separate concerns. An asset pipeline may use both, converting or transcoding data into the format the target GPU API will sample.

Fixed-rate block compression cannot preserve arbitrary source data exactly. Encoders approximate the source within the representation available to each block, so artifacts depend on the format, source content and encoder. The existence of BC4, BC5, BC6H and BC7 alongside BC1–BC3 reflects the fact that one representation is not ideal for every channel layout, dynamic range or quality requirement.

That is why this guide does not rank BC1 through BC7 on one universal quality scale. BC6H solves an HDR-data problem that BC1 does not, BC4 and BC5 target different channel counts, and BC7 provides a more flexible RGB/RGBA representation at twice BC1’s block size. The correct comparison starts with what data must survive compression and which formats the target graphics path supports.