Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
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. Find me on Mastodon.
See more from me
The comments on this article are closed.
22 comments
Page: «2/3»
  Go to:

Asu Feb 4, 2017
Respect for Valve, respect for ARK.
F.Ultra Feb 4, 2017
View PC info
  • Supporter
Quoting: GuestBit of a tricky situation this. One the one hand, developers should write proper software instead of relying on driver work-arounds. Mesa should be standards compliant, and not intentionally break itself because of some lazy game dev. Then there's the case of needing to maintain the list of work-arounds, itself something unpleasant enough.
On the other hand, people will just want to run a game.

Personally, I'm on the side of not requiring game specific modifications for a driver. I think I'd rather see various options that can be toggled in a driver (typically via environment variables) and a custom launch script for any game that needs it. Just personal preference really.

That nvidia apparently adds support for things like this is also something to think about because unfortunately most game devs seams to test on nvidia only so when they do something non standards they will not see it other than "don't works with Mesa". Once such thing seams to be gamma settings in older libSDL which does not work on Mesa (or fglrx) but does with nvidia and it appears that old libSDL does it wrong (something about using the wrong context if I remember correctly).
1xok Feb 5, 2017
This is exactly the support Linux needs. In this way Linux gaming will grow slowly and continually.
jf33 Feb 5, 2017
If you're Valve and find a bug in a game and you can't make the developers fix it, then please don't mess up Mesa drivers, which are written to comply with the OpenGL specification. Why not implementing the workaround in Steam? Steam is not written against any spec. It's supposed to just make games work. So this is where you should implement such hacks.
marcus Feb 6, 2017
View PC info
  • Supporter
I agree with jf33. Either this or make another wrapper application that can conditionally patch such features into mesa (LD_PRELOAD or whatever). Quirks for individual games or applications in generic code are a nightmare. The result would be a situation like in Windows, where games get faster when you rename them because the drivers switch out the shaders and turn on 'quirks'/'bugfixes' based on the exename.

Further, has anyone thought about who is to maintain such quirks? How long should they stay? Up to which severity do you patch mesa? And who is going to maintain the hell of errata/quirks you get? I just don't like the approach and would rather that Linux stay clear from this approach. If the game is broken, return it. If you need a quirk in the driver to make it work you have proof that its broken. End of story.
F.Ultra Feb 7, 2017
View PC info
  • Supporter
Quoting: jf33If you're Valve and find a bug in a game and you can't make the developers fix it, then please don't mess up Mesa drivers, which are written to comply with the OpenGL specification. Why not implementing the workaround in Steam? Steam is not written against any spec. It's supposed to just make games work. So this is where you should implement such hacks.

This cannot be fixed in Steam, the game expects OpenGL to return a certain version string. Steam cannot change this value, people want to run games and not run Steam and (and this is the big one) the other vendor does this so in order to stay relevant there is no other way for Mesa than to do the same.

There is exactly zero chance for us in the smaller league (AMD and on open drivers) to drive the development of the rest of the industry. To quote Metallica: "Sad but true".
jf33 Feb 7, 2017
Quoting: F.UltraThis cannot be fixed in Steam, the game expects OpenGL to return a certain version string. Steam cannot change this value
Steam could simply set the environment variable MESA_GL_VERSION_OVERRIDE before launching the game.
TheRiddick Feb 7, 2017
I think there is a way to do that in the command section of a games properties under steam right?
F.Ultra Feb 7, 2017
View PC info
  • Supporter
Quoting: jf33
Quoting: F.UltraThis cannot be fixed in Steam, the game expects OpenGL to return a certain version string. Steam cannot change this value
Steam could simply set the environment variable MESA_GL_VERSION_OVERRIDE before launching the game.

From 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. Also 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.
Liam Dawe Feb 7, 2017
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.
I agree, that's a bad idea for that exact reason.
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.