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

Quoting: slaapliedjeThey 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'.

We are running in circles here. I previously mentioned that if you have a the requirement of stable kernels or workstations, you must stick to the officially supported distros (i.e. RHel/Centos or Ubuntu LTS) so you can use the dynamic module (and this appliers for both Nvidia and AMD). But lets be real, this discussion is about people that mostly use their GPUs for gaming so getting the latest kernel for the latest hardware is an standard requirement for a Linux user as GPU driver is just one of the many drivers you may need.

Quoting: slaapliedjeThat'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.

Having to get the latest kernel or an specific library version is completely related to the fact that you bought the latest hardware. If you go bleeding edge with the hardware you will have to go bleeding edge with Linux, that's the way it works in our system.

And regarding of having to install your drivers before putting the new one, that's exactly what you have to do no matter if you have AMD or Nvidia (this is probably not 100% true with AMD GPUs, though).

Quoting: slaapliedjeBut 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?

DKMS is a handy option but it's far from being the ideal solution for Linux as many things can go wrong during the build of the module (dealing with those errors will be quite hard for most users), not to mention that you force the user to install a building tools. IMO, from a distro maintainer POV it's probably far better to have everything in the kernel as this helps to avoid the maintenance of the dynamic module (one less package, one less headache).

Quoting: x_wing

Quoting: slaapliedjeThey 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'.

We are running in circles here. I previously mentioned that if you have a the requirement of stable kernels or workstations, you must stick to the officially supported distros (i.e. RHel/Centos or Ubuntu LTS) so you can use the dynamic module (and this appliers for both Nvidia and AMD). But lets be real, this discussion is about people that mostly use their GPUs for gaming so getting the latest kernel for the latest hardware is an standard requirement for a Linux user as GPU driver is just one of the many drivers you may need.

Quoting: slaapliedjeThat'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.

Having to get the latest kernel or an specific library version is completely related to the fact that you bought the latest hardware. If you go bleeding edge with the hardware you will have to go bleeding edge with Linux, that's the way it works in our system.

And regarding of having to install your drivers before putting the new one, that's exactly what you have to do no matter if you have AMD or Nvidia (this is probably not 100% true with AMD GPUs, though).

Quoting: slaapliedjeBut 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?

DKMS is a handy option but it's far from being the ideal solution for Linux as many things can go wrong during the build of the module (dealing with those errors will be quite hard for most users), not to mention that you force the user to install a building tools. IMO, from a distro maintainer POV it's probably far better to have everything in the kernel as this helps to avoid the maintenance of the dynamic module (one less package, one less headache).

Thing is, and my point being, yku should NOT HAVE to go bleeding edge just to get a graphics card to work. With nvidia you do not, as most distributions package the drivers themselves. With AMD you will always be chasing the latest mesa libs or kernel, because distrubutions don't chase AMD. The proprietary drivers for AMD have been a mess for a long time and so distributions gave up on packaging them. The open source ones tsnd to not perform as well, as noted earlier in this thread. So being forced to use the proprietary driver for either 'team' to get the full benefits out of your hardware makes me think both of them only give us as much as they think we deserve.
I usually backed Matrox back in the day as everything just worked out of the box. But then the Parhelia came out and the driver install was much like nvidia's and it sucked.
Funny thing is, now Matrox hardware is supported in the nvidia driver, go figure.
So let's all admit, both have their advantages and disadvantages. Neither is 'evil' they both compete for different audiences for the most part. Truth is, for any of the things like DLSS and Raytracing, nvidia still is going to trounce AMD this time around. They got a jump on the tech. AMD was trying so hard to catch up, this is their first gen on ray tracing, so performs similar to the the 2080 from what I have seen, where the rest of stuff is about at 3080 speeds.
The ONLY reasons I would switch to AMD is for better Wayland support and Async Reprojection in VR (which may be pointless with the new cards).
With a new 3080 upgrade... I take the 2080 out of my machine and put in the 3080, done. For switching I will have to reconfigure 3 OSs...

Quoting: Shmerl

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 :)

See, I have had the exact opposite experience. The Radeon laptop that I have, it worked mistly with the fglrx driver, but would break all the time as it wouldn't work either with a newer kernel, or xorg. Then there was a point in time where it fit in that tiny slit of not being supported by the open source driver OR fglrx, and I basically had to switch to Windows...

Quoting: slaapliedje

Quoting: Shmerl

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 :)

See, I have had the exact opposite experience. The Radeon laptop that I have, it worked mistly with the fglrx driver, but would break all the time as it wouldn't work either with a newer kernel, or xorg. Then there was a point in time where it fit in that tiny slit of not being supported by the open source driver OR fglrx, and I basically had to switch to Windows...

My experience has been that:

• My ATI Rage 128 took forever to get support but eventually worked (this was back in 2000/2001, so not much point in comparing further)


• My Radeon (some mid-2000s laptop model, sorry can't remember more) worked wonderfully in Linux but had shoddy 3D performance (it was fine, but not great - laptop though), great experience otherwise, solid hardware and fantastic TV output (yes, it was that long ago)


• my GeForce 680, 980 and 1080 Ti all worked well in games, but the 980 and 1080 Ti both had weird things happening: lots of kernel incompatibilities, system freezes were common (better now, but still happen, especially with VT switching, CUDA, NVdec or VDPAU - basically anything that's supposed to give NVIDIA an advantage) and OpenGL texture corruption and/or texture sync (don't ask, I'm still not sure what it it precisely, but any desktop compositor will go out of sync with actual framebuffers eventually and require a restart - still happens with compton, picom, Mutter and KWin).

Of course, my main gripe with NVIDIA is still the missing VR reprojection on Linux, but now you have a bit of background on how well things have been working in general as well.

Honestly I think the driver installation situation is about equal for NVIDIA and AMD (though the built-in AMD driver gives a slight win there for general usage). For gaming I think the issue for AMD is distribution support for the driver options and for NVIDIA, well, it's NVIDIA :P


Last edited by Cybolic on 5 December 2020 at 11:30 am UTC

Quoting: slaapliedjeWith AMD you will always be chasing the latest mesa libs or kernel, because distrubutions don't chase AMD.

That sounds so dramatic, until you realise that on many popular distributions "chasing" means adding a repo and letting your update manager handle the rest. On rolling distros like Arch you're already running the latest and greatest so you're pretty much good to go. I'm on Mint, but I certainly don't spend any more time "chasing libs" than I spent chasing new Nvidia drivers back when I owned their hardware.

Quoting: slaapliedjeThe open source ones tsnd to not perform as well, as noted earlier in this thread.

That's not generally true for AMD these days, according to benchmarks. There are exceptions of course, but gamers are usually better off with Mesa.


Personally I switched from AMD/ATI to Nvidia about 15 years ago, when fglrx was making my life miserable. But I don't see a reason to pick a camp and stick with it. No hardware vendor has earned my undying loyalty.

I've had less issues since I switched back to AMD after a few Nvidia GPUs that mostly just worked and that's enough to keep me here for now. Being dependent on one less proprietary piece of software is also nice.

Quoting: slaapliedjeThing is, and my point being, yku should NOT HAVE to go bleeding edge just to get a graphics card to work. With nvidia you do not, as most distributions package the drivers themselves.

Installing the latest driver for Nvidia is not going bleeding edge? As I said, having to update your kernel to the latest stable version is not isolated to AMD hardware.

Quoting: slaapliedjeWith AMD you will always be chasing the latest mesa libs or kernel, because distrubutions don't chase AMD. The proprietary drivers for AMD have been a mess for a long time and so distributions gave up on packaging them. The open source ones tsnd to not perform as well, as noted earlier in this thread. So being forced to use the proprietary driver for either 'team' to get the full benefits out of your hardware makes me think both of them only give us as much as they think we deserve.

Once you have a kernel that supports your hardware there is no need to keep updating it (unless there are some driver level bugs that requires fixing, of course). And "chasing" the latest Stable Mesa drivers is fairly trivial in any distro but, once you have support of your hardware you only have to do that if you want to get the new fixes or features of Mesa.

Who told you that "The proprietary drivers for AMD have been a mess for a long time and so distributions gave up on packaging them"? Did you ever take a look on how AMDGPU-PRO is packaged? And I can ask the same regarding the driver performance you mention. I think that you have a big bias regarding many things of the open source drivers.

Quoting: slaapliedjeSo let's all admit, both have their advantages and disadvantages. Neither is 'evil' they both compete for different audiences for the most part. Truth is, for any of the things like DLSS and Raytracing, nvidia still is going to trounce AMD this time around. They got a jump on the tech. AMD was trying so hard to catch up, this is their first gen on ray tracing, so performs similar to the the 2080 from what I have seen, where the rest of stuff is about at 3080 speeds.

How many games I can play with DLSS or RT on Linux? Truth is that we are on Linux and those are pointless features for now. IMO, right now this technologies have the same weight as Physx had in the past.


Last edited by x_wing on 5 December 2020 at 2:52 pm UTC

Quoting: x_wingHow many games I can play with DLSS or RT on Linux? Truth is that we are on Linux and those are pointless features for now. IMO, right now this technologies have the same weight as Physx had in the past.

For RT, it is most likely coming soon, see the movements from Khronos on vulkan RT API (which is literally tailored for dxvk/vkd3d use). So RT definitely matters, unless you are completely against proton of course.

For DLSS, who knows ... Hope it comes, maybe yes, maybe no. Nvidia did release the headers for some of that but not all, the sdk itself is under NDA. Guess it's in Valve's hands to unlock the situation now, I don't see what anyone else can do. Unless Stadia goes Nvidia for next round, that would help a lot.

Fuck it. I had a nice rant going about this subject, but then my mobile fennec crashed on me, and I don't give enough of a shit to try and convince peopls that updating your entire kernel so that you can get your video card working is an unsustainable msthod of doing it.

Quoting: 3zekiel

Quoting: x_wingHow many games I can play with DLSS or RT on Linux? Truth is that we are on Linux and those are pointless features for now. IMO, right now this technologies have the same weight as Physx had in the past.

For RT, it is most likely coming soon, see the movements from Khronos on vulkan RT API (which is literally tailored for dxvk/vkd3d use). So RT definitely matters, unless you are completely against proton of course.

For DLSS, who knows ... Hope it comes, maybe yes, maybe no. Nvidia did release the headers for some of that but not all, the sdk itself is under NDA. Guess it's in Valve's hands to unlock the situation now, I don't see what anyone else can do. Unless Stadia goes Nvidia for next round, that would help a lot.

Yeah, shocker. I still have to dualboot for things, and there the features are definitely being adopted more and more.

Quoting: x_wingIf the average Joe knows how to install the latest Nvidia driver on a distro, he should also be able to keep to date the AMD counter part as it will require exactly the same steps.

But I've given you the reason why some people (like me) say that Nvidia is easier to maintain for average Joe.
But at least we've agreeded that for some users AMDGPU-PRO are a must (to get a pro app support , opencl etc).
And here's the deal - while you have repos for Nvidia which make installing drivers a breeze you don't have something along those lines for AMDGPU-PRO.
So steps are really not the same.
Yes, I can do a manual driver installation via command line. Yes, I can do driver uninstall and reinstall after a kernel update. But should I as a desktop user? I don't think so. And I haven't had to mess with it while using Nvindia for years.

And mind I'm not talking for a fanboy perspective. I don't care whether my system has a team red or green gpu. I care about about performance and how hassle free it is. And at this point if you're a creative that does not want to mess with system Nvidia IMO wins. No matter how much I cheers for AMD and for adoption of Wayland.