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

[Rudolf Polzer]

On Wed, Aug 10, 2011 at 08:50:38AM +0200, Marek Olšák wrote:
> On Wed, Aug 10, 2011 at 7:11 AM, Rudolf Polzer <divverent at xonotic.org> wrote:
> > 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.

Sounds insane. What if triangle processing on the GPU uses patented algorithms?

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

Of course not, and it's unlikely any commercial vendor will have any interest
in that, as THEY can also just pay for the S3TC license.

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

Which is highly unlikely to ever happen, as I have no contacts into the
standards groups.

> The OpenGL ARB cannot incorporate S3TC into a core spec anyway.

But it already is core part of OpenGL 3.0.

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

Wouldn't that be abysmally slow? I do remember that trying to do integer
operations from a GLSL shader is one of the worst ideas one can have, see the
Bitcoin WebGL experiments, which ended up performing WORSE than a pure
JavaScript miner. And decoding S2TC requires lots of bit tests and shifts.

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

If that is for sure - I wonder if I can get a more official statement on this -
then I will include full DXT5 alpha encoding in the S2TC spec. This would
resolve the worst quality issues on S2TC we get in Xonotic (as we store
heightmaps for relief mapping in the alpha channel).

One question though - should S2TC then have its own texture formats?

What would be the timeline and procedure to get something into a core ARB spec?

Would this even be possible to complete till 2017 (when S3TC's patents expire)?
I assume it'd take many years, as complex business processes will have to be
executed for that.

So it might be better, and lead to faster adoption, to have a preliminary MESA
specific extension for this first.

Best regards,

Rudolf Polzer