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