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

[Ben Skeggs]

On Wed, 2011-08-10 at 08:50 +0200, Marek Olšák wrote:
> 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.
I'm still very confused as to why this'd be a problem...  I can only
imagine how many patents get violated by just telling the GPU to render
a triangle.. Wtf is the difference here?

Ben.

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