Released yesterday, both Mesa 18.1.8 as a bug-fix release and Mesa 18.2.0 as the latest full release of the open source graphics drivers are now out. As usual, the Mesa team are suggesting you wait for Mesa Mesa 18.2.1 if you plan to upgrade, at least if you want a fully stable experience.
For the RadeonSI (AMD) driver, it now has compatibility profile support up to OpenGL 4.4. This is quite important for historic reasons, since there will be applications and games that rely on it that won't be updated (including for us in Steam Play/Wine). Personally, I think that's one of the more important features of this release, since it will give users a better experience. RadeonSI also now has compute shader support in the Mesa shader cache.
There's also various improvements to the Intel ANV Vulkan driver, various performance improvements, bug fixes and much more. Since I don't personally use Mesa, having an NVIDIA 980ti I use their proprietary driver so I'm not exactly too up to speed on it all. Great to see it progress though! If you want a more in-depth look, Phoronix has their usual overview.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: whizseQuoting: lejimsterI think this is the problem: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.
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
0 Likes
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.Great! I will file a new bug for the menu hang. The patch is most likely not the right way to solve it though.
That leaves just one major problem left with 32-bit Rage now, the megatexture corruption.
https://youtu.be/EUwq4dbnFkA
The textures was reported in bug 107694 but sadly nixed by Mesa devs.
0 Likes
I’m getting 60 FPS with a few drops to 47FPS on the Game The Long Dark but works great this new Mesa.
1 Likes, Who?
Quoting: F.UltraQuoting: x_wingQuoting: 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
1 Likes, Who?
Quoting: x_wingQuoting: F.UltraQuoting: x_wingQuoting: 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.
0 Likes
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
0 Likes
Patreon
PayPal
See more from me