Shawn Hargreaves Blog
Consider the flow of data through a typical game:
Making the data smaller has benefits at every stage:
So we should always compress everything as much as possible, right?
But every ointment has a fly…
Before we can use compressed data, we must decompress it. The question is, does this decompression work take more or less time than we saved by using compression in the first place? We can choose to decompress our data at any of the stages I listed above. Stages that come before the decompression operation will benefit from the compressed format, while later stages will not. Games often combine multiple forms of compression that are decompressed at different times:
Those last two bullets are interesting because they decompress inside the GPU after data is fetched from memory. This allows the compression to benefit every stage of the data flow. Unlike JPEG compression, DXT textures remain compressed after loading, so they save memory and bandwidth as well as filesystem storage space. And because the GPU is a highly asynchronous parallel processor, decompressing DXT textures or packed vertex data is literally free! Of course the hardware cannot actually decompress data in zero time, but there are dedicated unpacking units which run in parallel with other GPU tasks, and which are fast enough to never be the performance bottleneck. So in practice, taking advantage of these compression features will never cost you extra time to decompress the data, and can save a lot of time if your rendering is bottlenecked by memory bandwidth.
I set out to write this article specifically about packed vertex data formats, but just setting the scene has made it long enough already, so the details will have to wait for my next post.
Nice breakdown of the different stages.