[Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"
divverent at xonotic.org
Mon Aug 1 10:44:01 PDT 2011
I developed, together with Maik Merten, a replacement for S3TC with the
- 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
- 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
- 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
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
- 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
- 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?
More information about the mesa-dev