Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#575 closed task (fixed)

Automatically add force_s3tc_enable to ~/.driconf

Reported by: Philip Taylor Owned by:
Priority: Nice to Have Milestone: Alpha 2
Component: Core engine Keywords:
Cc: fabio.ped@… Patch:

Description

On many Linux systems, we need the user to force the enabling of S3TC in their drivers. (We no longer require the drivers to do compression, so we don't need libtxc_dxtn). Currently we tell them to run driconf and do it themselves.

Perhaps the game could automatically edit the ~/.driconf file and add an application-specific entry to set force_s3tc_enable. Given the documentation it sounds like the intention is that the file is a standard format that can be edited by multiple tools, so we probably shouldn't suffer from incompatible format changes. But maybe this would still be too fragile and/or evil?

Change History (24)

comment:1 by fabio, 14 years ago

Cc: fabio.ped@… added

What about using the S3TC decompression functions even if the GL_S3_s3tc extension is not available, without modifying .driconf? Maybe an interface option could be added to enable or disable this behavior if someone has problems.

comment:2 by Philip Taylor, 14 years ago

Unfortunately that doesn't work - Mesa rejects the compressed texture format identifiers if it hasn't already chosen to advertise the relevant GL extension.

comment:3 by fabio, 14 years ago

I thought that this was not the case since many games try to use compressed textures without checking the GL_S3_s3tc extension (e.g.: ETQW, spring engine) and since they also compress textures in game, most texture are empty. I thought that if using only texture decompression it would work.

comment:4 by Philip Taylor, 14 years ago

I originally thought that too, but it didn't work when I tested it, and Mesa's src/mesa/main/texformat.c uses if (ctx->Extensions.EXT_texture_compression_s3tc) { ... } when deciding whether to accept GL_COMPRESSED_RGB_S3TC_DXT1_EXT etc, so I don't believe there's any way to make it accept the textures without it enabling that extension.

comment:5 by fabio, 14 years ago

Maybe mesa could change that... one year ago I indeed opened a bug report on improving S3TC behavior but it didn't go anywhere: http://bugs.freedesktop.org/show_bug.cgi?id=24207

There was also a proposed improvement at http://cgit.freedesktop.org/~csimpson/mesa/log/?h=s3tc-by-the-book that is not yet merged.

comment:6 by Philip Taylor, 14 years ago

If Mesa changes then that'd be great - we always pre-compress textures now so we just need it to say whether it's capable of rendering S3TC, then we can pass it the right format. I think we still need this kind of driconf solution until any such changes are implemented and widely deployed, though.

comment:7 by (none), 14 years ago

Milestone: Unclassified

Milestone Unclassified deleted

comment:8 by Andrew, 14 years ago

Milestone: Backlog

comment:9 by fabio, 14 years ago

There is no need to modify .drirc to enable s3tc. You just need to set this environment variable:

force_s3tc_enable=true

to get the same behavior. This could be added to resources/0ad.sh:

force_s3tc_enable=true /usr/games/pyrogenesis "$@"

or even better integrated into the executable file so that one have the same behavior when directly running it.

Note however that forcing S3TC without installing libtxc_dxtn.so (either with driconf or the environmental variable) don't work with gallium drivers (see bug https://bugs.freedesktop.org/show_bug.cgi?id=29012 )

comment:10 by fabio, 14 years ago

Wrt r8315 you may want to keep suggesting libtxc_dxtn.so since this is currently the only way to enable S3TC with gallium drivers (r300g, r600g, softpipe), until this is fixed in mesa.

comment:11 by Philip Taylor, 14 years ago

Ooh, the environment variable trick looks pretty useful. (Is this documented anywhere?)

It looks like the value is read each time SDL initialises its video system, so the game can call setenv itself (we don't have to set the value externally in a wrapper script). When it's enabled there's an ugly message

ATTENTION: default value of option force_s3tc_enable overridden by environment.
ATTENTION: option value of option force_s3tc_enable ignored.

on stderr. Maybe what we should do is:

  • Start SDL and use SDL_SetVideoMode with default settings.
  • If the S3TC extension is missing, shut down SDL and call setenv("force_s3tc_enable", "true", 1) and restart SDL.
  • (Optional step, if we find some drivers have rendering errors when force_s3tc_enable is set because they don't really support it: Upload a compressed texture then test its pixel values to see if it's correct; if not then force s3tc to false and restart SDL again.)
  • If the S3TC extension is still missing, tell the user to install libtxc_dxtn.

Hopefully that would be enough to cover all the cases. Not sure if I'm missing any serious problems, though.

in reply to:  11 ; comment:12 by fabio, 14 years ago

Hopefully that would be enough to cover all the cases. Not sure if I'm missing any serious problems, though.

That sounds OK to me.

The only problem I see is that if regular releases will provide only compressed textures ( http://www.wildfiregames.com/forum/index.php?s=&showtopic=13617&view=findpost&p=212031 ) then "force s3tc to false" in the optional step will make all textures disappears. So if some drivers have rendering errors when force_s3tc_enable is set they should keep them. Maybe the optional step could still be left but let then only print a warning message if the texture appears corrupted (something like "We tried to force S3TC and it worked, but the texture decompression render corrupted texture. Please report this bug at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa .").

Also some driver (e.g. the r600g gallium) still doesn't enable S3TC even with libtxc_dxtn just to avoid broken texture. So if S3TC is still missing it should tell user to install libtxc_dxtn or, if that still didn't work, to report to mesa.

in reply to:  12 comment:13 by fabio, 14 years ago

The only problem I see is that if regular releases will provide only compressed textures ( http://www.wildfiregames.com/forum/index.php?s=&showtopic=13617&view=findpost&p=212031 ) then "force s3tc to false" in the optional step will make all textures disappears. So if some drivers have rendering errors when force_s3tc_enable is set they should keep them. Maybe the optional step could still be left but let then only print a warning message if the texture appears corrupted (something like "We tried to force S3TC and it worked, but the texture decompression render corrupted texture. Please report this bug at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa .").

Ignore this, since according to http://www.wildfiregames.com/forum/index.php?s=&showtopic=13617&view=findpost&p=212101 it appears that the game could still use uncompressed textures decompressing the precompressed ones:

we have our own S3TC decompression algorithm in the engine (to decompress the textures at runtime when the user doesn't have S3TC support)

Anyway forcing S3TC should work, if it gives rendering errors then it's a driver problem and there could also be other driver problems that can't all be checked. So the optional step could eventually implemented later if someone really complains about texture corruption.

comment:14 by philip, 14 years ago

(In [8356]) Set force_s3tc_enable automatically for greater chance of compressed texture support on Linux (see #575).

comment:15 by Philip Taylor, 14 years ago

Resolution: fixed
Status: newclosed

I changed my mind about detecting the extension and reinitialising SDL, since that sounds like it might do unpleasant things if we switch into fullscreen mode then leave then switch back - it's better to just put up with the "ATTENTION" messages.

So we always set force_s3tc_enable, unless disabled in our .cfg file or overridden by an existing environment variable, and then tell people to use libtxc_dxtn if that wasn't enough. Sounds like this should be sufficiently fixed for now.

(This is all a bit nasty - if there are better ways to handle textures in Mesa (in the present or the future) (with the restrictions that we only want to ship compressed textures, and really prefer having compressed textures in VRAM for performance) I'd be happy to change this all again.)

comment:16 by fabio, 14 years ago

Milestone: BacklogOS Alpha 2

comment:17 by fabio, 14 years ago

You'll may want to add that if S3TC is missing and force_s3tc_enable is false to try to set it to true (but anyway is true by default and one should know if he forced it to false).

comment:18 by Philip Taylor, 14 years ago

If a user has explicitly set it to false via the environment variable, I assume they know what they're doing and really want it to be disabled (and they can deal with the consequences themselves), so it's nicer to not override that.

comment:19 by fabio, 14 years ago

I meant the force_s3tc_enable option in local.cfg.

comment:20 by Philip Taylor, 14 years ago

Ah, sorry, I misunderstood. If a user has explicitly set it to false via the config file, I still assume they know what they're doing :-) . I don't want to add too much complexity to the warning messages, so I just made r8367 point to the CompressedTextures page which can give more details about everything (and a less 404ish link to libtxc_dxtn) - if it's common that people set the config file incorrectly then we can tell them there to switch it back.

comment:21 by fabio, 14 years ago

Well done, I think it shouldn't be clearer. Maybe the last part of the console warning:

Performance warning: your graphics card does not support compressed textures. The game will try to continue anyway, but may be slower than expected. Please try updating your graphics drivers; if that doesn't help, please try upgrading your hardware.

could be also removed, since a better explanation is now given on the GUI.

comment:22 by fabio, 14 years ago

I also noticed that when S3TC is disabled (without libtxc_dxtn) there is no music in the menu screen. Reenabling libtxc_dxtn make music appears again.

comment:23 by Philip Taylor, 14 years ago

Argh, yes, thanks - should be fixed in r8368.

Note: See TracTickets for help on using tickets.