Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

Rise of the Tomb Raider tested on AMD RX 580

By - | Views: 48,740

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.
20 Likes
About the author -
author picture
I'm a Linux gamer from Finland. I like reading, long walks on the beach, dying repeatedly in roguelikes and ripping and tearing in FPS games. I also sometimes write code and sometimes that includes hobbyist game development.
See more from me
The comments on this article are closed.
68 comments
Page: «3/7»
  Go to:

KuJo Apr 19, 2018
Here another AMD-Benchmarks with an older (officially not supported) 2nd Gen GCN-Card:

AMD FX-6100
R9 280X 3GB VRAM (2nd Gen GCN)
16GB RAM
AMDGPU RadeonSI, Mesa 18 with Padoka PPA
Linux Mint 18.3 Sonya, Kernel 4.16.2

Because of lack of time: Only a single-one benchmark run. Not optimized yet (Gamemode not activated yet).
FPS at 1920x1080, medium settings

Mountain: Avg. 60,62 / Min. 24,98 / Max. 105,28
Syria: Avg. 45,02 / Min. 27,88 / Max. 60,79
GValley: Avg. 60,47 / Min. 37,76 / Max. 91,76
Shmerl Apr 19, 2018
Quoting: cRaZy-bisCuiTI wonder when the time has come that the Feral Vulkan Ports will perform better than Windows native!

Unlikely, unless somehow underlying Vulkan driver will have a lot better performance than native D3D. It makes more sense to compare wrappers themselves, like Feral vs dxvk/vkd3d.


Last edited by Shmerl on 19 April 2018 at 9:50 pm UTC
cRaZy-bisCuiT Apr 19, 2018
Obviously it's doubtfull, but since DirectX 12 doesn't perform as it should and DirectX 11 has a significant CPU overhead with AMD graphics cards on Windows it's possible. Feral is in some scenarios pretty close to even out results. A little more optimization for RADV and the port and it could happen. ;)

It would also be interesting to compare DXVK under Windows and under Linux as well and see if there's a difference.
MagicMyth Apr 19, 2018
Well I've just been playing the game for the last few hours on a GCN 1.0 card: R7 370 2GB and its been working out great. The only bug I came across was with the fancy hair option making Lara's hair go punk most of the time. Turning that setting off avoids the issue and gives a good speed boost as well. I've not noticed any slow downs on Medium plus some extra bits turned on (Tessellation, Sun lighting). The resolution technically is "low" at 1360x768 as that is the TV's native resolution.

So yes GCN 1.0 hardware does work fine so long as you have the amdgpu kernel driver enabled (FYI I'm using Linux 4.16 on a Intel [email protected]).
Shmerl Apr 20, 2018
Quoting: GuestI may give DXVK a go in a couple weeks just out of interest.

Can you tell if the game is using D3D11 or D3D12 when translating to Vulkan? No one seems to know this.

Quoting: Guest--edit: I may also play with gallium hud soon, to see how well it's using each cpu core, and any other options I can see. Again, just out of interest.

Since it's using Vulkan, you won't be able to use GALLIUM_HUD with it, and Mesa developers didn't come up with Vulkan HUD yet.


Last edited by Shmerl on 20 April 2018 at 1:40 am UTC
x_wing Apr 20, 2018
Quoting: Shmerl
Quoting: GuestI may give DXVK a go in a couple weeks just out of interest.

Can you tell if the game is using D3D11 or D3D12 when translating to Vulkan? No one seems to know this.

Quoting: Guest--edit: I may also play with gallium hud soon, to see how well it's using each cpu core, and any other options I can see. Again, just out of interest.

Since it's using Vulkan, you won't be able to use GALLIUM_HUD with it, and Mesa developers didn't come up with Vulkan HUD yet.

Why do you think that Feral work it's a "wrapper". If you think as a "wrapper" as DXVK is, I think you're wrong.

In the other hand, DXVK implements DX11 over Vulkan API, so it won't be possible to do the DX12 test.
Shmerl Apr 20, 2018
Quoting: x_wingWhy do you think that Feral work it's a "wrapper". If you think as a "wrapper" as DXVK is, I think you're wrong.

Because that's what many claimed about Feral games in the past. They don't rewrite renderers from scratch in Linux APIs, they take renderers in D3D, and fit OpenGL / Vulkan backend for them. Exactly same idea as Wine, except they don't do it on the binary loading stage (static translation), but use access to source code to make compiler build resulting binary with translation already cooked in. And if they also have access to shaders sources, they can avoid ad-hoc translation of shaders.

Anyway, unless Feral changed their approach somehow for this game, I expect it to use same wrapper idea as before.

Quoting: x_wingIn the other hand, DXVK implements DX11 over Vulkan API, so it won't be possible to do the DX12 test.

So far no one confirmed to me, that Feral are translating D3D12 in this case.


Last edited by Shmerl on 20 April 2018 at 3:29 am UTC
x_wing Apr 20, 2018
Quoting: Shmerl
Quoting: x_wingWhy do you think that Feral work it's a "wrapper". If you think as a "wrapper" as DXVK is, I think you're wrong.

Because that's what many claimed about Feral games in the past. They don't rewrite renderers from scratch in Linux APIs, they take renderers in D3D, and fit OpenGL / Vulkan backend for them. Exactly same idea as Wine, except they don't do it on the binary loading stage (static translation), but use access to source code to make compiler build resulting binary with translation already cooked in. So unless Feral changed their approach somehow for this game, I expect it to use same wrapper idea as before.

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 (unless you're in a high level language... but the wrapping just goes one layer down). Unless the game has a very bad design, you won't have to implement the DX calls with another API (which is what wine does). So, Feral works is a native implementation.
Shmerl Apr 20, 2018
Quoting: x_wingIf 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.


Last edited by Shmerl on 20 April 2018 at 3:55 am UTC
x_wing Apr 20, 2018
Quoting: ShmerlThe difference with proper multiplatform engine is that 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.

Well, the game was ported to PS4, so one would spect that the engine is well designed enough in order to not be so tightly embraced to a graphic API (in fact, it support two graphic APIs on Windows). As I said, wrapping not necessary means to translate low level API calls.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring 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!
The comments on this article are closed.