[Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"
brian.e.paul at gmail.com
Wed Aug 3 08:04:06 PDT 2011
On Mon, Aug 1, 2011 at 11:44 AM, Rudolf Polzer <divverent at xonotic.org> wrote:
> 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
> - 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
> "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
> - 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?
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?
More information about the mesa-dev