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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
