To go along with Liam’s benchmarks of the game on his Nvidia GPU, I decided to also run some tests on my RX 580 to give you a picture of the AMD performance of the Rise of the Tomb Raider port. So, let’s go!
Disclosure: I participated in the closed Linux beta for ROTTR and thus received a key for the game from Feral.
Let’s first go over my gaming rig specs before we jump into the results. My system uses an AMD R7 1700 at 3.7GHz and 16 GB of 2133MHz DDR4 RAM. The GPU I am using is an Asus ROG RX 580 8 GB. On the software side I’m using Antergos with Linux 4.15.15 with Mesa 18.0.1. Feral’s Gamemode was installed and operational for these tests.
Due to time constraints I stuck to running the benchmark through the Lowest, Low, Medium, High and Very High without anti-aliasing at 1080p resolution. Benchmarks were repeated a couple of times on each preset to eliminate as many discrepancies as possible.
So, let’s have a look at the numbers:
On the Lowest preset the game quite simply ran flawlessly, maintaining an average of above 100 FPS during each of the three scenes the benchmark went through. The low minimum framerate during the Syria scene appears to be an oddity of this game that makes the minimum framerates in this benchmark largely meaningless. While monitoring the game, it never actually seemed to drop down to 24 FPS, so my guess is that some individual frames in the benchmark just take abnormally long to render and bring the minimum framerate way down. You can see similar numbers in my other benchmarks of the game but I wouldn’t consider these low minimums meaningful. I decided not to average them out so as to avoid looking like I am tampering with the results.
Low preset isn’t a big change from the Lowest in terms of performance. The game still maintains an average framerate of around 100 FPS throughout the benchmark.
On medium settings the game is finally starting to make the RX 580 work but the averages are still very much on the healthy side of 60 FPS and even according to the somewhat untrustworthy minimums the game is maintaining a stable framerate.
On High settings the gap to 60 FPS is narrowing but there’s still some wiggle room for anti-aliasing effects and possibly increased resolution here.
At Very High some of the Scenes are hitting near the desired 60 FPS average and dipping below the 60 FPS at times, although not to a point of unplayability. You could probably still enable some anti-aliasing and get away with it, but if you are unwilling to occasionally dip below the 60 mark you might need to drop some settings to achieve a constant framerate.
Overall I’d say this port is working quite wonderfully. Not only are AMD cards on the officially supported list, they would seem to be running quite well too. Do note however that 1st and 2nd generation GCN graphics cards (or older) are not supported, which makes sense considering the experimental state of the Vulkan drivers for those graphics card. According to Feral at a minimum you want an R9 285. So, if your GPU is either that or an R9 380, RX 470/570, RX 480/580 or better you should be good to go.
When it comes to the actual game, I sadly haven’t been able to test it too much. I played about 3-ish hours of the game during the beta and I didn’t run into issues, graphical or stability-wise so I think the game beyond the benchmark is also shipping in good condition. As far as the gameplay and story are concerned, I’ll leave the evaluation of the game to those with more time on their hands.
Article taken from GamingOnLinux.com.
Here's mine @1440p V-High preset FXXA
If you want to have a multiplatform support you will need an abstraction layer that "wraps" the OS API, every software has to do that in order to get multiplatform support
In case of proper multiplatform engine, such abstraction sits above system specific APIs. In case of wrapping, system specific API like D3D takes priority, and everything else is translated from it. I.e. it's a post factum design that needs to retrofit things, rather than proper from scratch one.
As far as I know, Feral don't redesign existing Windows only engines, they just fit Vulkan behind D3D for them. Therefore it's a wrapper, and not a native approach.
strings says DX11:
NxShader_DX11CopySurfacePS_Default
NxShader_DX11CopySurfaceVS_Default
NxShader_DX11ErrorMatPS_ColorPass
NxShader_DX11ErrorMatVS_Default
NxShader_DX11HistogramDebug_ColorPass
...
DX11AdapterId
DX11OutputId
I'm not sure how you are using the term wrapper vs native. I suppose you mean writing a new graphics backend for the engine vs translating the DX11 API into Vulkan calls. Seems like the translation is a more generic solution and more easily applied to other games. It's the sort of thing that could build momentum and as more support is added and performance tweaked then porting games only becomes easier over time, as opposed to writing a from-scratch backend for an engine they might never use again.
strings says DX11:
NxShader_DX11CopySurfacePS_Default
NxShader_DX11CopySurfaceVS_Default
NxShader_DX11ErrorMatPS_ColorPass
NxShader_DX11ErrorMatVS_Default
NxShader_DX11HistogramDebug_ColorPass
...
DX11AdapterId
DX11OutputId
Ah, thanks for confirming! I wonder then, why dxvk supposedly performs much worse.
I'm not sure how you are using the term wrapper vs native. I suppose you mean writing a new graphics backend for the engine vs translating the DX11 API into Vulkan calls.Yes, exactly. Native would mean no translation, but direct usage of the API. Translation means that foreign API still sits in between.
Ah, thanks for confirming! I wonder then, why dxvk supposedly performs much worse.
I expect that Feral is not doing any on the fly shader translations.
Here's mine @1440p V-High preset FXXA
Our resolutions aren't that much different and yet there's ~30ish frame difference so it really makes me want to retry with Mesa 18. Might have to fire up Fedora/Ubuntu...AFTER my exam that is.
Last edited by drlamb on 20 April 2018 at 1:32 pm UTC
Ah, thanks for confirming! I wonder then, why dxvk supposedly performs much worse.
I expect that Feral is not doing any on the fly shader translations.
That can only reduce stuttering, but it shouldn't make it perform better in general. However if they rewrite shaders and optimize them - that can make some difference.
Last edited by Shmerl on 20 April 2018 at 1:33 pm UTC
Here's mine @1440p V-High preset FXXA
Our resolutions aren't that much different and yet there's ~30ish frame difference so it really makes me want to retry with Mesa 18. Might have to fire up Fedora/Ubuntu...AFTER my exam that is.
I know it's not a huge jump but actual number of pixels extra on your res is quite a few. Though going on you have a TR I would have thought you'd be closeer than 30 ish.
Does the FE use have different clocks to the rx64 ?
Does the FE use have different clocks to the rx64 ?
Yes, The FE has higher base and boost clocks, though mine does throttle a bit unless I force the fans/undervolt (currently not possible on Linux - waiting for 4.17). After my exam I'm going to give it the liquid metal treatment to see if that improves things a little bit.
Does the FE use have different clocks to the rx64 ?
Yes, The FE has higher base and boost clocks, though mine does throttle a bit unless I force the fans/undervolt (currently not possible on Linux - waiting for 4.17). After my exam I'm going to give it the liquid metal treatment to see if that improves things a little bit.
May be the difference then, Mines under water and rarely hit's the 50's even after a few hours, warmer weather it will I should think.
I was kinda hoping that AMD's Wattman would come to us but I should doubt it will :(
They probably just do HLSL to SPIR-V. This is vulkan after all. Not OGL. I'm sure they tweak them but I doubt they rewrite them. Honestly I think people are sometimes a bit unfair to Feral. No port is truly fully native because they're ports after all. Even Windows gets ports and some of them are literally unplayable. Remember Arkham Knight? At least Feral's ports always perform decently and don't just do wine or something similar. I don't support wrapping and doing not much else but they seem to actually care and work on their ports not just wrap them. Anyways just my two cents.Ah, thanks for confirming! I wonder then, why dxvk supposedly performs much worse.
I expect that Feral is not doing any on the fly shader translations.
That can only reduce stuttering, but it shouldn't make it perform better in general. However if they rewrite shaders and optimize them - that can make some difference.
Last edited by Scoopta on 20 April 2018 at 7:11 pm UTC
They probably just do HLSL to SPIR-V. This is vulkan after all.
Good point. glslang should support HSLS to SPIRV-V translation in some way already. Unlike HLSL → SPIR-V, dxvk is translating dxbc directly, so may be it has less potential to optimize.
I think people are sometimes a bit unfair to Feral. No port is truly fully native because they're ports after all.
I don't mind the fact that it's not fully native. Just the fact that they never release games DRM-free :)
Last edited by Shmerl on 20 April 2018 at 7:31 pm UTC
I was kinda hoping that AMD's Wattman would come to us but I should doubt it will :(
Actually there's Wattman like functionality in 4.17
Yep! This is what I was referring to and I personally can't wait.
Initial wattman-like support
Taken from here, which is also referenced in the above phoronix link. Thanks Disharmonic.
I was kinda hoping that AMD's Wattman would come to us but I should doubt it will :(
Actually there's Wattman like functionality in 4.17
Yep! This is what I was referring to and I personally can't wait.
Initial wattman-like support
Taken from here, which is also referenced in the above phoronix link. Thanks Disharmonic.
I was referring to the actual program that's part on the AMD driver on windows, not the underling functions
Yeah. As someone else mentioned the DRM is probably the publisher's decision not the devs and therefore not Feral's.They probably just do HLSL to SPIR-V. This is vulkan after all.
Good point. glslang should support HSLS to SPIRV-V translation in some way already. Unlike HLSL → SPIR-V, dxvk is translating dxbc directly, so may be it has less potential to optimize.
I think people are sometimes a bit unfair to Feral. No port is truly fully native because they're ports after all.
I don't mind the fact that it's not fully native. Just the fact that they never release games DRM-free :)
Well, there's radeon-profile that seems to have some overclocking/fan control support. Haven't tried the overclocking feature myself. It does seem like the project is dead though and the main dev hasn't done anything on Github since last August. Radeon-profile githubI was kinda hoping that AMD's Wattman would come to us but I should doubt it will :(
Actually there's Wattman like functionality in 4.17
Yep! This is what I was referring to and I personally can't wait.
Initial wattman-like support
Taken from here, which is also referenced in the above phoronix link. Thanks Disharmonic.
I was referring to the actual program that's part on the AMD driver on windows, not the underling functions
Yeah. As someone else mentioned the DRM is probably the publisher's decision not the devs and therefore not Feral's.
There are ambiguous statements on this from Feral themselves. To avoid too much off-topic in this thread, there is one specifically about it.
Last edited by Shmerl on 20 April 2018 at 10:31 pm UTC
I was referring to the actual program that's part on the AMD driver on windows, not the underling functions
Gotcha. Radeon software on Linux would be nice. I'll just be happy if I can achieve similar results as it doesn't matter (to me) how I interact with "wattman."
Yeah. As someone else mentioned the DRM is probably the publisher's decision not the devs and therefore not Feral's.
There are ambiguous statements on this from Feral themselves. To avoid too much off-topic in this thread, there is one specifically about it.
Already use it but it's not really comparable to wattman on windows
Patreon
PayPal
See more from me