Please excuse the broken english title. I’m also not entirely satisfied with not updating Mesa and LLVM and thinking about how to write up updating those in a friendly way
Intro
The goal of this guide is to get up and running with Ubuntu 20.10 and a RX6800 / RX 6800 XT with Steam & Vulkan in a reasonably quick way.
There are a lot of moving parts to a Linux distro and no one entity is responsible for everything needed under the umbrella of “Let’s Game.” Low level stuff in the Kernel, binary black-box blobs for device firmware, versions of low-level virtual machines for graphics rendering and more all factor, ultimately, into “Can I click on this game and run it?”
Ubuntu 20.10 was released around October 24 this year; AMD Launched their GPUs just a short time later. From the file date and times, it looks like they were qualifying their driver package around October 27 +/-.
If you download the AMD driver package from AMD.com, you’ll see many (MANY) packages as part of the download – LLVM, Xorg, dkms/kernel module implementation for Kernel 5.6 – I think, but not totally sure, this is a backport of some of the stuff in Kernel 5.10 for distros on “older” (haha, relative term) kernels, etc. This is why, if you try to use the amdgpu dkms on a 5.8.x kernel, you’ll get compile errors. And ultimately errors installing the amdgpu-dkms package.
One key thing in the driver from AMD is a binary firmware image. This is a closed-source component of the otherwise open stack that provides some low-level hardware interfaces and is a kind of compromise between a fully and completely open video driver stack and other more-closed approaches such as what we see with Nvidia’s approach to their Linux drivers.
Ultimately, a large part of the work companies like AMD are doing, goes into what is being built right now. Code in the mainline kernel, in mesa, in vulkan, etc won’t be ready for end users right away, for a variety of reasons, not the least of which is that “everything else isn’t done yet.” Software Development is hard, and the graphics subsystem of Linux is probably not as mature, in some ways, as it should be.
It is a sort of interesting situation – If you’re AMD, do you spend the time and effort trying to get the New Awesome Thing From Kernel Current running on Kernel Old OR do you try to bring the users forward with you in time to Kernel Current? Other things In Kernel Current may have bugs, and the code is not as heavily tested.
Obviously, in the context of AMD’s RX 6800 (XT) launches, the kernel itself is outside of AMD’s wheelhouse. Nevertheless, a lot of users expect AMD to try to make sure there is at least a reasonable out-of-the-box experience on Day 1. So some things are backported from Kernel Current to Kernel Old, with varying levels of success.
It further complicates things that “Let’s play a game” Is not just AMD’s driver and The Kernel. Vulkan, RadV and many other components are in the mix. Often, with Steam, Proton is also involved. This is near impossible to manage pre-release with NDAs because of the sheer number of parties involved.
I believe that all AMD can do is try to anticipate what those devs will need and supply as much documentation as possible. It’s a bit of a paradox that the more open the solution is, the more people need to be involved, the more difficult it is to co-ordinate and manage that openness ahead of launch. One of the best strategies is to focus efforts right at the forefront of where development is happening – in the kernel, in 3d, in games – and then once time passes that code will be in the hands of users as that code makes its way down the chain.
This guide is not the most perfect and optimal setup for the new GPUs. I expect it to be surpassed by January 2021, if not sooner. I’m going to walk you through getting a newer Linux Kernel, and so newer AMDGPU drivers in the kernel, obsoleting the need for the backported dkms driver from AMD’s downloadable driver.
I have some reservations about doing it this way for technical reasons, but I am hoping this setup a path of low resistance for new users that also doesn’t paint them into too much of a corner when thinking about the support Canonical/Ubuntu will eventually provide for updated kernels in updates to 20.10 natively via .deb packages.
Getting Started
This guide assumes you have some experience with Linux, know the terminology, and are comfortable in the terminal. A lot of this could be accomplished without the terminal, but I believe my instructions will be more reliably reproduced using the terminal.
I will do my best to also explain my thought process, which is the most important thing to understand in any process.
Install Ubuntu 20.10. I checked “Install Updates” and “Install 3rd party Drivers” for my installation, with an internet connection set.
When you first reboot, there will be no proper graphics driver loaded for your RX 6800 GPU. That’s okay. First, update the system using the software center, or the terminal:
sudo apt update && apt upgrade -y
Reboot, because you’re probably going to get a new kernel. Make sure you’ve got all the Canonical updates before we do anything further.
Next, head over to AMD.com and download the Ubuntu drivers for your GPU. Mine were:
amdgpu-pro-**20.45**-1164792-ubuntu-20.04
I extracted the archive to /tmp/amdgpu-pro-20.45-1164792-ubuntu-20.04
. Inside the archive are a lot of deb packages and you need almost all of them. Inside the directory is a shell script – amdgpu-install
it has a bug where if your home directory (username) has a space in it, it’ll fail. So I always copy it to /tmp or somewhere just to make sure it has the best chance of working.
in your terminal, go to the folder that contains all the debs and run ./amdgpu-install. In my case:
cd /tmp/amdgpu-pro-20.45-1164792-ubuntu-20.04
./amdgpu-install
It should be noted there is a doc folder here. With doucmentation! amdgpu-install DOES have working options for opencl, rocm, etc if those tickle your fancy.
They’re a bit outside of this quick-n-dirty howto, however.
Just for some aside commentary – look at all the places AMD had to touch in order to get this going – core, dkms (for kernel module), gst/omx, libdrm/2, mesa, etc. There are a lot of packages that are part of amdgpu-install.
Good and Matching Mesa/RADv/etc support is key. Matching means trying to use newer-newest versions of these components into newer/newest kernel. You cannot mix LLVM, Mesa and Kernel versions arbitrarily.
Overcoming The Error from AMD’s installer
Setting up amdgpu-dkms (1:5.6.20.906300-1164792) ...
Removing old amdgpu-5.6.20.906300-1164792 DKMS files...
------------------------------
Deleting module version: 5.6.20.906300-1164792
completely from the DKMS tree.
------------------------------
Done.
Loading new amdgpu-5.6.20.906300-1164792 DKMS files...
Building for 5.10.0-051000rc4-generic
Building for architecture x86_64
Building initial module for 5.10.0-051000rc4-generic
ERROR (dkms apport): kernel package linux-headers-5.10.0-051000rc4-generic is no
t supported
Error! Bad return status for module build on kernel: 5.10.0-051000rc4-generic (x
86_64)
Consult /var/lib/dkms/amdgpu/5.6.20.906300-1164792/build/make.log for more infor
mation.
dpkg: error processing package amdgpu-dkms (--configure):
installed amdgpu-dkms package post-installation script subprocess returned erro
r exit status 10
dpkg: dependency problems prevent configuration of amdgpu:
amdgpu depends on amdgpu-dkms (= 1:5.6.20.906300-1164792); however:
Package amdgpu-dkms is not configured yet.
dpkg: error processing package amdgpu (--configure):
dependency problems - leaving unconfigured
Setting up vulkan-utils (1.2.141.0+dfsg1-1) ...
No apport report written because the error message indicates its a followup erro
r from a previous failure.
Processing triggers for man-db (2.9.3-2) ...
Errors were encountered while processing:
amdgpu-dkms
amdgpu
E: Sub-process /usr/bin/dpkg returned an error code (1)
By the way, this install will fail. It’s meant for Ubuntu 20.04, as far as I can tell, and you can get LTS working, too, without too much headache. This guide is for 20.10, remember. I think this is probably the Better Path for Newbie-er Users. Maybe.
It is likely this install will error out because your kernel is too new – you’re probably now on Kernel 5.8 – this installer from AMD wants Kernel 5.6. Maybe not if AMD posted something newer. It’s okay, no big deal, let’s not worry about that for now.
Let’s instead get the Newest of the New kernels:
https://kernel.ubuntu.com/~kernel-ppa/mainline/
Look in that list. For me, v5.10-rc4 was the newest one, and the one I used. If 5.10 comes out, use that (and not a newer one) or if there is rc5 rc6 – try those. These Release Candidate versions. This is where the work is happening.
Developers are here, building the future. Yes, I know you want to experience The Future on Kernel 5.8, or Kernel 5.6, or whatever your distro shipped with, but instead, let us show you how to step into the future yourself. Eventually the time delta between Now and The Future may be smaller, but for now, with new hardware releases, it feel’s like a lot.
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc4/
These are the ones I used for this guide, YMMV, but newer is probably better so actually check!
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc4/amd64/linux-headers-5.10.0-051000rc4-generic_5.10.0-051000rc4.202011152030_amd64.deb
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc4/amd64/linux-image-unsigned-5.10.0-051000rc4-generic_5.10.0-051000rc4.202011152030_amd64.deb
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc4/amd64/linux-modules-5.10.0-051000rc4-generic_5.10.0-051000rc4.202011152030_amd64.deb
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc4/amd64/linux-headers-5.10.0-051000rc4_5.10.0-051000rc4.202011152030_all.deb
Download them.
Open a terminal:
sudo apt doesn’t know about the current working directory, so you should specify a full path. In my case my username for this guide is w, so something like the above screenshot.
Once that’s done, we actually don’t need the amd dkms anymore. the one that won’t install properly. Remove it:
apt remove amdgpu-dkms
Sometimes amdgpu remains blacklisted in /etc/modprobe.d – be sure to remove it or the amdgpu module from the kernel won’t load properly. Check
/etc/modprobe.d/blacklist-radeon.conf
and /etc/modprobe.d/blacklist-amdgpu.conf
to make sure. Understand what is happening here – amdgpu is in the kernel but amdgpu-dkms package provides an alternative amdgpu. However, the “20.45” package from AMD is in sort of this difficult spot where they qualified the driver for 20.04 but 20.10 was released just days before these
cards dropped. The actual dev work is happening against the newer kernel, not the kernel in Ubuntu 20.04… but that can’t really be helped. One wouldn’t want dev efforts focused on hacking drivers into an old kernel, if one wants their driver included in the kernel in the first place.
Ah, The Firmware. Sweet Sienna Cichlid!
Okay, so there is also The Firmware. This is the binary blob I alluded to earlier. It’s in the stuff you downloaded from AMD, but all these binary blobs are also tracked in the linux-firmware git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
The commit here we want is from 2 days ago, Sienna Cichlid.
What we want to do is clone this repo, and copy the amdgpu firmwares into /lib/firmware/amdgpu
where the AMDGPU kernel driver looks for & expects this version of the binary blob to be.
There is a copy of the same firmware in the download from AMD, but I like the idea of you, dear reader, being aware that this git repo exists.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/about/
Terminal Time:
# go to your home directory
cd ~
# make a directory for this
mkdir fw
# clone the repo
git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git fw
# see what's in there
ls fw
There’s a ton of stuff in there!
Binary Blobs exist to support a lot more than GPUs.
Copy all the files in amdgpu to /lib/firmware/amdgpu . You can do that however you like, or from the terminal this is how I did it:
rsync -avh fw/amdgpu/* /lib/firmware/amdgpu/
Reboot again.
Hopefully I didn’t break your system. If I did, sorry, post a comment I’ll try to make this more user friendly.
Did it work?
If it worked, skip my rambling for the next section. If it did not work, read on. We will get through this together, dear reader.
dmesg
is ahandy command for chekcing recent kernel messages, in this post-reboot world.
If your firmware is missing, or there is some problem, you will see errors like:
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.128968] [TTM] Initializing pool allocator
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.128969] [TTM] Initializing DMA pool allocator
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.128985] [drm] amdgpu: 16368M of VRAM memory ready
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.128986] [drm] amdgpu: 12005M of GTT memory ready.
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.128989] [drm] GART: num cpu pages 131072, num gpu pages 131072
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129129] [drm] PCIE GART of 512M enabled (table at 0x0000008000300000).
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129565] amdgpu 0000:0c:00.0: Direct firmware load for amdgpu/sienna_cichlid_sos.bin failed with error -2
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129566] amdgpu 0000:0c:00.0: amdgpu: failed to init sos firmware
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129608] [drm:psp_sw_init [amdgpu]] *ERROR* Failed to load psp firmware!
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129660] [drm:amdgpu_device_ip_init [amdgpu]] *ERROR* sw_init of IP block <psp> failed -2
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129661] amdgpu 0000:0c:00.0: amdgpu: amdgpu_device_ip_init failed
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129664] amdgpu 0000:0c:00.0: amdgpu: Fatal error during GPU init
Nov 21 13:06:20 w-X570-AORUS-MASTER kernel: [ 60.129682] amdgpu: probe of 0000:0c:00.0 failed with error -2
Nov 21 13:06:37 w-X570-AORUS-MASTER systemd[1560]: Started Application launched by gnome-shell.
If you ran dmesg before we sort of went “off script” wi th the ./amd-install script from the download from AMD, you may have seen that message.
By the way, strictly speaking, firmware blobs are managed by linux-firmware deb on Ubuntu. As of this writing canonical has not updated this deb.
Why? I think canonical could do us all a huge favor and make it so that the linux-firmware deb is completely automatically updated whenever the master branch pointer is moved on the linux-firmware git repo, upstream. That’s modern DevOps. I would be happy to do that for Canonical should they ask. Eventually the files you copied into the firmware folder will be overwritten and replaced by files that are managed by that linux-firmware.deb file. Eventually you’ll get an error about that – just warning you now .
This is an example of what I’m talking about when I say that AMD isn’t really fully responsible here. They do/did provide a firmware package! But Linux is more complicated than that because So Many People are involved and “Graphics/Gui” isn’t one group led by a charismatic and benevolent dictator the way The Kernel is. Because of stuff like this, AMD generally tries to put their stuff in /opt but not everything knows to look there automatically. Just my $0.02 I don’t see an easy solution short of a Linus Torvalds type conductor managing the GUI end of linux. all of it. Even the DE.
Reply and let me know something went wrong so I can fix it in the guide. It should work, though.
Vulkan
You may need to apt install vulkan-utils
because we want to run vulkaninfo
If you get a Vulkan error, that’s probably not good. If it works, then go ahead and install steam from the software center. Don’t sorry about the 32 bit error unless that’s the only error you have.
Don’t forget to enable Steam Play for All titles and not just Selected titles.
There are some downsides with this approach. For one, we’re still on Mesa 20.2 and LLVM 9. Ideally we want to be on Mesa 20.3 and LLVM11, but I will have to spend some more time thinking about the fastest and more reliable path on that. We have only gone to Where The Work Is Being Done as far as the Driver and Kernel are concerned; 3D acceleration implementation, and the work Valve is doing, is still ahead of where we are now.
Another aspect of this to be aware of is that there are multiple groups working on the same thing. AMDGPU fully open and AMDGPU Pro and the LLVM/MESA/Valve aspect is actually a pretty complicated set of relationships and goals.
At least, with this barebones setup, you should be able to play most games in Steam.