On Mon, Aug 1, 2011 at 11:44 AM, Rudolf Polzer <divver...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev