On 08/03/2011 01:58 PM, Ian Romanick wrote: > 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.
Pardon my ignorance, but why do hardware drivers need a decompressor? Bryan > 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev