[Mesa-dev] Naked DXTn support via ARB_texture_compression?

[Petr Sebor]

Hi,

I have not been watching the situation around the DXTn compressed texture
formats and Mesa closely for quite some time, but after trying to run 
our games
on Mesa (that is, the 7.11-dev, Gallium) instead of the proprietary binary
drivers, I was struck by the fact that there is still no native support for
handling compressed texture formats.

Well, this is an old story and I understand that there is a common (and 
probably
valid) fear from the possibility of being legally attacked because of 
using patented
algorithms, but maybe there is a simple and hopefully legal way, that 
might alleviate
the problem and make the life of many people a lot easier.

Motivation: We already have the compressed texture data, created either 
by a closed source
library (nvdxt) or some other tool that already had to tackle the legal 
issues. And moreover,
I am not interested in using on-the-fly texture 
compression/decompression features of Mesa
itself at all. I just want the texture data, represented by a binary 
blob to end up somewhere
in the hardware and I assume that copying such data around is pretty legal.

Quite some time ago, while reading ARB_texture_compression spec, I have 
hoticed that it is written
in a way that it explicitly allows the implementation to know about (and 
advertise) compressed
texture formats, without actually providing compression/decompression 
itself, yet - ofcourse,
with some limitations. Since then our codebase is equipped with the 
following code:

(and as far as I remember, at least in windows, there actually were 
drivers that didn't advertise
the S3TC extensions, yet listed the S3TC formats via the 
ARB_texture_compression, so this idea
is nothing new)

< .. snip .. >

// Check if the driver features on-the-fly compression to S3TC,
// we can be sure it will HW accelerate these formats as well.
self.cap.texture_compression_dxt.set(is_gl_supported("GL_EXT_texture_compression_s3tc"));

if (! self.cap.texture_compression_dxt) {
     // If such extension does not exist, try the last resort service.
     // Even though the driver does not support runtime compression, it 
can accept
     // (and probably HW accelerate) rendering in provided compressed 
texture formats we're enumerating below.
     GLint num_compressed_formats;
     self.glGetIntegerv(GL_NUM_COMPRESSED_TEXTURE_FORMATS, 
&num_compressed_formats);

     GLint *const compressed_formats(static_cast<GLint 
*>(alloca(sizeof(GLint) * num_compressed_formats)));
     self.glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, compressed_formats);

     bool texture_DXT1_support(false);
     // We're ignoring DXT3, we don't use it.
     bool texture_DXT5_support(false);

     // Check for DXT1 and DXT5 formats only, we don't use DXT3
     for (GLint idx = 0; idx < num_compressed_formats; ++idx) {
         if (compressed_formats[idx] == GL_COMPRESSED_RGB_S3TC_DXT1_EXT) {
             texture_DXT1_support = true;
             message(GL_MESSAGE "Enumerated DXT1 compressed texture 
format.");
         }
         else if (compressed_formats[idx] == 
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT) {
             texture_DXT5_support = true;
             message(GL_MESSAGE "Enumerated DXT5 compressed texture 
format.");
         }
     }

     self.cap.texture_compression_dxt.set(texture_DXT1_support || 
texture_DXT5_support);
}
< .. snip .. >

Sure, this imposes some limitations like ... for example, not being able 
to use glCompressedTexSubImage
with full texture extents, but that is typically not a problem for many 
games/applications.

So, having the Mesa to provide only the way to copy the compressed data 
to the hardware
with the native compressed format support would really save the day, at 
least for anyone
who just wants to use the feature of the hardware he/she owns, without 
actually using the
patented algorithms.

I have been looking sparsely over the Mesa code, thinking first I might 
just hack around the idea
a present it with the patch, but it would probably end up just like this 
- a hack, that should
be better architected in by someone fluent with the Mesa source.

I know that at least our games would benefit from this feature immediately,
but I guess Wine people might welcome this as well, where 'benefit' 
means - do not have to
painfully install the external DXT library, which is very likely not 
needed at all.

What are your opinions? It it something that might be possible to do 
within Mesa?

Kind regards,
Petr Sebor

--
Petr Sebor / SCS Software [ http://www.scssoft.com ]