A Comparison of Several Texture Compression Schemes /PS2,XBOX .../

[joe75]

http://www.hemiware.com/technology.htm

Features:

Texture Compression - VQ for PS2, S3TC for GAMECUBE, Xbox and PC


PS2

Features:

· VQ compression (2 bits per pixel, full 32 bit output)
· Auto-generate mipmaps - uses GS bandwidth to save main bus bandwidth
· Path 3 parallel uploads
· 100% VU T&L with clipping
· Data amplification (gets the most out of available DMA cycles)
· Support for user VU code

.
.


http://web.onetel.net.uk/~simonnihal/texcom/texcompcomp.html

Conclusions:
Since there is no good model for measuring the quality of image compression, the following must be regarded as being based on personal opinion. My conclusions, in no particular order, are...

o Except for very special cases, 4 bpp palettised textures are effectively obsolete. DXTC gives the same compression rate at substantially better image quality, and VQ gives better (or at least no worse) results at a higher compression ratio.

o It appears that it takes rare cases to make DXTC look bad, assuming identical resolutions. Of course, this may be influenced by the resolution of the display device.

o Given identical memory requirements, it appears that the VQ may be better than DXTC. What was interesting was that the RMS error for the "Equal storage costs" was almost identical for the 24bit, 8bit, and DXTC modes on all three test cases.

 

[Fafalada]

· Auto-generate mipmaps - uses GS bandwidth to save main bus bandwidth

I would think that after nearly 6 years these kind of silly misconceptions would be a thing of the past.
Oh well...


joe,
without knowing the performance implications of their VQ scheme you can't really claim any kind of conclusions. There is a wealth of information on B3D from countless discussions in regards to how various texture compression schemes could be, or have been implemented on PS2 - they all come with certain tradeoffs.

 

[joe75]

I would think that after nearly 6 years these kind of silly misconceptions would be a thing of the past.
Oh well...


joe,
without knowing the performance implications of their VQ scheme you can't really claim any kind of conclusions. There is a wealth of information on B3D from countless discussions in regards to how various texture compression schemes could be, or have been implemented on PS2 - they all come with certain tradeoffs.

... 99% MS /XBOX,PC/ users think that PS2 has not any TC.

 

[Squeak]

I would think that after nearly 6 years these kind of silly misconceptions would be a thing of the past.
Oh well...

?
33% is nothing to be sneezed at, or am I missing something?

 

[Fafalada]

Uploading per-mip-level cuts the bandwith usage by average ~4-10 times.

The only reason to do what they are doing is if you have too much bandwith, and you want to save memory.

 

[Squeak]

Ah yes, but for textures that always has all mip levels visible (like terrain textures), or just the two nearest , you should be able to save both memory and bandwidth.

 

[Fafalada]

Uhmm...

[font=Verdana, Helvetica]

if you base your optimization efforts on speculation instead of real data, you'll waste a lot of time speeding up the parts of your program that were fast already.

You want the pipeline to be fast with general case that happens most of the time, not special case like terrain texture that makes up for about 5% of your texture budget, if that.
4-10x savings I talked about were on entire scene in actual games, not 'per texture'.

[/font]There's also another issue - saving GIF bandwith isn't much help if you stall VU and consequent GIF transfers while GS is busy generating mipmaps. Yes, there are situations where it may help, but they are far from being the common case.

For that matter certain things that are always drawn (like terrain textures) can often be put into your resident texture buffer, rather then wasting transient resources for it.

 

[Fox5]

http://www.hemiware.com/technology.htm

Features:

Texture Compression - VQ for PS2, S3TC for GAMECUBE, Xbox and PC


PS2

Features:

· VQ compression (2 bits per pixel, full 32 bit output)
· Auto-generate mipmaps - uses GS bandwidth to save main bus bandwidth
· Path 3 parallel uploads
· 100% VU T&L with clipping
· Data amplification (gets the most out of available DMA cycles)
· Support for user VU code

.
.


http://web.onetel.net.uk/~simonnihal/texcom/texcompcomp.html

Conclusions:
Since there is no good model for measuring the quality of image compression, the following must be regarded as being based on personal opinion. My conclusions, in no particular order, are...

o Except for very special cases, 4 bpp palettised textures are effectively obsolete. DXTC gives the same compression rate at substantially better image quality, and VQ gives better (or at least no worse) results at a higher compression ratio.

o It appears that it takes rare cases to make DXTC look bad, assuming identical resolutions. Of course, this may be influenced by the resolution of the display device.

o Given identical memory requirements, it appears that the VQ may be better than DXTC. What was interesting was that the RMS error for the "Equal storage costs" was almost identical for the 24bit, 8bit, and DXTC modes on all three test cases.

Isn't VQ like ancient? When I was recently looking up texture compression schemes, I saw that all the Voodoos (straight from the Voodoo 1) were listed as having a form of VQ compression. (I think it was also a compression heavily used in Unreal and other Glide rendered games, and that I don't think ATI or nvidia supported)

 

[Squeak]

Isn't VQ like ancient? When I was recently looking up texture compression schemes, I saw that all the Voodoos (straight from the Voodoo 1) were listed as having a form of VQ compression. (I think it was also a compression heavily used in Unreal and other Glide rendered games, and that I don't think ATI or nvidia supported)

VQ (vector quantization) is basically making a look-up table of identical parts or, in most cases, parts that look most like each other (within the boundaries af the look-up tables capacity) of a large data set.
With CLUT VQ (colour look up table) colours a narrowed down to either 16 (4bit) or 256 (8bit) that are each given an entry in the look-up table.
CLUT VQ is build into the GS.

The 4bit/p VQ, the one talked about on the linked site, invented by Simon Fenney (Simon F on this site), is really a form of ordered dithering, where 16 (4bit) 2x2 blocks are selected to compose the whole image.

I don't know the specifics of how this technique can be done in multipass on the GS, maybe someone can explain?

 

[ERP]

I would think that after nearly 6 years these kind of silly misconceptions would be a thing of the past.
Oh well...

I've actually worked on a PS2 game that did use the GS to autogenerate mipmaps following a texture upload, but it certainly wan't for performance reasons. We were extremly tight on memory and extremly underutilising the GS, so it was all about image quality at the expense of performance, rather than memory.

 

[joe75]

Isn't VQ like ancient? When I was recently looking up texture compression schemes, I saw that all the Voodoos (straight from the Voodoo 1) were listed as having a form of VQ compression. (I think it was also a compression heavily used in Unreal and other Glide rendered games, and that I don't think ATI or nvidia supported)

http://web.onetel.net.uk/~simonnihal/texcom/texcompcomp.html
... go and see ... Test Results !!!

 

[akira888]

<snip> The 4bit/p VQ, the one talked about on the linked site, invented by Simon Fenney (Simon F on this site), is really a form of ordered dithering, where 16 (4bit) 2x2 blocks are selected to compose the whole image.

The 2x2 VQ algorithm on Dreamcast allowed for (IIRC) 256, not 16, representative blocks. With only 16 2x2 blocks the end result would be pretty rancid for pretty much all textures, save for the most extremely simple ones.

The ~2bpp data footprint is due to the fact that each texel in a 2x2 square will share the same 8 bit index into the block table, and therefore it will need to only be stored once for all four texels.

 

[Squeak]

Yes of course, it's been some time since I thought about this. AFAIK a 1bit pp mode was also possible, but never used.

 

[Fafalada]

I don't know the specifics of how this technique can be done in multipass on the GS, maybe someone can explain?

I don't really recall the details anymore, it's been too long ago but one way I remember working out was around 2 operations per texel, and required unpacking before use. It's not the only way though, people have used variations that aren't exactly the same as DCs 2x2VQ but give similar enough results, and afaik cheaper.
Theoretically it could be done in like 1/4 ops/texel if there wasn't for some issues with the way GS addresses memory.

The 1bpp variant you mentioned gives results a bit worse then 4bit Clut textures, but if you're really tight on space(maybe like project ERP mentioned ) it could still be useable for some things.

I've actually worked on a PS2 game that did use the GS to autogenerate mipmaps following a texture upload, but it certainly wan't for performance reasons.

Exactly - I just find it baffling that people would still believe this is a performance benefit.

 

[Simon F]

Conclusions:
Since there is no good model for measuring the quality of image compression, the following must be regarded as being based on personal opinion. My conclusions, in no particular order, are...

I thought that looked familiar.

The 4bit/p VQ, the one talked about on the linked site, invented by Simon Fenney (Simon F on this site), is really a form of ordered dithering, where 16 (4bit) 2x2 blocks are selected to compose the whole image.

Sorry, I can't take the credit for inventing it. My work (which was in Dreamcast) was inspired by an earlier paper, “Rendering from Compressed Textures” by Beers, Agrawala, and Chadda.

BTW, it's ~2bpp (not 4bpp) in the standard DC VQ approach, although you could use an extra level of heirarchy to get it to ~1bpp.

 

[Hellbinder]

Ok hold on. Something is totally fishy.

DREAMCAST had VQ Compression. I distinctly remember that Ps2 was getting hammered (and still is) in the texture department because all they had was a Quirky way to use JPEG compression on textures.

In fact i am 100% positive that was the case.

I just bought a slimline PS2 and still teh textures are a blurry mess even on their best games compared to the Xbox. There is no way in heck that the PS2 has decent texture compression.. at least from a visual standpoint.

At any rate Dreamcast had VQ. Unless sony dreamed some way to do it in software years later then they do not have VQ.

 

[MrWibble]

Ok hold on. Something is totally fishy.

DREAMCAST had VQ Compression. I distinctly remember that Ps2 was getting hammered (and still is) in the texture department because all they had was a Quirky way to use JPEG compression on textures.

In fact i am 100% positive that was the case.

I just bought a slimline PS2 and still teh textures are a blurry mess even on their best games compared to the Xbox. There is no way in heck that the PS2 has decent texture compression.. at least from a visual standpoint.

At any rate Dreamcast had VQ. Unless sony dreamed some way to do it in software years later then they do not have VQ.

Palettised textures are PS2's only hardware compression. Technically they could be thought of as a type of vector quantisation, but it's probably not what most people would know by VQ, and it's not the same as what the DC had.

There are however ways to use the GS to decompress textures in vram - as pointed out this wastes a lot of draw time, but can save on main ram and bandwidth.

You could use the IPU to decompress jpeg/mpeg compressed textures but then you'll still have to upload them. Probably reasonable for caching large amounts of texture but I'm not sure if it's done very often. I don't think jpeg is a good idea for textures anyway, some of the artefacts could show up fairly badly.

That said I've played plenty of PS2 games where the textures were not "a blurry mess"...

 

[Squeak]

There are however ways to use the GS to decompress textures in vram - as pointed out this wastes a lot of draw time, but can save on main ram and bandwidth.

But PA graphs shows that GS is idle a lot if the time, so maybe it's more of a waste not to do compression, at least of the resident textures.

You could use the IPU to decompress jpeg/mpeg compressed textures but then you'll still have to upload them. Probably reasonable for caching large amounts of texture but I'm not sure if it's done very often. I don't think jpeg is a good idea for textures anyway, some of the artefacts could show up fairly badly.

IPU decompression could have been used as an alternative/supplement to streaming. It's probably possible to compress 4 or 8bit CLUT data with jpeg. Then decompress it, not per frame, but in small chunks when the player comes near a portal or instead of loading it all from disc.
Iframe animated textures though, I'm sure has been used in some games, one very obvious example is the video-screen at the first dock in Beyond Good and Evil, you can actually see mpeg compression blocks in some frames of the texture.

 

[MrWibble]

But PA graphs shows that GS is idle a lot if the time, so maybe it's more of a waist not to do compression, at least of the resident textures.

Idle? Which graphs are these? It generally seems to spend most of its time stalled, except when it's finished drawing. In which case it would be hard to try to leverage the remaining time because on more stressful scenes you'd be overbudget. You could try to increase the resolution only in scenese you know are underbudget, but there's probably a better use of the GS than decompressing a texture or two.

I have actually used some GS compression schemes myself, primarily to get a lot more texture into memory - but it's not something I'd see as generally useful.

IPU decompression could have been used as an alternative/supplement to streaming. It's probably possible to compress 4 or 8bit CLUT data with jpeg. Then decompress it, not per frame, but in small chunks when the player comes near a portal or instead of loading it all from disc.
Iframe animated textures though, I'm sure has been used in some games, one very obvious example is the video-screen at the first dock in Beyond Good and Evil, you can actually see mpeg compression blocks in some frames of the texture.

I don't think you can use the IPU to compress CLUT textures - just the CLUTs themselves where the saving would be pretty minimal (and probably look nasty for any level of compression). On the whole you'd probably be better off getting the EE to unzip textures.

For animated textures - yes, the IPU is fine for that...

 

[Barbarian]

But PA graphs shows that GS is idle a lot if the time, so maybe it's more of a waist not to do compression, at least of the resident textures.

The problem is that GS decompression happens after synchronization with path3 and potentially can stall geometry xgkicks (if your transform loop happens to finish before decompression). There hasn't been conclusive evidence how this affect performance, compared with let's say uncompressed uploads. The problem is that most games use VQ compression to store 4x the amount of textures and that makes it impossible to run comprehensive benchmarks.