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.
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.
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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
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).
0 Likes
This is exactly the support Linux needs. In this way Linux gaming will grow slowly and continually.
0 Likes
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.
1 Likes, Who?
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.
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.
1 Likes, Who?
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".
1 Likes, Who?
Quoting: F.UltraThis cannot be fixed in Steam, the game expects OpenGL to return a certain version string. Steam cannot change this valueSteam could simply set the environment variable MESA_GL_VERSION_OVERRIDE before launching the game.
1 Likes, Who?
TheRiddick Feb 7, 2017
I think there is a way to do that in the command section of a games properties under steam right?
0 Likes
Quoting: jf33Quoting: F.UltraThis cannot be fixed in Steam, the game expects OpenGL to return a certain version string. Steam cannot change this valueSteam 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.
0 Likes
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.
0 Likes
Patreon
PayPal
See more from me