Trying the experimental GCN 1.0 support in AMDGPU

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.



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.



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.



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.



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.



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



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.



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.



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.



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.



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.