Closed marciosr closed 7 years ago
Seems so, I have black textures in Rocket League
Easy to build the lib: https://dri.freedesktop.org/wiki/S3TC/
Ideally this goes into the freedesktop runtime but it is patent encumbered until October of this year so maybe it should be bundled here until then @alexlarsson ?
Can we, kind of, hack it together on our machines?
We could add an extension point for the s3tc library maybe. Then people can build it?
On openSUSE there is installed by default s2tc package that provides libtxc_dxtn.so. To play Team Fortress 2 it's enough to export force_s3tc_enable=true
We discussed this on IRC and @alexlarsson will probably add s2tc to the freedesktop runtime (until s3tc patents expire at least). This will probably still be a problem for 32bit games though.
I am having issues with TF2 showing mostly black when in game. I have a Dell XPS 15 9550 running the NVIDIA 381.22 drivers. I am running openSUSE tumbleweed. Is this related to this issue? The wiki said TF2 should run with the drivers I have. I made sure the flatpak was up to date.
Most likely yes, this just needs to get packaged.
So I built s2tc but it has some caveats; It is only for 64bit games and in my limited testing (Shadow of Mordor) it doesn't seem to get loaded by Nvidia so it might not like the /app
prefix or something. An AMD user did say it worked for them on a game though.
I am having issues with TF2 showing mostly black when in game. I have a Dell XPS 15 9550 running the NVIDIA 381.22 drivers.
I tried TF2 on Nvidia drivers and everything worked fine here, same driver version. Maybe it was using integrated graphics?
When I try to run the game from the console I see the NVIDIA drivers but it looks like the error is related to the ELF class. It is showing a 64 bit class when I believe it should be 32 bit.
TF2_console_launch.txt failed to dlopen /home/nkane/.var/app/com.valvesoftware.Steam/data/Steam/steamapps/common/Team Fortress 2/bin/engine.so error=libopenal.so.1: wrong ELF class: ELFCLASS64 failed to dlopen engine.so error=libopenal.so.1: wrong ELF class: ELFCLASS64 AppFramework : Unable to load module engine.so!
Fixes the issues with Unity games.
Edit: Nope, Ballistic Overkill still has the same issue
@TingPing Well, most Linux systems are 64bit and most games are 32bit so the workaround for shipping 64bit s3tc doesn't really help much
@nanonyme I am well aware, there is no reasonable solution for us building multilib atm though.
@TingPing so does it currently work if you compile the library yourself host-side? How should it be exposed?
@nanonyme Building things on the host isn't really helpful, we will just have to work out getting building working on flatpaks end (or do an awful hacky workaround there).
@TingPing Not 100% aware of how Flatpak specs work: it be possible to workaround by installing 32bit Flatpak instead on a 64bit machine so you get 32bit s3tc?
@nanonyme No, currently the Steam Flatpak is 64bit only. Maybe around GUADEC I can talk to @alexlarsson more about it.
@TingPing This seems backwards to me. Steam is a 32bit application so surely you should only be building i386, not x86_64?
Steam ships both 32 and 64bit games, so the flatpak has to be 64bit for wide support. This is admittedly odd and this is the first multilib package here so it has kinks to work out.
@TingPing I tried TF2 on Nvidia drivers and everything worked fine here, same driver version. Maybe it was using integrated graphics?
Looks like flatpak has an issue with nvidia cards that use optimus. I installed steam locally and it works correctly when using optirun.
@nkane2898 Maybe related to #16 or flatpak/flatpak#869
FYI, textures work OK for me when following @etam link above for both Half-Life 2: Deathmatch and Counter-Strike: Global Offensive.
Tested on Fedora 26 x86_64 with integrated Intel HD Graphics 5300, stock drivers, under both Wayland and Xorg.
Running like this:
$ flatpak --env=force_s3tc_enable=true run com.valvesoftware.Steam
Half-Life 2: Deathmatch - (32bit, apparently not loading the new s2tc lib above but still works anyway with force_s3tc_enable)
<logs>
OpenGL: Mesa DRI Intel(R) HD Graphics 5300 (Broadwell GT2) x86/MMX/SSE2 3.0 Mesa 17.0.5 (3.0.0)
$ objdump -a /proc/`pgrep hl2_linux`/exe
file format elf32-i386
$ grep -c libtxc_dxtn /proc/`pgrep hl2_linux`/maps
0
Counter-Strike: Global Offensive
$ objdump -a /proc/`pgrep csgo_linux64`/exe
file format elf64-x86-64
$ grep -c libtxc_dxtn /proc/`pgrep csgo_linux64`/maps
4
@TingPing anything new on this now after GUADEC?
@nanonyme @alexlarsson Will add S2TC to the runtime. Vague ideas about building multi-lib stuff: https://github.com/flatpak/flatpak/wiki/BOF-GUADEC-2017#multilib-building
Unless I misinterpreted, looks like @alexlarsson just added S2TC to latest runtime. I don't currently have a game installed that suffer of the problem so will take a while to test
@TingPing tested, works for me. How about removing the compiling of S2TC in the app if it's part of runtime already?
@nanonyme So its working on 32bit games now?
@TingPing Well, I first noticed there was a 32bit libtxc_dxtn.so under /app/lib/lib32/lib/ (that's a pretty nutty path) so I thought to test Grim Fandango since it didn't before render correctly for me with a 64bit build (eg main character was missing textures). Works fine now. In short yes, 32bit games now work with 64bit app for me
Cool, consider this closed then. I'll remove our bundled s2tc soon also.
Note that mesa 17.3 will have S3TC by default, no more need for the external library.
@FabionPedretti FWIW the library is shipped through runtime, not app but anyhow not removing it has value in that most users will not have Mesa 17.3 for quite some time
in that most users will not have Mesa 17.3 for quite some time
The host drivers don't matter. Anyway once the runtime gets a new Mesa with it (which is probably a while from now) then s2tc can probably be safely removed again.
@TingPing uhm, that sounds dangerous. Are the kernel requirements for Freedesktop runtime documented somewhere as they sound quite high?
@nanonyme I'm not an expert on it but as I understand it new Mesa should run on reasonably old kernels. I know EL7 users seem to have no problems. I don't think every possible interaction with the host kernel is documented for the freedesktop runtime though.
@TingPing Had a conversation about this on a GPU driver channel: the impression I got from there the major thing here is that if you're using an old kernel, you might get random missing OpenGL extensions or lower OpenGL versions. Mesa checks for the features and won't advertise unless available. Something to keep in mind: if you hit strange issues, check kernel version
Yea absolutely.
Trying to run CS GO on flatpaked Steam give me a error message of missing GL_EXT_texture_compression_s3tc or GL_EXT_texture_compression_dxt1 + GL_ANGLE_texture_compression_dxt3 + GL_ANGLE_texture_compression_dxt5.
terminal output.txt
Thanks