[Mesa-dev] Naked DXTn support via ARB_texture_compression?

[Jose Fonseca]

Petr,

You don't believe that IHVs may have narrow licenses of the S3TC patent. How do you explain the statement:

   WARNING:  Vendors able to support S3TC texture compression in Direct3D
    drivers do not necessarily have the right to use the same functionality in
    OpenGL.

in http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt ?

This is just a piece of evidence. I heard this from several different people now.

I do not know what are the S3TC licensing terms from NVIDIA, ATI, Intel, or anybody in particular. 

S3TC patent seems to have been filed at least in US, Europe, and Japan, so this is not just an US issue as I've read several times elsewhere.

Truth is that NVIDIA managed to release an opensource product that does S3TC compression and decompression. Therefore, if IHVs or another entity saw enough economic incentive they could make Linux opensource drivers with S3TC support a reality just as well. It all boils down to economics.

If people are serious about supporting S3TC on open source drivers they should reach out the IHVs to ascertain the licensing status, perhaps convincing them to license for Linux open-source drivers, or license the patent themselves.


A much more interesting preposing is to invest in Khronos ETC format. It's nearly equivalent from a technical POV, and I believe that the IP is available in much less onerous terms. I'm not sure about hardware support in desktop GPUs, but most mobiles stacks support it.


Jose

________________________________________
From: Petr Sebor [petr at scssoft.com]
Sent: Saturday, March 19, 2011 23:23
To: Jose Fonseca
Cc: Henri Verbeet; mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

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 ]