A Possible Workaround For The S3TC Patent Situation

[Jonno]

There are other, unpatented, texture compression schemes, though.

Notably including RGTC, which is required by OpenGL 3.0, and already supported in Mesa on at least swrast, i965c, r300g, r600g and nouveau.
Mesa also supports LATC, but only only on swrast, r300g and r600g. LATC is, like S3TC, not required by any OpenGL version, but still supported by the blobs.

Developers of free games should probably investigate whether RGTC or LATC is suitable for their needs before committing to S2TC...

[sabriah]

Here are summaries of the image file format .gif patent story

http://www.kyzer.me.uk/essays/giflzw/

http://www.cloanto.com/users/mcb/19950127giflzw.html

http://burnallgifs.org/

Maybe they can serve how to handle this patent.

[baffledmollusc]

As I understand it (correct me if I'm wrong), the basic idea behind this workaround is that if games pass an S3TC compressed texture to mesa, it will pass it through to the graphics card which will uncompress it in hardware. Presumably the assumption here is that the graphics card vendor has a patent license for S3TC decode so all will be well.

Is this true, though? I have a vague memory of reading something somewhere that vendors' patent rights are very narrow and may only cover the use of the graphics hardware in combination with the proprietary driver, so having an open source driver tell the hardware, here, decode this, may still run afoul of the patent.

[divVerent]

You may be right, but Mesa already takes the risk of passing raw data through.

[divVerent]

Notably including RGTC, which is required by OpenGL 3.0, and already supported in Mesa on at least swrast, i965c, r300g, r600g and nouveau.
Mesa also supports LATC, but only only on swrast, r300g and r600g. LATC is, like S3TC, not required by any OpenGL version, but still supported by the blobs.

Developers of free games should probably investigate whether RGTC or LATC is suitable for their needs before committing to S2TC...

Neither is, as not enough graphics chipsets support them yet

RGTC also is only suitable for normalmaps - it is "Red/Green Texture Compression" after all and cannot encode a blue channel. And LATC only contains luminance and alpha.

Furthermore, from reading the RGTC extension spec, I am very sure it infringes on the S3TC patent, as it makes use of the very same compression technique (namely, inferred color values). In fact, it is identical to S3TC/DXT5 alpha channel encoding. Instead, RGTC and LATC are special cases that I maybe should support with a subset in my S2TC compressor too. I guess Mesa is taking the risk, because the format has a different name and RGTC support is not "universally known" to be mostly identical to one S3TC mode.

[oibaf]

A little update on the 0 A.D. hack as I remember more: on Linux it tried to initialize OpenGL, if S3TC ext is not available it setenv force_s3tc_enable=1 (env variable to force S3TC in mesa for S3TC decompression only) and reinitialize OpenGL. If S3TC ext is now available it will use it for decompressing only. Dunno if it still

Anyway I remember there were a lot of proposal to workaround the S3TC patent, e.g: http://cgit.freedesktop.org/~csimpso...tc-by-the-book
Just search on the ML for many others but no one was ever accepted.

This somewhat reminds me the attempts at proving the Riemann hypothesis...

[divVerent]

The beauty of this approach is that mesa does not HAVE to accept it - it works as external library and the burden of supporting it or not is purely in the hand of the distros.

[JanC]

1. Ubuntu (UK, but makes profit in the USA)

The Canonical "holding company" is officially registered on the Isle of Man, not in the UK, but it has subsidiaries in the US and the UK of course.

1. Suse (Provo, UT, USA)

SuSE is a German company, but they are owned by a US company and they have a US office, which could be attacked instead of course.

1. Debian (France, but is a widespread distro and has major download servers in the USA, possibly can risk losing them, probably better not)

Debian as a project on its own is not registered anywhere (it's not a legal entity) AFAIK, but SPI (which provides services to them, like handling their finances to some degree) is registered in the US as a non-profit. In theory Debian does not have to care, but individual developers and SPI might be vulnerable to lawsuits (even if I doubt SPI can be held legally responsible for anything Debian does, a lawsuit by a company with lots of cash could force them into bankruptcy, meanwhile blocking (or stealing away) important Debian projects fundings...).

1. CentOS (Belgium, [...])

Not sure where you get this from. I think the CentOS dnsmaster is Belgian, but there is no legal entity (at least none is listed on their website?), so individual contributors are responsible on their own?

[Tgui]

You don't understand how GPUs work or what texture compression accomplishes. DXTC/S3TC is specifically designed to be (near) instantly decompressable with a massively-parallel processor without needing to make a large number of memory accesses.

Deflate/gzip/lzma/etc. all require you to essentially start reading a file at the beginning and scanning through it to the part you want to access. That would mean a pixel shader goes from an O(1) operation on a simple texture access to an O(N) operation. You'd essentially slam the GPU back into the stone age by requiring that kind of texture access at runtime.

If you're implying that we should just store textures uncompressed in video memory, then you are making two very silly assumptions. First, you're assuming that having 1GB of video memory means that we can just slap uncompressed raw textures for a modern game into vmem and have room to spare; that's just ridiculously wrong. Second, you're assuming that the size of memory has no impact on performance of memory accesses inside of shaders, which is also wrong for any well-designed memory controller (especially when the underlying memory layout uses tiling to make any additional texture lookups in a particular shader likely to all closely coincide with the address of first lookup).

Thanks for the suggestion, though. I'm sure the hardware engineers and specification authors never thought of that before, ever. Your power of Internet forum logic will surely revolutionize the GPU industry and free them of the evil patent tyrants.

The proposed compression seems good enough to me. I really replied here because you made me laugh with your response.

[F.Ultra]

This is how trademarks work.

Sorry about that, I don't know why I wrote copyright when I meant trademark. I do know that you cannot loose your copyright so I simply blame this error to fatigue.

Back to patents however, if the court treats you differently because you haven't enforced your patent before then that is cause for appeal. It is a long tradition among patent holders to not enforce their patents until they see widespread usage (due to people feeling confident since the patents has never been enforced) and then strike out of nowhere and start to litigate. If I'm not mistaken, MP3 was such a case.

Lodsys is another example, they have only started to litigate this year if I'm not mistaken even though their oldest patent was filed in 1997.