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.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
16 comments
Wonder 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!
And before anyone chimes in with " you just need to add..." They don't work!
0 Likes
Wonder 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.
0 Likes
Wonder 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?
0 Likes
Finally 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.
0 Likes
Wonder 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.
Just tried with the Arch testing packages.... No go.
I'll look into it a bit more, time permitting.
0 Likes
Wonder 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?
Arrrh that's right, damn!
Wonder 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.
Just tried with the Arch testing packages.... No go.
I'll look into it a bit more, time permitting.
Looks like it is a glibc issue. :'(
0 Likes
Wonder 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?
Arrrh that's right, damn!
Wonder 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.
Just tried with the Arch testing packages.... No go.
I'll look into it a bit more, time permitting.
Looks like it is a glibc issue. :'(
Anyone that knows what kind of magic that Steam adds when running games? I've tried to rename "DyingLightGame" to "DyingLightGame.exe" and then created a small shell script named "DyingLightGame" that just did "./DyingLightGame.exe" as a preparation for doing glibc preload but the game refused to start even with such a basic script (it couldn't find the steam overlay I think it complained about) so it looks like Steam does more than just execute the binary.
0 Likes
Anyone that knows what kind of magic that Steam adds when running games? I've tried to rename "DyingLightGame" to "DyingLightGame.exe" and then created a small shell script named "DyingLightGame" that just did "./DyingLightGame.exe" as a preparation for doing glibc preload but the game refused to start even with such a basic script (it couldn't find the steam overlay I think it complained about) so it looks like Steam does more than just execute the binary.No need for custom scripts. You can add your LD_PRELOAD magic to the game's launch options. Right click the game in your library, select "Properties" -> "SET LAUNCH OPTIONS...":
LD_PRELOAD=path_to_lib.so %command%Just bear in mind that when it comes to Dying Light and glibc, others have tried and failed. I hope you have better luck.
Last edited by tuubi on 9 September 2018 at 8:04 pm UTC
1 Likes, Who?
I think this is the problem:Finally 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
0 Likes
I think this is the problem:Finally 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
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.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?
Wonder 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?
Wonder 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
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.
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