[Mesa-dev] Naked DXTn support via ARB_texture_compression?

[Petr Sebor]

On 19.3.2011 16:33, Jose Fonseca wrote:
>> In this situation, the DXTn (S3TC) related agorithms were all implemented and used outside of the
>> Mesa body and as far as I can see, nothing of the patent applies here.
> Petr,
>
> You're assuming that the IHV licensed the S3TC patent for all uses of their hardware. Although NVIDIA appears to have done so (per http://code.google.com/p/nvidia-texture-tools/wiki/FAQ), other vendors may have not: the S3TC patent is often licensed to be used only on particular platforms. driver stacks, or use cases.
>
> Enabling  S3TC decompression on hardware for which IHV does not have a license covering Linux OS and Mesa driver stack may lead to S3 suing somebody -- the developer, the user, the linux distribution, or the hardware vendor -- typically whoever has the deepest  pocket.
>
> So although it _appears_(*) to be safe to enable S3TC decompression on NVIDIA GPUs, there is no reason to think that of AMD, or Intel GPUs.
>
> Jose
>
> (*) I am not a lawyer.

Jose,

you are probably better lawyer than I am. I haven't realized that such 
thing might happen - I mean - the need to have a license to use the hardware
on specific operating system and more, on a particular stack. That's 
absolutely totally crazy. Even though I personally internally don't 
believe* this
is the case, the truth is that I don't know. And I agree that knowing it 
is what really matters.

However, at least a part of your message carries good news. It happened 
quite some time ago, but you're right that nVidia na S3 cross-licensed
some of their technology, including S3TC. And according to the FAQ you 
have linked it seems it might be actually possible to realize the proposed
approach at least on their hardware if nothing else. That might be a 
nice first step.

(*) I _believe_ that the S3TC relates mainly to the hardware decoding. 
This is where it becomes useful when saving memory and bandwidth.
The situation when the hardware vendor obtains such narrow license - say 
- this chip on that operating system and such 3D stack sounds
pretty strange to me. But yes, it might be possible, but I somehow 
believe that AMD and Intel got the S3TC license under similar terms like
NV did. Just my $0.02.

Maybe the others (Intel, AMD) might (or might not) follow after it 
becomes more clear what is covered under their license?
It would be great if someone of Intel, AMD reading this list could shed 
some light on this.

However, even if Mesa for any reason decides not to implement the 
compressed format passthrough in well defined terms
of ARB_texture_compression, it is not a tragedy. I just thought that I 
could point out that there might be a simple solution
to have at least some S3TC support in the free GL stack. Where people 
would learn it is perfectly ok to ignore the implementation
ability to compress/decompress data on the fly when they already have 
precompressed data and there is a simple passthrough available.

And more, this is not a hack - it is well defined interface which you 
can already depend on at least with NV hardware
on Windows (this is what I can see here right now) and it was already 
used as the only way on some particular drivers in the past
(sorry, my memory prevents me to be more specific, I just know we just 
had to use it to get S3TC).

Regards,
Petr

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