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

[Petr Sebor]

On 4.8.2011 12:19, Rudolf Polzer wrote:
> On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote:
>> On 08/03/2011 12:11 PM, Bryan Cain wrote:
>>> 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.
Ian,

I think it is really not the same issue. The S3TC patent is about the 
algorithm itself,
not about copying blocks of memory. The quote from 
EXT_texture_compression_s3tc
only underlines the fact that Direct3D stack (both runtime and driver) 
does not have to provide
S3TC compression/decompression algorithm at all, whereas driver 
providing EXT_tc_s3tc
typically has to be able to compress the textures in the software (and 
thus implement the
patented stuff). Direct3D serves as a pass-through to the hardware, they 
don't have to mess
with the patent at all while the hw vendor typically has the 
decompression part covered.

> 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!
I had the similar argument several weeks ago. I have suggested that Mesa 
could use similar
approach I have seen several years ago with GL drivers on windows - ie. 
drivers reporting
DXTn formats in the available compressed format list through the 
ARB_texture_compression,
whereas _not_ listing EXT_tc_s3tc in the extension string, effectively 
doing the same thing as the
Direct3D, allowing a passthrough of such data. I can only guess that the 
vendor didn't have had the
compression part covered nor wanted to pay for that part at the given 
time. It worked well.

Regards,
Petr

--
Petr Sebor / SCS Software [ http://www.scssoft.com ]