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

[Rudolf Polzer]

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?

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?

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?

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.

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 am asking, as S2TC currently also avoids inferred alpha values. But that this
is necessary seems to generally not be agreed on, given lots of related stuff
on various mailing lists I find on the net. S2TC also has a branch "s2tc+alpha"
that uses full DXT5 alpha encoding instead, but I am unsure whether this branch
is still fulfilling the entire purpose of S2TC or not.

Best regards,

Rudolf Polzer