Nvidia's Linux support? AMD actually has open source drivers these days, just like Intel, Nvidia just gives you a binary module, which means in order to make use of that hardware you have to taint your kernel and aren't free to update it if the in-kernel ABI changes. It's basically on par with the vendors of all those "useless ARM devices out there", none of them with "usable Linux support".
AMD is finally approaching parity in the past year or two, but Nvidia is still ahead in terms of day-to-day usability. It sucks that they're closed, but if you just want to install a driver and have your system work, Nvidia is ahead.
Look at this mess: https://wiki.archlinux.org/index.php/Xorg#AMD Do you want AMDGPU, AMDGPU PRO, ATI, or Catalyst? How do you choose? Let's assume you want open source and recent, so probably AMDGPU. OK that's relatively straightforward, but now let's say you want Vulkan support. That's over here: https://wiki.archlinux.org/index.php/Vulkan#Installation and golly wouldn't you know it there are three choices, vulkan-radeon, amdvlk, and vulkan-amdgpu-pro. How do those relate to the radeon and amdgpu drivers mentioned earlier? Arrrrrrrrrrgh.
Meanwhile on nvidia, you install "nvidia" and you're done.
I've been working in gaming on Linux profesionally for ten years. If I were buying a new GPU today, I would pick nvidia.
I think you might be blinded by prior experiences (yes, that sounds illogical). The choice you have with AMD now is not bad for users, they get a working good and free driver with their distro out of the box. And people like you, who work in gaming under Linux and might use a more custom distro, can figure out which one is the best driver in your specific situation (it's AMDGPU always anyway).
I'd never buy a Nvidia card for Linux now. I wouldn't have done so three years ago, but now? That'd be a huge step backwards.
It's possible. The last time I bought an AMD GPU for my personal use was in 2009 or 2010. But I really do work with this stuff every day. In our QA lab, the AMD machines have far more problems than the Nvidia machines do. Valve's VR software works much less consistently; installing modern versions of the drivers on Ubuntu is a huge pain, you have to use 3rd party repos maintained by some random guy; missing features and driver bugs are much more common on AMD (though not unheard of on Nvidia either).
AMD is definitely getting better, and being open source is an enormous point in its favor, but it's still just less usable day-to-day for an end user. I hope this changes.
Unfortunately very few Linux people even see a point in actually using their GPU. As long as it can composite terminal emulators, they think everything is great. I've seen such reasoning in discussions about sway, where people are encouraged to throw out their $500+ GPU in favor of the on-die Intel GPU...
...Vulkan? Proton? In terms of 3D acceleration libraries and support, its never been better on linux. I actually just switched to manjaro full-time because everything I wanted to play now works on linux, too.
Mesa drivers are fine.
The one with horrid performance is their proprietary AMDGPU-PRO, but there's no reason to use it. (especially since Mesa now support GL compatibility profile)
Mesa drivers are far from fine, they only got rid of the "core only" braindead schism just last year (IIRC) and that was thanks to pressure from AMD to get games working. Even then a lot of Mesa's codepaths are downright awful.
Nvidia had OpenGL as a major focus for decades (it was even the first API to get new features introduced in their hardware via extensions - though nowadays they also seem to do the same with Vulkan) and their OpenGL implementation's quality shows.
Yes, Mesa is not perfect. (particularly annoying thing is that it is possible to lock up entire GPU by invalid memory accesses in shader, infinite loops not always recover cleanly and lock up GPU too, and these bugs are accessible through WebGL, etc.)
But I prefer occasional crash in badly behaved software than abysmal performance of their proprietary implementation. (and it crashes too, usually on software using legacy pre-GL3 context).
And as to compatibility context, IMO OpenGL shouldn't have defined it at all. It is rather weird to have rendering code using both legacy fixed pipeline and modern shaders. From my experience it just causes problems everywhere, and I had encountered unexpectedly bad performance and glitches on Nvidia drivers too. (though maybe less often than on Intel/AMD)
My experience with NV on Linux is out of date, from 2003-ish (?) when the binary driver was new, to 2010, but I remember a few drawbacks I couldn't overcome and happily made the switch to ATI/AMD:
1) Closed driver
2) Weird incompatible multimonitor support called twinview? Where windows would maximize to stretch across all your screens
3) Abusive on the PCI subsystem, so that my sound hardware would experience underruns, both spurious and reproducible events such as during workspace switches
4) Lockups
5) Corruption/lockups switching between FB terminals and the X terminal
I switched to ATI and the open source driver and all these problems went away.
> which means in order to make use of that hardware you have to taint your kernel and aren't free to update it if the in-kernel ABI changes.
I have difficulty placing all the blame on Nvidia here since it is the kernel developers long-held disdain for stable driver ABIs that Nvidia feels forces their hand. There are those who argue otherwise, but that argument is basically "all software should be open source". Even if we go with the more reasonable "all drivers should be open source" that still introduces problems because of bonkers patent law nonsense.
AMD doesn’t support 8K monitors under Linux. I agree, NVIDIA has far better usability for most users. The fact that it’s a binary blob means nothing to anyone who isn’t an OSS activist.
> aren't free to update it if the in-kernel ABI changes.
How often is that actually an issue? Last time I ran into that was when I was still running Debian Sid and NVIDIA was far from the only thing that ended up breaking.
