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

[Rudolf Polzer]

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.

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. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds
a data block as is. So, if anyone needs IP rights then, it's the author of the
game that comes with precompressed S3TC textures - and not the graphics driver!

Or does this cause a ridculous interpretation where Mesa COULD legally use this
interface ONLY if it verifies the bitstream of the texture to see that no S3TC
IP is used by it, or "fixes" it by turning S3TC into S2TC by a proper mapping
of pixel values?

At least that's my opinion (IANAL too).

Best regards,

Rudolf Polzer