Sign in to follow this  
subi211

Loading compressed textures through MESA

Recommended Posts

subi211    137
(I apologise, this is a cross post. I originally posted this in the Linux section, but according to the stats no-one has even read it there :) )

[color="#1C2837"][size="2"]At the moment, if I want to use compressed textures in my game I have to have GL do it during the upload. This is obviously slower than I'd like, so I'd prefer to compress the textures offline and load the compressed data directly using glCompressedTexImage2D.

This works perfectly fine on Windows using DXT1, 3 and 5. However, once I get to Linux I have problems.[/size][/color]
[color="#1C2837"] [/color]
[color="#1C2837"][size="2"]One machine has an Intel 915GM running Mesa 7.7.1 on Mesa DRI Intel which supports only FXT1 (a format developed by 3DFX as a rival to S3TC in 1999 which suffers from lack of adoption). It'll compress textures to FXT1 through glTexImage2D just fine, but point blank refuses to load them through glCompressedTexImage2D. Even if I use glGetCompressedTexImage to get data compressed by glTexImage2D. Also, I have the 3DFX encoder source, and none of the 4 different flavours of FXT1 (mixed, hi, chroma, and alpha) are the same as what glCompressedTexImage2D is returning on this machine.
[/size][/color]
[color="#1C2837"][size="2"]My other machine has a Radeon 9800 in it, running Mesa 7.7.1 on Mesa DRI R300. This supports SRGB_ALPHA_S3TC_DXT1, 3 and 5, and again will compress textures during upload. However, this time [/size][/color][color="#1C2837"][size="2"]glCompressedTexImage2D [/size][/color][color="#1C2837"][size="2"]doesn't just fail, it bombs out with "Mesa 7.7.1 implimentation error: unexpected internalFormat 0x8c4f in radeonChooseTextureFormat" (0x8c4f being [/size][/color][color="#1C2837"][size="2"]SRGB_ALPHA_S3TC_DXT5 in this case).[/size][/color]
[color="#1C2837"][size="2"]
So, two questions: Does MESA actually support loading compressed textures (I know it's an area under development), and if so, exactly what flavour of FXT/DXT does it accept and where can I get an offline encoder for it?[/size][/color]
[color="#1C2837"] [/color]
[color="#1C2837"][size="2"]Thanks.[/size][/color]
[color="#1C2837"] [/color]

Share this post


Link to post
Share on other sites
subi211    137
Also, and I accept that this may be something of an obvious question, what exactly is the difference between (for example) GL_COMPRESSED_RGBA_S3TC_DXT5_EXT and GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT? As far as I know DXT5 is a standard method, so why two different formats?

Share this post


Link to post
Share on other sites
Yann L    1802
[quote name='subi211' timestamp='1302861732' post='4798722']
Also, and I accept that this may be something of an obvious question, what exactly is the difference between (for example) GL_COMPRESSED_RGBA_S3TC_DXT5_EXT and GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT? As far as I know DXT5 is a standard method, so why two different formats?
[/quote]
The former is a DXT5 compressed internal format for a texture in linear colour space, the latter is a DXT5 compressed internal format for a texture in sRGB colour space with linear alpha. This doesn't affect the method of compression, but the colourspace of the texture data.

I can't really help with your Mesa problem other than saying that from past experiences, relying on [i]anything [/i]within Mesa is a suicide mission. If you absolutely want to go ahead, looking through the Mesa source might be a possibility. Keep in mind that FXT, DXTC, etc are all patented algorithms, and you can get in legal trouble if you implement them yourself (rather than using the driver-supplied ones).

Share this post


Link to post
Share on other sites
subi211    137
And they wonder why virtually no games get ported to Linux. :)

Thanks for that, I admit I had a sneaking suspicion that might be the case. I'll just have to rely on the on-the-fly compression when I need it.

The weird thing is, by using driconf to force availability of all the compression methods, it WILL load the texture, but the decompression is trash - a checkerboard of alternating correct and wrong 4x4 squares. :)

Share this post


Link to post
Share on other sites
Yann L    1802
All serious modern Linux OpenGL drivers will bypass Mesa anyway, so I wouldn't worry too much about this. People using ATIs Catalyst or NVidia's proprietary drivers will not be affected by these bugs. Your application will run just the same way as it does under Windows.

For legacy or Intel hardware, you could try to check if you're running under Mesa and fallback to on-the-fly compression if it is the case.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this