Welcome back to Formula 1! Feral Interactive have given Linux gaming another great title, with the release of F1 2017 today.
Disclosure: My key was provided by Feral Interactive.
This is the first title from Feral Interactive that is Vulkan only, hopefully this means all future ports will use Vulkan so they can continue to refine their Vulkan work and keep improving the performance.
Here’s a little look at the Linux version in video form. This took far too many takes, more than I would care to admit, and I still didn't manage to win. Let's say it's just to show off how well it runs and ignore my complete lack of skill, shall we?
Direct Link
I actually thought I did okay until one of those last corners—dammit!
Port report & Benchmarks
The game has a built in benchmark mode, to access it simply go into the main settings, then to graphics options and you will see the entry there. This has made testing it rather easy, especially with the nice output it gives at the end.
In terms of the actual performance, it performs pretty damn well. I decided to dust off the Windows 10 drive to make a proper comparison for this one.
System specifications for testing: Ubuntu 17.10 (Gnome)/Windows 10, Intel i7-5960X 3GHZ, Nvidia GeForce GTX 980 Ti (387.22), 16GB DDR4 RAM, 1080p. All benchmarks had AA and AFx16 on.
First up, are the Linux scores. Please note all benchmarks were done on the preview build, but I don't expect the released build to have changed much in terms of performance. Also, the benchmarks were also tested on the 384 driver series, which showed practically no difference.
Update: Benchmarks re-done on the release build, no real difference.
As you can see, even on the highest setting it hits above 60FPS at a minimum, making it super smooth and responsive to play.
For comparison, here are the Linux (Vulkan) vs Windows (DirectX) scores:
See also: Samsai took a look at the performance with an AMD GPU.
While it’s another Linux port that doesn’t perform to Windows levels, I’m more than happy that on max settings it will stay above 60FPS resulting in a fantastic experience all around. Even so, it’s hard to ignore the difference in performance here which is pretty big. Much bigger difference than what I was personally expecting.
Of course, benchmarks only tell a tiny part of the story. I personally never put too much faith in benchmarks, considering you need to have the exact same hardware and software setup to see my scores. The question is, how does the game actually feel to play? Hopefully I will answer that and more below!
As usual, the Feral launcher looks awesome. Customized for F1 2017 with all the usual bits and bobs I’ve come to appreciate like monitor and resolution picking:
An interesting feature that I’ve never seen before, is the launcher giving an option of sending a crash report to Feral directly. It allows you to enter an email address too, so that they can get in touch—handy! I should note that was a driver issue my end, nothing to do with the game itself.
The game will tell you if your CPU is not in high performance mode, which their FAQ shows to run this command:
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
With this to set it back into power saving mode:
echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Run them at your own risk, I am simply copying them from the Feral FAQ to make it simple. For me, I haven’t had any issues using them.
The Linux version does seem to have at least one graphical difference with the Windows version. On Windows, Ambient Occlusion seems to have On/Off, ASSAO and HBAO+, but on Linux we don’t get HBAO+.
The first load of the game can take a while, for me it was around three minutes. Likely doing shader compiling, but every run after that took seconds. Don’t be alarmed if your first load time is rather long.
I haven't had a single freeze or crash, not once. I think this might actually be the most stable Linux port I've had from Feral Interactive. Really pleased with that.
Some thoughts
Following on from the Linux release of F1 2015, what we have here is a completely different world in terms of content and how the game feels as a whole. Since we didn’t get F1 2016, for Linux gamers it is such a huge difference it’s nuts.
I’m not someone who generally keeps up with F1 nowadays, so I won’t go into details on how it’s faithful to the sport or anything like that. I’m taking it as it is, with it being a rather great racing game to have on Linux.
Honestly, the way the career mode feels it's almost like a racing-RPG. There’s a fair bit of customization on offer, starting with actually creating a character, instead of choosing a famous driver while you also pick your team, helmet style and so on. I think it really helps with the sense of satisfaction in a racing game such as this, if I'm racing under my own name with my own style it makes me more excited to be a proper part of it.
I tend to fall out with racing games pretty quickly, as they end up being a dull experience once you’ve gone from race to race and nothing really changes. With F1 2017, it gives you plenty to do thanks to features like the R&D system, engine management and more. Seriously, it feels like I’m levelling up my car in some sort of RPG when I’m using my points.
You get Resource Points from completing practice sessions, winning races and so on. You can then spend those in the R&D Tree. Here, you can tweak your vehicle by adjusting the Chasis, Aerodynamics, Powertrain and Durability.
The downside of the career mode are the character models when you’re speaking to someone, as they’re a bit naff. Not the worst I’ve seen, but not amazing either. I’m not all that fussed about them though, considering the main point of the game is the racing.
The inclusion of some classic cars from the last 30 years is also a really nice touch, for those who love the classic designs it’s quite exciting to be able to drive them. They look absolutely gorgeous too. In fact, all the cars both modern and classic look highly polished and realistic. During the career mode, you will get invited to some events to drive these classic cars, but you can also choose to use them in races outside of the career mode if you desire. The events themselves are always different as well, some of which can be really quite challenging.
The rivalry system was also a good bit of fun, with you being given a rival over a period of multiple racing weekends. You gain access to a few statistics and winning the rivalry awards you “kudos” with your team. Throughout the rivalry, it will update you on how you’re doing, to give you that little bit extra to work towards and it’s yet another feature that really helped me get invested in the whole experience.
Two things I did notice is that the voice over work was far too quiet against the rest of the game and, along with that, the subtitles are done really weirdly. The subtitles tend to advance too quickly, which was a bit odd. Not a major issue, just weirdly timed.
What makes the driving experience great in F1 2017 is that the cars don’t suddenly go into an uncontrollable mess as soon as a wheel touches the dirt like a lot of racing games. I do that a lot too, because I’m an awful driver. Please don’t ever let me drive a real car, let alone an F1 car. On top of that, when you’re going full-throttle, it still feels like you have a good amount of control over the vehicle.
The driving experience is truly engaging, with your team chatting in your ear if you do an illegal move, warning you to cede that position or get a penalty. Something I heard rather a lot! Still unsure as to the exact rules, since at times I'm sure I've not been penalized for the same manoeuvrers. If you’ve got some damage, they will ask if you want to change your strategy with a little display in the right corner of the screen and show you what is damaged and how badly.
I'll be honest, racing in F1 2017 does feel like a bit of a tiring experience. Considering how long some of the races are, it's not going to be a game for everyone. For me it's especially difficult with my permanent hand injury, but I've enjoyed it so much I've tried powering through the pain for this. The game has made me sweat in fear as I swing around corners, as I move my body uncontrollably left and right with the turns, it's just such an awesome feeling.
Also, the game can be as easy or as difficult as you want it to be. There’s plenty of options for driving assists like braking assistance, anti-lock brakes, dynamic racing line (all the time, or corners only), pit assist and so on. You can also choose the difficulty of the AI, so there’s a lot of options to enable people of all skill to enjoy it.
Overall
Overall, it beats the pants off of F1 2015. A proper career mode, which is exciting to play, drivers that seem to have reasonably good AI and it does look fantastic. Probably the best F1 game I’ve ever played, hell, it’s one of the best racing games I’ve ever played.
As I said before, I haven’t really followed the sport properly for years. As I got older my interest in it just faded away, however, after playing F1 2017 it’s made me excited about it again.
We will be doing a livestream tonight on our Twitch channel, unless something truly terrible happens. It should be a community game, so you will be welcome to join in with us!
You can find F1 2017 for Linux on Steam and the Feral Store.
Article taken from GamingOnLinux.com.
Quoting: BrisseWant to try something running native Vulkan? Try Doom 2016 or Wolfensten 2 The New Colossus. Sadly, neither of those are available for Linux :(
And the first one flies using one. The second one probably will too after Wine makes some of the newer extensions visible.
As expected, fps are lower than first run, but they're still quite impressive for 1080p@Ultra. The surprise: GTX1060 & RX 580 fps gets higher FPS than Guru3d benchs on Windows. Not sure, but I think that later patches of the game improved performance so Guru3d shows the release/prereslease performance.
Sadly Phoronix didn't use GTX 980ti on the new test run, what would have give an idea of how much plays the CPU on this game comparing Liam results.
Last edited by x_wing on 3 November 2017 at 7:07 pm UTC
Quoting: edddeduck_feralI have pretty cool Force Feedback effects on my G25 with Dirt Rally on Linux too :)Quoting: wleoncioQuoting: edddeduck_feralWe worked with Fanatec to get full support for their wheels on Mac and Linux starting with F1 2017, this includes Force Feedback, LED shift support and speed details on the LED display if you have an F1 style wheel. As far as we know we're the only game developer to have full Linux support for these wheels right now so we're pretty excited to see what everyone thinks!
That is such great news! I've been meaning to purchase a Fanatec wheel (mainly because of how easy they can be disassembled), but I wouldn't pull the trigger on such an expensive setup before being basically 100% sure it would work on all my racing games.
Right now only F1 2017 is supported with Force Feedback etc on Linux. But going forward we'll have it in our future racing games. :D
Quoting: x_wingPhoronix updated their test and included RADV benchs with Mesa 17.3.
As expected, fps are lower than first run, but they're still quite impressive for 1080p@Ultra. The surprise: GTX1060 & RX 580 fps gets higher FPS than Guru3d benchs on Windows. Not sure, but I think that later patches of the game improved performance so Guru3d shows the release/prereslease performance.
Sadly Phoronix didn't use GTX 980ti on the new test run, what would have give an idea of how much plays the CPU on this game comparing Liam results.
And again with the apples and oranges. You can't come to any conclusions using Guru3D benchmark because they had completely different system and benchmark. Michael at Phoronix was using a significantly faster CPU for one thing. Were they even running on the same track?
Quoting: pete910Nice, Runs well tbh. The whole game is better that the 2015 I had. Not had a lot of time in it just yet though.
Some benchies @ 1440p
Low
Ultra
Just to add, on the 387.22 driver.
cpu limited i guess?
1440p Ultra with GTX 1070, drivers 387.22
[
edit: ohh wait i now see you have different track :)
Last edited by Xpander on 3 November 2017 at 7:37 pm UTC
Thank you Feral for the great penguin support (the actual customer support is excellent btw)!
Quoting: BrisseAnd again with the apples and oranges. You can't come to any conclusions using Guru3D benchmark because they had completely different system and benchmark. Michael at Phoronix was using a significantly faster CPU for one thing. Were they even running on the same track?
We can definitely get some conclusions from Guru3D bench. If you see their setup, it's quite similar to Liam setup plus some overclock in the CPU. And if you see Liam results, you'll note as me that the performance from guru3d is lower than Liams in Windows (and Guru3d had their cpu at 4.2 Ghz!). Definitely there was some performance improvement in game/drivers since the game release.
About the track of the test, you can check that in the bench script. So yes, guru3d and phoronix test are using Australia track.
I don't think that i7 [email protected] vs i7@[email protected] aren't comparable, but as the former is a little more powerfull It is quite interesting to analize how CPU power affects Nvidia driver performance on Linux.
Comandante Ñoñardo Nov 4, 2017
And I really would like to see a Windows10 vs Windows7 vs Linux benchmark using modest hardware like core i3 or an under-clocked core i5 with a gtx750ti or GTX1050ti, because if you want to build an Steam Machine, you may want to use and small case with a low profile card and a low power processor with an SFX format 300W PSU
They are not ported, the source code is not "translated" to run natively. They have had added an extra layer so that they don't NEED to be ported. This is a crucial difference.
And from THAT perspective, these releases are pretty damn impressive. They are like Wine on steroids, with a 100% smooth experience and pretty darn good performance.
They just are NOT ports.
Quoting: BeamboomThe whole problem here is that we call these releases "ports", when they in fact are "wrapped". Nobody expects a game run in Wine to be on par with Windows performance. We should apply that same expectation on these games.
They are not ported, the source code is not "translated" to run natively. They have had added an extra layer so that they don't NEED to be ported. This is a crucial difference.
And from THAT perspective, these releases are pretty damn impressive. They are like Wine on steroids, with a 100% smooth experience and pretty darn good performance.
They just are NOT ports.
As long as there are no Windows binaries inside - and I never heard of that for Feral ports - you're wrong.
Using a source wrapper is still a port. While WINE uses Windows binaries.
Quoting: BeamboomThe whole problem here is that we call these releases "ports", when they in fact are "wrapped". Nobody expects a game run in Wine to be on par with Windows performance. We should apply that same expectation on these games.
They are not ported, the source code is not "translated" to run natively. They have had added an extra layer so that they don't NEED to be ported. This is a crucial difference.
And from THAT perspective, these releases are pretty damn impressive. They are like Wine on steroids, with a 100% smooth experience and pretty darn good performance.
They just are NOT ports.
The loss of performance doesn't mean that there is Dx to Vulkan wrapper. It just means that the game was designed for an API in mind and then they decided to add support to another (just take a look on The Talos Principle benchs).
In the moment you see an elf file as executable, you can be sure that the game was compiled to run natively. We can discuss all day about "how much wrapped the game is", but we don't have access to the source code and sometimes there is no other way to make the port out of wrapping win32 calls.
The concept of "port" or "wine-like" is meaningless without the details of the low level design.
Comandante Ñoñardo Nov 4, 2017
Quoting: BeamboomThe whole problem here is that we call these releases "ports", when they in fact are "wrapped". Nobody expects a game run in Wine to be on par with Windows performance. We should apply that same expectation on these games.
They are not ported, the source code is not "translated" to run natively. They have had added an extra layer so that they don't NEED to be ported. This is a crucial difference.
And from THAT perspective, these releases are pretty damn impressive. They are like Wine on steroids, with a 100% smooth experience and pretty darn good performance.
They just are NOT ports.
Sadly, the actual Linux gaming porting scenario consist in legally crack a windows port of a console game for to make it work on a Linux machine.
Now, I don't want Linux game porters/crackers, I want true Linux game developers.
If someday I have a game "porting" company, my method will be this:
1. Get the publishing rights
2. Get the game assets and code
3. Develop a game using those assets that must look and behave identical to the original console/windows game.
The result will not be a Linux port of a Windows/console game; it will be a Linux version of that Windows/console game.
This method will take more time, but the result will be better and indeed it can be done at the same time of the console/windows development stage.
And, unlike a Linux port of a Windows port of a console game, a Linux version can include features that the original Windows/console don't have, such as better textures, better physics or even extra levels to play.
Quoting: GuestQuoting: Comandante ÑoñardoQuoting: BeamboomThe whole problem here is that we call these releases "ports", when they in fact are "wrapped". Nobody expects a game run in Wine to be on par with Windows performance. We should apply that same expectation on these games.
They are not ported, the source code is not "translated" to run natively. They have had added an extra layer so that they don't NEED to be ported. This is a crucial difference.
And from THAT perspective, these releases are pretty damn impressive. They are like Wine on steroids, with a 100% smooth experience and pretty darn good performance.
They just are NOT ports.
Sadly, the actual Linux gaming porting scenario consist in legally crack a windows port of a console game for to make it work on a Linux machine.
Now, I don't want Linux game porters/crackers, I want true Linux game developers.
If someday I have a game "porting" company, my method will be this:
1. Get the publishing rights
2. Get the game assets and code
3. Develop a game using those assets that must look and behave identical to the original console/windows game.
The result will not be a Linux port of a Windows/console game; it will be a Linux version of that Windows/console game.
This method will take more time, but the result will be better and indeed it can be done at the same time of the console/windows development stage.
And, unlike a Linux port of a Windows port of a console game, a Linux version can include features that the original Windows/console don't have, such as better textures, better physics or even extra levels to play.
The cost in time, and money, involved in doing all of that is just basically far too much to build a viable game porting company out of. For smaller, simple type games it might be ok, but not for anything more complicated. And ultimately, it doesn't matter: if the game runs, and runs well enough, then what does it truly matter?
While it might be a nice idea to be able to rewrite entire games each time, that is unfortunately wishful thinking unless porting games that already use engines capable of cross-platform play (unreal, unity3d, etc).
A lot of these people who talk about doing the ports "the right way" have probably never tried to port anything or translate to a different programming language before for any kind of project that actually has to ship and make money. Once that becomes true, you start to worry about things like deadlines and cost. You start asking yourself questions like, "If it passes the tests, does it matter if the performance is worse?"
I've been there. At my work, I had to translate embedded assembly, which is not fun to implement in a higher-level language. I know the translated version performs worse, but it's much, much easier to maintain, and it behaves the same. Well, it DID behave the same, until we started extending the code, because it was easier to do. And then, y'know, we eventually started cleaning it up, but that's only because it's a code-base we intend to use in future projects. If there wasn't the promise of future income, our company probably wouldn't be bothering to clean up the old code. Sucks, I know, but making something that currently works correctly be as nice as it can be doesn't typically feed you as well as making a new thing.
Last edited by niarbeht on 4 November 2017 at 5:03 pm UTC
Quoting: Comandante ÑoñardoQuoting: BeamboomThe whole problem here is that we call these releases "ports", when they in fact are "wrapped". Nobody expects a game run in Wine to be on par with Windows performance. We should apply that same expectation on these games.
They are not ported, the source code is not "translated" to run natively. They have had added an extra layer so that they don't NEED to be ported. This is a crucial difference.
And from THAT perspective, these releases are pretty damn impressive. They are like Wine on steroids, with a 100% smooth experience and pretty darn good performance.
They just are NOT ports.
Sadly, the actual Linux gaming porting scenario consist in legally crack a windows port of a console game for to make it work on a Linux machine.
Now, I don't want Linux game porters/crackers, I want true Linux game developers.
If someday I have a game "porting" company, my method will be this:
1. Get the publishing rights
2. Get the game assets and code
3. Develop a game using those assets that must look and behave identical to the original console/windows game.
The result will not be a Linux port of a Windows/console game; it will be a Linux version of that Windows/console game.
This method will take more time, but the result will be better and indeed it can be done at the same time of the console/windows development stage.
And, unlike a Linux port of a Windows port of a console game, a Linux version can include features that the original Windows/console don't have, such as better textures, better physics or even extra levels to play.
Yes, this is the perfect world. I would prefer that developers take Linux from the beginning into account too. But it won't happen for AAA games unless it will become realistic to sell something like 1 million copies (just a guess, but certainly not much less) of a game solemnly on Linux. That's still a long road to go (explained here https://www.gamingonlinux.com/articles/observer-is-a-fantastic-brain-hacking-horror-adventure-my-thoughts.10644/comment_id=107101 :) ).
For now we have to stick to games that are afterwards modified to run on Linux (and we need to buy them!!!). But to be honest, it is the result that counts. The quality of Feral/Aspyr/VP etc. reached an astonishing level. I don't mind the small performance penalty or the knowledge that it could be better. The games are rock solid, beautiful, very smooth and fast enough to keep me enjoyed for a long time.
Last edited by jens on 5 November 2017 at 6:47 am UTC
Quoting: meggermanQuoting: liamdaweQuoting: fatriffFeral recommends using the NVIDIA 384 driver series for now when playing this game as there are some current regressions with the 387 series up through 387.22.As already stated in the article and in the comments, I tested both driver versions and the difference was negligible.
Phoronix is getting 133FPS on Ultra VS your 80FPS on the same card..
I'm currently going through more tests to see if I can find any reason for me to possibly have lower than expected performance.
Keep in mind with Phoronix, his CPU is overclocked at 1.7GHZ faster than mine.
The linked Youtube be benchmark is also using a 1GHZ faster processor.
The base clock on mine is only 3GHZ, which could account for a lot of it.
Then again keep in mind that it might not be that ..
Quoting: pete910Arguments aside, Vulkan is awesome.
1440p ultra settings. CPU barely braking a sweat. How it should be on modern CPU's ;)
Could it be Gnome again ? I have experienced slower performance on select games under Gnome, it's one of the reasons i moved away from it. Phoronix testing was done under Unity AFAIK and that uses compiz, ubuntu-unity(compiz) is still the default recommended platform for most linux titles and id imagine many are tested on there.
Does Gnome desktop really take it's hand off the compositing fully ? If so how does the full screen hot key to mode work so seamlessly to grab the game window and present it in overview mode. Perhaps now Ubuntu has moved to Gnome, future games can be developed and tested on Gnome.
Could what ?
Not that I use gnome or even *buntu :P
Quoting: Comandante ÑoñardoSadly, the actual Linux gaming porting scenario consist in legally crack a windows port of a console game for to make it work on a Linux machine.
In essence, yeah.
Quoting: EikeAs long as there are no Windows binaries inside - and I never heard of that for Feral ports - you're wrong.
Using a source wrapper is still a port. While WINE uses Windows binaries.
I did simplify my statement, but I am not wrong. Huge parts of a source code on a language that is on all platforms - like C, C++, and now even C# - is per default multi-platform. It's only certain parts of the code - typically related to file system, graphical libraries and other platform specific libraries - that needs to be worked on. You can easily write a terminal program that can be compiled on all platforms without changing a single character.
So "porting" is in practise about changing the platform specific parts of a code. If you compile a source code by having that code to access another api instead of system apis, that is for all practical purposes to be called a "wrapper".
We can discuss semantics until we grow grey hair, but fact remains that in gaming, the graphical part - who remains platform specific - is a major part of a games performance. MAJOR part. So adding a middle layer to translate DX calls to Vukan calls is no minor detail. It doesn't matter then if the sources are recompiled to access those libraries - this part IS wrapped. And that is in essence what this is about.
Quoting: BeamboomSo "porting" is in practise about changing the platform specific parts of a code. If you compile a source code by having that code to access another api instead of system apis, that is for all practical purposes to be called a "wrapper".
We can discuss semantics until we grow grey hair, but fact remains that in gaming, the graphical part - who remains platform specific - is a major part of a games performance. MAJOR part. So adding a middle layer to translate DX calls to Vukan calls is no minor detail. It doesn't matter then if the sources are recompiled to access those libraries - this part IS wrapped. And that is in essence what this is about.
First off, by your concept of "wrapper" and "port" it will always be a grey definition. We don't know how a game is designed and how much coupled it is with original system, so all that we can discuss is a supposition game.
But let's get it simple: you assume that the games is "wrapped" due that it doesn't show a equal performance as Windows. But, why do you get that conclussion? It isn't possible that the way a game architecture focused on Dx11 is difficult to adapt to Vulkan? It isn't possible that a part of the gap is due that Nvidia hardware performs better with Dx11 than with Vulkan? You have lots of question to answer before conclude that Feral has a "wrapper" of Dx11...
https://www.reddit.com/r/linux_gaming/comments/5cis3p/feral_interactives_indirectx/
Quoting: x_wingIt isn't possible that the way a game architecture focused on Dx11 is difficult to adapt to Vulkan?
It is. In fact, Feral have stated just that their Vulkan talk earlier this year. Personally I see it as the API bias of the engine. And the fact is, most engines are biased towards D3D9 or D3D11. There is simply no economical way to fix this. This is demonstrated pretty well by Croteam. IIRC, they stated that their Serious Engine 3.5 was still mainly D3D9 biased. And you see the OpenGL renderer bolted there take a serious performance hit. They are slowly trying to change the bias to Vulkan, but it's proving to be a slow task. They have managed to exceed OpenGL performance without too much trouble, but exceeding D3D11 performance is (last time I heard) still not happening. Which may be why SS4 is taking more time than expected.
Quoting: x_wingFirst off, by your concept of "wrapper" and "port" it will always be a grey definition.
It's a bit grey yeah - and I have also stated that I have simplified here. But:
Quoting: x_wingyou assume that the games is "wrapped" due that it doesn't show a equal performance as Windows.
No, I say it is so because it is so. It is public knowledge, they do have their technology middle layer they use to translate DX to OpenGL (and now Vulkan) - even the name of that wrapper is known (I don't remember now but it should be only a quick googling away).
Read the links others have provided in this very thread. This is fact. This is not assumptions. It's just how it is. How do you think they could do all these releases, and how can they be so stable as they are? Because the main game is left as it is - no core code is changed in any significant way whatsoever.
And this is important that we know when we do judge these releases, else it's just plain unfair to them and the titles we do have and will receive - all thanks to their wrapper. This is not a demonstration of Vulkan, it's a demonstration first and foremost of their middle layer software that translates for them.
Last edited by Beamboom on 6 November 2017 at 10:12 pm UTC
Patreon
PayPal
See more from me