AMD Radeon RX 6800 and the RX 6800 XT are out today

Quoting: tuubiYou should simply remove the old xorg.conf file. You don't need one for AMD or Intel.

In case you want to fiddle with options (e.g. to enable TearFree), it's better to just create a new file in /etc/X11/xorg.conf.d/ containing nothing but the device section for the driver.

You don't need one with Nvidia, either, and the butchered thing that their automated tool produces is just awful.

The invention of xorg.conf.d and being able to use snippets rather than having to specify the whole thing was a great improvement.

Quoting: MohandevirFrom what I heard from another user, couldn't Debian testing be considered a rolling release? Might give it a shot, eventually.

For the most part it's rolling. During Debian freeze period that precedes the release it's not.

There are some options for updating key components during the freeze though.


Last edited by Shmerl on 18 November 2020 at 6:49 pm UTC

Gamers Nexus review: https://www.youtube.com/watch?v=jLVGL7aAYgY

Quoting: x_wing

Quoting: slaapliedjeWith AMD being kernel based and needing latest Mesa, hardly anyone really packages those unless you want to make your system less stable and are into the whole ppa things. or you start compiling things from source, which I'm not exactly keen on doing for just the graphics card to work. You almost need to be running a rolling release like Arch to be able to just pop the card in and have it go.

I told you this before: you can install AMDGPU dkms using AMDGPU-PRO package release. You don't need a rolling release, having the driver in the kernel has nothing to do with the "problem" you mention. And if your point is that having a dkms driver makes your system less stable... well, that's exactly what happens with Nvidia.

No, it's more about getting a current mesa build. DKMS is easy. Though from my understanding is it shouldn't be needed with the AMD as it's in the kernel instead of needing a separate thing (though for the non-kernel driver you mention, sure the dkms would work).

Edit: Also of note, Debian doesn't seem to package amdgpu as dkms. They even have OpenRazer dkms packages, but not any radeon / AMD ones (last Radeon one I can see is from Jessie and is the fglrx one, which is ancient).


Last edited by slaapliedje on 18 November 2020 at 8:41 pm UTC

Quoting: Shmerl

Quoting: MohandevirFrom what I heard from another user, couldn't Debian testing be considered a rolling release? Might give it a shot, eventually.

For the most part it's rolling. During Debian freeze period that precedes the release it's not.

There are some options for updating key components during the freeze though.

Yeah, I run Debian Sid. Only really becomes unstable when they do the temp freeze on testing and that short period after a new stable comes out (as a huge amount of packages get flooded in).

I would have loved to buy one Rx 6800 xt, money is ready, spammed all day long on my mobile at work, but in my country they were nowhere to be found. Only two resellers managed to put the cards online with no stock to be seen but with a huge premium, even on Amazon the products are a no show.

So, I'm happy the support is better than usual but what's the damn point if you can't buy the f**king thing... So pissed off right now, they ruined the party for me.

It should be illegal to promote and advertise product that are not fully available. Looking at the Ps 5, Xbox series X, rtx 3xxx and now Rx 6xxx...

Edit : how could I forgot the ryzen 59xx series... MIA too.


Last edited by TobyGornow on 18 November 2020 at 8:03 pm UTC

Quoting: slaapliedjeNo, it's more about getting a current mesa build. DKMS is easy. Though from my understanding is it shouldn't be needed with the AMD as it's in the kernel instead of needing a separate thing (though for the non-kernel driver you mention, sure the dkms would work).

I'm not sure what you mean here. Hopefully this will clarify your picture:

AMGPU: It's the AMD driver module that lives inside the kernel. You can update it by getting the latest stable/unstable kernel in your distro or by installing it as DKMS (the latter is what I mean by "installing it from AMDGPU-PRO").

Mesa: these are userspace libraries/drivers that implements graphics APIs (OpenGL, Vulkan, etc.). You can get a version by several ways:

• From your distro official repositories


• Third party repositories


• AMDGPU-PRO linux drivers package


• By compiling them by yourself (this step includes dealing with dependencies!)

So, getting the latest Mesa build is fairly trivial now days and the same can be said in order to get the latest kernel (at least in the majority of distros). IMO, any user that wants to setup his system for the latest Nvidia GPU will probably have to deal with both issues as well (with the difference that he may have to avoid some Linux kernel versions).


Last edited by x_wing on 18 November 2020 at 8:28 pm UTC

Quoting: x_wing

Quoting: slaapliedjeNo, it's more about getting a current mesa build. DKMS is easy. Though from my understanding is it shouldn't be needed with the AMD as it's in the kernel instead of needing a separate thing (though for the non-kernel driver you mention, sure the dkms would work).

I'm not sure what you mean here. Hopefully this will clarify your picture:

AMGPU: It's the AMD driver module that lives inside the kernel. You can update it by getting the latest stable/unstable kernel in your distro or by installing it as DKMS (the latter is what I mean by "installing it from AMDGPU-PRO").

Mesa: these are userspace libraries/drivers that implements graphics APIs (OpenGL, Vulkan, etc.). You can get a version by several ways:

• From your distro official repositories


• Third party repositories


• AMDGPU-PRO linux drivers package


• By compiling them by yourself (this step includes dealing with dependencies!)

So, getting the latest Mesa build is fairly trivial now days and the same can be said in order to get the latest kernel (at least in the majority of distros). IMO, any user that wants to setup his system for the latest Nvidia GPU will probably have to deal with both issues as well (with the difference that he may have to avoid some Linux kernel versions).

Yes, I know what all of that is. I've been using Linux for 20+ years at this point. I also vividly remember the hassle I had of trying to get the one AMD system I ever owned to work. Either the fglrx wouldn't compile with newer kernels, or the open source driver had shit performance. I was hoping this situation had improved, but it doesn't seem that way.

1) official repos don't have it (debian sid)
2) I try to avoid third party repositories because they tend to break shit
3) AMDGPU-PRO linux package is not available for any Debian system.
4) Compiling myself is what I try to avoid.

So yeah, there are pros and cons to how AMD does it and how nvidia does it. Most distributions seem to favor the nvidia method, otherwise they'd take the AMDGPU Pro drivers and put them in the repos.

Quoting: x_wingSo, getting the latest Mesa build is fairly trivial now days and the same can be said in order to get the latest kernel (at least in the majority of distros). IMO, any user that wants to setup his system for the latest Nvidia GPU will probably have to deal with both issues as well (with the difference that he may have to avoid some Linux kernel versions).

Not really. nVidia bundles the API libraries with the driver, so I don't think Mesa really plays big role at all. I remember that there used to be bit trouble with that as driver would overwrite Mesa libraries. I don't know if these days things are less hassle as distro packaging has gotten better or drivers integrate with the system bit nicer way.

Kernel stuff is pretty much true though. Good thing is that you don't need to update the kernel. Bad thing is that you can't update to latest kernel, you'll have to wait for the support. You'll have to even longer if your distro doesn't provide the latest driver.


Last edited by Anza on 18 November 2020 at 8:53 pm UTC

Quoting: slaapliedjeYes, I know what all of that is. I've been using Linux for 20+ years at this point. I also vividly remember the hassle I had of trying to get the one AMD system I ever owned to work. Either the fglrx wouldn't compile with newer kernels, or the open source driver had shit performance. I was hoping this situation had improved, but it doesn't seem that way.

1) official repos don't have it (debian sid)
2) I try to avoid third party repositories because they tend to break shit
3) AMDGPU-PRO linux package is not available for any Debian system.
4) Compiling myself is what I try to avoid.

So yeah, there are pros and cons to how AMD does it and how nvidia does it. Most distributions seem to favor the nvidia method, otherwise they'd take the AMDGPU Pro drivers and put them in the repos.

Most distros doesn't favor Nvidia method, they just add their drivers because is the only way to make that hardware work (the "easiness" of Nvidia drivers is 100% thanks to the work the community does). And if you buy the latest Nvidia hardware, you are forced to use a third party repository, just like with AMD if you get their latest GPU. In the end, both delivers the same but AMD gives more options and more freedom.


Last edited by x_wing on 18 November 2020 at 9:05 pm UTC

Quoting: AnzaNot really. nVidia bundles the API libraries with the driver, so I don't think Mesa really plays big role at all. I remember that there used to be bit trouble with that as driver would overwrite Mesa libraries. I don't know if these days things are less hassle as distro packaging has gotten better or drivers integrate with the system bit nicer way.

AMDGPU-PRO does the same as well (you get proprietary and open source stack). The difference is related on how rigid are the correlations between kernel modules versions and libraries are. My point is that there isn't much difference in the driver installation for the latest hardware between one and another.


Last edited by x_wing on 18 November 2020 at 9:11 pm UTC

Here on Fedora 33, Mesa, LLVM and the kernel are up-to-date, and I just noticed the updated firmware package is built and in testing, so we can consider it to be compatible from day one.

Well done AMD!
Now I'm just dreaming of a Ryzen 5800X + Radeon RX 6800 rig, but I need to save some money first...

Looking good on the performance side. Hoping for good availability now, 500 Euros is my threshold this time.

Edit: Also very happy about the driver situation this time.


Last edited by iskaputt on 18 November 2020 at 10:21 pm UTC

Have a 6800XT on pre-order (was only option). Who knows if it will be for-filled... They took my money non the less.

I would also like to point out that the reported clock rates are not correct when people saying they can overclock to the moon.

This same issue happened a fair while back with older AMD cards where they would say whatever high clock but perform the same or worse then stock.


Last edited by TheRiddick on 19 November 2020 at 2:53 am UTC

Quoting: MohandevirFrom what I heard from another user, couldn't Debian testing be considered a rolling release? Might give it a shot, eventually.

Stayed on Debian a few years, I think testing is just the next version (currently "bulls-eyes" future 11.0) than stable.
I considered unstable (sid) to be the true Debian rolling but I've never been so happy moving to manjaro, rolling release + easiest experience I've ever had!

Debian testing is close to Debian unstable, with only difference that packages go through some consistency process first (so unstable can be broken more often). So both are semi-rolling.


Last edited by Shmerl on 19 November 2020 at 2:57 am UTC

Quoting: ShmerlDebian testing is close to Debian unstable, with only difference that packages go through some consistency process first (so unstable can be broken more often). So both are semi-rolling.

Yeah, from my understanding it goes like this.

Package enters Unstable, stays for 10 days, if no bug reports are created, and dependencies all work, it is moved to testing. Once it enters Freeze, new versions of packages don't get pushed down to Testing and only bug fixes get applied until the release team is happy that there aren't release critical bugs, then a release happens and Testing becomes the next release and a new Testing branch is created and Unstable gets a bunch of broken stuff. It has varied a bit over the many years, but that is usually the only time dependencies become funky in Unstable.

Quoting: x_wing

Quoting: slaapliedjeYes, I know what all of that is. I've been using Linux for 20+ years at this point. I also vividly remember the hassle I had of trying to get the one AMD system I ever owned to work. Either the fglrx wouldn't compile with newer kernels, or the open source driver had shit performance. I was hoping this situation had improved, but it doesn't seem that way.

1) official repos don't have it (debian sid)
2) I try to avoid third party repositories because they tend to break shit
3) AMDGPU-PRO linux package is not available for any Debian system.
4) Compiling myself is what I try to avoid.

So yeah, there are pros and cons to how AMD does it and how nvidia does it. Most distributions seem to favor the nvidia method, otherwise they'd take the AMDGPU Pro drivers and put them in the repos.

Most distros doesn't favor Nvidia method, they just add their drivers because is the only way to make that hardware work (the "easiness" of Nvidia drivers is 100% thanks to the work the community does). And if you buy the latest Nvidia hardware, you are forced to use a third party repository, just like with AMD if you get their latest GPU. In the end, both delivers the same but AMD gives more options and more freedom.

You don't have to use a third party repo with Debian. Literally just have non-free repo enabled. Sure if you run Fedora/rhel/cent you enable rpmfusion and you can get the packages. Most *buntu distros have nvidia packaged for them as well.
It has been years since I bothered downloading the nvidia driver from them or any other repo.
And as stated by others, nvidia has their own OpenGL/Vulkan drivers so I haven't needed to mess with mesa for a long time. Nvidia also supports their older cards for much longer than AMD/ATI has in general.
So I really WANT to support AMD as I believe that the hardware should all have open source drivers. I just want it to be easier to do so without compromising convenience and stability by adding third party repos or compiling custom libraries.

Quoting: slaapliedjeNvidia also supports their older cards for much longer than AMD/ATI has in general.

I think you'll find that the oldest AMD GPU drivers still included in upstream Mesa are for the R100-series from year 2000, whereas Nvidia current "legacy" driver series includes support for HW based on the Fermi architecture (2009) and later. But maybe you're comparing proprietary drivers only?

Nvidia's drivers used to be objectively better on Linux, but I don't think that's the case any more. My last Nvidia GPU was a GTX 960 and I was happy with it, but I've been even happier with the two AMD GPUs I've owned since.


These discussions tend to end up full of partisan hyperbole (often mostly based on hearsay), but in the end, both vendors are easy to live with these days for someone who just wants to play some games. No game requires the latest kernel or Wayland—so Nvidia's reluctance to play ball is almost irrelevant—but new kernels and Mesa packages are readily available on any mainstream distro for those who need them so us AMD/Mesa users are fine too.

That said, in my opinion and experience AMD currently has an edge on Linux even if you ignore the ethical and technical implications of Open Source vs proprietary. Personally I don't like to ignore these implications, so that's another reason I'm happier on AMD.

Quoting: ShmerlOh, and by the way. Debian testing has kernel 5.9, Mesa 20.2.2 and llvm 11. So you basically don't need to compile anything if I understand correctly :) That's better for day 1 than RDNA 1 (Navi 1) release.

Unless you just want to benefit from even newer support in upstream versions, then it's compiling time anyway :)

Just don't forget to check if firmware is there. I had to install it manually on Debian Unstable this year for RX 5700XT because firmware package in the repo was about 1 year old there.