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

[Brian Paul]

On Mon, Aug 1, 2011 at 11:44 AM, Rudolf Polzer <divverent at xonotic.org> wrote:
> 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?

Hi,

I saw the story about this on Phronix a couple weeks ago.  I like it.
As far as I'm concerned, I think it would be OK to integrate this into
Mesa to use as a fallback when libtxc_dxtn isn't available.

Does anyone else have an opinion?

-Brian