GeForce RTX 3060 Ti arrives December 2, hits RTX 2080 SUPER level performance

Quoting: x_wing

Quoting: CybolicBased purely on anecdotal observation, I suspect it's because there's been many HOWTO guides for NVIDIA drivers written by "mainstream" news sites and its often mentioned in Youtube videos, whereas I have yet to see anyone mention how to set things up with AMD.

It's probable, but that doesn't justify the common idea that Nvidia gives better support for driver installation. IMO, there is a big bias going on regarding AMD drivers.

It's true I really wasn't clear, sorry for that.
Yes, my statement is really on the end user usability, what Nvidia themselves provides also suck. I said in message before, but for me Nvidia is not a wonderland either, and company wise I'm not a very huge fan. For AMD, I am not more of a fan, as I don't consider them open (they just code drop ...), although they at least give doc. They also lock firmwares who have full dma access, so advanages are not a lot ... The rest is really observation from end user usability. I have view on centos/Fedora and ubuntu where overall Nvidia gave less problems (did not say "no problem") on my experience, either personal or when supporting colleagues. It might be thanks to distro, but I don't really care, I just care for end result.

There is always the wayland arguments, but having no special use for wayland, that does not really concern me. I mean, I did make it work too, just did not have much point. I run wayland mostly for xrun setup with Nvidia, so that Intel card does not clash with Nvidia's xorg + openbox env. It does require multi cable, so it is not ideal either ... Once again, never said is perfect. But it does work, and setup is easy to find / use.
For AMD, can't say the same. I had issues on issues, work & home. And from what I read here and there, can't say I'm alone.

And it is easier to get latest Nvidia than AMD on my distros. It's most likely not thx to Nvidia, but it's what happens. As for failures after new kernel, well, since it's tested by distro maintainers I guess (is their own packages), that's why it never breaks for me.

As for dkms on debian, it is indeed a special case of where it should tend to work, since you have a fully stabilized kernel, albeit I doubt you'd run anything where you need latest driver (there's no official support for autodesk/tensorflow and co there, and using a distro with very old packages is sub obtimal for gaming). I did use on centos before for a ML guy, was a case where it did not break also, stable kernel and all that. On Ubuntu, using website dkms was painful, very painful (with hw enablement stack).

Once again, I agree, neither are actually a walk in the parc in all occasions. AMD requires to go and pull git stuff, Nvidia you have to go back to old gcc for their nvcc stuff, but you have scl to help you. Which is really the point on usability, whether Nvidia does smthg themselves or not, since they are the main vendor, people adapt ... And there are a lot of stuff to workaround their stuff, often out of the box or easily ... That's just the way it is.

On pure Gaming, as long as you don't want the very latest proton, it should be fine. But my fear is you still get hangs, APUs that do not even let you boot ... all this kind of fun stuff. Stuff, that basically never happened to me with Nvidia. Worst you have there is nvcc yelling on you to give him an older compiler, which since you can still boot in normal env is not so hard. Overall, this has been the issues I faced and my work experience, and not just on my machines. I also agree my use is not casual, and I might push into more issues than standard gamer obviously, but the APU not booting as an example ...

Maybe things are changing, but for now, I still would not recommend to someone who ask me to go AMD for GPUs on Linux. Once AMD start to work upstream correctly, enabling hw support much earlier in the flow, and stop doing code drops maybe things will change. Until then, I put them in same category as Nvidia, and only judge on factual present usability.
I would also precise, if using older AMD card, then it is probably a different story, after one year it's true my wife's issues reduced dramatically. But, that's a long time to stabilize stuff. And I have no doubt it's not just their fault once again, but results are what matters - albeit, once again they should enable hw much earlier...

I'm really betting on Intel more than them. Most likely, even if Intel card are not quite as powerful / a bit costlier, and unless they really crap out, this is what I will hopefully soon recommend. I think they have the weight to use OneAPI with fpga and co too to shake up CUDA monopoly too, which would be a blessing. And since they enable hw support long before, you're in for a much smoother ride. Once again, full featured consumer hw, stability, and very upstream flow is the right way to go, and it deserves my money. Is the same reason I still buy Intel CPU, even tho AMD ones are objectively getting better, Intel is a large contributor.


Last edited by 3zekiel on 4 December 2020 at 5:00 pm UTC

Quoting: slaapliedjeNow maybe if Intel does something amazing with their dedicated GPUs, and makes the drivers compatible, then there'll be a better experience. But even then you'd still be tied to newer Mesa drivers, which is usually the sore point to the AMD ones.

For the latest Mesa part, this is also an issue of AMD working in "code drops" mode. Which is the typical Silicon's company vision of open source. Every now and then, you drop code. Result is, most often you end up with not well tested code in releases that themselves often come late.
Since Intel works upstream and enable hw much earlier, and usually long before hw availability, you end up with smthg much more robust. Well, not to say you will never have to go to next major version, but it should be much much less frequent, and git should be an absolute rarity thx to that. Next major version is a lesser evil at least, and you can often find semi official ways to get it. It's also included in HWE for ubuntu, and base for Fedora. For centos, well, that will still be a pain for sure. But at least, launch drivers support should be better if you fall on the right release time (that's centos for you ;p ).

Quoting: slaapliedjeReally? Swapping kernels out for something you compiled yourself or fetched from some third party seems great to you??

There really isn't such a thing as 'latest' stable kernel, when you're running a stable distribution such as RH/CentOS, Debian Stable, Ubuntu LTS, etc. Sometimes you just don't want to be running unsupported configurations, which running the 'latest stable' kernel wouldn't be.

I never said to compile or use a third party. In your distro (Debian), I'm sure that you can download the latest kernel from unstable or experimental repos, just like you do in order to install the latest Nvidia drivers.

And when I mention "stable", I'm not talking about of what your distro considers stable. Also, in the moment you install the latest Nvidia driver you will also be running an "unsupported" configuration. Getting the latest version of a software implies getting into something not well tested in the distro and this "issue" applies for AMD and Nvidia.

Quoting: slaapliedjeYeah, they're just different, and as you said, sometimes it's just a matter of which distribution you use, on which is supported better. Unless you end up with some sort of AMD Linux distribution where they keep it up to date for future cards and prepares them for their users, then there is no 'perfect' solution at this point. Now maybe if Intel does something amazing with their dedicated GPUs, and makes the drivers compatible, then there'll be a better experience. But even then you'd still be tied to newer Mesa drivers, which is usually the sore point to the AMD ones.

Why do you imply that AMD must keep up to date their drivers in a distro? You ask for something that not even Nvidia does. If you want to be fair with the proprietary driver status, then you should ask your distro why the don't provide those packages in the repo. And regarding Mesa, the requirement to get the latest version are the same as for Nvidia.

Quoting: 3zekiel

Quoting: slaapliedjeNow maybe if Intel does something amazing with their dedicated GPUs, and makes the drivers compatible, then there'll be a better experience. But even then you'd still be tied to newer Mesa drivers, which is usually the sore point to the AMD ones.

For the latest Mesa part, this is also an issue of AMD working in "code drops" mode. Which is the typical Silicon's company vision of open source. Every now and then, you drop code. Result is, most often you end up with not well tested code in releases that themselves often come late.
Since Intel works upstream and enable hw much earlier, and usually long before hw availability, you end up with smthg much more robust. Well, not to say you will never have to go to next major version, but it should be much much less frequent, and git should be an absolute rarity thx to that. Next major version is a lesser evil at least, and you can often find semi official ways to get it. It's also included in HWE for ubuntu, and base for Fedora. For centos, well, that will still be a pain for sure. But at least, launch drivers support should be better if you fall on the right release time (that's centos for you ;p ).

Yeah, I think what it really comes down to is there isn't a stable driver model for graphics cards in general. Not even Linux specific, as graphics drivers are for sure the one thing across platforms (except the Mac, which meh) which are constantly having updates. Whether they are new features being added, new support for the next graphics cards, or even just fixing performance in games / applications.

This really is the cause of most of the problems with Linux, as the update mechanisms for drivers aren't really a 'thing' when they are all in the kernel. This is why dkms was created, so it could dynamically rebuild new drivers when kernel updates happened. It shouldn't be the other way where you need a whole new kernel version just to support the new hardware. Should be able to dynamically build a kernel module for your existing kernel. Needing extra libraries to be pulled from git, or compiling your own kernel off of kernel.org is so... 1999.

The random code drops by AMD completely explains why we're in this situation. But for now, the AMD vs nvidia decision may end up being simply accessibility to the cards. Seems both are sold out everywhere, but for AMD it's because they're selling so many chips to Sony and Microsoft for consoles, where nvidia is selling theirs to crypto-miners. So kind of a moot point!

Quoting: x_wingI never said to compile or use a third party. In your distro (Debian), I'm sure that you can download the latest kernel from unstable or experimental repos, just like you do in order to install the latest Nvidia drivers.

And when I mention "stable", I'm not talking about of what your distro considers stable. Also, in the moment you install the latest Nvidia driver you will also be running an "unsupported" configuration. Getting the latest version of a software implies getting into something not well tested in the distro and this "issue" applies for AMD and Nvidia.

How is it unsupported if I install nvidia drivers from the debian repo? Unlike Ubuntu and their Universe / Multi-verse repositories, Debian supports ALL of theirs... one of the reasons Debian is superior.

Quoting: slaapliedjeYeah, they're just different, and as you said, sometimes it's just a matter of which distribution you use, on which is supported better. Unless you end up with some sort of AMD Linux distribution where they keep it up to date for future cards and prepares them for their users, then there is no 'perfect' solution at this point. Now maybe if Intel does something amazing with their dedicated GPUs, and makes the drivers compatible, then there'll be a better experience. But even then you'd still be tied to newer Mesa drivers, which is usually the sore point to the AMD ones.

Quoting: x_wingWhy do you imply that AMD must keep up to date their drivers in a distro? You ask for something that not even Nvidia does. If you want to be fair with the proprietary driver status, then you should ask your distro why the don't provide those packages in the repo. And regarding Mesa, the requirement to get the latest version are the same as for Nvidia.

I'm not, what I'm implying is that distros don't support AMDGPU Pro drivers within their distribution. Whether that is because they're too hard or because AMD doesn't let them, I haven't looked into. But nvidia clearly does allow distributions to put their drivers in repositories. Simple as that. Have you seen any distribution contain repositories with the proprietary AMD driver? If so, I'd like to know about them, as I haven't seen any. I mean let's hold both companies to the same standard, do they both allow repackaging of their drivers? Or are we stuck with the three distros they support (RHEL, CentOS, Ubuntu)? Even the open source drivers require firmware blobs, so the ones who are happy about that can't be 100% happy.

This just brings up the problem I stated in my last post, neither solution is 100% great. Nvidia just happens to have better distribution support as of right now. Unless you're using a rolling release (as you said, latest kernel) then you're shit out of luck for AMD.

Quoting: 3zekielYes, my statement is really on the end user usability, what Nvidia themselves provides also suck. I said in message before, but for me Nvidia is not a wonderland either, and company wise I'm not a very huge fan. For AMD, I am not more of a fan, as I don't consider them open (they just code drop ...), although they at least give doc. They also lock firmwares who have full dma access, so advanages are not a lot ... The rest is really observation from end user usability. I have view on centos/Fedora and ubuntu where overall Nvidia gave less problems (did not say "no problem") on my experience, either personal or when supporting colleagues. It might be thanks to distro, but I don't really care, I just care for end result.

I can understand an statement that reads "In my distro XXX, Nvidia have drivers that are easier to update/install" (which is probably debatable, but whatever). My problem is that most of the time the statement just reads like "Nvidia have drivers that are easier to update/install", giving credit to Nvidia for something that don't deserve and blaming AMD for something they are not responsible of. My point here is that AMD provides the exact same driver support as Nvidia does (with the advantage of having a driver inside the Linux kernel, of course).

Quoting: 3zekielThere is always the wayland arguments, but having no special use for wayland, that does not really concern me. I mean, I did make it work too, just did not have much point. I run wayland mostly for xrun setup with Nvidia, so that Intel card does not clash with Nvidia's xorg + openbox env. It does require multi cable, so it is not ideal either ... Once again, never said is perfect. But it does work, and setup is easy to find / use.
For AMD, can't say the same. I had issues on issues, work & home. And from what I read here and there, can't say I'm alone.

IMO, Wayland argument is the same as CUDA argument. These are feature that each user will give more or less value. BTW, your solution is completely if and only if you have a second GPU in your system. Unfortunately, not all CPUs includes a GPU so it's far from being perfect in the end (and, from a end user pov, definitely is not a easy as having one GPU for everything).

Quoting: 3zekielAnd it is easier to get latest Nvidia than AMD on my distros. It's most likely not thx to Nvidia, but it's what happens. As for failures after new kernel, well, since it's tested by distro maintainers I guess (is their own packages), that's why it never breaks for me.

As for dkms on debian, it is indeed a special case of where it should tend to work, since you have a fully stabilized kernel, albeit I doubt you'd run anything where you need latest driver (there's no official support for autodesk/tensorflow and co there, and using a distro with very old packages is sub obtimal for gaming). I did use on centos before for a ML guy, was a case where it did not break also, stable kernel and all that. On Ubuntu, using website dkms was painful, very painful (with hw enablement stack).

Once again, I agree, neither are actually a walk in the parc in all occasions. AMD requires to go and pull git stuff, Nvidia you have to go back to old gcc for their nvcc stuff, but you have scl to help you. Which is really the point on usability, whether Nvidia does smthg themselves or not, since they are the main vendor, people adapt ... And there are a lot of stuff to workaround their stuff, often out of the box or easily ... That's just the way it is.

As I said, both provides similar solutions. How easy is to get one or another in your system depends of your distro and your experience.

Quoting: 3zekielOn pure Gaming, as long as you don't want the very latest proton, it should be fine. But my fear is you still get hangs, APUs that do not even let you boot ... all this kind of fun stuff. Stuff, that basically never happened to me with Nvidia. Worst you have there is nvcc yelling on you to give him an older compiler, which since you can still boot in normal env is not so hard. Overall, this has been the issues I faced and my work experience, and not just on my machines. I also agree my use is not casual, and I might push into more issues than standard gamer obviously, but the APU not booting as an example ...

TBF, Nvidia can also have similar problems: https://www.reddit.com/r/linux_gaming/comments/k4r48t/have_you_been_experiencing_unrecoverable_hard/

I never used an APU though, so I cannot give any opinion about them.

Quoting: slaapliedjeYeah, I think what it really comes down to is there isn't a stable driver model for graphics cards in general. Not even Linux specific, as graphics drivers are for sure the one thing across platforms (except the Mac, which meh) which are constantly having updates. Whether they are new features being added, new support for the next graphics cards, or even just fixing performance in games / applications.

This really is the cause of most of the problems with Linux, as the update mechanisms for drivers aren't really a 'thing' when they are all in the kernel. This is why dkms was created, so it could dynamically rebuild new drivers when kernel updates happened. It shouldn't be the other way where you need a whole new kernel version just to support the new hardware. Should be able to dynamically build a kernel module for your existing kernel. Needing extra libraries to be pulled from git, or compiling your own kernel off of kernel.org is so... 1999.

The random code drops by AMD completely explains why we're in this situation. But for now, the AMD vs nvidia decision may end up being simply accessibility to the cards. Seems both are sold out everywhere, but for AMD it's because they're selling so many chips to Sony and Microsoft for consoles, where nvidia is selling theirs to crypto-miners. So kind of a moot point!

Ah yes, driver update issue is a bit of a mess. That being said, kernel code has no real reason to change dramatically once stabilized for this kind of devices. It really is just a bridge to talk with dma stuff and firmware, you might have some bugs to solve at first, but then... Also, for bug/security, point releases should be enough. DKMS/akmods may still help if needed.
I expect issues will mostly happen at mesa level, which is still an open issue. And for this well, I guess no silver bullets, having a separate vulkan package should be much much easier than opengl, so it might be the solution with time, just a separate lib to update. But for opengl, no idea... Since it has so many deps, and is depended upon by so many things.
I think many distro need to change a bit how they work too. I have to deal with Centos for proprietary stuff in particular, and it is a freaking pain in the ass. At some point, compiler is so old (on centos 7) that you can't get anything modern to work (even autoconf and co are too old, I'm not sure how the hell this can happen). Supporting OSes for 10 years encourage very bad behaviour for devs. At least, there should be *some* level of updates (jumping from lts kernel to lts kernel after few point release each times would be a good middle point as an example).
It also causes security issues, since using some sw such as gnome/firefox in old version, even pseudo extended support releases can go bad easily (less coverage because not many users, so researchers do not test, so basically only hackers test ...).

But well, some level of issues will remain with current model. Vulkan is a good occasion to solve it, by making something more minimal, with less dependencies that could actually be updated regularly. Also, with its virtual lib system, it would be easy to have multiple version live together, like our Python friend.

As for chip availability, yeah ... I think waiting for Intel will not be hard, since we will not have any chips from Nvidia/AMD either before either :) Scalpers, miners (on both side from rumours I heard) and Sony/Microsoft, and most probably selling pro cards for Nvidia which is crazy margin and probably comes first.


Last edited by 3zekiel on 4 December 2020 at 6:02 pm UTC

Quoting: slaapliedjeHow is it unsupported if I install nvidia drivers from the debian repo? Unlike Ubuntu and their Universe / Multi-verse repositories, Debian supports ALL of theirs... one of the reasons Debian is superior.

So, installing a new kernel from Debian testing is unsupported but installing Nvidia drivers from testing is supported?

Quoting: slaapliedjeI'm not, what I'm implying is that distros don't support AMDGPU Pro drivers within their distribution. Whether that is because they're too hard or because AMD doesn't let them, I haven't looked into. But nvidia clearly does allow distributions to put their drivers in repositories. Simple as that. Have you seen any distribution contain repositories with the proprietary AMD driver? If so, I'd like to know about them, as I haven't seen any. I mean let's hold both companies to the same standard, do they both allow repackaging of their drivers? Or are we stuck with the three distros they support (RHEL, CentOS, Ubuntu)? Even the open source drivers require firmware blobs, so the ones who are happy about that can't be 100% happy.

This just brings up the problem I stated in my last post, neither solution is 100% great. Nvidia just happens to have better distribution support as of right now. Unless you're using a rolling release (as you said, latest kernel) then you're shit out of luck for AMD.

If you don't want to imply that then you should probably start saying that Nvidia is better supported in your distro and that's it. And you don't need to have a rolling release. You just have to get the latest kernel and Mesa version if and only if you have the latest hardware, something you can do without a rolling release.

Quoting: x_wing

Quoting: slaapliedjeHow is it unsupported if I install nvidia drivers from the debian repo? Unlike Ubuntu and their Universe / Multi-verse repositories, Debian supports ALL of theirs... one of the reasons Debian is superior.

So, installing a new kernel from Debian testing is unsupported but installing Nvidia drivers from testing is supported?

They BACKPORT kernels from testing to stable. https://packages.debian.org/buster-backports/linux-image-5.9.0-0.bpo.2-rt-amd64-unsigned Also backports for nvidia drivers are also enabled.

What I was saying is that installing them ARE supported You just don't WANT to have to install newer kernels unless you really need something in the new kernel, that was my point. The whole 'meh, let's swap out the kernel' should be more of a 'holy shit, you're forced to get a new kernel because you want a new GPU?' It should be like any other platform, you update the driver for newer card support, you shouldn't have to update your whole kernel. Not everyone can just do that, like if they have a workstation where they are tied to a specific kernel for business case (like nessus won't accept anything but the kernel version string to certify it's not vulnerable).
Not sure why people don't take such things into account when they say 'just update the kernel'.

Quoting: slaapliedjeI'm not, what I'm implying is that distros don't support AMDGPU Pro drivers within their distribution. Whether that is because they're too hard or because AMD doesn't let them, I haven't looked into. But nvidia clearly does allow distributions to put their drivers in repositories. Simple as that. Have you seen any distribution contain repositories with the proprietary AMD driver? If so, I'd like to know about them, as I haven't seen any. I mean let's hold both companies to the same standard, do they both allow repackaging of their drivers? Or are we stuck with the three distros they support (RHEL, CentOS, Ubuntu)? Even the open source drivers require firmware blobs, so the ones who are happy about that can't be 100% happy.

This just brings up the problem I stated in my last post, neither solution is 100% great. Nvidia just happens to have better distribution support as of right now. Unless you're using a rolling release (as you said, latest kernel) then you're shit out of luck for AMD.

Quoting: x_wingIf you don't want to imply that then you should probably start saying that Nvidia is better supported in your distro and that's it. And you don't need to have a rolling release. You just have to get the latest kernel and Mesa version if and only if you have the latest hardware, something you can do without a rolling release.

That's what we're talking about here, if you are going to get the latest hardware, you basically have to upgrade kernel / mesa instead of just letting your distro packages handle it. Debian Sid apparently already has the minimum (kernel 5.9.x and Mesa 20.2+ (may have been 20.1+ that is needed). But that IS a rolling release. Yes they have backports, but you'd have to 'prep' for stable and install that stuff before you pull out your old card and put in the new.

But the way nvidia and AMD do it with their proprietary driver is more supportable, as you don't have to muck with new kernels, and they package their own OpenGL/Vulkan libraries. DKMS is the correct way to go here. If your distribution breaks DKMS, that means they didn't test kernel+dkms+driver integration, and that's ON THE DISTRIBUTION, not nvidia or AMD's fault, right?

In the past, different distributions would end up patching flgrx to work with Xorg, or they wouldn't roll out new Xorg or flgrx drivers so as to not cause breakage. Now not all distributions have a large amount of testers / developers working on them, so some hardware support is simply lacking testing, and that could easily cause your system to not boot to a gui. But at least then (if you know what you're doing) you have a chance to try to fix it. A lot of times in the past, Windows would just crash, and safe mode is a pain to try to get a video driver working again....

Quoting: slaapliedjeI have been using nvidia for years, and it has pretty much been 'just works'.

I remember Nvidia breaking more than once due to kernel updates and I remember Nvidia messing up my install to the point of frustration and wiping out the whole OS to reinstall. Not upstreaming their driver has consequences. Ditching the blob felt very good and I'm not interested in going back to that horror :)


Last edited by Shmerl on 4 December 2020 at 8:10 pm UTC