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

Hello,

New to linux, have a new build and trying to install AMD drivers for a 6600 XT on POP OS 20.04 ( 21.04 install would hang )

Trying to follow Wendell’s tutorial but I get “Unsupported DEB-based OS: /etc/os-release ID ‘pop’” when I put ./amdgpu-install in the terminal

Any tips on how to get to the next step would be a big help

If your reading this , have a great weekend

did you use the AMD vidcard version to install?

if so:
card may not be yet supported in linux drivers…

Thanks for reply , yes I used the AMD driver on their site

you only need the firmware out of that, otherwise amdgpu open source will work fine :slight_smile:

Thank you for the reply Mr. Wendell, really enjoy your vids

…UPDATE… Pop os would not work no matter what , tried Ubuntu and BINGO !

Thanks again Wendell

Hey Wendell, great video. I had a little bit to add to make it easier for people to get going.

I would caution people using UUKU and the likes.

1.) Having people add random PPAs to their system usually leads to broken systems when they do not know what they are doing.

2.) UUKU and those external kernel adders and parameter adders eventually go rogue and people have issues removing the old stuff and adding the new stuff (if they don’t know what they are doing).

With that said, you can go on github and download the kernel as a zip file and just extract the files that you need.

Overall, the video is not bad and I do agree that it is an easier solution as long as the person understands what they are doing. I have helped fix too many issues from easy solutions that people blindly install. They don’t know what they did so they cannot explain to me what went wrong and where they got the information(s) from.

Hello again,

Sorry for the newb question

Trying to get a 6600 XT working on ubuntu 21.04 now ( had 20.04 working )
Following Wendell’s newest video , I get stuck at the part where I copy git files to my system; says permission denied.

Why would permission be denied ? Did I miss something ?

Thanks

Because that directory is only writable by root, so you’d have to sudo cp ….

That being said, you should never be writing to root-only directories manually unless you know exactly what you’re doing. And sorry if that sounds like being an ass, but if the permissions already trip you up I’m not sure that’s the case.

1 Like

:slight_smile: Thanks for the info , don’t mind learning the hard way

Going to try that

Have a good one

Also, it looks like you’re trying to copy the contents of your home directory to /lib/firmware/amdgpu which is probably not what you had in mind.

2 Likes

And this is exactly why I never include sudo in anything that I post on the web. It keeps the honest people honest and forced them to learn what it is that they are actually trying to do. So many stack exchange searches end in carnage.

1 Like

Not really a random PPA. It is a code base I have personally worked on.

It just grabs debs from Ubuntu and runs them. I’ve had no issues installing in the something like 3 or 4 years I have used it.

PPAs are the Ubuntu way.

Downloading Kernels from Github is the opposite of user friendly and will most definitely create issues for people manually copying files around. At least with the deb you can undo the process.

1 Like

Fair, I am a Debian shill and would rather do things the Debian way.

In general, I was speaking to the non-technical savvy people that install random PPAs because someone on the internet told them to do it; they don’t know what they are doing and they tend to get themselves into trouble that way.

PPAs and alternative repositories tend to make these people dependent on others and and as a result, they may run into a dead end when the repo is no longer supported. I remember when Oibaf would take for ever to get something updated and people would screech about this volunteer not working fast enough. Or their would switch to a different repo because they have the new hotness and then broke their install.

All that to say that, I appreciate those out there that make things more accessible to those that do not currently have the skill set, just be sure to educate the people on what is happening so that they may be able to do this on their own one day. One bad experience usually turns people of of the alternative OS route and they will talk about those bad experiences to other people.

Yeah I agree with that. You can have outdated tutorials explaining how to install a piece of software with old PPAs.

Different distro’s definitely have different ways of doing things.

In this case at least for now these PPAs are the best. By at least the time of the next Ubuntu release this will probably be a non-issue.

1 Like

Hey guys. Thanks for the guide, Wendell. I still have a dangling problem that I wanted to bring up, in case anyone knows what to do

TL;DR: AMDGPU is installed and mostly works, but Vulkan games are not launching and giving an LLVM error


I’m upgrading (well, more like previous died on me) from an ~8 year old NVIDIA GTX 760 and got an RX 6700 XT. Using Debian Sid. Upgraded kernel to 5.13 from the Debian Experimental branch (I know I could’ve gotten 5.14 from the ubuntu kernel site, but I didn’t want to go too far into a frankendebian, and figured 5.13 was enough since the minimum for my card is 5.11) . AMD firmware is installed. Installed the ubuntu amdgpu driver from AMD.com, used the --no-dkms flag to circumvent the problem with the install erroring out. No other parameters were used apart from that one

This is the output of vulkaninfo:
vulkaninfo.txt (42.3 KB)
(Bonus question: should I be concerned at all about the radv warning at the top of this ^?)

And now for the error I’m talking about. When attempting to launch a game with the Vulkan renderer (I’ve tried multiple), I get the following:

: CommandLine Error: Option 'help-list' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

I’ve googled around but I haven’t really found a solution to this. I’m out of my depth around this area, I’m regrettably a bit confused about how radv/LLVM/OpenCL etc all work or what they do, so I figured I’d be a good time to ask for help. One thing that might be worth mentioning (I don’t know if this is the culprit, but given that it’s complaining about ‘help-list’ being registered more than once, it seemed suspicious) is that aptitude reports multiple LLVM packages installed side by side.

i A libllvm11
i A libllvm12
i A libllvm12:i386
i A libllvm12.0-amdgpu
i A libllvm12.0-amdgpu:i386

The first three are from the Sid repos, and packages on my system depend on these. The last two are obviously from the amdgpu driver install, and it depends on them. Is it fine for them to exist side-by-side like this or could this be the culprit for my error?

Let me know if there’s any other info I could provide!

EDIT: vkcube works by the way, for whatever that’s worth.

No this is “normal” even on a functioning system. It’s because RADV is strictly speaking not spec compliant as it says, but it is still feature complete as far as I know, just seems to do some things different then defined. I’m not super sure what the differences are though. Fact is though you don’t need to worry about it.

Multiple packages is normal, but having different versions (i.e. 11 and 12) is probably the issue.
I would check if anything is relying on LLVM 11 anymore, and if not, just get rid of it. Apt should tell you what depends on it when you try to uninstall it.

Is there a particular need for the official driver from AMD’s site, you should be good to go with amdgpu driver from the kernel.

If you are trying to run a hybrid stack for official OpenCL/ROCm with the opensource amdgpu kernel driver, there is a little more plumbing that you need to do.

Could you elaborate on what your use case is. Also, having both LLVM version could be causing an issue as well as not having the most recent MESA installed.

@Mastic_Warrior @mihawk90 Hey guys. First of all, I have to say - shamefully, I did not even realize that I could simply use the driver from the kernel and need nothing else (save for the firmware). Since I come from NVIDIA-land (well, NVIDIA-land-from-8-years-ago at least), I figured I absolutely needed something else. I ran the uninstall script for the AMD website stuff, made sure xserver-xorg-video-amdgpu from the Sid repos was installed, and everything works fine now. The LLVM error that was showing up with vulkan games is gone. Thank you!

As for the LLVM 11/12 versions question, yeah I do have programs that depend on both, which is why I was hesitant to remove them. But all that doesn’t matter now thankfully. My conclusion is that the amdgpu LLVM12 package was conflicting with my repo LLVM12 package.

My use case is nothing fancy at all, just a desktop that can play games natively and on Wine/Proton. Out of curiosity, what use case would someone have for using the AMD website open-source driver now instead of this method (kernel handles it all)? And also, which mesa version should I be running right now? I seem to be on Mesa 21.2.1 right now, as per the Sid repos.

Now the only thing that I need to set up is hardware encoding for OBS. Though I fear that might be outside of the scope of the thread, and I haven’t even given it a shot yet. Heard AMD’s hardware encoding on OBS was a bit finicky, but we’ll see.

1 Like

No idea to be honest. The amdgpu-pro installer makes sense because some applications really want the pro (and OpenCL is also weird on the Open Source variant), but for the open one I haven’t really understood that.
I think it might be for distros that don’t ship the driver for some reason? But then again, AMD only has packages for Debian and RHEL I think? So yeah…

You need an ffmpeg build with VAAPI enabled, not sure if Debian has it in their repo. On Fedora it seems to work fine with the right ffmpeg build.

usually just the latest you can get your hands on. But that being said, a version too new might depend on driver stuff that isn’t in your repos yet, so I would go the safe route and just use whatever is in the repos.
Also note that as of Mesa 20.2 the ACO shader compiler is now the default and LLVM is just a secondary option for compatibility purposes.