Mesa 18.1.8 and Mesa 18.2.0 have been released, pushing Linux open source GPU drivers further

Quoting: whizse

Quoting: lejimster

Quoting: ziabiceFinally I can put my hands on RAGE and Wolfenstein!

Been playing Rage. Although only 64bit works properly for me and I had to add xact to get the sound working.

I need to do some driver testing to see if its just a buggy version of mesa-git, but 32bit Rage and Wolfenstein N.O. tend to crash in the menus.

I think this is the problem:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=bc65dcab3bc48673ff6180afb036561a4b8b1119

Though I'm seeing hangs, not crashes, in the menu in Rage, haven't tried Wolfenstein yet.

Could you try if this fixes the problem for you?
https://pastebin.com/iwGynY9E

Ok, so I have been testing the patch for a few hours, haven't experience one hang on either Rage or Wolfenstein N.O. with it.

That leaves just one major problem left with 32-bit Rage now, the megatexture corruption.

https://youtu.be/EUwq4dbnFkA

Quoting: lejimsterOk, so I have been testing the patch for a few hours, haven't experience one hang on either Rage or Wolfenstein N.O. with it.

That leaves just one major problem left with 32-bit Rage now, the megatexture corruption.

https://youtu.be/EUwq4dbnFkA

Great! I will file a new bug for the menu hang. The patch is most likely not the right way to solve it though.

The textures was reported in bug 107694 but sadly nixed by Mesa devs.

I’m getting 60 FPS with a few drops to 47FPS on the Game The Long Dark but works great this new Mesa.

Quoting: F.Ultra

Quoting: x_wing

Quoting: pete910Wonder if this will fix Dying light for non *butu users ?

And before anyone chimes in with " you just need to add..." They don't work!

DL wasn't working on Ubuntu 18.04 with Mesa 18.1, but using Mesa 18.2RC made it work (for me and many others, I think). So, try to test it and share your results.

I thought the problem with DL was with the new version of glibc?

I heard the same and also thinked that as I found out that the game wasn't working anymore when upgrading to Ubuntu 18.04. Nevertheless, I compiled my self Mesa drivers and made it work (last time I tested I used Mesa 18.02RC3). Not sure if it's glibc the problem, you can see others making it work here: https://www.reddit.com/r/linux_gaming/comments/901n3l/dying_light_crashing_to_desktop/

About getting the command that Steam runs before starting a game, just set as game start parameters: echo %command%

Worth mention: steam sets a lot of environment variables that let's the steamlib to start (from your user name to game information). You may want to create an script that prints the environment for you (I say this because I assume that you want to run from a terminal "without" steam in the middle, so you must create the env in order to make it work)

EDIT: Also I need to mention that if you want to simply preload glibc on your system, you will be forced to also preload the lib loader (you can find it on /lib/x86-linux-gnu/ld-X.XX.so). The problem with this idea is that older versions of glibc will probably not work with libs linked against a more modern version. This means that you'll be forced to add all your system dependencies linked against this old version. In others words: you may want to create a new libs hierarchy of your target system (maybe docker can help here) and use chroot in order to start using this new hierarchy (of course this is not trivial and will get you some headaches...).


Last edited by x_wing on 10 September 2018 at 3:42 pm UTC

Quoting: x_wing

Quoting: F.Ultra

Quoting: x_wing

Quoting: pete910Wonder if this will fix Dying light for non *butu users ?

And before anyone chimes in with " you just need to add..." They don't work!

DL wasn't working on Ubuntu 18.04 with Mesa 18.1, but using Mesa 18.2RC made it work (for me and many others, I think). So, try to test it and share your results.

I thought the problem with DL was with the new version of glibc?

I heard the same and also thinked that as I found out that the game wasn't working anymore when upgrading to Ubuntu 18.04. Nevertheless, I compiled my self Mesa drivers and made it work (last time I tested I used Mesa 18.02RC3). Not sure if it's glibc the problem, you can see others making it work here: https://www.reddit.com/r/linux_gaming/comments/901n3l/dying_light_crashing_to_desktop/

About getting the command that Steam runs before starting a game, just set as game start parameters: echo %command%

Worth mention: steam sets a lot of environment variables that let's the steamlib to start (from your user name to game information). You may want to create an script that prints the environment for you (I say this because I assume that you want to run from a terminal "without" steam in the middle, so you must create the env in order to make it work)

EDIT: Also I need to mention that if you want to simply preload glibc on your system, you will be forced to also preload the lib loader (you can find it on /lib/x86-linux-gnu/ld-X.XX.so). The problem with this idea is that older versions of glibc will probably not work with libs linked against a more modern version. This means that you'll be forced to add all your system dependencies linked against this old version. In others words: you may want to create a new libs hierarchy of your target system (maybe docker can help here) and use chroot in order to start using this new hierarchy (of course this is not trivial and will get you some headaches...).

Just don't understand how it could be a mesa problem since I had the same version (18.0.7) on 16.04 where it worked and in 18.04 when it didn't. Then of course those mesa:s could have been compiled differently (one was padoka and the other was Ubuntu stock) which could explain some of it but still...

Best would perhaps be to set up a vm to run DL (if there exists graphic drivers in VM:s these days that are powerfull enough to atleast make the game start) and then incremetnally try each version of glibc between the version from 16.04 up to where it breaks in order to see which patch (if the problem lies in glibc) that makes the game crash. Could be quite some time consuming task though since compiling glibc is probably not a small task.

Quoting: F.UltraJust don't understand how it could be a mesa problem since I had the same version (18.0.7) on 16.04 where it worked and in 18.04 when it didn't. Then of course those mesa:s could have been compiled differently (one was padoka and the other was Ubuntu stock) which could explain some of it but still...

Best would perhaps be to set up a vm to run DL (if there exists graphic drivers in VM:s these days that are powerfull enough to atleast make the game start) and then incremetnally try each version of glibc between the version from 16.04 up to where it breaks in order to see which patch (if the problem lies in glibc) that makes the game crash. Could be quite some time consuming task though since compiling glibc is probably not a small task.

Yes, that's a lot of work. I remember attaching gdb to the game process and checking that the crash was due a segmentation fault. Weird things is that the blow up was outside Mesa nor glibc (As far I remember) and in a very high memory position (can't remember if the pointer was on that position or if the stack was there).

If I have the time I'll try to run with my system-wide Mesa (padoka stable) and share the stack trace. Also, if padoka stable gets updated this week, I'll check if starts working with that version.

One final mention: I'm using KDE Neon, but it's basically Ubuntu 18.04.


Last edited by x_wing on 10 September 2018 at 7:47 pm UTC