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

[Rudolf Polzer]

On Sun, Aug 07, 2011 at 06:48:39PM -0700, Jose Fonseca wrote:
> 
> 
> ----- Original Message -----
> > On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > On 08/03/2011 12:11 PM, Bryan Cain wrote:
> > > > On 08/03/2011 01:58 PM, Ian Romanick wrote:
> > > >> I think this solves the issue for the compressor and for the
> > > >> software
> > > >> decompressor.  I don't think this solves the problem for the
> > > >> decompressor for hardware drivers, so that may still pose a
> > > >> problem for
> > > >> Linux distros.
> > > > 
> > > > Pardon my ignorance, but why do hardware drivers need a
> > > > decompressor?
> > > 
> > > To quote the EXT_texture_compression_s3tc spec:
> > > 
> > >     WARNING:  Vendors able to support S3TC texture compression in
> > >     Direct3D
> > >     drivers do not necessarily have the right to use the same
> > > functionality in
> > >     OpenGL.
> > > 
> > > This is the same issue that Linux distros have with
> > > ARB_texture_float
> > > being enabled in hardware drivers.  The hardware may implement the
> > > functionality, and the hardware vendor may have some license for
> > > the
> > > patent, but that license may not cover making the functionality
> > > available in Mesa.  That S3 has sued Apple is some indication that
> > > these
> > > licenses may have very narrow scope.
> 
> > Why should exactly Mesa be the one to have IP rights then? Mesa
> > doesn't feed
> > S3TC data anywhere, when using S2TC or another alternative.
> 
> > Feeding self-compressed S2TC data is no issue, as it doesn't use any
> > of the
> > S3TC IP. How the GPU actually decodes it, is none of Mesa's business.
> 
> It's not black and white: there can be both direct and indirect infringement on certain certain countries.  Please read patent law and/or contract a real lawyer.

I am German. So you say US patent law is more ridiculous than I could ever
imagine. To summarize:

If you feed data X to decoder circuit A, you may not need a patent license,
while feeding the VERY SAME data X to decoder circuit B you may suddenly need
one, ONLY because of the nature of how the circuits A and B work?

Ridiculous, but if this is law, we have to accept it.

> > Feeding precompressed data, however, is also none of Mesa's business
> > - and
> > also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa
> > already is
> > taking. 
> 
> False.  Mesa does NOT already do this.  It needs an additional component to enable S3TC, which is clearly marked as third-party IP sensitive, and advise people to contact a lawyer or obtain a license.
> 
> So please stop making false accusations.

Wrong, Mesa does. There is a driconf option that enables S3TC uploading (by
claiming extension support) even if libtxc_dxtn is not present. So the code
to do this already comes with Mesa, it just needs a configuration option to
be enabled.

Furthermore, IIRC some games ALREADY toggle this option on startup so they can
upload S3TC textures with Mesa (I forgot which game that is, though).

> > At least that's my opinion (IANAL too).
> 
> Don't get me wrong, I think S2TC's an interesting piece of work, but how do you dare to presume to tell us what we should or should not do in legal matters, while claiming to not be a lawyer, nor offering to pay legal expenses resulting from following your advice?  You must think really highly of yourself, or think we are really dumb to not have thought/discussed this till now.
> 
> We need this sort of "IANAL" opinions just as much as we need chronic tooth pain.

We have a problem and need to work towards a solution. I am not saying that my
solution is the right one. I am saying we have to work towards one, and need people
who are actually qualified to do it. I provided an idea, and we need to find ou
if this idea is viable.

As, "Mesa not supporting S3TC, ever" will be the end of linux gaming before it
really started.

Best regards,

Rudolf Polzer