Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
So, from what I gathered, rendering engines take common image formats like PNG or JPG and convert them into their favored formats, such as Targa or DDS.
Does it mean that using the already converted texture format directly results in faster render times?
As I explain in another answer, GPUs cannot read PNG or JPG, full stop. Those formats just do not provide the random access functionality we need for rendering, where we need to be able to map instantly from "texture coordinate (0.2, 0.7)" to "here is the memory address of the data for that specific texel" without scanning through all of the image data before that point in the stream to find it.
Anything that loads a PNG or JPG first decompresses it to a GPU-readable format, then displays that format. So you don't gain a per-frame speed advantage/disadvantage versus using dedicated GPU formats, because you are using a dedicated GPU format no matter what you do.
Where storing your images in GPU-ready formats like DDS can help is that you don't need to take time to decompress it on load — you can dump bits straight from the disc/network into VRAM and use them directly, without any transcoding. This can save time when booting the game, loading levels, or streaming content, and give you more predictable memory layouts (more of a concern on embedded systems like older consoles).
The other advantage is that you can take time offline to compress textures into a smaller format while preserving image quality. Not smaller compared to JPG/PNG usually (they're really good at compressing, while GPU formats usually aren't, due to the random access limitation), but smaller than the GPU version you'd get if you just did the most naive transcode.
By default, most libraries/APIs will decompress PNG/JPG images to uncompressed RGBA8 for use on the GPU: that's 8 bits for each of four colour channels, adding up to 32 bits per pixel. By contrast, some DDS formats can get down to 4 bits per pixel — one eighth the size — at the cost of image quality or giving up colour channels you might not need for certain textures.
The smaller size (vs raw RGBA8) both helps save on the game's video memory demands, so you can fit more textures/etc. in memory at once or load/stream content faster, and reduces the bandwidth demands of sampling the texture, which can give you a performance boost during rendering.
But you can get that benefit from JPG/PNG too if your transcoding step re-compresses them into one of these more packed GPU formats instead of uncompressed RGBA8. The difference is that if you do this compression offline and save the GPU-ready DDS asset to later load in game, you can use a slow compressor that maximizes the visual quality available for a given format. You don't care if it takes a while, since it can run on your build machine overnight without adding to loading times for players.
Doing it on load when transcoding from JPG/PNG, you usually go for a fast compressor that might not make optimal choices, and it's too late for the designer to fiddle with format and compression settings to find the right trade-off for each image. So you more often have to fall back on less compressed GPU formats if you're loading from JPG/PNG at runtime.
