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 [p...@scssoft.com]
Sent: Saturday, March 19, 2011 23:23
To: Jose Fonseca
Cc: Henri Verbeet; mesa-dev@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 ]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
