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

[Marek Olšák]

On Wed, Aug 10, 2011 at 7:11 AM, Rudolf Polzer <divverent at xonotic.org> wrote:
> On Tue, Aug 09, 2011 at 11:45:23PM +0200, Marek Olšák wrote:
>> On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> > I don't have time for a longer reply now, but I do think your S2TC work is interesting, and that you've successfully contoured the patent claims, at least for the decompression, as I didn't look at the compression bits.
>> >
>> > But, there was never anything you could have done to improve the situation for GPU S3TC decompression.  It's not just a US patent system vs the rest.  It's complex, but it's all in the archives, as it has all been discussed before.
>>
>> Well, actually, there is a solution. A solution which has not been
>> available until now.
>>
>> The solution is not to use GPU S3TC decompression, obviously. Instead,
>> let's use GPU S2TC decompression. We have integer opcode support
>> coming, right? We can use those to decompress S2TC textures, which
>> would be loaded as integer textures. Of course, we'd have to implement
>> filtering as well and maintain a few shader variants in case somebody
>> binds an S2TC texture, so that we can switch a shader to S2TC
>> decompression for a particular sampler.
>>
>> The only problem is S2TC can't correctly decompress every S3TC
>> texture, so we'd be noncompliant. Noncompliant is probably better than
>> not working at all. So what do you guys think?
>
> If we go there... wouldn't it be an alternative to trivially convert S3TC to
> S2TC, by mapping all pixel values to values that don't use inferred colors?

Not sure. It would be safer to avoid anything that assumes full
knowledge of S3TC.

>
> That way, we'd still be using the S3TC circuits, but we'd only feed S2TC
> into them. Would this be enough to evade the patent - as we'd basically not
> care if that circuit does any more than S2TC decoding?

I would rather avoid that circuit altogether.

>
> To exaggerate again: what if we upload null bytes into that decompressor
> circuit? The decoding algorithms would still run on the hardware, but all we
> would get out of it is it expanding a sequence of null bytes to 8 times its
> length. Would even this still infringe, just because that circuit is a S3TC
> decoder?

I think so.

>
> Obviously, the same quality loss would be incurred by this, which is - from my
> tests - big enough to consider such a decoder noncompliant. Because of this I
> would suggest that - if we go one of these two ways - we should add a separate
> extension string for support of S2TC.

The problem is there is no adoption of S2TC in the industry. The
current state is that Unigine products don't run without full S3TC.
Neither does the id Tech 4 engine. Most, if not all, D3D games
consider S3TC a standard. In order to succeed, S2TC must become a
standard too.

The OpenGL ARB cannot incorporate S3TC into a core spec anyway.
Perhaps they would be interested in S2TC as a temporary replacement.
Proprietary drivers could implement S2TC easily using their hardware
(patented) S3TC decoder. Mesa would have to decode it using shaders.
But there would be at least something in the core spec that is one-way
compatible with S3TC and has comparable quality, even though the
algorithms are different.

>
> You can see for yourself here (screenshot of a scene using S3TC-decoded-as-S2TC
> - note the already visible dithering moire that comes from the S2TC decoder
> case that handles S3TC without using color ramps):
>
> https://github.com/divVerent/s2tc/wiki/img/s3tcnv-dds-s2tc.png
>
> and here (texture comparison, temporary URL):
>
> http://rm.rm.rm-f.org/~xonotic/temp/s3tc-to-s2tc/
>
> Also, s2tc now comes with a tool to quickly convert S3TC to S2TC:
>
> https://github.com/divVerent/s2tc/blob/master/s2tc_from_s3tc.cpp
>
> Together:
>
> GL_EXT_texture_compression_s3tc:
>        - upload of any S3TC texture
>                - only possible if the HW vendor has a broad enough license of
>                  the patents, i.e. only possible for nouveau
>        - encoding of existing textures to S3TC or S2TC (here, S2TC is good
>          enough to claim compliance)
>
> GL_MESA_texture_compression_s2tc:
>        - upload of any S2TC texture
>                - decoding can take place using S3TC circuits, or using code on
>                  the GPU
>                - attempts to upload S3TC using this will yield reduced quality
>        - encoding of existing textures to S2TC
>        - uses same constants as S3TC for uploading the texture - basically,
>          these two extensions define the very same interface, but expect
>          different data
>
> I am currently "field testing" S2TC in Xonotic, and got no complaints about
> reduced texture quality yet (although I found a few non-optimal cases myself
> which I will fix by manually excluding these textures from S2TC compression
> - and the same places were already bad with AMD Compressonator, so I consider
> it good that these are a bit easier to find now). So, if we go this route, all
> I'd have to do for Xonotic, is to have it also accept the
> GL_MESA_texture_compression_s2tc extension string if the user/mod declares that
> the textures that come with it are S2TC.
>
> One other question: is the alpha encoding of DXT5 generally considered NOT
> covered by the S3TC patents? Personally I am unsure about that, as it depends
> a lot on HOW you interpret the S3TC patents. The only thing that makes the S3TC
> patents possibly not also include the alpha encoding, is the use of the word
> "color" - but exactly this may be enough to make it not apply there.

I don't see a problem with that. EXT_texture_compression_latc and 3dc
use the DXT5 alpha encoding for both luminance and alpha. rgtc is the
same as latc, but the components are swizzled to rg. There is already
a DXT5 alpha encoder/decoder included in Mesa to support rgtc, latc,
and 3dc. There are no IP claims for those extensions whatsoever.

Marek