Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay!

Steam Play versus Linux Version, a little performance comparison and more thoughts

Posted by , | Views: 38,064

Now that Steam has the ability officially to override a Linux game and run it through Steam Play instead, let's take a quick look at some differences in performance.

Before I begin, let's make something clear. I absolutely value the effort developers put into Linux games, I do think cross-platform development is incredibly important so we don't end up with more lock-in. However, let's be realistic for a moment. Technology moves on and it's not financially worth it to keep updating old games, they just don't sell as well as newer games (with exceptions of course). The intention with such comparisons is not to favour any developer or any method of gaming on Linux. It’s just to show what’s possible, what the differences are, what doesn’t work and so on. As the years go on, there will be more ways to run older games better and better, of that I've no doubt.

I'm not a zealot for any one particular method of gaming either and as a fan of all things gaming, software and technology, I thought it might be interesting and hopefully you do too. The tests were attempted on some games that have a Linux version, while also being games that are quite heavy on your system.

Note: All tests done at 1080p on Ubuntu 18.10, with the NVIDIA 415.25 driver and my 980ti with Proton 3.16-6.

First up, let's take a look at Tomb Raider (2013) which arrived on Linux back in 2016. Since Tomb Raider has a handy built-in benchmark tool, we will start off simply by showing the results:

Benchmarks also only tell one part of the story. In the case of Tomb Raider, through Steam Play it needed to run through entirely at least once or there was quite a lot of stuttering which wasn't the case in the Linux version. However, the Linux version has parts of the game where performance dives a lot and the Steam Play version is better there. To Feral Interactive's credit (who ported it to Linux), their later ports are miles ahead of this.

Sidenote: For the videos, the titles "Steam Play" and "Linux" show their corresponding videos to the side, in case that wasn't clear.

In the case of Cities: Skylines which released on Linux back in 2015 at the same time as the Windows version, testing out the "Benchmark" map from the Steam Workshop resulted in something I didn't expect. The performance was very close but the Linux version was noticeably smoother with a couple of extra FPS.

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

Either way, a big city doesn't perform well no matter how you do it. I should note here too, that even though the Linux versions performs slightly better it does eat up quite a bit more RAM.

Next up, MXGP3 a rather new Linux port from November 2018. Given how it's quite new, I honestly would have thought it would do reasonably well. As noted in my previous article, the performance of the Linux version isn't very good and Steam Play blows it out of the water.

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

Not a pretty picture, with the official Linux version struggling at times to even hit 30FPS it makes it difficult to control. It's also not a very good game but that's a different thing altogether…

Dying Light is up next, a personal favourite of mine. Also no benchmark mode I could find for the Linux version, so a comparison video keeping it as close as I could:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

As you can see, both versions work quite well. I've completed the game more than once and I was actually happy enough with the performance of the Linux version, it was good enough and playable. However, the Steam Play version with Vulkan is at times around double the performance of the Linux version which is quite striking.

Next up, I tried Total War: WARHAMMER II. A Linux port from Feral Interactive released only in November last year. This would have been quite an exciting comparison, since the Linux version uses Vulkan. First issue encountered when trying it in Steam Play, is that it gives you a completely blank white launcher, so you need to opt into their new launcher beta which does work in Steam Play.

So you hit play on the fancy new launcher, guess what happens next? You get a brief moment of life, a glorious flash of black…and then it just quits to the desktop. Happens across both Proton 3.7 and 3.16. So, Total War: WARHAMMER II in Steam Play is a dud whereas the actual Linux version does work rather nicely.

The curious one is Rise of the Tomb Raider, I've been told this should work in Steam Play to do a comparison. However, it faced the same issue for me as Total War: WARHAMMER II. A black screen for a moment and then it quits on me. I have sent a log to the creator of DXVK for that, maybe it will help somewhere. Again, the Linux version from Feral works nicely.

 

The testing in this article was going to be longer, I had some grand plans for doing a lot of comparisons. However, Steam Play is still in beta and it has an uphill battle ahead of it. Rise of the Tomb Raider, Total War: WARHAMMER II, Civilization VI, Deus Ex: Mankind Divided and BioShock Infinite didn't work at all in Steam Play across both Proton 3.16 and 3.7 but the Linux versions do work. Sad about not being able to test more, but it's an example of how a supported release is the better option for certain games (especially multiplayer games like Darwin Project) and not the answer to everything as some claim. Great as an option but not quite ready for prime time overall, it will be fun to watch it evolve over this next year.

As I've said before though, with Steam Play it's not just a case of squeezing out extra performance. It's also a question of support and features of the Linux version (gamepad support, fullscreen issues, missing graphics options and so on). From a performance standpoint though, it shows clearly Linux can be a gaming platform that performs well.

The biggest question in my mind is: do you really get any true support with games you purchase to play in Steam Play? What exactly are you paying for? I don't really have an answer for that. For a purchased game, the developer (you would think) would be focused on it and fix issues as they come up. With Steam Play though, it covers such a massive list you could end up waiting a while for a fix (if it's possible at all). Thankfully, Valve has made a good step towards stopping Steam Play updates breaking games, since the latest Steam client beta no longer overrides the Proton version for a game in the whitelist.

I may do more tests in future, if readers want me to you will need to let me know what games you want to see tested (they have to have a benchmark mode in the Linux version). We still don't have a decent amount of Linux games that actually do have a benchmark mode, so it does make such a thing rather tricky to get a lot of value out of it and comparison videos eat a huge amount of time for even the most basic rough editing.

If you wish to support GamingOnLinux, we have many options available see here.

Article taken from GamingOnLinux.com.
42 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more information here.
About the author -
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
112 comments
Page: «6/12»
  Go to:

PJ 18 January 2019 at 11:58 pm UTC
this tests make me think that John Carmack might have been right after all ;) ...
Leopard 19 January 2019 at 1:02 am UTC
PJthis tests make me think that John Carmack might have been right after all ;) ...

No , just look at one message above.

When ports done right ; native is preffered.
titi 19 January 2019 at 2:49 am UTC
mxgp3 for me it's like 1-5fps with the linux "port". It's completly unplayable.
BUT fully playable with smooth framerates using proton
elmapul 19 January 2019 at 7:16 am UTC
i'm really disapointed, i was saying "there is no reason to run those games on proton, they already run on wine"
well, looking at those numbers, looks like we were wasting more performance than i thought and its hard to support aspy/feral with ports like that.

even if i want, i cant afford to pay an hardware much better than the needed to play the games, using windows is just cheaper at that point, using it and donating the money i saved on hardware to some floss software seems to be an better contribution than be just an number...
elmapul 19 January 2019 at 7:43 am UTC
KimyrielleAlso, remember when Loki's native ports stopped working on newer Linux machines because of library updates and distro changes? Native ports aren't the perfect solution either, honestly.

native ports are the solution, but with the current marketshare we will not have many.
the fact that those old games stoped working is only an sign of an bigger problem: no one is held accountable to break compatibility on linux.
microsoft knows that they and their parners will lose a lot of money if they break backward compatibility, but on linux? no one care, if anything goes wrong just let the comunity fix it, and if they dont fix it, the distro makers certainly will not either, unless a lot of people are willing to pay... for support, i guess you cant sell support if no one have troubles.

at least with valve on our side, some one makes profit on each game sold so they have an reason to care.
and as for the marketshare, well, i dont see it changing anytime soon without exclusives


MagicMythI can see Steam Proton soon being able to run a tone of older games easily that Windows 10 either requires a lot of hacks for or just can't be done. It will be a funny time when a large amount of one's Windows games collection only works on Linux as the years go by.

and people will just buy then again on gog, hack it until it works or install windows subsystem for linux and install wine on it S(some people are already doing that)



Avehicle7887Nice article and it answers my question of "How does native Dying Light compare to DXVK?" pretty much perfectly. But to be honest, I kinda expected these results since all the native games tested are using OpenGL. Porting houses need to adopt Vulkan the same way Feral did.

OpenGL is still fine for low graphics titles but for intensive games Vulkan is a must.

dying light is an old port, vulkan didnt even exist back then.
still, its impressive that vulkan is so fast that you can translate from DX to Vk and still get an better performance than just runing it on openGL...


[quote=YoRHa-2B]
KimyrielleIf I remember right, Valve already hired the person behind DXVK, so it's not that they aren't getting compensated for their work.
Literally me. That's why I mentioned it ;)

OMG, its you ? THANKS!

wvstolzingAs to Vulkan pn the PS5, I wouldn't hold my breath for it. I expect Sony to use their own proprietary even-closer-to-the-bare-metal graphics API, together with their own proprietary tools for the developers.

Also, the choice of FreeBSD as the os most likely has nothing to do with wanting to work in a unixy environment, or FreeBSD's own strengths (networking? jails? ZFS? tidy directory structure and great man pages?), but everything to do with the permissive licensing.

Sony and Nintendo are part of the Khrnos group, they fund vulkan, but i doubt they only support it.

their strategy may be the same strategy that microsoft uses.
support openGL and vulkan to get the multiplatform games, and have their on proprietary api for those who want to take the most of the hardware (and to make it more expensive for the companies they hire to make exclusives, to break the platform exclusivity)
since PS4 is the king of the current gen, most games should be developed using its own propritary APi first, then ported to Dx to run on xbox and pc, and in parallel ported to switch... just kidding no one makes games for switch =p


Last edited by elmapul at 19 January 2019 at 8:05 am UTC
jens 19 January 2019 at 8:45 am UTC
View PC info
  • Supporter
Avehicle7887Nice article and it answers my question of "How does native Dying Light compare to DXVK?" pretty much perfectly. But to be honest, I kinda expected these results since all the native games tested are using OpenGL. Porting houses need to adopt Vulkan the same way Feral did.

OpenGL is still fine for low graphics titles but for intensive games Vulkan is a must.

Yes, and to be fair, when Feral did their Tomb Raider 2013 port Vulkan was simply no option. At that time their work was the best to get on Linux, similar with DX:MD and other Feral games. Naturally when time proceeds other options may evolve, like DXVK, that is able to use a superior approach compared to the options back then. Newer Feral ports that use Vulkan are today the reference in terms of what is possible on Linux, because today their approach offers them more possibilities than what DXVK is able to do.

That said, DXVK clearly wins when looking at availability. Whereas Feral port are usually several months later than the Windows release, Steam Play/DXVK works on day one (if it works). Would be cool if Feral could improve on this side and shorten the time between window and their release date. Dunno what is in their hands though.


Last edited by jens at 19 January 2019 at 8:47 am UTC
Beamboom 19 January 2019 at 8:55 am UTC
thykrIt baffles me that non-native is much faster than native.

I really hope someday some smart software engineers will be able to explain why it is that way.

It's because none of them are really native, they all (including Feral & Co) use wrapper libraries. So to call those releases "ports" are really quite misleading.
dvd 19 January 2019 at 8:57 am UTC
jensThat said, DXVK clearly wins when looking at availability. Whereas Feral port are usually several months later than the Windows release, Steam Play/DXVK works on day one (if it works). Would be cool if Feral could improve on this side and shorten the time between window and their release date. Dunno what is in their hands though.

How is DXVK and SteamPlay porting? Who would pay 60 to 100 euros for that? No one... If i wanted to play wine games i would stick by the appdb... You know what else works on day one (if it works at all)? Windows...
Purple Library Guy 19 January 2019 at 9:13 am UTC
elmapul
KimyrielleAlso, remember when Loki's native ports stopped working on newer Linux machines because of library updates and distro changes? Native ports aren't the perfect solution either, honestly.

native ports are the solution, but with the current marketshare we will not have many.
the fact that those old games stoped working is only an sign of an bigger problem: no one is held accountable to break compatibility on linux.
Thing about Linux is, most of the software ecosystem for it is open source, and all the open source stuff with critical mass is maintained and improved on an ongoing basis. So the stuff just gets updated along with the libraries. Everyone uses the current versions or pretty close to because why would you use the old versions when your distro will cheerfully automate updating to the new for free?
Even the closed software for Linux tends to be stuff that's updated and security-fixed fairly continuously--server stuff and whatnot.

For Linux, closed games and their ephemeral nature are an outlier (and until recently much more of an outlier--there hardly were any through much of Linux's development). So this is not a problem anyone had much reason to think about. Making Linux as good as it could be by ruthlessly ripping out cruft and replacing outdated things (with certain exceptions, [cough] X [/cough]) took decisive priority over backwards compatibility because there was little backwards to need compatibility with.
mirv 19 January 2019 at 9:58 am UTC
View PC info
  • Supporter
  • Top Supporter
Beamboom
thykrIt baffles me that non-native is much faster than native.

I really hope someday some smart software engineers will be able to explain why it is that way.

It's because none of them are really native, they all (including Feral & Co) use wrapper libraries. So to call those releases "ports" are really quite misleading.

Well, most games probably have some kind of abstraction over the rendering API anyway. And most porting might use some library for the bulk of the work, but I think extra tweaks are made where necessary outside of that.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon, Liberapay or Paypal. We have no adverts, no paywalls, no timed exclusive articles. Just 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!

You need to Register and Login to comment, submit articles and more.


Or login with...

Livestreams & Videos
Community Livestreams
  • Crawl About: „The Warlock of Firetop Mountain“
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Comments
Latest Forum Posts