Problems related to Linux/Radeon/texture compression

[[CTX]vitaminx]

Hello all,

here I'd like to explain a general problem on Linux that makes me (and others?) unable to run Spring on Linux using the Open Source Radeon drivers.

Not (yet?) supported on R300+ radeon chips is the OpenGL extension s3tc texture compression:
http://dri.freedesktop.org/wiki/S3TC

Spring fails to start because of that:

Needed OpenGL extension(s) not found:
GL_ARB_texture_compression
Update your graphic-card driver!
graphic card: Mesa DRI R600 (RV610 94C9) 20090101 x86/MMX/SSE2 TCL
OpenGL version: Mesa DRI R600 (RV610 94C9) 20090101 x86/MMX/SSE2 TCL

This happens even with the option "compress textures" turned off.

There are patent issues with this OpenGL feature, so I'm not sure when/if it will be implemented.



My question is - is it really necessary that spring depends on that feature? Can't the check not just be turned off when "compress textures" is deselected?

Thanks for making suggestions here :)
vitaminx

[SpliFF]

It's probably "required" because many Spring games ship with DDS textures in the models. I think that by default DDS uses s3tc (correct me if wrong).

I suppose if DevIL can load DDS directly it could be used to convert the textures on-the-fly but I don't know how easy this will be (or whether it really solves the problem).

This is why proprietary formats should never be used in open-source software, there's always the patent threat hanging over them.

BTW, you can actually modify your DRI drivers to support s3tc. Essentially it means downloading and installing a hack so the responsibility for IP infringement falls on you, the user.

http://homepage.hispeed.ch/rscheidegger ... index.html

That link looks a bit old but I've seen newer instructions around.

EDIT: Ha ha, it's the same information you posted, and it's unmaintained. Still I'd keep looking around, there might be someone still supporting/distributing it somewhere, after all, the legal issue probably only affects Americans and countries that share patent protection with them ("free trade" agreements, ha ha).

[SpliFF]

I'm bumping this as I've just successfully run spring on opensource x11 drivers for the first time. The trick seems to be largely undocumented.

1.) Install driconf (emerge driconf, apt-get driconf, ...)
2.) Run driconf as your normal user account, it will open a GUI.
3.) On the "Image Quality" tab activate "Enable S3TC texture compression even if software support is not available"
4.) Close driconf, if you aren't in "Expert Mode" it will save automatically.

This fixes the "most textures are white" issue which is caused by the underlying Mesa library bailing on DDS textures instead of passing them through to the card like they should. It looks like a knee-jerk reaction to the whole S3TC is patented issue and a misinterpretation of the OpenGL specification.

I still get some graphics corruption around fonts and I'm sure the acceleration and quality will be less than the ATI proprietary catalyst (fglrx) driver but it's a great thing to know if you can't or won't run the binary drivers.

[liamdawe]

Fixes like that happen all the time on Linux, many people know about them but they cannot be shipped officially with the drivers/games/applications etc because of the patent issues.

I'm just lucky that the recent official ati drivers now work properly with spring for me.

[SpliFF]

It's not only a patent issue. What happens is that the mesa drivers ignore textures when the application asks for them to be compressed 'on-the-fly'.

To handle already compressed textures all that needs to happen is the mesa driver passing the texture through to hardware with the correct flags. Since basically all hardware supports S3TC this works.

However the OpenGL spec actually says you can ignore a compression you can't do and handle the texture uncompressed. That means if software hands the driver an uncompressed texture and asks for it to be compressed to an unsupported format it is legal for the driver to use the texture uncompressed. You use more VRAM that way but at least the application works as expected.

I discussed this with the mesa devs and they agreed with my interpretation, so I'm not sure why they backflipped and made this 'opt-in' when it should be on by default. At least distros can enable this in /etc/drirc so it isn't a total loss. I guess they decided to play it ultra-conservative which is understandable given how fucked up Americas patent system is.

Big thanks to Mesa/Xorg dev Corbin Simpson who did the actual work on getting this corrected.

[hoijui]

maybe put it in the FAQ:
http://springrts.com/wiki/FAQ:trouble

[SpliFF]

Done, I've also updated the previous thread related to this topic so hopefully people won't get stuck or bork their system trying to install libdxtn.

[hoijui]

nice!