Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Trying the experimental GCN 1.0 support in AMDGPU

By - | Views: 25,412
Inspired by the recent release of Dawn of War 3, I decided to try out the experimental GCN 1.0 support in the new AMDGPU kernel driver and share my experiences.

Before I get to the actual testing I think I should first write down a couple of words about the kernel drivers and why this testing was done to begin with.

At this point in time there are two kernel drivers for AMD graphics hardware that matter: Radeon and AMDGPU. These drivers are responsible for managing the hardware while Mesa and other components on top of them provide OpenGL support for example. Radeon is the older driver of the two and it’s in a fairly mature state but it does have a couple of downsides, mainly the lack of Vulkan support. AMDGPU is a newer AMD-made driver which has support for GCN 1.2 hardware and Polaris and it supports the RADV open source Vulkan driver.

My card being a first generation GCN GPU (the R7 370 is practically a rebrand of the R9 270, which was a rebrand of the HD 7870) it’s supported by the Radeon kernel driver and quite well too. However, Feral Interactive recently released Down of War 3 which did something quite unique: only the Vulkan version (experimental as it may be) was supported on AMD hardware due to a missing OpenGL feature (ARB_bindless_texture, for those that are curious). Since there is no Vulkan support at all for my GPU without AMDGPU, I decided that I’d do a bit of an experiment to see if the experimental GCN 1.0 support in AMDGPU is in a good enough condition for you to warrant switching to it over Radeon. The aim of this experiment was to test the state of various Vulkan games, of which we sadly only have a handful, and OpenGL games to see if there would be a performance difference between the two drivers.

The testing was carried out on my main gaming rig which consists of an R7 1700 8-core CPU running at 3.7 GHz, 16GB of 2133 MHz RAM and the Strix R7 370 4G card. Despite the experimental state of the GCN 1.0 support in AMDGPU I decided to stick to stable software components: Mesa 17.1.2, Linux 4.11.3 and LLVM 4.0. Testing the experimental AMDGPU support on Arch was made simple by the fact that the experimental support is built into the stock kernels, so you only need to create a file in /etc/modprobe.d/ with the line “blacklist Radeon” to switch to AMDGPU. Note that doing so on a pre-GCN card will probably not yield any particularly great results since AMDGPU only supports GCN hardware.

Initial impressions weren’t particularly promising and actually reminded me quite a bit of my first experiments with the Nouveau open source driver for Nvidia hardware. Immediately when I got to the login screen a purple line ran vertically on the left side of my monitor and the image quality didn’t quite look right. Particularly text looked blurry. The desktop was usable though and both issues were fairly minor, but noticeable nonetheless. On Radeon neither of these things happened and the pixels looked quite a bit better.

image

Now, I cannot really put image quality into any kind of a number but I can run various benchmarks that will at least give me numerical figures of performance. I decided on a set of my usual benchmarks complemented by a couple of games that I figured would be interesting. Let’s begin by running a set of OpenGL benchmarks comparing the performance of the two drivers and move onto the Vulkan testing a bit later on.

image

Starting with a game I’ve spent quite a lot of time playing recently, you can see the AMDGPU driver was noticeably slower than Radeon. Both drivers maintained playable framerates but considering we are below the 60 FPS threshold it’s quite clear that Radeon offers the better gaming experience here being significantly closer to that 60 FPS mark than AMDGPU.

image

Half-Life 2: Lost Coast isn’t a particularly demanding benchmark but I’ve included it here since it’s been a part of my benchmark set pretty much always. The results were almost the same, though Radeon was just a tiny bit faster. However, considering we are above 200 FPS the difference is quite insignificant.

image

Time for some traditional 3D benchmarks. Unigine Heaven at 1080p with AA, Graphical Quality and Tessellation maxed out yielded a win for the Radeon driver once again, this time with a fairly significant 66.4% margin.

image

Valley was a similar story. AMDGPU was significantly slower than Radeon.

image

I included Counter-Strike: Global Offensive in the testing due to the popularity of the game. Being a Source game like HL2 the performance difference isn’t surprising but it’s there regardless. You could probably happily play CSGO on either of the two drivers but Radeon was measurably faster in this test.

image

Time for the open source benchmark of the set. Xonotic with the settings cranked to Ultra at 1080p showed a considerable difference in performance between the two drivers. The average framerates may not matter so much in this 100+ FPS range but the game had a bit of a hick-up on AMDGPU which dropped the minimum framerate all the way down to 40 FPS, which can definitely affect your performance in a fast-paced game like this.

Now, let’s begin testing Vulkan, which is pretty much the main reason behind this experiment of ours.

image

First to establish a bit of a baseline I ran Talos Principle on OpenGL on both drivers. You can see the AMDGPU driver getting beaten by quite the margin here.

image

Taking the better result from the OpenGL testing I compared it against the performance on Vulkan. And, as you might imagine, I wasn’t particularly thrilled by this outcome. OpenGL on Radeon was significantly faster than Vulkan on AMDGPU and even OpenGL on AMDGPU was faster, though by a smaller margin, than the Vulkan result. On top of this the Vulkan renderer had numerous graphical glitches, which forced me to run the benchmark on High settings instead of Ultra.

image

If you want to talk about CPU bound benchmarks, here’s one. Since the selection of Vulkan games isn’t particularly high I decided to bring out vkQuake, a Quake engine that uses a Vulkan renderer. As a comparison I used Darkplaces, a Quake engine with an OpenGL renderer. It’s not the optimal comparison but I think I can still make my point. While vkQuake is arguably very playable, running the timedemo of demo1 at blazingly fast 597 FPS, the Darkplaces engine was able to pull 1400 FPS on OpenGL on both the AMDGPU and Radeon drivers. In fact, I was able to use some of the more advanced graphical settings on Darkplaces and get a better performance AND higher visual quality at the same time compared to vkQuake.

Rest of my Vulkan testing didn’t yield any numerical data so I will stick to describing it with words. I intended to run a benchmark of Serious Sam Fusion on Vulkan and OpenGL but sadly I was bored to death before the first run of the benchmark was even done. The benchmarks in Serious Sam Fusion are a full level played by a bot that also moves like a robot, goes through every secret and has a 100% accurate aimbot. Quite simply, the benchmark was boring and long and I wasn’t willing to waste that much time on this test. From the few incomplete benchmark runs it seems that Vulkan had no significant impact on the performance and there were also some minor but noticeable visual glitches.

So, that wraps up the okay-but-not-impressive department of Vulkan games and now we move over to the total-train-wreck portion. Dawn of War 3, the game that was the inspiration for this testing, immediately hung after launch, giving me a black screen. With the Vulkan drivers being thinner than the OpenGL drivers this black screen wasn’t something I could take care of with an alt-tab either and I had to forcefully reboot the machine to get my graphics back. Mad Max with the beta Vulkan renderer worked a little bit better but after about 30 seconds of gameplay the game hung in a similar fashion and I had to reboot the machine. Finally I tried the Vulkan renderer of Ballistic Overkill and the game simply crashed me back to desktop, a result I found surprisingly positive in the light of the total system hangs I’d experienced earlier.

So, overall the Vulkan results either didn’t impress or were a quite spectacular failure. Initially I planned for this experiment to take a full week, just like I did with my Nouveau experiment some time ago but it seems I’ve grown a bit too comfortable with the performance figures I’ve seen on the Radeon driver and instead I cut the experiment down to a single day. Based on my testing there weren’t really any benefits of using the AMDGPU driver over Radeon. Sure, you are able to play certain Vulkan games but even with those Vulkan games you are getting reduced performance and/or graphical glitches. With OpenGL you can expect reduced performance more or less across the board and with certain games that teeter on the edge of playability, like Quern: Undying Thoughts, you can find yourself going below those desired minimum framerates where before you were able to achieve at least that consistent 30 FPS threshold.

Despite these quite negative words I’m putting here I would like to stress the point that this testing is specific to my R7 370, a graphics card that only has experimental support in AMDGPU, so do not take my words as a general bashing of the AMDGPU driver. I’ve used AMDGPU on my laptop and I haven’t seen the sorts of issues there that I’ve seen on my desktop. However, I think this testing shows that you shouldn’t really be concerned about whether or not you should switch to AMDGPU with your first generation GCN card. According to the testing you’ve seen here, there are practically no benefits in doing so, Vulkan games for the most part do not work or they run slower, image quality is worse and OpenGL in general runs slower.

As for that Dawn of War 3, well, bindless textures seem to have made their way to Mesa-git so I imagine the OpenGL renderer will work on my GPU in the foreseeable future. And should it not, well, I think my GPU might be due for an upgrade soon enough either way. Article taken from GamingOnLinux.com.
10 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.
20 comments
Page: «2/2
  Go to:

axredneck Jun 19, 2017
amd-staging kernel doesn't have this bug with purple line for me (because of new Display Code maybe) but it also doesn't have BFQ so for now i stick to linux-zen and radeon.
Leopard Jun 20, 2017
Quoting: seven.....and this is why i always use nvidia.....

Did you see that Amd card is not supported properly?

Try that with an Rx 580 and see the difference.
darkszluf Jun 20, 2017
got a similar experience with Oland XT and decided to stick to radeonsi.

hell the PRO driver doesn't even work properly here.
Blauer_Hunger Jun 20, 2017
Quoting: seven.....and this is why i always use nvidia.....
I prefer AMD because of it's open-source driver (at the moment I'm using amdgpu with an R9 270X, based on a Pitcairn refresh, without any problems), which can be used with PRIME without any problems. This isn't possible with nvidia cards, neither with nouveau, which lacks reclocking support, nor with the proprietary driver, which can only render everything on the dGPU or nothing. The Bumblebee project (which tried to make PRIME work when Nvidia didn't support hybrid graphics on Linux at all) seems abandoned since 2013.

And what about the Code 43 errors with gpu-passthrough of nvidia cards? AMD doesn't do such crap. The cards that have reset issues have workarounds without an impact on performance. In contrast, to run Nvidia Geforce cards with passthrough, you need to disable some hypervisor features to make them run, and you can't even use the emulated QXL video card, so it's impossible to use them on headless systems.
strunkenbold Jun 20, 2017
GCN gen1 cards have very low priority for AMD, thats sad as even newer cards (although the lower ends) still use the architecture.
The performance difference is a regression. amdgpu and radeon where always on the same level. RadV had very poor support in the beginning. Im actually surprised things are working better now, when I tested last time, any vulkan app crashed the system hard.
Thanks for the test, saved me time to try myself.
Arcanoxer Jun 20, 2017
Quoting: Blauer_Hunger
Quoting: seven.....and this is why i always use nvidia.....
I prefer AMD because of it's open-source driver
And i prefer a working driver, lt's that easy.
There are to many problems with AMD Hardware under Linux (closed and open driver).
Leopard Jun 20, 2017
Quoting: Blauer_Hunger
Quoting: seven.....and this is why i always use nvidia.....
I prefer AMD because of it's open-source driver (at the moment I'm using amdgpu with an R9 270X, based on a Pitcairn refresh, without any problems), which can be used with PRIME without any problems. This isn't possible with nvidia cards, neither with nouveau, which lacks reclocking support, nor with the proprietary driver, which can only render everything on the dGPU or nothing. The Bumblebee project (which tried to make PRIME work when Nvidia didn't support hybrid graphics on Linux at all) seems abandoned since 2013.

And what about the Code 43 errors with gpu-passthrough of nvidia cards? AMD doesn't do such crap. The cards that have reset issues have workarounds without an impact on performance. In contrast, to run Nvidia Geforce cards with passthrough, you need to disable some hypervisor features to make them run, and you can't even use the emulated QXL video card, so it's impossible to use them on headless systems.

AMD open source driver is not an absolute solution because it still lacks of FreeSync and HDMI audio. These are very important but they're missing on Mesa.
Luke_Nukem Jun 20, 2017
Okay, vkquake is a vulkan port of quakespasm wich is the openGL version. You should have just used that instead of darkplaces since that engine has numerous bits'n'bobs added to it.
koyal13 Jun 20, 2017
I think it's still too early to make this benchmark...
STiAT Jun 20, 2017
While I'm not thrilled with the results having a RX460, I am still able to play most games very reasonable on lower settings.

I still own a nvidia 1080, but I decided to stay with amdgpu anyway. Just because I can be happy each mesa release that something works now which didn't work before :D.


Last edited by STiAT on 20 June 2017 at 9:30 am UTC
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.