[Dri-devel] another texture compression patch (hopefully "IP" safe)

[Roland S. <rsc...@hi...>]

ok, here's another attempt, which uses an external dxtn library (patch 
against current Mesa cvs trunk).

There is a new configuration option to enable the s3tc extension even if 
the external library is not available (useful for games such as nwn, 
ut2k3 which use precompressed textures), though maybe it doesn't belong 
in that configuration section. You should probably not enable this 
globally, as some apps might try to compress textures on-the-fly and 
fail (the ChooseTextureFormat function doesn't know if it's called from 
store_compressed_teximage or store_teximage).
It is also possible to force compression of textures, obviously only if 
you have the dxtn library installed (should get ignored otherwise). This 
could be useful if you have some memory-challenged chips such as 8/16 MB 
M7. Don't know if this is a good option though, it seems to be very 
problematic. It works well with things like QuakeIII (QuakeIII will only 
compress textures without alpha components if you don't force it) or 
rtcw (compresses almost no of its textures), but fails miserably in 
other apps (for instance the really old UT, it works but the game gets 
really slow - I suspect it constantly reuploads some textures, 
everything requiring some sort of dynamic textures will have performance 
issues). Furthermore, some apps will fail (for instance some cubemap 
demo here will generate lots of mesa user errors if this is enabled, it 
will fail for all apps using anything except 2d and cube targets). This 
option also required some mesa changes (mesa based its decision if a 
format is compressed or not on the supplied internalFormat parameter, 
and not based on what format was actually chosen). These changes are 
probably not very nice, OTOH mesa could not deal with the case that if a 
compressed texture format is suggested by the app but a uncompressed 
format was returned by the ChooseTextureFormat function (which is legal 
to do) at all. It also doesn't seem to be legal according to the GL spec 
to return a compressed format if it isn't explicitly requested. I'm a 
bit puzzled too about the generic compressed formats, since it's not 
allowed to base the format decision on the target param - AFAIK there 
are no compressed formats which will work with all targets, making this 
useless?

The external library is just hooked in with dlopen/dlsym stuff - not 
sure how portable this is.
The compression routines seem to be a bit on the slow side, but at least 
they work. No lame comments please about the code quality in the 
library, I know it's crappy (but feel free to improve it...). I guess 
the overhead for fetching single pixels is very significant, but is 
shouldn't be used too often probably.
I've considered using the texel2 library from 
http://glide.sourceforge.net/ instead, but there is IMHO too much 
"voodoo stuff" in there, since the sole reason for the external dxtn 
library is to avoid potential IP problems it should IMHO be as small as 
possible. The library will almost certainly not work correctly on 
big-endian systems, and it relies on some mesa constants for the GLchan 
format which is not nice. I don't know if the compile parameters used 
make sense, they are fresh from google ;-).

Comments (technical, political, legal...)?

If some parts have any chance to get applied, I'm happy to rip out the 
unacceptable stuff, correct the bugs I've probably included and resubmit 
another patch...

Roland