[Mesa-dev] S2TC - yet another attempt to solve the "S3TC issue"

[Bryan Cain]

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
> <divverent at 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.