Why Your GPU Hates PNG
How GPU actually loads your textures

Textures Are Everywhere
Every 3d model you see in a game has textures wrapped around it. Color. Roughness. Normal maps. Sometimes four or five textures per object. A single scene can have hundreds of them.
That is a lot of image data. And it all has to live on your GPU.
The Problem With PNG and WebP
You probably know PNG and WebP. They are great for the web. Small file sizes. Good compression. Your browser loves them.
But your GPU does not.
Here is the thing. PNG and WebP use CPU-side compression. Formats like deflate or lossless dictionary coding. These are designed to make files small on disk and fast to send over a network.
Your GPU cannot read any of that. It has no idea what a PNG is.
What Actually Happens When You Load a Texture
Your game loads a PNG from disk. The CPU decompresses it into raw pixel data. Every single pixel. Fully uncompressed. Then it uploads that raw data to the GPU (because again, GPU has no idea what a PNG is, it needs raw pixel data).
A 1024x1024 texture with four channels becomes 4 megabytes. Uncompressed. Sitting in VRAM (VRAM is like RAM, but for the GPU). Every single one of them.
You had a nice small 200kb PNG on disk. Now it is 4mb on your graphics card. Multiply that by a few hundred textures and you are eating through your VRAM budget fast.
Why the GPU Cannot Just Decompress It
GPUs are not built like CPUs. They are massively parallel processors designed to do simple math on huge batches of data. They do not have the logic to run general purpose decompression algorithms like deflate.
They need to sample any pixel at any time. Randomly. Thousands of times per frame. That means the data has to be in a format the GPU can read directly without running a decompression pass first.
GPU-Native Compressed Formats
This is where block compression comes in. Formats like BC1 through BC7 on desktop. ASTC and ETC2 on mobile. These are compressed formats that the GPU hardware can read natively.
The GPU does not need to decompress them into raw pixels. It samples directly from the compressed data. The decompression happens in hardware at read time. Basically for free.
A BC7 compressed 1024x1024 texture takes about 1mb in VRAM instead of 4mb. It stays compressed the entire time. On disk. In memory. On the GPU. Everywhere.
So Why Not Just Use BC7 Files Directly
You could. Formats like DDS have existed for a long time. But they have limitations. No universal container for all platforms. No good support for basis universal transcoding. No built-in mip levels done right. No modern metadata.
And the biggest issue. Desktop GPUs speak BC7. Mobile GPUs speak ASTC. You would need to ship different files for different platforms.
Enter KTX2
KTX2 solves all of this in one container.
It stores textures in GPU-ready compressed formats. It supports BC7 and ASTC and ETC2. It can use Basis Universal supercompression which means you store one file and transcode it to whatever the target GPU needs at load time.
The transcode is fast. It goes from one compressed format to another. No full decompression step. No 4mb raw pixel blowup.
It supports mipmaps baked right in. It handles cube maps and texture arrays. It has proper metadata for color spaces and channel layouts.
The Full Picture
PNG on disk. CPU decompresses it. Raw pixels uploaded to GPU. Huge VRAM cost. This is the old way.
KTX2 on disk. Already GPU compressed. Transcoded if needed to match the hardware. Uploaded directly. Stays compressed in VRAM. Small. Fast. Correct.
Your textures stay compressed from the moment they leave disk to the moment a shader samples them. That is the entire point. That is why KTX2 is better.
Appendix
What is VRAM?
VRAM is like RAM, but for the GPU. It is a small amount of memory that is dedicated to the GPU. It is used to store textures, vertex data, and other data that the GPU needs to access quickly.
What are mipmaps?
Mipmaps are pre-generated smaller versions of a texture. Half size. Quarter size. Eighth size. All the way down to like 1x1.
When an object is far away from the camera the GPU picks the smaller version instead of sampling the full resolution one. No point reading a 1024x1024 texture for something that is 5 pixels on screen.






