🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
OpenGL Texture Compression
Author
My apologies, I've already posted this question in the OpenGL section (here), but I wasn't getting a response. It is more of a Linux-specific thing anyway.
The details are in the linked post, but basically, I'm finding that some drivers are claiming to support GL_ARB_texture_compression, but not (apparantly) exposing any compressed formats, or having anything else in the extensions string identifying less "normal" formats.
Can anyone point me in the right direction?
ARB_texture_compression simply provides a framework for compressed textures. It is perfectly valid to support that extension without actually supporting any compressed format (IIRC, this is even mentioned in the extension specification).
Having said that, the state of texture compression is admittedly embarrassing in the open source drivers - not for any technical reasons, but because of software patents. The specification requires that a driver be able to compress textures on the fly, and to decompress textures on the CPU (software rendering in fallbacks); however, that is covered by software patents, which means that we are unable to legally implement it in many parts of the world.
In theory, the R300 driver supports texture compression, either in a castrated, incorrect way, where you can upload pre-compressed texture data (many games want to do that) but without on-the-fly compression. On-the-fly compression is also possible in theory, though you need an external library which (for the above-mentioned software patent issues) is not part of Mesa.
On the other hand, I have no idea how good that support actually is. I suspect that it is rather bug-ridden. As you can see, the whole compressed texturing area is a legal mess, which is why I've never tested it and tend to stay away from it. There are more crucial things to improve and bugs to fix (though not so long ago I was thinking about changing that - screw software patents; we'll see).
Bottom line advice for you as a developer: Don't insist on texture compression. As long as your game ships with uncompressed textures, it should be very easy to just fallback to normal textures if texture compression is not available. After all, the only difference is in a couple of flags how you upload the texture; once it's uploaded, there is no difference for you.
Yes, it'll be slower in texture-bandwidth limited scenarios; feel free to tell your users about that. I'd appreciate it if you also told them about the underlying reason: It's not because we (the driver developers) are stupid, it's because silly laws are limiting what we can do.
Having said that, the state of texture compression is admittedly embarrassing in the open source drivers - not for any technical reasons, but because of software patents. The specification requires that a driver be able to compress textures on the fly, and to decompress textures on the CPU (software rendering in fallbacks); however, that is covered by software patents, which means that we are unable to legally implement it in many parts of the world.
In theory, the R300 driver supports texture compression, either in a castrated, incorrect way, where you can upload pre-compressed texture data (many games want to do that) but without on-the-fly compression. On-the-fly compression is also possible in theory, though you need an external library which (for the above-mentioned software patent issues) is not part of Mesa.
On the other hand, I have no idea how good that support actually is. I suspect that it is rather bug-ridden. As you can see, the whole compressed texturing area is a legal mess, which is why I've never tested it and tend to stay away from it. There are more crucial things to improve and bugs to fix (though not so long ago I was thinking about changing that - screw software patents; we'll see).
Bottom line advice for you as a developer: Don't insist on texture compression. As long as your game ships with uncompressed textures, it should be very easy to just fallback to normal textures if texture compression is not available. After all, the only difference is in a couple of flags how you upload the texture; once it's uploaded, there is no difference for you.
Yes, it'll be slower in texture-bandwidth limited scenarios; feel free to tell your users about that. I'd appreciate it if you also told them about the underlying reason: It's not because we (the driver developers) are stupid, it's because silly laws are limiting what we can do.
Author
Thanks, that makes things a lot clearer. We don't insist on it, but on some of our target hardware it can make quite a difference, as it's quite low memory. But I can prevent most of the swapping by using 16-bit textures if compression isn't available.
Cheers!
Cheers!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
