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.
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.
RussianNeuroMancer Feb 3, 2017
I don't think this is good idea. Wouldn't it will be better to ask game developers fix their engine?
I also pretty sure someday they will decide to update their engine, probably require higher OpenGL version, discover that Mesa for some reason report 3.2 to the game while support 4.5 or 4.6, they could make another workaround, instead of fixing thing right way, or straight declare Mesa as unsupported driver.
I also pretty sure someday they will decide to update their engine, probably require higher OpenGL version, discover that Mesa for some reason report 3.2 to the game while support 4.5 or 4.6, they could make another workaround, instead of fixing thing right way, or straight declare Mesa as unsupported driver.
6 Likes, Who?
I don't think this is good idea. Wouldn't it will be better to ask game developers fix their engine?
I also pretty sure someday they will decide to update their engine, probably require higher OpenGL version, discover that Mesa for some reason report 3.2 to the game while support 4.5 or 4.6, they could make another workaround, instead of fixing thing right way, or straight declare Mesa as unsupported driver.
They will update their engine with Vulkan.
https://www.gamingonlinux.com/articles/ark-survival-evolved-plans-to-use-vulkan-for-linux-this-year.8831
Last edited by Leopard on 3 February 2017 at 10:47 pm UTC
1 Likes, Who?
I don't think this is good idea. Wouldn't it will be better to ask game developers fix their engine?It's always better if a developer fixes their game properly, but the problem is most likely won't. We are a tiny market in most developers eyes, Mesa even more so in comparison to NVIDIA proprietary (proof of that here, 73% are NVIDIA). NVIDIA likely has something like this built-in already, which is why it's only an issue on Mesa.
I also pretty sure someday they will decide to update their engine, probably require higher OpenGL version, discover that Mesa for some reason report 3.2 to the game while support 4.5 or 4.6, they could make another workaround, instead of fixing thing right way, or straight declare Mesa as unsupported driver.If ARK does ever fix it, then it would be a very quick patch for Mesa and they could then remove this, so it's not really an issue.
2 Likes, Who?
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.
Wellll, it seems like this is extensible though. I mean, it's meant to fix this one game, but it looks like it could work for any game that had some kind of weird OpenGL version requirement--once you've got it working for ARK, you could easily add other games to a list or something, right? And there's bound to be more of them, so.
0 Likes
Likely, yes.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.
Wellll, it seems like this is extensible though. I mean, it's meant to fix this one game, but it looks like it could work for any game that had some kind of weird OpenGL version requirement--once you've got it working for ARK, you could easily add other games to a list or something, right? And there's bound to be more of them, so.
Personally, I think it's damn important for end-users to get a good experience. I don't think users should have to deal with setting special launch options or dealing with any kind of hack to get a game running on Mesa. It's nothing but a nuisance. Most users don't give a frig about the politics inside the drivers, they just want the game to run.
3 Likes, Who?
I don't think this is good idea. Wouldn't it will be better to ask game developers fix their engine?
I also pretty sure someday they will decide to update their engine, probably require higher OpenGL version, discover that Mesa for some reason report 3.2 to the game while support 4.5 or 4.6, they could make another workaround, instead of fixing thing right way, or straight declare Mesa as unsupported driver.
They will update their engine with Vulkan.
https://www.gamingonlinux.com/articles/ark-survival-evolved-plans-to-use-vulkan-for-linux-this-year.8831
True, but like others have said, this is unlikely to happen. It's hard enough to get some developers to port to Linux in the first place, even if they're using OpenGL. Even less likely that they are willing to make changes for one set of drivers. The end users experience should be priority now as it looks like Valve are pushing to replace the pro driver stack with the open source on SteamOS. We want users to have a flawless experience, so they come back and support the community. Not having to hunt around for bug fixes/hacks.
Having said that, if the developers were ever to fully support mesa properly. They could easily submit a patch to revert the "hack", this is the beauty of open source.
It looks like the priority is going to be native titles on Steam, but I hope some workarounds are added for Rage, Doom and other id titles that need it to get OpenGL through wine running properly on mesa.
1 Likes, Who?
TheRiddick Feb 4, 2017
Well its good to see they are using Vulkan now, I'm not sure if they ever got DX12 out the door but there seems to be no practical reason to use DX12 when you game is on multi-platform. Its a real shame Apple doesn't support Vulkan, but I guess in time there will be some VK to Metal conversion tools to make the process quite easy for developers.
0 Likes
Liam,
Crazy thought if valve developers happen to look through this site / are aware of this site.
It might be worthwhile reaching out to Valve and to Gabe Newell and see if they would be interested in doing an interview for this site.
We might get some interesting insights into what they are planning for SteamOS / Linux gaming.
I was really down on Valve for a while, only because I really wanted linux gaming and what they had put into motion to succeed. On reflection what they have done and allowed is incredible.
Last edited by truebluewoo on 4 February 2017 at 12:55 am UTC
Crazy thought if valve developers happen to look through this site / are aware of this site.
It might be worthwhile reaching out to Valve and to Gabe Newell and see if they would be interested in doing an interview for this site.
We might get some interesting insights into what they are planning for SteamOS / Linux gaming.
I was really down on Valve for a while, only because I really wanted linux gaming and what they had put into motion to succeed. On reflection what they have done and allowed is incredible.
Last edited by truebluewoo on 4 February 2017 at 12:55 am UTC
2 Likes, Who?
GustyGhost Feb 4, 2017
You have really built up a wealth of resources here. I'm patiently waiting for the day a prominent company or event or press references the GOL statistics page which has been running almost long enough to show meaningful changes in trends.
0 Likes
They will update their engine with Vulkan.Sure, I believe it when I see it. I tell you here and now, they won't update their engine at all. Not now and not in 6 month nor in a year. The game is full of bugs and never has seen significant bug fixes and if they would try to update the engine - which has more than 1,5 years of development - they will break the game completely.
https://www.gamingonlinux.com/articles/ark-survival-evolved-plans-to-use-vulkan-for-linux-this-year.8831
I suggest you not to hold your breath, they will probably bring more DLCs before they even try to fix any bugs or update the engine.
0 Likes
Bit 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?
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.
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?
This 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
This 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
Patreon
PayPal
See more from me