Direct Rendering Infrastructure

On Wed, Dec 18, 2002 at 10:14:16PM -0500, Geoffrey Antos wrote:
> I believe that it is safe to go ahead and implement S3TC texture 
> decompression code in DRI.
> 
><snip>
> 
> Thus, there are many indications that S3TC can be used for Open Source
> projects without fear.

You don't understand how patents work, do you?  All of those people
(except OpenIL, anyway) have licensed the algorithm itself.  The algorithm
is freely-available (it's even part of the patent documents).  The problem
is that S3 haven't released the patent to the public domain, and so they
can sue whomever they want if they're using the patent without an
appropriate license.  Just because they haven't sued OpenIL doesn't mean
they won't.  Considering the financial state S3/SonicBlue are in, I
wouldn't be too surprised if they soon become one of the many companies who
only stay in business because they decide to arbitrarily assert their
patent rights.

Patents aren't something which go away if they're not enforced (unlike
trademarks).

By implementing S3TC without a patent license, the DRI team would be
opening the DRI project up for potential litigation.

-- 
http://trikuare.cx

On Wed, 18 Dec 2002, magenta wrote:
>
> By implementing S3TC without a patent license, the DRI team would be
> opening the DRI project up for potential litigation.

On the other hand, by being too timid, the DRI team can also eventually
doom itself to obscurity. If everybody else supports S3TC, and popular
games (which accounts for about 99% of all the 3D market in the world
right now) need it - like DOOM III apparently will do - then at some point
the relevance of DRI becomes less.

You have to balance things out. Yes, the US is litiginous, and clearly way
too much so. Is the answer to just cower in a hole and hope it passes?
Maybe. And maybe not.

Sw patents are bad. You can rant and rail against them all you want, but
as things stand now, a large portion of the badness is the _fear_ they
spread. I think allowing that fear to take over is just giving up entirely
on it.

		Linus

Am Donnerstag, 19. Dezember 2002 05:10 schrieb Linus Torvalds:
> On Wed, 18 Dec 2002, magenta wrote:
> > By implementing S3TC without a patent license, the DRI team would be
> > opening the DRI project up for potential litigation.
>
> On the other hand, by being too timid, the DRI team can also eventually
> doom itself to obscurity. If everybody else supports S3TC, and popular
> games (which accounts for about 99% of all the 3D market in the world
> right now) need it - like DOOM III apparently will do - then at some point
> the relevance of DRI becomes less.
>
> You have to balance things out. Yes, the US is litiginous, and clearly way
> too much so. Is the answer to just cower in a hole and hope it passes?
> Maybe. And maybe not.
>
> Sw patents are bad. You can rant and rail against them all you want, but
> as things stand now, a large portion of the badness is the _fear_ they
> spread. I think allowing that fear to take over is just giving up entirely
> on it.

As always, you're "our" man, Linus!
Welcome home to Europe...;-)

But without kidding, couldn't you as THE well known OSS proponent get in 
contact with VIA the owner of S3?

Several people (even Brian Paul) tried to get some wisdom out of them but they 
didn't get any response, yet ;-(

Regards and if we didn't "read" each other in the next days

Marry Christmas

-Dieter

Am Donnerstag, 19. Dezember 2002 05:40 schrieb Dieter N=FCtzel:
> Am Donnerstag, 19. Dezember 2002 05:10 schrieb Linus Torvalds:

> Marry Christmas

Ever anger with Marry... *LOL*

Merry Christmas!

=2DDieter

On Wed, Dec 18, 2002 at 08:10:30PM -0800, Linus Torvalds wrote:
> 
> You have to balance things out. Yes, the US is litiginous, and clearly way
> too much so. Is the answer to just cower in a hole and hope it passes?
> Maybe. And maybe not.

Maybe the proper course of action would be to try to come up with a
workalike mechanism which doesn't infringe on the patent.  For example,
using an approximation of the actual algorithm.  I seem to recall that the
S3TC algorithm is basically a simple "store every corner of an NxN square
at full precision and store the gradients at a lower precision"
algorithm...

Also, what about doing hardware-only support, and just breaking for
software fallback?  Then it'd be up to the hardware (which ostensibly has a
license) to implement the algorithm.

-- 
http://trikuare.cx

On Wednesday 18 December 2002 11:20 pm, you wrote:
> On Wed, Dec 18, 2002 at 08:10:30PM -0800, Linus Torvalds wrote:
> > 
> > You have to balance things out. Yes, the US is litiginous, and clearly way
> > too much so. Is the answer to just cower in a hole and hope it passes?
> > Maybe. And maybe not.
> 
> Maybe the proper course of action would be to try to come up with a
> workalike mechanism which doesn't infringe on the patent.  For example,
> using an approximation of the actual algorithm.  I seem to recall that the
> S3TC algorithm is basically a simple "store every corner of an NxN square
> at full precision and store the gradients at a lower precision"
> algorithm...
> 
> Also, what about doing hardware-only support, and just breaking for
> software fallback?  Then it'd be up to the hardware (which ostensibly has a
> license) to implement the algorithm.

What about just implementing it as a patch hosted outside the U.S.?
Leave the choice up to the users just like with decss.

On Wed, 18 Dec 2002, magenta wrote:
>
> Also, what about doing hardware-only support, and just breaking for
> software fallback?  Then it'd be up to the hardware (which ostensibly has a
> license) to implement the algorithm.

That sounds like a good approach (and almost certainly acceptable for
games, which at this point is the only user of S3TC, I guess)

			Linus

Nicholas Leippe wrote:

>On Wednesday 18 December 2002 11:20 pm, you wrote:
>  
>
>>On Wed, Dec 18, 2002 at 08:10:30PM -0800, Linus Torvalds wrote:
>>    
>>
>>>You have to balance things out. Yes, the US is litiginous, and clearly way
>>>too much so. Is the answer to just cower in a hole and hope it passes?
>>>Maybe. And maybe not.
>>>      
>>>
>>Maybe the proper course of action would be to try to come up with a
>>workalike mechanism which doesn't infringe on the patent.  For example,
>>using an approximation of the actual algorithm.  I seem to recall that the
>>S3TC algorithm is basically a simple "store every corner of an NxN square
>>at full precision and store the gradients at a lower precision"
>>algorithm...
>>
>>Also, what about doing hardware-only support, and just breaking for
>>software fallback?  Then it'd be up to the hardware (which ostensibly has a
>>license) to implement the algorithm.
>>    
>>
>
>What about just implementing it as a patch hosted outside the U.S.?
>Leave the choice up to the users just like with decss.
>

Bettr still. A loadable part of Mesa/ drivers. Have a simple default 
module that does nothing/ returns an error if S3TC (de)compression is 
requested. Then someone, out of reach of the patent, can write a version 
of the module that works. A single C file should work, built against the 
DRI/XF86/Mesa headers, and it replaces the default version. If at some 
later date S3/VIA decide we can use it, the infastructure is there. If 
needed for speed, the code could then be builtin instead of a module. 
Add in the hooks for a loadable module, is simply preparing for quick 
implementation when S3/VIA give the go ahead.

    -Thomas

On Wed, 18 Dec 2002, Linus Torvalds wrote:
> On Wed, 18 Dec 2002, magenta wrote:
> >
> > By implementing S3TC without a patent license, the DRI team would be
> > opening the DRI project up for potential litigation.
> 
> On the other hand, by being too timid, the DRI team can also eventually
> doom itself to obscurity. If everybody else supports S3TC, and popular
> games (which accounts for about 99% of all the 3D market in the world
> right now) need it - like DOOM III apparently will do - then at some point
> the relevance of DRI becomes less.
> 
> You have to balance things out. Yes, the US is litiginous, and clearly way
> too much so. Is the answer to just cower in a hole and hope it passes?
> Maybe. And maybe not.
> 
> Sw patents are bad. You can rant and rail against them all you want, but
> as things stand now, a large portion of the badness is the _fear_ they
> spread. I think allowing that fear to take over is just giving up entirely
> on it.

In general, I completely agree with Linus on the above.  One of my 
favorite quotes by Thomas Jefferson is something to the effect of, 
"The tree of liberty must be refreshed from time to time with the blood of 
patriots and tyrants. It is natural manure."

I think if the DRI does proceed to implement it - I believe many vendors 
will probably remove that code before they ship their product - think 
RedHat and MP3 support in RedHat 8.0.  It bothers me to do that, but in 
many ways it is understandable.  You must pick your battles to fight 
wisely.

-- 
//========================================================\\
||  D. Hageman                    <dhageman@...>  ||
\\========================================================//

Thomas Dodd wrote:
> 
> 
> Nicholas Leippe wrote:
> 
>> On Wednesday 18 December 2002 11:20 pm, you wrote:
>>  
>>
>>> On Wed, Dec 18, 2002 at 08:10:30PM -0800, Linus Torvalds wrote:
>>>   
>>>
>>>> You have to balance things out. Yes, the US is litiginous, and 
>>>> clearly way
>>>> too much so. Is the answer to just cower in a hole and hope it passes?
>>>> Maybe. And maybe not.
>>>>     
>>>
>>> Maybe the proper course of action would be to try to come up with a
>>> workalike mechanism which doesn't infringe on the patent.  For example,
>>> using an approximation of the actual algorithm.  I seem to recall 
>>> that the
>>> S3TC algorithm is basically a simple "store every corner of an NxN 
>>> square
>>> at full precision and store the gradients at a lower precision"
>>> algorithm...
>>>
>>> Also, what about doing hardware-only support, and just breaking for
>>> software fallback?  Then it'd be up to the hardware (which ostensibly 
>>> has a
>>> license) to implement the algorithm.
>>>   
>>
>>
>> What about just implementing it as a patch hosted outside the U.S.?
>> Leave the choice up to the users just like with decss.
>>
> 
> Bettr still. A loadable part of Mesa/ drivers. Have a simple default 
> module that does nothing/ returns an error if S3TC (de)compression is 
> requested. Then someone, out of reach of the patent, can write a version 
> of the module that works. A single C file should work, built against the 
> DRI/XF86/Mesa headers, and it replaces the default version. If at some 
> later date S3/VIA decide we can use it, the infastructure is there. If 
> needed for speed, the code could then be builtin instead of a module. 
> Add in the hooks for a loadable module, is simply preparing for quick 
> implementation when S3/VIA give the go ahead.

Mesa itself doesn't have any sort of module loading facility.

But I've prototyped some texture compression code and all the "interesting" 
bits are contained in the texcompress.c file.  If someone feels like going out 
on a limb they could try to flesh out the stubs in that file.  There are 
changes to other files (like texformat.h) that I'm sitting on but could 
probably be checked in safely.  With everything else in place (including minor 
updates to the DRI driver(s)) someone could probably produce a texcompress.o 
file that would do the job.

As for talking to S3, the contact I had was apparently a dead end.  With all 
the mergers/spin-offs/acquisitions that S3 has gone through in recent years 
(Sonic Blue, Via, Diamond, ATI) it's not clear who might even own the patents 
anymore.

-Brian

PS: I'll be on vacation from Dec 20 - Jan 5 and probably won't be able to do 
any of the above-mentioned stuff until next year.

magenta wrote:
 > You don't understand how patents work, do you?  All of those people
 > (except OpenIL, anyway) have licensed the algorithm itself.  The
 > algorithm is freely-available (it's even part of the patent
 > documents).  The problem is that S3 haven't released the patent to the
 > public domain, and so they can sue whomever they want if they're using
 > the patent without an appropriate license.

I believe the point was that since NVidia is distributing source code
implementing S3TC with an unrestrictive licence, that they are just as
vulnerable as DRI is.  They might have a licence for their own use of
the algorithm, but they can't transfer that licence to the rest of the
world.

This tends to imply to my non-lawyer eyes that the S3TC patent is very
unlikely to be strongly enforced.  If VIA wants to sue someone,
they'll sue the entity with assets first.  Or maybe they *have* made
such a broad licence grant to NVidia, allowing them to redistribute
the patent licence free of charge.  In which case DRI can just include
the S3TC code and use it under the NVidia licence.  Allowing one party
to redistribute patent rights but not another is hardly a "reasonable
and nondiscriminatory" licence.

Either way, DRI looks safe to me.  And remember that this isn't a DMCA
violation, just a patent issue.  No one is going to jail, and it would
be (non-legal advice here!) extraordinarily difficult to prove any
actual damages.  And there is no one involved with DRI with assets to
pay such an award anyway.  Really, the worst that can happen is that
you will be forced to take the code out.

Andy

-- 
Andrew J. Ross                NextBus Information Systems
Senior Software Engineer      Emeryville, CA
andy@...              http://www.nextbus.com
"Men go crazy in conflagrations.  They only get better one by one."
  - Sting (misquoted)

On Thu, Dec 19, 2002 at 10:59:24AM -0800, Andy Ross wrote:
> And there is no one involved with DRI with assets to
> pay such an award anyway.

Except all the distros.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html

On Thu, Dec 19, 2002 at 10:59:24AM -0800, Andy Ross wrote:
> magenta wrote:
>  > You don't understand how patents work, do you?  All of those people
>  > (except OpenIL, anyway) have licensed the algorithm itself.  The
>  > algorithm is freely-available (it's even part of the patent
>  > documents).  The problem is that S3 haven't released the patent to the
>  > public domain, and so they can sue whomever they want if they're using
>  > the patent without an appropriate license.
> 
> I believe the point was that since NVidia is distributing source code
> implementing S3TC with an unrestrictive licence, that they are just as
> vulnerable as DRI is.  They might have a licence for their own use of
> the algorithm, but they can't transfer that licence to the rest of the
> world.

But they're not transferring the license to others, they're just providing
a reference implementation.  nVidia themselves wouldn't be sued for it, but
someone releasing new software using that implementation could be.  It's
the same situation that a number of mp3 encoders were in a couple years
ago; Fraunhofer released a reference implementation for ISO specification
purposes, and then they turned around and sued everyone who used that
reference implementation in their own encoder.

> This tends to imply to my non-lawyer eyes that the S3TC patent is very
> unlikely to be strongly enforced.  If VIA wants to sue someone,
> they'll sue the entity with assets first.  Or maybe they *have* made
> such a broad licence grant to NVidia, allowing them to redistribute
> the patent licence free of charge.  In which case DRI can just include
> the S3TC code and use it under the NVidia licence.  Allowing one party
> to redistribute patent rights but not another is hardly a "reasonable
> and nondiscriminatory" licence.

But there's nothing about patents which requires them to be under a
reasonable or nondiscriminatory license.

> Either way, DRI looks safe to me.  And remember that this isn't a DMCA
> violation, just a patent issue.  No one is going to jail, and it would
> be (non-legal advice here!) extraordinarily difficult to prove any
> actual damages.  And there is no one involved with DRI with assets to
> pay such an award anyway.  Really, the worst that can happen is that
> you will be forced to take the code out.

Good point, in theory.  In practice, see how Fraunhofer handled their
compression patent.  Didn't they sue a lot of the free encoder makers for
damages based on the spurious claim that they were "funded by banner ads?"
(Not that DRI has banner ads anywhere, but it does/did have funding from
third-party sources, and a particularly twisted lawyer could claim that the
work itself is a form of funding...)

-- 
http://trikuare.cx

On Thu, 19 Dec 2002, Ian Romanick wrote:
>
> On Thu, Dec 19, 2002 at 10:59:24AM -0800, Andy Ross wrote:
> > And there is no one involved with DRI with assets to
> > pay such an award anyway.
> 
> Except all the distros.

I think that even wilful patent infringement only means "triple damages"  
(plus lawyers fees, but that doesn't "help" the company that sues).

And since DRI support for S3TC is likely to _help_ (or at least not
hinder) hardware companies to sell more hardware, I don't see what the
damages would be all about.

As far as I can tell, the whole S3TC patent thing only makes sense as a
way to make other graphics chip vendors license the technology, not as a
weapon against software projects. That's _regardless_ of whether they have
money or not.

			Linus

magenta wrote:
 > But they're not transferring the license to others, they're just
 > providing a reference implementation.  nVidia themselves wouldn't be
 > sued for it, but someone releasing new software using that
 > implementation could be.

By that same logic, DRI can't be sued for providing the code to
XFree86, you'd have to sue XFree86.  And XFree86 is immune from suits
because they only provide it to distribution vendors, who can't be
sued because you'd have to go after the users instead. :)

Remember this is a patent.  The IP isn't the code, it's the algorithm.
If NVidia can grant us a license to use the algorithm, then we can use
the algorithm.  If they can't, then they're equally as liable for
patent infringement because they're distributing infringing software
themselves.

None of that says that we won't get sued.  But the fact that NVidia
has not been asked to remove their code seems to me to be strong
evidence that VIA takes a liberal and reasonable view of patent
licenses for software implementations of the S3TC algorithm.  They may
not be bureaucratically set up to *grant* licenses to free software
implementations, but they aren't nailing anyone to crosses either.

 > Good point, in theory.  In practice, see how Fraunhofer handled
 > their compression patent.  Didn't they sue a lot of the free encoder
 > makers for damages based on the spurious claim that they were
 > "funded by banner ads?"

In fact, I don't believe they did.  They *threatened* to sue, and the
software was removed from download areas in a few cases.  I'm not
aware of any actual court proceedings or depositions that took place
regarding free software MP3 implementations.  Someone correct me if
I'm wrong.

Again, I'm not a lawyer.  But it would seem to be *very* hard for VIA
to claim damages from DRI distribution of an algorithm that is already
freely available.  At worst, they could force the algorithm's removal
from the code base.

Andy

-- 
Andrew J. Ross                NextBus Information Systems
Senior Software Engineer      Emeryville, CA
andy@...              http://www.nextbus.com
"Men go crazy in conflagrations.  They only get better one by one."
  - Sting (misquoted)

On Thu, Dec 19, 2002 at 11:32:02AM -0800, Linus Torvalds wrote:
> 
> On Thu, 19 Dec 2002, Ian Romanick wrote:
> >
> > On Thu, Dec 19, 2002 at 10:59:24AM -0800, Andy Ross wrote:
> > > And there is no one involved with DRI with assets to
> > > pay such an award anyway.
> > 
> > Except all the distros.
> 
> I think that even wilful patent infringement only means "triple damages"  
> (plus lawyers fees, but that doesn't "help" the company that sues).
> 
> And since DRI support for S3TC is likely to _help_ (or at least not
> hinder) hardware companies to sell more hardware, I don't see what the
> damages would be all about.

I think that VIA could make the claim that by offloading S3TC functionality
into software, it would damage their revenue because then hardware
manufacturers would no longer have to license S3TC themselves if the driver
just converts it to native textures if it's not available in silicon.

-- 
http://trikuare.cx

Ian Romanick wrote:
 > Andy Ross wrote:
 > > And there is no one involved with DRI with assets to pay such an
 > > award anyway.
 >
 > Except all the distros.

How is that an argument against DRI implementing S3TC?  If the
distribution vendors don't want to ship it because of liability
concerns, then they don't have to.  Red Hat did this with the MP3
software in 8.0, for example.  You aren't arguing that free software
MP3 implementations shouldn't have been written in the first place, are
you?

Andy

-- 
Andrew J. Ross                NextBus Information Systems
Senior Software Engineer      Emeryville, CA
andy@...              http://www.nextbus.com
"Men go crazy in conflagrations.  They only get better one by one."
  - Sting (misquoted)

Geoffrey Antos wrote:
> I believe that it is safe to go ahead and implement S3TC texture 
> decompression code in DRI.

I don't understand why it is not possible for DRI to support S3TC on 
hardware that implements it. In this case the DRI wouldn't be 
*implementing* S3TC, just handing over pre-compressed textures. Or am I 
misguided?

-d

On Thu, Dec 19, 2002 at 12:43:48PM -0800, Andy Ross wrote:
> magenta wrote:
>  > But they're not transferring the license to others, they're just
>  > providing a reference implementation.  nVidia themselves wouldn't be
>  > sued for it, but someone releasing new software using that
>  > implementation could be.
> 
> By that same logic, DRI can't be sued for providing the code to
> XFree86, you'd have to sue XFree86.  And XFree86 is immune from suits
> because they only provide it to distribution vendors, who can't be
> sued because you'd have to go after the users instead. :)

Good point.  Though you can also argue that the "providing" it ends when a
binary distribution happens (since again, the algorithm itself is given as
part of the patent documentation, and all that source code is is a
machine-readable form of an algorithm).

> None of that says that we won't get sued.  But the fact that NVidia
> has not been asked to remove their code seems to me to be strong
> evidence that VIA takes a liberal and reasonable view of patent
> licenses for software implementations of the S3TC algorithm.  They may
> not be bureaucratically set up to *grant* licenses to free software
> implementations, but they aren't nailing anyone to crosses either.

I think the best way would be to get an official response from VIA.

(BTW, when exactly did VIA buy out
Diamond/S3/SonicBlue/Empeg/Conglomeramania anyway?  I must have missed that
news.)

>  > Good point, in theory.  In practice, see how Fraunhofer handled
>  > their compression patent.  Didn't they sue a lot of the free encoder
>  > makers for damages based on the spurious claim that they were
>  > "funded by banner ads?"
> 
> In fact, I don't believe they did.  They *threatened* to sue, and the
> software was removed from download areas in a few cases.  I'm not
> aware of any actual court proceedings or depositions that took place
> regarding free software MP3 implementations.  Someone correct me if
> I'm wrong.

Hm, yeah, based on what I can find on Google, there were never any actual
lawsuits, only threats.

-- 
http://trikuare.cx

Am Donnerstag, 19. Dezember 2002 16:32 schrieb Thomas Dodd:
> Nicholas Leippe wrote:
> >On Wednesday 18 December 2002 11:20 pm, you wrote:
> >>On Wed, Dec 18, 2002 at 08:10:30PM -0800, Linus Torvalds wrote:
> >>>You have to balance things out. Yes, the US is litiginous, and clearly
> >>> way too much so. Is the answer to just cower in a hole and hope it
> >>> passes? Maybe. And maybe not.
> >>
> >>Maybe the proper course of action would be to try to come up with a
> >>workalike mechanism which doesn't infringe on the patent.  For example,
> >>using an approximation of the actual algorithm.  I seem to recall that
> >> the S3TC algorithm is basically a simple "store every corner of an NxN
> >> square at full precision and store the gradients at a lower precision"
> >>algorithm...
> >>
> >>Also, what about doing hardware-only support, and just breaking for
> >>software fallback?  Then it'd be up to the hardware (which ostensibly has
> >> a license) to implement the algorithm.
> >
> >What about just implementing it as a patch hosted outside the U.S.?
> >Leave the choice up to the users just like with decss.
>
> Bettr still. A loadable part of Mesa/ drivers. Have a simple default
> module that does nothing/ returns an error if S3TC (de)compression is
> requested. Then someone, out of reach of the patent, can write a version
> of the module that works. A single C file should work, built against the
> DRI/XF86/Mesa headers, and it replaces the default version. If at some
> later date S3/VIA decide we can use it, the infastructure is there. If
> needed for speed, the code could then be builtin instead of a module.
> Add in the hooks for a loadable module, is simply preparing for quick
> implementation when S3/VIA give the go ahead.

Couldn't this be a "general" API to get missing stuff (e.g. ATI's "Smooth 
Vision", "HyperZ" etc.) into the DRI? Something like to get (binary) addon 
modules into the tree.

What do you think?

-Dieter

On Thursday 19 December 2002 11:39 pm, you wrote:
> Couldn't this be a "general" API to get missing stuff (e.g. ATI's "Smooth 
> Vision", "HyperZ" etc.) into the DRI? Something like to get (binary) addon 
> modules into the tree.
> 
> What do you think?

Probably a very good idea--then vendors could publish very simple, small 
binary loadable objects (hals) that do so.  It would probably only be 
reasonable for such features that only need to be turned on/off somehow, as 
opposed to features that require more complicated interaction.  I suppose it 
should be possible to expose hooks for them, but that might incur too big a 
price.

Otoh, vendors might be even more scared from this as it's much easier to 
reverse engineer a small module that does exactly what you want to learn how 
to do than to learn the same thing reverse engineering an entire binary 
driver if that's indeed what they're afraid of... (of course, publishing 
something like this in the first place removes the need to reverse engineer 
it--except in the case of supporting other architectures).


Nick

> As for talking to S3, the contact I had was apparently a dead end.  With all 
> the mergers/spin-offs/acquisitions that S3 has gone through in recent years 
> (Sonic Blue, Via, Diamond, ATI) it's not clear who might even own the patents 
> anymore.
> 

I find it somehow ironic that the best way to find out who owns/enforces
the patent is to ignore them, and violate the patent.

-- 
Russ Dill <Russ.Dill@...>

On Fri, 20 Dec 2002, Russ Dill wrote:

> 
> > As for talking to S3, the contact I had was apparently a dead end.  With all 
> > the mergers/spin-offs/acquisitions that S3 has gone through in recent years 
> > (Sonic Blue, Via, Diamond, ATI) it's not clear who might even own the patents 
> > anymore.
> > 
> 
> I find it somehow ironic that the best way to find out who owns/enforces
> the patent is to ignore them, and violate the patent.

If you're not worried about a potential lawsuit, go for it.  No one's 
stopping you.

Adam

On Fri, Dec 20, 2002 at 03:54:59PM -0500, Adam K Kirchhoff wrote:
> > I find it somehow ironic that the best way to find out who owns/enforces
> > the patent is to ignore them, and violate the patent.
> 
> If you're not worried about a potential lawsuit, go for it.  No one's 
> stopping you.

Is it "patented technology" or "patented algorithm"? I mean - where that patent
works - in USA only, USA+EU or everywhere in the world?
What law will be broken by putting patched DRI binaries on polish server?

-- 
http://decopter.sf.net - free unrealistic helicopter simulator

Am Donnerstag, 19. Dezember 2002 19:02 schrieb Alan Cox:
> On Thu, 2002-12-19 at 04:40, Dieter N=FCtzel wrote:
> > But without kidding, couldn't you as THE well known OSS proponent get in
> > contact with VIA the owner of S3?
> >
> > Several people (even Brian Paul) tried to get some wisdom out of them b=
ut
> > they didn't get any response, yet ;-(
>
> I have a meeting with the vice president of VIA scheduled on Jan 2nd or
> 3rd. Thats not public info and S3TC isnt the primary item but I will
> mention it.

Sorry, second try. I had forgotten to CC DRI-Devel.

Alan,

what came out of this?

Regards,
	Dieter
=2D-=20
Dieter N=FCtzel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel at hamburg.de (replace at with @)

On Sun, 2003-02-23 at 11:24, Dieter N=C3=BCtzel wrote:
> > I have a meeting with the vice president of VIA scheduled on Jan 2nd or
> > 3rd. Thats not public info and S3TC isnt the primary item but I will
> > mention it.
>=20
> Sorry, second try. I had forgotten to CC DRI-Devel.
>=20
> Alan,
>=20
> what came out of this?

Slow progress. Stuff is happening in some areas but S3TC isn't one that yet
has answers. To start with VIA apparently are only one partner in S3

Now that there are patches available to support S3TC compressed textures
on Radeon cards, are there any plans to integrate those patches into the
DRI source tree?

Adam

On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
> Now that there are patches available to support S3TC compressed textures
> on Radeon cards, are there any plans to integrate those patches into the
> DRI source tree?

I think there is one little problem:

- S3TC included into DRI CVS
- DRI CVS copied into XFree86 CVS
- XFree86 makes release
- RedHat puts new XFree86 in distribution
- S3TC patent holder sues RedHat

So maybe it's better to put patches/binaries on unofficial websites and in p2p? 

-- 
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat their bodies
Usenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net

On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote:

> On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
> > Now that there are patches available to support S3TC compressed texture=
s
> > on Radeon cards, are there any plans to integrate those patches into th=
e
> > DRI source tree?
>
> I think there is one little problem:
>
> - S3TC included into DRI CVS
> - DRI CVS copied into XFree86 CVS
> - XFree86 makes release
> - RedHat puts new XFree86 in distribution
> - S3TC patent holder sues RedHat
>
> So maybe it's better to put patches/binaries on unofficial websites and i=
n p2p?

Why not just leave it up to RedHat, then, to either leave the code in or
pull it out?

Adam

On Sun, Dec 28, 2003 at 11:08:26AM -0500, Adam K Kirchhoff wrote:
> Why not just leave it up to RedHat, then, to either leave the code in or
> pull it out?

RedHat was just example. Point is that patent holder may sue anyone who:

- will release XFree86 version with S3TC support 
- has some money

And it is possible that some distribution would remove whole DRI support just
to not have problems with S3TC.

-- 
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat their bodies
Usenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net

Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff:
> On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote:
> > On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
> > > Now that there are patches available to support S3TC compressed
> > > textures on Radeon cards, are there any plans to integrate those
> > > patches into the DRI source tree?
> >
> > I think there is one little problem:
> >
> > - S3TC included into DRI CVS
> > - DRI CVS copied into XFree86 CVS
> > - XFree86 makes release
> > - RedHat puts new XFree86 in distribution
> > - S3TC patent holder sues RedHat
> >
> > So maybe it's better to put patches/binaries on unofficial websites and
> > in p2p?
>
> Why not just leave it up to RedHat, then, to either leave the code in or
> pull it out?

Very, very true!

That's exactly what I would have suggested.
There are NO "software patents" in the EU (EP=DC) at least here in Germany.

We have asked (S3/VIA etc.) so many times for advice, but haven't had any=20
definitive answer, even sometimes NO answer at all.

So let's put it in and see "what will happen".
Here in Europe (Germany) the patent "owner" have to "fight" (defend) his=20
patent. Without that it can be deleted...

Maybe we should host mesa3d and DRI in a "save" country.

Greetings,
	Dieter

=2D-=20
Dieter N=FCtzel
@home: <Dieter.Nuetzel () hamburg ! de>

Dieter N=FCtzel wrote:
> Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff:
>=20
>>On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote:
>>
>>>On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
>>>
>>>>Now that there are patches available to support S3TC compressed
>>>>textures on Radeon cards, are there any plans to integrate those
>>>>patches into the DRI source tree?
>>>
>>>I think there is one little problem:
>>>
>>>- S3TC included into DRI CVS
>>>- DRI CVS copied into XFree86 CVS
>>>- XFree86 makes release
>>>- RedHat puts new XFree86 in distribution
>>>- S3TC patent holder sues RedHat
>>>
>>>So maybe it's better to put patches/binaries on unofficial websites an=
d
>>>in p2p?
>>
>>Why not just leave it up to RedHat, then, to either leave the code in o=
r
>>pull it out?
>=20
>=20
> Very, very true!
>=20
> That's exactly what I would have suggested.
> There are NO "software patents" in the EU (EP=DC) at least here in Germ=
any.
>=20
> We have asked (S3/VIA etc.) so many times for advice, but haven't had a=
ny=20
> definitive answer, even sometimes NO answer at all.
>=20
> So let's put it in and see "what will happen".
> Here in Europe (Germany) the patent "owner" have to "fight" (defend) hi=
s=20
> patent. Without that it can be deleted...
>=20
> Maybe we should host mesa3d and DRI in a "save" country.

I think using an external library (such as the already mentioned stuff=20
from 3dfx) for compression/decompression would solve potential problems.=20
Just passing the already compressed textures to the chip should be no=20
problem IMHO, Mesa/DRI would just rely on the external library for=20
compression (and decompression for software fallbacks). So distributors=20
wouldn't have to worry, and end users could install the external library=20
if they want without the need to patch and compile everything.
Another possiblity would be to #ifdef everything out per default -=20
disabled code shouldn't be a problem (if some algorithm is patented, it=20
is open to the public anyway). That would still mean everybody needed to=20
compile Mesa/DRI themselves, though.

Roland
btw I don't think you can lose a patent, even in europe. You can lose=20
trademarks if you don't defend them. If a patent is actually valid and=20
can be enforced (bascially court will decide this, not patent office) is=20
a different matter of course.

Am Sonntag, 28. Dezember 2003 18:16 schrieb Roland Scheidegger:
> Dieter N=FCtzel wrote:
> > Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff:
> >>On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote:
> >>>On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
> >>>>Now that there are patches available to support S3TC compressed
> >>>>textures on Radeon cards, are there any plans to integrate those
> >>>>patches into the DRI source tree?
> >>>
> >>>I think there is one little problem:
> >>>
> >>>- S3TC included into DRI CVS
> >>>- DRI CVS copied into XFree86 CVS
> >>>- XFree86 makes release
> >>>- RedHat puts new XFree86 in distribution
> >>>- S3TC patent holder sues RedHat
> >>>
> >>>So maybe it's better to put patches/binaries on unofficial websites and
> >>>in p2p?
> >>
> >>Why not just leave it up to RedHat, then, to either leave the code in or
> >>pull it out?
> >
> > Very, very true!
> >
> > That's exactly what I would have suggested.
> > There are NO "software patents" in the EU (EP=DC) at least here in Germ=
any.
> >
> > We have asked (S3/VIA etc.) so many times for advice, but haven't had a=
ny
> > definitive answer, even sometimes NO answer at all.
> >
> > So let's put it in and see "what will happen".
> > Here in Europe (Germany) the patent "owner" have to "fight" (defend) his
> > patent. Without that it can be deleted...
> >
> > Maybe we should host mesa3d and DRI in a "save" country.
>
> I think using an external library (such as the already mentioned stuff
> from 3dfx) for compression/decompression would solve potential problems.
> Just passing the already compressed textures to the chip should be no
> problem IMHO, Mesa/DRI would just rely on the external library for
> compression (and decompression for software fallbacks). So distributors
> wouldn't have to worry, and end users could install the external library
> if they want without the need to patch and compile everything.
> Another possiblity would be to #ifdef everything out per default -
> disabled code shouldn't be a problem (if some algorithm is patented, it
> is open to the public anyway). That would still mean everybody needed to
> compile Mesa/DRI themselves, though.
>
> Roland
> btw I don't think you can lose a patent, even in europe. You can lose
> trademarks if you don't defend them.

True.

But someone can request a "patent action of nullity".

> If a patent is actually valid and=20
> can be enforced (bascially court will decide this, not patent office) is
> a different matter of course.

But we have NO "software patents" currently, here.

=2D-=20
Dieter N=FCtzel
@home: <Dieter.Nuetzel () hamburg ! de>

On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote:

> On Sun, Dec 28, 2003 at 11:08:26AM -0500, Adam K Kirchhoff wrote:
> > Why not just leave it up to RedHat, then, to either leave the code in o=
r
> > pull it out?
>
> RedHat was just example. Point is that patent holder may sue anyone who:
>
> - will release XFree86 version with S3TC support
> - has some money
>
> And it is possible that some distribution would remove whole DRI support =
just
> to not have problems with S3TC.

Then no one will download/purchase/use that distribution.  Their loss :-)

Adam

On Sul, 2003-12-28 at 16:55, Dieter N=C3=BCtzel wrote:
> We have asked (S3/VIA etc.) so many times for advice, but haven't had any=
=20
> definitive answer, even sometimes NO answer at all.

I don't think S3, VIA and friends even know who actually owns it right
now.

You need to distinguish between:
	An implementation of S3TC compression
	A tool that is using existing licensed S3TC compression aware hardware

The former is certainly covered by the patent. The latter does not seem
to be, no more than say an X86 application violates patents on aspects
of x86 CPU design

If someone can precisely define what the patch has in it and the patent
numbers again (I lost them) I can see if our patent/legal people will
take a look at that aspect and give an opinion

On Sul, 2003-12-28 at 17:16, Roland Scheidegger wrote:
> btw I don't think you can lose a patent, even in europe. You can lose 
> trademarks if you don't defend them. If a patent is actually valid and 
> can be enforced (bascially court will decide this, not patent office) is 
> a different matter of course.

In certain cases you can. Mostly by a process known as Estoppel (which
is just a very old word for a promise). The behaviour is very different
to that of trademarks however.

For example if I own a patent and I release code that uses that patent
and invite you to use it then it is likely that if I tried to sue you
for patent violation I'd lose. By my actions I made a promise to you not
to do so.

Now you know why every intel and other document contains "no patents
licensed" type clauses 8)

As far as i know, software patents are not even legal in europe yet.
Hopefully they won't ever be... So, at least in europe, there shouldn't
be any problem using S3TC compression algorithm. Well that's all i
wanted to say... Bye

Le lun 29/12/2003 =C3=A0 00:16, Alan Cox a =C3=A9crit :
> On Sul, 2003-12-28 at 17:16, Roland Scheidegger wrote:
> > btw I don't think you can lose a patent, even in europe. You can lose=20
> > trademarks if you don't defend them. If a patent is actually valid and=20
> > can be enforced (bascially court will decide this, not patent office) i=
s=20
> > a different matter of course.
>=20
> In certain cases you can. Mostly by a process known as Estoppel (which
> is just a very old word for a promise). The behaviour is very different
> to that of trademarks however.
>=20
> For example if I own a patent and I release code that uses that patent
> and invite you to use it then it is likely that if I tried to sue you
> for patent violation I'd lose. By my actions I made a promise to you not
> to do so.
>=20
> Now you know why every intel and other document contains "no patents
> licensed" type clauses 8)
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel

> I don't think S3, VIA and friends even know who actually owns it right
> now.

S3Graphics (subsiduary of VIA) is the patent holder with Nadeem Mohammad
being the contact person about licensing there.

-- Daniel, Epic Games Inc.

Adam K Kirchhoff wrote:
> Now that there are patches available to support S3TC compressed textures
> on Radeon cards, are there any plans to integrate those patches into the
> DRI source tree?

Until an agreement can be reached between the open-source community and 
the patent holder, IT WILL NEVER HAPPEN!  STOP ASKING!!!

On Mon, 29 Dec 2003, Ian Romanick wrote:

> Adam K Kirchhoff wrote:
> > Now that there are patches available to support S3TC compressed textures
> > on Radeon cards, are there any plans to integrate those patches into the
> > DRI source tree?
>
> Until an agreement can be reached between the open-source community and
> the patent holder, IT WILL NEVER HAPPEN!  STOP ASKING!!!

Why are you YELLING?!!!  It's an easy question that A) I've never heard
asked, and B) I've never heard a definative answer (just speculation that
pops up every few months, last time before the patches were even
available). There's no reason to cop an attitude.  Just politely answer:
"Due to the legal implications, it's not going to happen at the moment."
See how simple that is?

If it will never happen this should be noted *prominently* on the DRI
website in big bold letters.  Otherwise, when it becomes common knowledge
that their are patches available and that they aren't being applied to the
code base, you can expect a whole hell of a lot more people asking this
very simple question, and we wouldn't want to upset you any more than you
already are.

And then you shouldn't be surprised when peole stop using the open source
DRI drivers in favor of closed source drivers.

Adam

BTW, since I originally asked this question, the general tone of the
discussion has been positive and the general consensus seems to be that
simply uploading the compressed textures to the card, and allowing the
hardware to handle the decompression is not a violation of the patents in
question.

Perhaps you'd like to wait till we hear back from the legal people Alan
Cox has asked to take a look at the issue before you jump to your
decision.

Adam

On Mon, 29 Dec 2003, Ian Romanick wrote:

> Adam K Kirchhoff wrote:
> > Now that there are patches available to support S3TC compressed textures
> > on Radeon cards, are there any plans to integrate those patches into the
> > DRI source tree?
>
> Until an agreement can be reached between the open-source community and
> the patent holder, IT WILL NEVER HAPPEN!  STOP ASKING!!!
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Even if a decision isn't reached, or a compromise with the patent holder
isn't possible, knowing who the patent holder is might be nice - we're
doing Radeon drivers right now for our own OS (unfortunately DRI is a
little too Linux-specific :) and we could license it for ourselves if so desired.

Ian: wouldn't it be possible to have an "official patch", for compressed
texture stuff, that tracks the trees & releases?

The same way Freetype contains patented code, you can get the source, you
can compile it, the moment you use it for anything you need to go talk to
Apple's licensing guys..

-- 
Matt Sealey

----- Original Message ----- 
From: "Adam K Kirchhoff" <adamk@...>
To: "Ian Romanick" <idr@...>
Cc: "DRI developer's list" <dri-devel@...>
Sent: Monday, December 29, 2003 10:58 AM
Subject: Re: [Dri-devel] S3TC


> 
> BTW, since I originally asked this question, the general tone of the
> discussion has been positive and the general consensus seems to be that
> simply uploading the compressed textures to the card, and allowing the
> hardware to handle the decompression is not a violation of the patents in
> question.
> 
> Perhaps you'd like to wait till we hear back from the legal people Alan
> Cox has asked to take a look at the issue before you jump to your
> decision.
> 
> Adam
> 
> On Mon, 29 Dec 2003, Ian Romanick wrote:
> 
> > Adam K Kirchhoff wrote:
> > > Now that there are patches available to support S3TC compressed textures
> > > on Radeon cards, are there any plans to integrate those patches into the
> > > DRI source tree?
> >
> > Until an agreement can be reached between the open-source community and
> > the patent holder, IT WILL NEVER HAPPEN!  STOP ASKING!!!
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > Dri-devel@...
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

On Mon, 29 Dec 2003, Matt Sealey wrote:
> 
> Ian: wouldn't it be possible to have an "official patch", for compressed
> texture stuff, that tracks the trees & releases?

I think that would be good, if somebody maintains it. It's pretty much 
guaranteed that anybody who has a modern graphics card has already been 
licensed for the patent, since the hw manufacturers would have done so 
already. So using the patch should be entirely legal, even if the DRI 
project may not want to worry about it.

Especially a patch that only passes the compressed textures down to the
hardware - it might make sense to not even have a software fallback.  
After all, the only people who care about this patch are game users, and
those people likely do not want to see software fallbacks anyway. 

Once you do that, the software doesn't actually do anything that was 
patented. It's all in the hardware.

		Linus

I am not a lawyer.  None of what follows is legal advice.  Furthermore, 
I am speaking for myself alone, NOT my employer.

Adam K Kirchhoff wrote:
> On Mon, 29 Dec 2003, Ian Romanick wrote:
>>Adam K Kirchhoff wrote:
>>
>>>Now that there are patches available to support S3TC compressed textures
>>>on Radeon cards, are there any plans to integrate those patches into the
>>>DRI source tree?
>>
>>Until an agreement can be reached between the open-source community and
>>the patent holder, IT WILL NEVER HAPPEN!  STOP ASKING!!!
> 
> Why are you YELLING?!!!  It's an easy question that A) I've never heard
> asked, and B) I've never heard a definative answer (just speculation that
> pops up every few months, last time before the patches were even
> available). There's no reason to cop an attitude.  Just politely answer:
> "Due to the legal implications, it's not going to happen at the moment."
> See how simple that is?

Please forgive my frustration.  I was yelling because apparently Allen 
Akin, Mike Harris, Brian, myself, and others saying that it's not going 
to happen for *years* in a normal tone of voice hasn't sunk into 
people's heads.  At this point I'm strongly considering marking any 
message with the text "S3TC" in it as spam.

http://marc.theaimsgroup.com/?l=dri-devel&m=104993712407263&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=104983843411445&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=104982146721455&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=104981082705861&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=104979949127559&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=104427973828003&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=104032667532589&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=103264830309986&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=103236369425011&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=98056163703227&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=98035135807986&w=2
http://marc.theaimsgroup.com/?l=dri-devel&m=97941445129143&w=2

Note that the earliest of these messages is from September of 2000. 
That's over *3* years ago!

This has also been discussed to death at the weekly IRC meetings.

http://dri.sourceforge.net/IRC-logs/

> If it will never happen this should be noted *prominently* on the DRI
> website in big bold letters.  Otherwise, when it becomes common knowledge
> that their are patches available and that they aren't being applied to the
> code base, you can expect a whole hell of a lot more people asking this
> very simple question, and we wouldn't want to upset you any more than you
> already are.

My company has fairly strict policies about what sort of "policy" 
declarations like that employees can make for projects that we don't 
host.  Otherwise, I can assure you I would have put that on the DRI main 
page ages ago.

> And then you shouldn't be surprised when peole stop using the open source
> DRI drivers in favor of closed source drivers.

Right...the only cards that are supported by open-source and 
close-source drivers are R200-family chips on x86.  Be my guest.  Don't 
blame the distros or the open-source developers for not wanting to put 
their necks on the line and risk potentially years of legal woe for 
something as *trivial* as texture compression.  We can live without 
S3TC.  Games may not run as fast, but there are plenty of other areas in 
the R200 driver that can be optimized without risking any legal wrath.

If *you* want to start your own CVS repository or distribute driver 
binaries with patent encumbered technology, knock yourself out.  I 
strongly suspect that none of the people here that have anything to lose 
are going to take on that risk.

> It's pretty much guaranteed that anybody who has a modern 
> graphics card has already been licensed for the patent, 
> since the hw manufacturers would have done so already.

FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their
Xabre Windows OpenGL drivers though supported it via DirectX/Direct3D. I
guess they didn't feel like licensing the patent from a competitor.

From the GL_EXT_texture_compression_s3tc specification:

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

> Once you do that, the software doesn't actually do anything that was 
> patented. It's all in the hardware.

I believe exposing the GL_EXT_texture_compression_s3tc and
GL_ARB_texture_compression extensions implies the driver to handle S3TC
compression as an application can pass in uncompressed data, ask the driver
to compress it and then retrieve the compressed data.

-- Daniel, Epic Games Inc.

On Mon, 29 Dec 2003, Daniel Vogel wrote:
>
> FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their
> Xabre Windows OpenGL drivers though supported it via DirectX/Direct3D. I
> guess they didn't feel like licensing the patent from a competitor.

Interesting.

> I believe exposing the GL_EXT_texture_compression_s3tc and
> GL_ARB_texture_compression extensions implies the driver to handle S3TC
> compression as an application can pass in uncompressed data, ask the driver
> to compress it and then retrieve the compressed data.

Sure. But do apps actually _do_ that?

If the issue is to just make gamers happy, who cares what people _could_ 
do? And if it means that the code doesn't need to do something that might 
be patented, that's the right thing to do.

I would not be surprised if the SiS issue was exactly that: the hardware 
was licensed, but not the software that allowed people to just ask the 
driver to do the compression for them.

But I'm obviously not a lawyer. I do know that a lot of countries don't 
allow software patents anyway, and that it would be silly for the DRI 
project to not allow or encourage people in Europe to have their own 
patches.

			Linus

On Mon, 29 Dec 2003, Ian Romanick wrote:

> I am not a lawyer.  None of what follows is legal advice.  Furthermore,
> I am speaking for myself alone, NOT my employer.
>
> Adam K Kirchhoff wrote:
> > On Mon, 29 Dec 2003, Ian Romanick wrote:
> >>Adam K Kirchhoff wrote:
> >>
> >>>Now that there are patches available to support S3TC compressed textures
> >>>on Radeon cards, are there any plans to integrate those patches into the
> >>>DRI source tree?
> >>
> >>Until an agreement can be reached between the open-source community and
> >>the patent holder, IT WILL NEVER HAPPEN!  STOP ASKING!!!
> >
> > Why are you YELLING?!!!  It's an easy question that A) I've never heard
> > asked, and B) I've never heard a definative answer (just speculation that
> > pops up every few months, last time before the patches were even
> > available). There's no reason to cop an attitude.  Just politely answer:
> > "Due to the legal implications, it's not going to happen at the moment."
> > See how simple that is?
>
> Please forgive my frustration.  I was yelling because apparently Allen
> Akin, Mike Harris, Brian, myself, and others saying that it's not going
> to happen for *years* in a normal tone of voice hasn't sunk into
> people's heads.  At this point I'm strongly considering marking any
> message with the text "S3TC" in it as spam.
>
> http://marc.theaimsgroup.com/?l=dri-devel&m=104993712407263&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=104983843411445&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=104982146721455&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=104981082705861&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=104979949127559&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=104427973828003&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=104032667532589&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=103264830309986&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=103236369425011&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=98056163703227&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=98035135807986&w=2
> http://marc.theaimsgroup.com/?l=dri-devel&m=97941445129143&w=2

Thanks for the list.  You'll notice, however, that nowhere was it said by
a representative of the DRI project that S3TC support (even of uploading
precompressed textures) would never make it into the codebase till the
legal issues were resolved.

> Note that the earliest of these messages is from September of 2000.
> That's over *3* years ago!
>
> This has also been discussed to death at the weekly IRC meetings.
>
> http://dri.sourceforge.net/IRC-logs/

One of the first hits for "Direct Rendering" and S3TC on google is:

http://dri.sourceforge.net/faq.phtml

There is no answer to the question:

"Will the DRI ever get S3TC or could FXT1 be made to work in it's place?"

However, if you're now saying that a decision *has* been made, I would
highly recommend the FAQ be updated to show this.

> > If it will never happen this should be noted *prominently* on the DRI
> > website in big bold letters.  Otherwise, when it becomes common knowledge
> > that their are patches available and that they aren't being applied to the
> > code base, you can expect a whole hell of a lot more people asking this
> > very simple question, and we wouldn't want to upset you any more than you
> > already are.
>
> My company has fairly strict policies about what sort of "policy"
> declarations like that employees can make for projects that we don't
> host.  Otherwise, I can assure you I would have put that on the DRI main
> page ages ago.
>
> > And then you shouldn't be surprised when peole stop using the open source
> > DRI drivers in favor of closed source drivers.
>
> Right...the only cards that are supported by open-source and
> close-source drivers are R200-family chips on x86.  Be my guest.  Don't
> blame the distros or the open-source developers for not wanting to put
> their necks on the line and risk potentially years of legal woe for
> something as *trivial* as texture compression.  We can live without
> S3TC.  Games may not run as fast, but there are plenty of other areas in
> the R200 driver that can be optimized without risking any legal wrath.
>
> If *you* want to start your own CVS repository or distribute driver
> binaries with patent encumbered technology, knock yourself out.  I
> strongly suspect that none of the people here that have anything to lose
> are going to take on that risk.

You're still assuming that it'd be a patent violation to allow the
hardware to handle precompressed textures.  I'd just as soon wait till
Alan speaks with, and hears back from, the lawyers that he was going to
talk to this about.

Adam

Adam K Kirchhoff wrote:

> BTW, since I originally asked this question, the general tone of the
> discussion has been positive and the general consensus seems to be that
> simply uploading the compressed textures to the card, and allowing the
> hardware to handle the decompression is not a violation of the patents in
> question.
> 
> Perhaps you'd like to wait till we hear back from the legal people Alan
> Cox has asked to take a look at the issue before you jump to your
> decision.

Again, I'm not a lawyer and this is not legal advice.

As you've already found, you need to implement software decompression 
for rendering fallbacks.  I don't know of any way that could /not/ be 
problematic.

Daniel Vogel wrote:

> I believe exposing the GL_EXT_texture_compression_s3tc and
> GL_ARB_texture_compression extensions implies the driver to handle S3TC
> compression as an application can pass in uncompressed data, ask the driver
> to compress it and then retrieve the compressed data.

The spec allows that behavior, but does not require it.  The 
internalFormat specified to glTexImage2D is a *suggestion* that the 
driver can follow or not.  If the app asks for 
GL_COMPRESSED_RGBA_S3TC_DXT1_EXT, it may get GL_RGBA8 or 
GL_COMPRESSED_RGBA_TXT1_3DFX.  The final choice is entirely at the 
driver's discression.

See also http://marc.theaimsgroup.com/?l=dri-devel&m=107178093226572&w=2

> > I believe exposing the GL_EXT_texture_compression_s3tc and
> > GL_ARB_texture_compression extensions implies the driver to 
> > handle S3TC compression as an application can pass in 
> > uncompressed data, ask the driver to compress it and then 
> > retrieve the compressed data.
> 
> The spec allows that behavior, but does not require it.

D'oh, you're right.

-- Daniel, Epic Games Inc.

On Llu, 2003-12-29 at 19:52, Linus Torvalds wrote:
> Especially a patch that only passes the compressed textures down to the
> hardware - it might make sense to not even have a software fallback.  
> After all, the only people who care about this patch are game users, and
> those people likely do not want to see software fallbacks anyway. 

The hardware also supports decompression of the texture since it can be
told to render it offscreen at 1:1 magnification for each size, its not
the nicest way to do it perhaps but that does avoid software issues.

The only thing it seems you can't do is compress to S3TC in the driver,
but I really don't see why that is ever needed ?

As to a patch, moving texture compression formats in general to a
standardised interface for software and using dlopen to load arbitary
texture format libraries as needed is more modular anyway.

Am 2003.12.29 21:23:45 +0100 schrieb(en) Daniel Vogel:
[...]
>=20
> I believe exposing the GL_EXT_texture_compression_s3tc and
> GL_ARB_texture_compression extensions implies the driver to handle S3TC
> compression as an application can pass in uncompressed data, ask the driv=
er
> to compress it and then retrieve the compressed data.
>=20
> -- Daniel, Epic Games Inc.
>=20
why not just advertise 4 for GL_NUM_COMPRESSED_TEXTURE_FORMATS and
GL_COMPRESSED_RGB_DXT1_EXT GL_COMPRESSED_RGBA_DXT1_EXT
GL_COMPRESSED_RGBA_DXT3_EXT GL_COMPRESSED_RGBA_DXT5_EXT
for GL_COMPRESSED_TEXTURE_FORMATS

And dont advertise the GL_EXT_texture_compression_s3tc extension.

So programs would detect that theres no compression in the driver
but that its ok to use precompressed textures.

Andreas

> The only thing it seems you can't do is compress to S3TC in 
> the driver, but I really don't see why that is ever needed?

You need it if you store your source art in a different format on disk (e.g.
using jpeg) and don't want to deal with compression yourself - I believe
e.g. Quake III does this. Most other games at the moment (definitely ours)
just pass textures pre-compressed to the API.

-- Daniel, Epic Games Inc.