It was a nice surprise to see Tomb Raider officially supporting AMD hardware. Of course, the level of that support now has to be tested, so let's run some benchmarks!
Thanks to Pepster from our IRC channel, I also managed to get results from his hardware, so we have an additional card to show results from. My computer is an [email protected] GHz, 8 GB of 1333 MHz RAM and the R7 370 4G. Pepster's rig has an i7-5830K and a HD7970. My rig runs Xubuntu 16.04 and thus uses Mesa 11.2 as stated in the official requirements for the game. Pepster used a bleeding edge Mesa from git on his Manjaro 15.12 installation.
Before we go into the benchmarks I'd like to remind you that the official benchmark is not fully representative of the actual performance you will see in-game, so don't entirely rely on these numbers to determine level of playability.
We tested on all of the available graphics presets from Low to Ultra. TressFX was not supported on my installation and it was not behaving correctly on Pepster's rig, so it was disabled for these benchmarks. Worth noting is also that Pepster had to leave his Depth of Field to Normal during the benchmark on Ultra to work around a lighting bug. This problem was not present on my rig, so it's likely a bug somewhere in the bleeding edge driver suite.
As you can see, the results look quite positive and these GPUs managed to keep a smooth framerate all the way to High, with Ultra becoming more of a cinematic experience on the R7 370. Once again I'd like to remind you that these benchmark numbers do not fully reflect the actual gameplay experience.
I did also play the game for a little over an hour on Normal graphics setting and I was pleased with the experience. The framerate seemed to mostly stay around 40-60 FPS, sometimes going well over 60 and other times dropping down to the 30s. Some areas of the game do seem more demanding though and particularly when there was loads of fire everywhere the framerate started creeping down towards 30. More of an annoyance was the stuttering during asset loading/streaming. When new areas were loaded in, the game would stutter for a couple of seconds, practically stopping the flow of the gameplay until the new assets were properly loaded. So far this hasn't happened during a critical moment but it's annoying nonetheless.
I haven't made it too far into the game but so far the gameplay experience seems quite acceptable on the R7 370. Based on the performance I've been getting I probably wouldn't take the game any higher than Normal settings but the game also doesn't need to look like total crap to make it run at a playable framerate. What I've seen so far is not perfect of course, but very good nonetheless and it's definitely nice to see the open source AMD drivers making it to the system requirements.
Once again, thanks to Pepster for giving me some benchmark data! Article taken from GamingOnLinux.com.
Thanks to Pepster from our IRC channel, I also managed to get results from his hardware, so we have an additional card to show results from. My computer is an [email protected] GHz, 8 GB of 1333 MHz RAM and the R7 370 4G. Pepster's rig has an i7-5830K and a HD7970. My rig runs Xubuntu 16.04 and thus uses Mesa 11.2 as stated in the official requirements for the game. Pepster used a bleeding edge Mesa from git on his Manjaro 15.12 installation.
Before we go into the benchmarks I'd like to remind you that the official benchmark is not fully representative of the actual performance you will see in-game, so don't entirely rely on these numbers to determine level of playability.
We tested on all of the available graphics presets from Low to Ultra. TressFX was not supported on my installation and it was not behaving correctly on Pepster's rig, so it was disabled for these benchmarks. Worth noting is also that Pepster had to leave his Depth of Field to Normal during the benchmark on Ultra to work around a lighting bug. This problem was not present on my rig, so it's likely a bug somewhere in the bleeding edge driver suite.
As you can see, the results look quite positive and these GPUs managed to keep a smooth framerate all the way to High, with Ultra becoming more of a cinematic experience on the R7 370. Once again I'd like to remind you that these benchmark numbers do not fully reflect the actual gameplay experience.
I did also play the game for a little over an hour on Normal graphics setting and I was pleased with the experience. The framerate seemed to mostly stay around 40-60 FPS, sometimes going well over 60 and other times dropping down to the 30s. Some areas of the game do seem more demanding though and particularly when there was loads of fire everywhere the framerate started creeping down towards 30. More of an annoyance was the stuttering during asset loading/streaming. When new areas were loaded in, the game would stutter for a couple of seconds, practically stopping the flow of the gameplay until the new assets were properly loaded. So far this hasn't happened during a critical moment but it's annoying nonetheless.
I haven't made it too far into the game but so far the gameplay experience seems quite acceptable on the R7 370. Based on the performance I've been getting I probably wouldn't take the game any higher than Normal settings but the game also doesn't need to look like total crap to make it run at a playable framerate. What I've seen so far is not perfect of course, but very good nonetheless and it's definitely nice to see the open source AMD drivers making it to the system requirements.
Once again, thanks to Pepster for giving me some benchmark data! Article taken from GamingOnLinux.com.
0 Likes
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.
18 comments
Yeah, I disabled depth of field and a few other things and getting higher numbers on utlra with my 7870 running on mesa and llvm git. There's a few dips when transitioning from cutscenes for some reason but performance is always at least 30 fps, averaging around the above results. Played for about an hour as well. Might tweak some settings or knock down textures to high since I couldn't see that big of a difference but, so far, so good. Feral definitely showed us Mesa users some love. I hope performance doesn't tank later on in the game in the snowy areas.
0 Likes
theRealPadster Apr 28, 2016
It was always known for being very well-optimised. The sad thing is, running the same settings on Windows and Linux I get maybe 65-75% of the performance on Linux. :/
0 Likes
It was always known for being very well-optimised. The sad thing is, running the same settings on Windows and Linux I get maybe 65-75% of the performance on Linux. :/On saints row 3 for example, I get around 70% the windows performance on nvidia card, and the same pattern keeps repeating on most of the linux games. I guess is the best we can get from an engine not optimized for opengl.
0 Likes
It was always known for being very well-optimised. The sad thing is, running the same settings on Windows and Linux I get maybe 65-75% of the performance on Linux. :/On saints row 3 for example, I get around 70% the windows performance on nvidia card, and the same pattern keeps repeating on most of the linux games. I guess is the best we can get from an engine not optimized for opengl.
I'm definitely not an expert, but from what I understand there is a substantial performance loss when going from DirectX to OpenGL as the original engine was built towards DX9 or 11. This is why Arma III for example performs better than a native port - a well optimized wrapper avoids the problem and provides very Windows like gaming experience. Still, TR was pretty decently optimized on Windows, so the performance hit is not a problematic this time.
0 Likes
cRaZy-bisCuiT Apr 28, 2016
But the ports are native, aren't they? I thought if you need to rewrite the whole engine anyway, it might be possible to get the best performance out of OpenGL that is possible. We could only hope that well optimized Vulkan games will have the same performance as either Vulkan on Windows or an D3DX12 (the syntax is very similar) Vulkan port on linux.
0 Likes
But the ports are native, aren't they? I thought if you need to rewrite the whole engine anyway, it might be possible to get the best performance out of OpenGL that is possible. We could only hope that well optimized Vulkan games will have the same performance as either Vulkan on Windows or an D3DX12 (the syntax is very similar) Vulkan port on linux.
Yes it is possible with a lot of time. Which is not really profitable. Considering there are not too many(percentage wise) people who actually interested in FPS but rather in smooth game-play and smooth game play can be even achieved with 30 FPS it is even more evidently that it is not main focus while porting games. So yes will hope that developers will stop using directx at all ore porting from directx to vulkan will be without big performance loss.
0 Likes
The game keep crashing on me... I have nvidia with latest drivers.
I summited them a bug report... Hopefully they can short it out
I summited them a bug report... Hopefully they can short it out
0 Likes
edddeduck_feral Apr 28, 2016
The game keep crashing on me... I have nvidia with latest drivers.
I summited them a bug report... Hopefully they can short it out
Disable your VPN is you have one enabled the game is known to have issues when launched behind a VPN and this has been the cause for a few crashes on launch.
1 Likes, Who?
The game keep crashing on me... I have nvidia with latest drivers.
I summited them a bug report... Hopefully they can short it out
Disable your VPN is you have one enabled the game is known to have issues when launched behind a VPN and this has been the cause for a few crashes on launch.
Wow... # systemctl stop openvpn made it work... I dont even redirect any traffic to that vpn...
Not to distrust what this game is trying to do on launch so the vpn makes it crashes... but can i ask you the cause of this?
0 Likes
edddeduck_feral Apr 28, 2016
The game keep crashing on me... I have nvidia with latest drivers.
I summited them a bug report... Hopefully they can short it out
Disable your VPN is you have one enabled the game is known to have issues when launched behind a VPN and this has been the cause for a few crashes on launch.
Wow... # systemctl stop openvpn made it work... I dont even redirect any traffic to that vpn...
Not to distrust what this game is trying to do on launch so the vpn makes it crashes... but can i ask you the cause of this?
There is a library called Square Enix Online that is part of the online multiplayer and some of the achievement statistics in the game. This is the first game on Linux with this library so it has a few issues with VPN but we are working with Square Enix to get them resolved so you can play behind a VPN again.
0 Likes
There is a library called Square Enix Online that is part of the online multiplayer and some of the achievement statistics in the game. This is the first game on Linux with this library so it has a few issues with VPN but we are working with Square Enix to get them resolved so you can play behind a VPN again.
Im not behind a vpn at all. Is this square enix online library doing more than trying to open a socket to call home? :P
Anybody with more time than me can checkout the system calls and allay my concerns here?
Id love to be able to sandbox games, although I dont know if it is possible and keep access to the GPU
0 Likes
edddeduck_feral Apr 28, 2016
The library only does what is needed for game specific things like achievements, progress and multiplayer game matching.
I would say posting on this forum or using Steam both will use potentially more user identifiable data than a system used to track how many deer you've shot and other achievement counters. :-)
I would say posting on this forum or using Steam both will use potentially more user identifiable data than a system used to track how many deer you've shot and other achievement counters. :-)
1 Likes, Who?
native vs wine gallium-nine comparison from the good old Pontostroy
View video on youtube.com
i did some benches with pc with a bit old parts
mobo: ip35-pro
cpu: intel E8400
gpu: powercolor hd 5770
ubuntu mate - mesa 11.03-devel oibaf ppa
low:
low 26,6
hig 61,3
ave 46,9
medium:
low 22,4
hig 32,0
ave 29,3
high:
low 19,3
hig 30,3
ave 21,9
ultra:
low 17,6
hig 30,4
ave 22,1
tassellation was off, it creates some funny effects that totally cracked me up ahahah
i don't mind skinny girls, but that's too much i guess :D
High
Ultra
I did try ultimate but the hair didn't render correctly so didn't bother
Last edited by pete910 on 28 April 2016 at 7:41 pm UTC
This is custom, the one it picks when you first start the game. These are all at 1440p
Custom
High
Ultra
I did try ultimate but the hair didn't render correctly so didn't bother
Last edited by pete910 on 28 April 2016 at 7:41 pm UTC
0 Likes
It was always known for being very well-optimised. The sad thing is, running the same settings on Windows and Linux I get maybe 65-75% of the performance on Linux. :/On saints row 3 for example, I get around 70% the windows performance on nvidia card, and the same pattern keeps repeating on most of the linux games. I guess is the best we can get from an engine not optimized for opengl.
I'm definitely not an expert, but from what I understand there is a substantial performance loss when going from DirectX to OpenGL as the original engine was built towards DX9 or 11. This is why Arma III for example performs better than a native port - a well optimized wrapper avoids the problem and provides very Windows like gaming experience. Still, TR was pretty decently optimized on Windows, so the performance hit is not a problematic this time.
Here on 960 2GB i have frame drop to less them 20fps...
0 Likes
The library only does what is needed for game specific things like achievements, progress and multiplayer game matching.
I would say posting on this forum or using Steam both will use potentially more user identifiable data than a system used to track how many deer you've shot and other achievement counters. :-)
Im not really talking about being identifiably... but i do wonder what kind of info is trying to gather if it crashes because im running a background vpn.
Opening a socket to call home is bad enough... but what kind of info is trying to gather if it crashes because of the vpn service? I mean, how are they related to opening a socket. Its obviously trying to do more
0 Likes
edddeduck_feral Apr 29, 2016
The library only does what is needed for game specific things like achievements, progress and multiplayer game matching.
I would say posting on this forum or using Steam both will use potentially more user identifiable data than a system used to track how many deer you've shot and other achievement counters. :-)
Im not really talking about being identifiably... but i do wonder what kind of info is trying to gather if it crashes because im running a background vpn.
Opening a socket to call home is bad enough... but what kind of info is trying to gather if it crashes because of the vpn service? I mean, how are they related to opening a socket. Its obviously trying to do more
It really isn't doing any more :) It looks for a valid network connection to connect to Square Enix Online and it doesn't know how to correct deal with a response that a VPN exists on the network list so crashes. We're working with Square Enix to get an updated version of the library that deals with machines that have a VPN setup on Linux correctly.
0 Likes
It really isn't doing any more :) It looks for a valid network connection to connect to Square Enix Online and it doesn't know how to correct deal with a response that a VPN exists on the network list so crashes. We're working with Square Enix to get an updated version of the library that deals with machines that have a VPN setup on Linux correctly.
I really want to believe it...
To check for a valid network connection, you ping something outside. Or directly try to make your call home. There is literally no other way, since you dont know what lies behind the computer and what will work.
Anything else its doing too much or gathering too much information. The computer is in charge of the routing. Or are you trying to actively ignore and avoid the routing table that can be found on every computer
A vpn is nothing special. Just another entry on this routing table.
Thats why im asking what this software is trying to do. How does it gather this "response that a vpn exists that make it crash"? Dont be afraid of being specific. I will understand the details :)
PS, more details for the layman: A vpn routing entry on the routing table is indistinguishable for a route to your home router. One will be default (or not) and there is no way to tell if that is the vpn or your regular connection.
Even taking a peek at this routing table to guess what your network looks like is stepping over the line. Thats why programs are not in charge of the routing, your kernel is. And it follows your instructions.
To see this routing entry as a vpn, you should also have to check the process list and even further
For instance, maybe you route everything via your normal connection, but have a special route via your phone as a backup, so it can check on your server...
will this software try to use my phone to call home as well and cost me money? Are they trying to call home no matter what?
I dont want to adventure to say what are they trying to do so a vpn software makes it crash, but it doesnt smell good
PS2: im having a very good time with this game, but we are not a gullible bunch. Please dont treat us like so
Last edited by aL on 30 April 2016 at 10:15 am UTC
0 Likes
Patreon
PayPal
See more from me