Return to

Ubuntu 20.10 + RX 6800 XT - How To Steam / Vulkan Up And Runing Guide [WIP]

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


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, 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 and download the Ubuntu drivers for your GPU. Mine were:


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

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: ...
Removing old amdgpu- DKMS files...

Deleting module version:
completely from the DKMS tree.
Loading new amdgpu- 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
Consult /var/lib/dkms/amdgpu/ for more infor
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:; however:
  Package amdgpu-dkms is not configured yet.

dpkg: error processing package amdgpu (--configure):
 dependency problems - leaving unconfigured
Setting up vulkan-utils ( ...
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:
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. :slight_smile:

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:

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.

These are the ones I used for this guide, YMMV, but newer is probably better so actually check!

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:

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.

Terminal Time:

# go to your home directory
cd ~ 

# make a directory for this
mkdir fw

# clone the repo
git clone   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 :slight_smile: 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.


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.


amazing work like always!

Admittedly I’ve not read everything but the intro right now and I’m wondering… LLVM? Doesn’t Mesa use ACO now by default instead of LLVM? Or am I mixing something up there?

yeah, but someone might want to play rise of the tomb raider or something :smiley: I really need someone to make a picture diagram of the love quadrilateral of vulakn/amdgpu/amdgpupro/mesa/llvm/radv


Rise is Vulkan though right? Shouldn’t that also use ACO as Mesa uses it?
visible confusion intensifies

now I’m getting mixed up. I think shadow is vulkan and rise is not? or am I mixing those up. Only the newer one is vulkan. Maybe I should have said someone might want to play bioshock infinite instead haha.

Hm, just going by the PC Gaming WIki here, who knows how accurate it is, but it says Rise uses Vulkan for the Linux version:

The first game in the Trilogy is OpenGL though which I had to learn quite painfully :expressionless:

But anyway, OpenGL is still using LLVM then? Good to know…

Maybe add a section on Kisak Mesa once Mesa Stable can use the 6800 XT?

Also, maybe a section on Xanmod? It’s PPA has an up to date linux-firmware that is really well maintained and pretty recent. That PPA might already have the 6800 XT firmware if they were on top of it.

Hi Wendell,

Thanks a lot for the guide.
I managed to score a RX6800 so I went through all the steps but I can’t get X to start in any way.
I tried with kernel 5.10rc5 at first but when it didn’t work, I cleaned up everything and tried again with 5.10rc4. whatever the version I use, nothing works :frowning: I can’t get X11 to start.

Just a quick note, there is an error in the kernel file names, headers are twice in the list and the linux-image file is missing.

I checked my dmesg, there are no references to amdgpu at all, are you sure you are supposed to remove amdgpu-dkms after the firmware files are copied?

I’m running Ubuntu 20.10 (upgraded from 20.04).

Thank you

try lsmod and see if amdgpu is listed? if not try modprobe amdgpu

The module doesn’t seem to load automatically at boot time, it loads manually but then GDM shows a white screen with “Oh no! Something has gone wrong.”

FYI when I do the “modprobe amdgpu” the console switches to graphic mode so that part seems to work.

I found that the installation process seems to add a blacklist file for amdgpu to my /etc/modprobe.d
I removed it but I now boot to the GDM white screen mentioned above

does the output from dmesg say anything about missing firmware?

No missing firmware but I found the issue, it seems that GDM3 has been broken by the update to 20.10…

but, the true culprit is that somehow during the installation process, 2 files get created in /etc/modprobe.d/blacklist-radeon.conf and /etc/modprobe.d/blacklist-amdgpu.conf

I don’t know if that happened because I used the uninstall script though…

Thanks a lot for taking the time to look into it Wendell

all good now? I suspect this is a weird edge case triggered by the 20.04> 20.10 upgrade, but I updated the guide just in case :slight_smile:

1 Like

Brilliant, thank you!

If you feel like updating the instructions, the name of the kernel packages are incorrect, the headers appear twice but not the kernel image.

Thanks again

1 Like

Gave this a crack, but mine just blinks a black screen at me. Guessing it might be because I’m on Kernel5.9 and not 5.10… I’ll just wait for proper release of 5.10 and continue using windows in the meanwhile.

Try lsmod and modprobe amdgpu in case that is your issue as well. There’s something weird with the blacklisting

I looked around all my blacklists and didn’t see amdgpu in any of them. I’ll take another look.

I can boot up into TTY with kernel 5.8 but for some reason 5.9 (using xanmod) it just blacks everything out and cycles my monitor on/off endlessly. The GPU fans do turn off so it appears the firmware may be engaged.

The only suspicious thing that occurred is that it did complain about some possible missing firmware files, however the files it suggests don’t even exist in the git repo so I just ignored those messages.

Ok I somehow managed to get it working. I followed some tips from the thread below.

Basically what I did was extract the firmware files from the amdgpu-pro driver instead of just downloading them from github, used those. AND I installed Kernel 5.10, its possible xanmod kernel 5.9 does not work with RDNA2 cards yet.

amdgpu module is loaded in 5.10 but it didn’t load in 5.8 or possibly 5.9. I remember when I installed POP OS I chose NVIDIA option which probably did all sorts of things to disable amdgpu. Anyway gotta run now, everything appears to work. Will do testing later.

1 Like