[Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"

[Rudolf Polzer]

Hi,

I developed, together with Maik Merten, a replacement for S3TC with the
following properties:

- does not use any "interesting" algorithms (no color ramps, each 4x4 block is
  just a 2 colors palette - basically, this is Color Cell Compression from
  August 1986)
- is perfectly decodable by any S3TC decoder
- can "somewhat" (at a noticeable quality loss) attempt to decode S3TC
- due to the simpler nature of the algorithm, it outperforms the S3TC
  libtxc_dxtn
- due to the compression being simpler, it was easier to write a good
  compression algorithm for it, and it sometimes yields better quality than
  NVidia Texture Tools encoding to "full" S3TC

It is called S2TC because each block only has 2 colors, and expands to "Super
Simple Texture Compression".

It comes in form of a libtxc_dxtn replacement library, so it can be used with
Mesa right now.

You can find more info on

https://github.com/divVerent/s2tc/wiki

including quality comparison pictures that compare it to "full" S3TC.

When used in conjunction with an OpenGL driver, this would mean:

- when a precompressed texture is uploaded, nothing changes - it is uploaded as
  "full" S3TC
- when an uncompressed texture is uploaded as a compressed format, it is converted
  using the S2TC encoder, which typically yields less quality than a S3TC encoder,
  but still renders correctly and usually "good enough" (see screenshots on my
  wiki)
- in case a software fallback hits (or llvmpipe is used), S2TC is used for
  decoding - due to some bit values only being defined in the full S3TC format
  spec, this will be somewhat wrong and yields reduced quality when precompressed
  S3TC textures are used
- I believe this suffices to claim support for GL_EXT_texture_compression_s3tc
  without having an "actual" S3TC compressor, as compressing to a sub-format of
  S3TC is the same as just having a less clever S3TC compressor. Decompressing being
  incorrect (but still good enough for most uses) in case of software fallbacks
  however may be a problem, but then one could still instead upload it to the
  GPU, let it decode it, and download the decoded texture instead

The question now is:

- does Mesa have any interest in integrating this method (doesn't have to be my
  reference implementation, which implements quite many selectable variations
  of the encoding methods), and still using full S3TC if a libtxc_dxtn is found?
- or would Mesa be interested in linking to this implementation as an alternative
  to "full" libtxc_dxtn especially for the USA, as it's likely that less
  licenses are required to use this method? One possible implementation BTW could
  be Linux distros shipping S2TC libtxc_dxtn by default, and providing a "simple"
  way for users to upgrade to a full S3TC library, if they are aware of the issues
  with it and see themselves not affected by them?

Best regards,

Rudolf Polzer