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 ]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
