Running The AMD Radeon R9 Fury With AMD's New Open-Source Linux Driver

Written by Michael Larabel in Display Drivers on 30 August 2015 at 12:09 PM EDT. Page 1 of 6. 25 Comments.

Now that Linux 4.2 is set to be released today, out on the horizon we have to look forward to Linux 4.3 kernel. Set to be merged into Linux 4.3 will be in the initial open-source AMD driver code for supporting the Radeon R9 Fury graphics cards. This open-source Fury support is the focus of our testing today with it being the first time powering up this Fiji GPU outside of Catalyst.

The Radeon R9 Fury support to be added to Linux 4.3 is AMD's first-cut support. This initial open-source support for the first GPUs with High Bandwidth Memory include support for graphics, SDMA, UVD video decoding, VCE video encoding, and other core functionality. Sadly, however, with Linux 4.3 there will not be any re-clocking / power management support. The R9 Fury support is being tacked onto the new AMDGPU kernel driver added in Linux 4.2 and there remains no support for power management on discrete GPUs -- at least until Linux 4.4 or later... With my initial AMDGPU tests from Linux 4.2 for this new driver that supports Tonga, Carrizo, and now Fiji, the Radeon R9 285 performance was quite slow due to the graphics card being bound to running at its boot core/memory frequencies rather than their designed high-performance power states. It will be interesting to see how this $550+ graphics card can perform on Linux 4.3 while being bound to its lowest frequencies.

Besides needing what will be the Linux 4.3 kernel (for my testing I obtained it from the DRM-Next Git tree for code that will be merged in the next two weeks to mainline), Fiji owners wanting to try this experimental open-source driver will also need the latest mainline libdrm and Mesa code now that the code is in the respective mainline Git repositories. The Fiji / AMDGPU support in user-space will become stable next month with the Mesa 11.0 release. Additionally, you will also need to grab the new xf86-video-amdgpu DDX driver (unless using xf86-video-modesetting), build the Mesa against LLVM 3.7 (or ideally LLVM 3.8 SVN as done in this article) for the latest AMD GPU LLVM compiler back-end, and also need to ensure you have all the necessary AMD Fiji microcode/firmware files downloaded and placed within /lib/firmware/amdgpu. Once you meet all of those requirements, the R9 Fury graphics cards should be able to power-up on this new open-source code.

In the non-rolling-release Linux distributions sending out new releases in Q4'2015, most of these new AMDGPU components should be in place. However, distributions like Ubuntu 15.10 will only be shipping with the Linux 4.2 kernel by default so there won't be this new open-source Fiji code in the kernel. Long story short, for the next few months you either need to be riding a bleeding-edge, rolling-release distribution like Arch or Gentoo, or be willing to jump through several steps if you want to use this half-baked driver.

While I came into this testing knowing the re-clocking support wouldn't be there for Fiji, news to me once I got the stack working is that only OpenGL 3.0 support is there for this new high-end graphics card on the open-source driver... While the rest of the hardware on the RadeonSI driver supports OpenGL 4.1 currently (and the hardware is OpenGL 4.5 capable) and the R600g Gallium3D driver for pre-GCN GPUs handles OpenGL 3.3, the Mesa 11.1-devel Git + LLVM 3.8.0 SVN code from this weekend only has enough support to reach OpenGL 3.0 compliance. Hopefully in the weeks ahead the Fiji support will catch up with OpenGL 4 so more Linux games can be run.

As another word of caution, when running tests, occasionally I run into some apparent mode-setting issues. A few times during testing I had to restart after I lost my display with the HDMI display reporting it was out of range.

The Slides Announcing The New "AMDGPU" Kernel Driver

For those not keeping up with their Phoronix reading, it's through this new AMDGPU kernel driver that in the future the Catalyst driver may utilize it rather than its own binary blob for their more unified driver model where Catalyst would be isolated to being a user-space binary-only component. However, AMD hasn't yet committed to when that change-over could happen, but it will likely still be a while. Details in AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy and AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver.

Related Articles