I expect to be chewed out for this:

I've seen so many people question the idea of includeing s3tc code in the DRI. While I agree that it will be unlikely in the near future and that there are far more pressing issues with driver compatibility, I have run accross a way that some bright and determined individual might be able to start laying a foundation for it.

I would ask that any such individual please take a look at this: http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/
Read carefully and realize that Dr. David S. Touretzky put himself on the line for this. Transcriptions of his courtroom battle are linked to this site.

He was only able to prevail through his creativity and his logical argument. The patent issue with regard to s3tc is different, and I fully admit that I am not legally trained. So please do not take what I state here as any form of consent or legal advice. But, if someone were curious, determined and (perhaps) foolhardy enough to try something similar to what Dr. Touretzky has done with decss, then they might just get away with it.

The problem happens later. If an individual posts s3tc code standalone they're probably safe. But if that individual then posts how to include the code in the DRI, or any other opengl implementation without an official license, then chances are patent holders will attack those implementations, even if they don't include the code in official distributions. No one wants that to happen. Whether any lawsuit would hold up in court is irrelevant to the setback that would happen as a result.

S3tc is a mistake for open source period. Why opengl can even incorporate it on any operating system is beyond my comprehension. I read an article some time ago (I wish could I reference it properly) that questioned the future of texure compression of any sort. As newer graphics cards are capable of so many billions of triangles/particles per second we end up with millions of smaller surfaces. Texuring these surfaces becomes tedious, but the size of the texture needed to fill a surface becomes smaller, forgoing the need for texture compression. So while the number of surfaces increases the size of textures decreases. So holding this to be true, would we not need to implement vertex compression in such a way to compensate for this shift?

I don't know if this is an acurate prediction or even a valid argument. But it is somewhat compelling, nonetheless. I don't understand 3d operations well enough to have a very strong opinion on the matter.

As a side note: What ever happened to FXT1 with 3Dfx cards? I was under the impression that FXT1 could actually work with s3tc textures. If that were true, then would there have been a way to "trick" an application requiring s3tc to use the fxt1 extension? A wrapper of some sort. Or just purposely mislabel the extension name. Maybe that would have patent issues as well. But what about games like quake3 or rtcw that allow for options to be enabled like "compress_textures". Is this a "generic" compression of some sort? It does not implicitly state "s3tc_compress_textures" as does UT 2003. I was curious if anyone could help me understand that. Are some texures pre-compressed while others are compressed on the fly?


PlasmaJohn wrote:
Mike A. Harris wrote:

  
On Tue, 8 Apr 2003, Ian Molton wrote:

    
isnt it about time we got something like
--enable-dodgylegalstatus-s3tc-code then?
      

...

  
Doesn't matter to me much either way though.  If someone does 
stick any patent encumbered code into Mesa, DRI, or XFree86 
however, I hope they do it in an easy-to-rip-out manner, so that 
distribution maintainers don't have to go through hell.
    

I've been thinking about this.  How hard would it be to build this as a
loadable module/LD_PRELOAD hack?  

Earlier NWN betas had some issues with one of the OpenGL calls that some bright
young lad(?) hacked around with an LD_PRELOAD.

If the module is easily compilable, or even available as a binary in a sane
IP domain, then risk is the individual's.

BTW, this was such a pain to track down, so for posterity (and archives):

  Patent Number: 5,956,431

  System and method for fixed-rate block-based image compression with
  inferred pixel values.

  Date Filed:  Oct.  2, 1997
  Date Issued: Sep. 21, 1999

I've seen a reference that this is a superset of S3TC.

John



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel