You can sign up to get a daily email of our articles, see the Mailing List page.
We do often include affiliate links to earn us some pennies. See more here.

Mesa 18.0 released, further advancing Linux graphics drivers

By - | Views: 28,104

Mesa 18.0 has been officially released today after a bit of a wait, further advancing Linux graphics drivers.

As usual, if you concerned about stability, the Mesa developers do suggest waiting for the first point release 18.0.1 for any pressing issues to get fixed up. The first point release should be due in early April, with a second due later that month as well.

Since I don't actually use Mesa, being an NVIDIA user I'm not personally too clued on on just how well they're doing. From what I hear from people close to me who are on Mesa, it's come a really long way for both AMD and Intel graphics in terms of performance and compatibility with games.

Feature highlights:

  • Disk shader cache support for i965 when MESA_GLSL_CACHE_DISABLE environment variable is set to "0" or "false"
  • GL_ARB_shader_atomic_counters and GL_ARB_shader_atomic_counter_ops on r600/evergreen+
  • GL_ARB_shader_image_load_store and GL_ARB_shader_image_size on r600/evergreen+
  • GL_ARB_shader_storage_buffer_object on r600/evergreen+
  • GL_ARB_compute_shader on r600/evergreen+
  • GL_ARB_cull_distance on r600/evergreen+
  • GL_ARB_enhanced_layouts on r600/evergreen+
  • GL_ARB_bindless_texture on nvc0/kepler
  • OpenGL 4.3 on r600/evergreen with hw fp64 support
  • Support 1 binary format for GL_ARB_get_program_binary on i965. (For the 18.0 release, 0 formats continue to be supported in compatibility profiles.)
  • Cannonlake support on i965 and anv

Naturally there's a lot of bugs that have been fixed as well as a result of the advancement. You should see more games work as a result of this release on top of the performance improvements (of which there's been quite a few).

Note: Their release notes state it's 17.4.0 due to an issue with git struggling to detect the move (their words).

Article taken from GamingOnLinux.com.
21 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
54 comments
Page: «4/6»
  Go to:

jens Mar 29, 2018
  • Supporter
Quoting: Shmerl
Quoting: jensIt would have been a lot more polite if you would have at least acknowledged jaycee's experience. Instead you completely ignored what he said in your direct response and just posted a general essay.

He was answering to my point, not I to his. However, saying that open development "doesn't necessarily help at all" because it doesn't guarantee fast bug fixing was not the topic I was talking about. How fast something is fixed doesn't depend on it.

You really don't like it to give in right ;)
Shmerl Mar 29, 2018
Quoting: GuestI'm confused - what are people arguing about?

I'm really not sure. Above some didn't like the idea that open development is a better model, and tried bringing counter examples, which weren't even to the point.
jens Mar 29, 2018
  • Supporter
Quoting: GuestI'm confused - what are people arguing about?
Just the usual :)
As soon as someone points out that Open Source/FOSS has its weaknesses too some brave FOSS warrior stands up and fights with a knife between its teeth till the last men ;)


Last edited by jens on 29 March 2018 at 6:14 pm UTC
Purple Library Guy Mar 29, 2018
Bottom line to me: Model A can be a better model, model B can be a worse model, but people using model B can still get good results sometimes and people using model A can screw it up or have insufficient resources. Open is certainly a better model for bug tracking. Employees of a company using a worse model may still be competent, committed people doing their best and manage to extract some good results.
omer666 Mar 29, 2018
Quoting: Purple Library GuyBottom line to me: Model A can be a better model, model B can be a worse model, but people using model B can still get good results sometimes and people using model A can screw it up or have insufficient resources. Open is certainly a better model for bug tracking. Employees of a company using a worse model may still be competent, committed people doing their best and manage to extract some good results.
You are completely right!
Ari El Uno Mar 30, 2018
Quoting: tonRI mean r600 (HD 2000 series) not Evergreen. I'd bold it.

I think that r600 (in Mesa) doesn't necessarily refer to HD 2000 series codename, it refers to the 3D driver used by Mesa, as showed on the RadeonFeature matrix table here: https://www.x.org/wiki/RadeonFeature/

So that evergreen part is pointing specifically at the GPU generation.
strunkenbold Apr 9, 2018
I fear that list of bugged Mesa games is not even 50% complete. It's really unfortunate that many bug reports stay open for months or even years. AMD Mesa team desperately needs a dev solely caring for fixing bug reports, writing piglits and do intense testing of stable releases.
IMO the problem is that Mesa is too slow picking up features. All devs focus on catching up what nvidia binary driver offers for months or years. Just look how long it already takes to offering OpenGL 4.6. RadeonSI needs to switch to NIR because of that and once this gets enabled by default you can be sure to see another bunch of regressions.
Unfortunately again, because of the current way bugs get fixed is following a completely random pattern, you can be either lucky or not.
In the end I wouldn't recommend Mesa to anyone. Except you have fun running current git Mesa / LLVM / AMD staging kernel. It is definitely fun to see the improvements Mesa made in the last years. I basically saw performance improvements of over 50% in some games but encountering bugs which no one is willing to fix for years sadly just spoils the fun.
Anyway I'm happy to see people reporting bugs but I don't think that this will be enough. In the end AMD will need someone taking care...
Shmerl Apr 10, 2018
Quoting: strunkenboldI fear that list of bugged Mesa games is not even 50% complete.

The list is populated by volunteers specifically for the purpose of bringing more attention to these bugs. Feel free to add what's missing if you know of any games like that.


Last edited by Shmerl on 10 April 2018 at 12:45 am UTC
strunkenbold Apr 10, 2018
Quoting: Shmerl
Quoting: strunkenboldI fear that list of bugged Mesa games is not even 50% complete.

The list is populated by volunteers specifically for the purpose of bringing more attention to these bugs. Feel free to add what's missing if you know of any games like that.

Sorry but the list is outdated and lists mainly game bugs. Also I didn't saw any dev ever reacting to that list.
Like the X3 bug, that one got even bisected, anything happend until now?
What's up with those many game related bugs? Is valve doing any work on them? Have they actually ever respond after they said "let's create a list"?
I think I'm not the only one who got the feeling that nothing happens here anymore.
Shmerl Apr 10, 2018
Quoting: strunkenboldSorry but the list is outdated and lists mainly game bugs. Also I didn't saw any dev ever reacting to that list.

Check page history. And if you are complaining about the list being incomplete, then help improving it.


Last edited by Shmerl on 10 April 2018 at 1:04 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.