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

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/03/2011 08:04 AM, Brian Paul wrote:
> 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?

I think this solves the issue for the compressor and for the software
decompressor.  I don't think this solves the problem for the
decompressor for hardware drivers, so that may still pose a problem for
Linux distros.

Of course, all of this may actually be irrelevant soon:

http://www.litigatingapple.com/blog/2011/7/24/why-htcs-courtship-of-s3-might-be-too-clever-by-half.html

I think the ideal solution would be to have something in core Mesa that
could eventually evolve into full S3TC support.  When this happens, I
don't think libtxc_dxtn is the best answer.  I think libsquish
(http://code.google.com/p/libsquish/) is probably a better answer.  This
library is used in other projects, and it has quite a bit more optimized
implementation.

What we really want is to just do the compression on the GPU, but that's
a bit larger project.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk45ml4ACgkQX1gOwKyEAw9A7wCeL5ZUq/9uGekga8n+Okc64hFT
qmgAoIEWClN8Tsc19ZqXS41BBfGa8ujX
=+djR
-----END PGP SIGNATURE-----