Jump to content
  • Advertisement
Sign in to follow this  
Digitalfragment

DXT compression vs downscaled textures

This topic is 2640 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has anyone here done performance analysis measuring the difference between using DXT3-5 textures vs textures that are half sized? Both yield a 4:1 compression ratio, yet the quality loss of a DXT5 texture under most compression algorithms is consistently worse than a simple downscale.

My understanding of hardware dxt decompression is that the cost of decompression is next to free, but not necessarily cheaper than a half-sized but uncompressed texture fetch given that both textures end up being swizzled/tiled (terminology depending on your platform) and of the same size in the cache. Am I completely wrong in my assumption on a hardware level, or are there fringe cases where this is either true or false (such as dealing with anisotropic textures, textures of a certain size, so on so forth)

Hopefully some of the hardware gurus on here can shed some light.

Share this post


Link to post
Share on other sites
Advertisement
I would generally disagree with your statement that quality loss is worse using DXT than a simple downscale. Granted this image is using DXT1 (it forgoes the alpha channel for even higher compression), but the results with DXT3 and 5 are similar if you use them in the correct context (5 for smooth alpha gradients, 3 for sharp alpha transitions).

catcompare2.jpg

Source (with more pictures of DT3/5 and the original uncompressed 768K source image)

As for performance difference, there isn't generally isn't any if the textures are the same size (in bytes). Since the decompress is done in hardware on fetch, I believe you are correct that they are stored equivalently in cache. However, using compression allows you to get much better performance for the perceived quality. A 2048x2048 texture with compression artifacts you will only really see if you are looking for them is usually much nicer than a 1024x1024 downscaled and blurrier texture where the higher quality details have been lost completely. Both take the same amount of ram and memory bandwidth to read, but the perceived quality increase of having 4 times as many pixels is significant. The average user probably won't be able to tell if you are compressing their textures or not, but most will be able to see a halving of texel resolution quite easily.

Share this post


Link to post
Share on other sites
Indeed, a DXT1 2048x2048 equals a 512x512 uncompressed. And no, DXT5 isn't superior to DXT1, it's just DXT1 with alpha channel stored interpolated.
There is a colour loss, but isn't generally much worse than regular JPEG artifacts (tip: don't ever, ever, EVER compress to Jpeg then to DXT1, always work your originals in lossless formats before going DXTn).

Specially on large objects (i.e. terrain textures) any loss on colour is way overcompensated by sharpness, lack of aliasing (due to giant-scaling the texture in the model), and detail conservation.

DXTn isn't suited for all kinds of applications, so you have to be well aware of how it works, and have some practical experience.
For instance, if your original image is 128x128 it's size in VRAM will be 64kb (nothing compared to 256/512/1024 MB current GPU have) and then all you have to lose there is colour (at such resolution, detail and sharpness won't be noticeable even in the original) therefore it will look "just ok" in DXT1 where you could easily use the uncompressed image as is, without downsampling.

Edit: Another example: If you're doing particles, it's usually better to use a grayscaled texture then colour manipulating the emissive compoment. Therefore, you can use L8 textures getting a 4:1 lossless "compression" ratio (A8L8 for alpha, you get 2:1). Almost no need to use DXTn; it may actually yield higher compression ratios, but the quality difference starts becoming too tempting.
A few particle FXs may need coloured textures though. You'll see, you have to be smart, know your texture formats, and decide on a per case basis.

Share this post


Link to post
Share on other sites

Indeed, a DXT1 2048x2048 equals a 512x512 uncompressed.


I'm fairly certain thats *not* the case, as that would make it 16:1 compression, not 4:1 compression as is documented everywhere.

I probably should have mentioned that our source art before compression is already at a higher resolution, and we are accustomed to appropriately creating individual mip levels to retain clarity. The problem with the quality reduction is that a lot of our details entirely inside or straddling dxt pixel blocks - for all intents and purposes, similar to stippling patterns.

Share this post


Link to post
Share on other sites

I'm fairly certain thats *not* the case, as that would make it 16:1 compression, not 4:1 compression as is documented everywhere

DXT2-5 has a 4:1 ratio; DXT1 achieves 8:1 ratio (against a 32-bit image). If you don't use alpha, DXT1 is your preferred choice.

My apologies though, as you're right 512x512 vs 2048x2048 is indeed 16:1; done my math wrong. There's no power of two downscaled resolution that can mantain the same aspect ratio, so let's say 512x1024 for explanatory purposes; but it's probably not a good idea to downscale in such way in a production environment.

I probably should have mentioned that our source art before compression is already at a higher resolution

I'm a bit confused.
"Source material -> downscale -> DXTn" vs "Source -> downscale -> store uncompressed"? right?

we are accustomed to appropriately creating individual mip levels to retain clarity.
The DDS format allows using custom mips; however if you use DXTn they'll be subject to compression too. I'm not sure if your problem lies in that you think you're forced to automatic mip map generation by using dxtn, or you don't like the artifacts caused on your custom mips (which is totally understandable, like I said, DXTn becomes weaker at lower resolutions).
Note however mipmaps solve two problems:
  1. Bandwidth usage.
  2. Filtering quality in very specific situations.
Therefore, by using DXTn you're getting automatic bandwidth reduction (reducing the need to switch lod at close distances). As for filtering quality, you can't solve that, but I'm pretty sure you won't notice it as the situations are very specific and tend to appear at steep angles (when you don't have anisotropic filtering to save the day) or when you have high frequency images at distant places (a. they're distant and hard to see, b. DXTn compression tends to suck with high frequency information anyway, just like Jpeg does).

You may have valid concerns that the mipmaps may not look the way you want in your artwork, but you should be asking yourself whether those artifacts in the mipmaps are actually going to be visible/noticeable once displayed in the 3D render (again, depends on the case).

Cheers
Dark Sylinc

Share this post


Link to post
Share on other sites

I'm fairly certain thats *not* the case, as that would make it 16:1 compression, not 4:1 compression as is documented everywhere.


It's actually 6:1 (for a 24-bit source) or 8:1 (for a 32-bit source), not 16:1 or 4:1 (DXT3 and 5 are 4:1). So no, it's not as good as 2048->512, but it's still pretty awesome.


I probably should have mentioned that our source art before compression is already at a higher resolution, and we are accustomed to appropriately creating individual mip levels to retain clarity. The problem with the quality reduction is that a lot of our details entirely inside or straddling dxt pixel blocks - for all intents and purposes, similar to stippling patterns.


Out of curiosity, does your art use a lot of solid color fills or gradients (such as 2D cell shading)? This is an area where texture compression artifacts can actually be noticed fairly easily, and it's common to just bite the bullet on memory and use full res uncompressed textures if these textures are relatively static and viewport aligned.

A screenshot could be worth 1000 words here, so if you have some images of the problems you're encountering with texture compression we might be able to suggest solutions that don't require you to use 4-8 times more VRAM with uncompressed assets.

Share this post


Link to post
Share on other sites

My apologies though, as you're right 512x512 vs 2048x2048 is indeed 16:1; done my math wrong. There's no power of two downscaled resolution that can mantain the same aspect ratio, so let's say 512x1024 for explanatory purposes; but it's probably not a good idea to downscale in such way in a production environment.

Np, i just wanted to make sure i missing something.


[quote name='Digitalfragment' timestamp='1316575821' post='4864078']I probably should have mentioned that our source art before compression is already at a higher resolution

I'm a bit confused.
"Source material -> downscale -> DXTn" vs "Source -> downscale -> store uncompressed"? right?
[/quote]
An automated process currently goes
source -> downscale -> DXTn

the topic here is debating the option now instead as:
source -> DXTn
vs
source -> downscale



[quote name='Digitalfragment' timestamp='1316575821' post='4864078']we are accustomed to appropriately creating individual mip levels to retain clarity.

The DDS format allows using custom mips; however if you use DXTn they'll be subject to compression too. I'm not sure if your problem lies in that you think you're forced to automatic mip map generation by using dxtn, or you don't like the artifacts caused on your custom mips (which is totally understandable, like I said, DXTn becomes weaker at lower resolutions).
-snip-
[/quote]
The latter. We do use custom mips within dds files, (assembled multiple uncompressed files, etc), which after compression loses the highgrain frequency that the artists are expecting to keep.


You may have valid concerns that the mipmaps may not look the way you want in your artwork, but you should be asking yourself whether those artifacts in the mipmaps are actually going to be visible/noticeable once displayed in the 3D render (again, depends on the case).

The resulting quality was already flagged as needing attention by our artists looking at the final product on the hardware. IMHO, the current situation acceptable loss of quality and not worth the extra memory of either solution, but in the end its also not my call.


Out of curiosity, does your art use a lot of solid color fills or gradients (such as 2D cell shading)? This is an area where texture compression artifacts can actually be noticed fairly easily, and it's common to just bite the bullet on memory and use full res uncompressed textures if these textures are relatively static and viewport aligned.

Far from. I already stated that the issue is closer to that of a stippling pattern (adjacent pixels have vastly different contrasts). The results of the various dxt compressors we have tried have in all cases 'smudged' the contrasted pixels out, or messing up the other areas. Worse comes to worst, we'll just programattical pick out dxt-blocks based on their correctness of multiple compressors and stitch them together. Though, thats gonna be a painfully slow automated process! ;)

FWIW: Gradients are an easy enough case to support DXT compression - normalise your channels and upload the white/black values in your shader to denormalize them for max precision.


A screenshot could be worth 1000 words here, so if you have some images of the problems you're encountering with texture compression we might be able to suggest solutions that don't require you to use 4-8 times more VRAM with uncompressed assets.

Completely agree, but I wont be green light by the execs on providing samples.

The other option, which we're currently exploring, is reordering and dissociating channels into different texture fetches in order to get better compression results across the board.

Thanks for the points, from the both of you. If nothing else, just having some theorywork confirmed gives us a few things to try out first.

Share this post


Link to post
Share on other sites

It's actually 6:1 (for a 24-bit source) or 8:1 (for a 32-bit source), not 16:1 or 4:1 (DXT3 and 5 are 4:1). So no, it's not as good as 2048->512, but it's still pretty awesome.

For a 24-bit source it's still 8:1 since no GPU in the market stores a 24-bit image in 3 bytes. They waste one more byte for alignment purposes. I don't know if this holds true for handheld GPUs. However, the image stored in regular RAM (either for caching or in managed DX) is probably 6:1; when it is kept.

When stored in HDD, it is a 6:1 ratio but it's hard to compare as an uncompressed file would be probably stored as PNG (or TGA with RLE compression, or lossy Jpeg) where the compressed size may vary drastically.

Share this post


Link to post
Share on other sites

[quote name='kuroioranda' timestamp='1316577890' post='4864088']
Out of curiosity, does your art use a lot of solid color fills or gradients (such as 2D cell shading)? This is an area where texture compression artifacts can actually be noticed fairly easily, and it's common to just bite the bullet on memory and use full res uncompressed textures if these textures are relatively static and viewport aligned.

Far from. I already stated that the issue is closer to that of a stippling pattern (adjacent pixels have vastly different contrasts). The results of the various dxt compressors we have tried have in all cases 'smudged' the contrasted pixels out, or messing up the other areas. Worse comes to worst, we'll just programattical pick out dxt-blocks based on their correctness of multiple compressors and stitch them together. Though, thats gonna be a painfully slow automated process! ;)

FWIW: Gradients are an easy enough case to support DXT compression - normalise your channels and upload the white/black values in your shader to denormalize them for max precision.[/quote]
Sounds like the source is high frequency data. This means you have pixels very different one from another. DXT isn't very good at it.
Just like PNG vs Jpeg. Jpeg sucks when compressing computer-made graphs (i.e. MS Excel graphs) text, etc.

You may find this explanation very interesting for your artists so they know how to arrange the colours. What to do and what to avoid. Note how the first image is close to the original, while in the second one, no compressed colour except 1 pixel actually matches the original (DXT works in 4x4 blocks)

One final note: What is the memory budget and how much is used? there's little point in using DXT if you have plenty of unused VRAM and the memory bandwidth isn't saturated. Often though, DXT is used preemptively to max out the number of assets that can be included.
Tools like NVPerfHUD (NVIDIA); GPU PerfStudio 2 (ATI) & Intel GPA (Intel, works on other cards too, with less info) will tell you the GPU's memory & bandwidth usage.

Edit: GIMP's dds plugin comes with 3 different methods to select colours for dxt interpolation, plus a "dithering" option. That's 6 combinations in total. You may want to give them a try.

Good luck on your problem
Dark Sylinc

Share this post


Link to post
Share on other sites
Which library are you using for DXT compression? They are most definitely not all equal in terms of quality or performance.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!