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

Petr Sebor petr at scssoft.com
Sun Aug 7 15:44:28 PDT 2011

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.

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


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

More information about the mesa-dev mailing list