FYI, relevant patents numbers are:
5,956,431
6,658,146
See more info here:
http://marc.theaimsgroup.com/?l=dri-devel&m=107704096508208&w=2
--- Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Mark Cass wrote:
> >
> > guys,
> >
> > finally have some good news. uploading DXT1, DXT3, and DXT5
> compressed
> > textures is working. i still need to implement compressed sub
> textures
> > and test very small textures.
> >
> > the issue was the tile size. i wrote an iterator into the driver to
> test
> > all possible tile sizes and found the one that worked. well,
> actually
> > two that worked. DXT1 has a different tile format than DXT3 and
> DXT5
> > which share the same format.
> Nice to hear it works.
>
> > my next question involves extensions. should the
> > GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc
> > extensions be enabled? the only reason i ask is that i think the
> > complete description of the extension includes the ability for the
> > driver to compress the textures. as was mentioned previously,
> adding
> > this ability to the driver could result in legal problems as s3tc
> is
> > intellectual property of S3/VIA inc.
> Ian has already answered the part about GL_ARB_texture_compression.
> GL_EXT_texture_compression_s3tc is a problem. You're not supposed to
> enable it if you can't guarantee that you can always handle the
> associated s3tc texture formats - and you can't guarantee that
> without
> software compression/decompression. But if you're not announcing it,
> nobody will use the dxt formats (even for precompressed textures) you
>
> just made to work (nwn and others will check if the extension is
> present). You could do what I did, don't enable the extension if
> software decompression/compression is unavailable per default, but
> make
> it possible to enable it via driconf. btw it's kinda ironic the
> extension can't be fully implemented - after all, we're talking about
> a
> Savage chip here!
>
> Just the other day, I had some strange idea how to write a s3tc
> compressor which would be legally unproblematic. I _think_ the format
>
> itself cannot be patented, only the compression apparatus (which is,
> btw, just math, but that's not the point here).
> So, use straight BTC[1] (block truncation coding)/CCC[2] (color cell
> compression) (there are plenty of references to these papers on the
> web)
> to compress! This works because s3tc is an improved btc/ccc, your
> textures would be correctly decompressionable by any s3tc
> decompressor.
> RGB_DXT1: use CCC. Instead of two base colors and two (or one,
> depending
> on the ordering of the colors) derived colors, only use the two base
> colors. That's all. Of course, quality would be much lower, only 1
> bit
> of the 2 bit index is used.
> RGB_DXT3: same as RGB_DXT1 for the color part. Alpha part is no
> problem
> (just uncompressed 4bit alpha anyway).
> RGB_DXT5. same as RGB_DXT1 for the color part. For alpha, use BTC
> (instead of 2 base values and 6 derived (or 4 derived and two fixed
> values, depending on the ordering of the two base values) only use
> the
> two base values. Not good quality (only 1 bit of the 3 bit index is
> used).
> RGBA_DXT1: problematic (not straight CCC). Probably non-infringing
> implementation would just use only one color, the second color would
> be
> used for the transparent case. So all pixels (safe the transparent
> ones)
> would end up with the same color within a block...
>
> Software decompresion though is a problem, if that's also covered by
> the
> patent. Using CCC/BTC would lead to errors, which could be very
> significant (unless you have compressed according to the above
> mentioned
> scheme, of course). In fact, in some cases the results could be
> completely wrong (for RGBA_DXT1, and RGBA_DXT5 at least, due to the
> different interpretation needed based on the ordering of the base
> values, which BTC/CCC decompressor would simply ignore).
>
> Roland
>
> [1] Image Compression Using Block Truncation Coding, Delp/Mitchell,
> IEEE
> Transactions on Communications 27: (9), 1979, pages 1335-1342
> [2] Two Bit/Pixel Full Color Encoding, Campbell et al., SIGGRAPH �86
> Conference Proceedings, Computer Graphics, Vol. 20, No. 4, August
> 1986,
> pages 215-223
>
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
