Compression Techniques in Consoles

[expletive]

I'm wondering if anyone knows the details of the hardware compression available in this and next-gen consoles. The root of htis is about the space limitations of the DVD-9 format but id like to understand if the new consoles have an advantage in terms of texture, video and audio, compression.

For audio, i think its pretty clear that all the new consoles will use compressed audio in the form of mp3 or wma so thats settled.

In terms of prerendedered video, the developers can use whatever quality they have room for, mpg4, wmvhd, mpg2, etc.

I guess my real question revolves around texture compression. What level of compression was available to PS2/Xbox and whats going to be available to 360/PS3? 2:1? 4:1? 8:1? Are these compression schemes available at all times or only under certain circumstances?

 

[arjan de lumens]

The "standard" texture compression method has for a very long time been S3TC (4bpp for RGB textures, 8bpp for RGBA textures); this hasn't changed in Xbox360/PS3/Revolution (of the previous generation, Xbox and Gamecube but not PS2 supported it too). The Xbox360 also supports 3Dc (8bpp, intended for use with normal maps).

 

[scificube]

edit:

Looks like G70 doesn't support 3Dc but instead v8u8 for 2:1 compression of normal maps. Didn't see that Dave's article had been updated.

 

[wireframe]

The Xbox360 also supports 3Dc (8bpp, intended for use with normal maps).

Doesn't Xbox/Xenos support the new 3Dc+ format like R520 and higher? 3Dc+ is 3Dc support for shadow and light maps, from what I've gathered on the subject. Not a huge distinction, I guess, but still.

 

[Heinrich4]

Perhaps SPEs could make a superior tax compression if compare "standard of the market" (in TRE in one SPE reaches something like 50:1 in mjpeg) s3tc/Dxtc/FXtc etc .

Maybe same occur in X360 Cpu Xenon with the extra registers in the VMX units .

(another day im read article with tax compression 15:2 with use s3tc+3Dc combined).

 

[Squeak]

If revolution had some kind of fast (enough) JPEGish decompression logic hardwired on Hollywood that would really make up for a lot of memory.
After all, it has been done before, Jaguar had scanline based DCT decompression hardware.

 

[ShootMyMonkey]

Dejavu...

As long as there is a hardware decompression on read, it's feasible, all right... but certainly not otherwise. For that matter, barring the really simple cases, almost any texture compression scheme you can dream up is not feasible unless it's supported in hardware.

Moreover, the quality with block DCT compression is just suspect, and that's especially going to be more noticeable if you're on an HD screen. MJPEG 50:1 is fine for pre-buffering movie frames before playing them back, but the quality is utterly hideous for textures, especially for textures used as numerical data. You can theoretically decode it in the pixel shaders, but any advantages you gain by the compression will be undone several hundred times over because you've made each texture read cost that much more. Again... if all you're doing is playing back a movie, probably not a big deal. When you're applying a dozen textures to each of hundreds of models... no way in hell.