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.
Samuel Pitoiset from Valve has sent in yet another patch to Mesa, this one focuses on the ARK games: ARK Survival Evolved and Survival Of The Fittest to to run without overrides.

Note: We have our own ARK server, details here.

Essentially, Samuel is arguing that overrides to force Mesa to use specific OpenGL versions should be mainly a developer-option, and that games which require it should auto-set it for users. I completely agree, it's less hassle for us and many people likely aren't aware that specific games need these hacks to run.

The interesting thing in addition to this work, is that Samuel directly references the page I setup on our wiki to track games broken or needing additional configs on Mesa. I guess I was onto something there then!

You can see the two patches here and second here.
QuoteThis patch adds a new driconf option override_glsl_version for launching ARK games without the MESA_GLSL_VERSION_OVERRIDE hack which should be only for developers.

This sounds redundant with force_glsl_version but that one is only for shaders that lack an explicit #version line. while this one will change the version of the core context. And this is especially useful for returning the version requested by the given app and not a more recent version.

This option is for the ARK games which "explicitely" [1] require a 3.2 context, and fail if the version is > 3.2. Presumably, "ShellShock Live" [2] will also need but I don't have that game yet (though I will be able to test in the next few days).

Although some users know how to launch the ARK games with that envvar, I think it would be really much better to be able to launch them "natively". And "ARK: Survival Evolved" is one of the most played game... [3]


I know people and likely some Mesa developers are opposed to having more game-specific bits in their drivers, but this is about getting the game to actually run, not about hacking around performance issues. Article taken from GamingOnLinux.com.
12 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.
See more from me
The comments on this article are closed.
22 comments
Page: «3/3
  Go to:

jf33 Feb 7, 2017
Quoting: TheRiddickI think there is a way to do that in the command section of a games properties under steam right?
Yes, there is one. But you still have to type yourself.

Quoting: F.UltraFrom what I understood from the patches this was not enough since it had to change the version of the shaders (or what ever it was) as well.
This is what MESA_GLSL_VERSION_OVERRIDE is for then. There's a lot of settings you can do without modifying Mesa's source code. Have a look at http://www.mesa3d.org/envvars.html.

Quoting: F.UltraAlso when looking there I found that they have had a file inside Mesa for quite some time (seams to be from 2012) to set application specific details already: https://github.com/imirkin/mesa/tree/master/src/mesa/drivers/dri/common , so this patch set was not the one that broke the "no application specific settings inside mesa" rule.
Which file exactly are you talking about? Also, keep in mind, that this is a private branch of Ilia Mirkin. The official source code is hosted at https://cgit.freedesktop.org/.

Quoting: GuestI don't think steam is the place to put workarounds. It ties the game to Steam - worse yet, it might tie it to a specific version of Steam, and breaks with an update. Better to keep it in the game's launcher.
This is a good point. Yes, adapting the game itself is always the best option. (The "game launcher", as you call it, is part of the game isn't it? Or is it something separate and under Valve's control?) Now we're talking about the situation where it seems impossible to do that (ignorant game developers). You can now either
- do nothing (doesn't make the game work for the average Joe, because he isn't able to set the correct environment variables himself)
- modify Steam (only makes it work for the average Joe, because average Joe uses Steam)
- modify Mesa (makes it work for all, but messes up Mesa's code, possibly causes bugs in the future etc. - look at what marcus has written)

I would say, option 2 is by far the best. I mean it doesn't make the game work worse for people who don't use Steam (that's including myself, btw). It just improves the experience when using Steam. And yes, if Valve decides to implement a workaround in Steam, they might have to adapt it, as soon as the game itself changes. But they that's exactly what they have to do, if they implement it in Mesa. That's the problem with workarounds.


Last edited by jf33 on 7 February 2017 at 10:22 pm UTC
F.Ultra Feb 9, 2017
View PC info
  • Supporter
Quoting: jf33
Quoting: F.UltraAlso when looking there I found that they have had a file inside Mesa for quite some time (seams to be from 2012) to set application specific details already: https://github.com/imirkin/mesa/tree/master/src/mesa/drivers/dri/common , so this patch set was not the one that broke the "no application specific settings inside mesa" rule.
Which file exactly are you talking about? Also, keep in mind, that this is a private branch of Ilia Mirkin. The official source code is hosted at https://cgit.freedesktop.org/.

Sorry about that, the file from the official source code is this one: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/common/drirc


Last edited by F.Ultra on 9 February 2017 at 5:35 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.