I just wish we had an equivalent of AMD Software on Linux, so I could mess around with the settings more.
For example, I like to limit the GPU to 50-75% of it's total power for ambient heat/cooling reasons, or UPS/PSU/electricity bill reasons when specific games make it hard to cap framerates.
With AMD Software on Windows, it's no big deal. On Linux, the best I found was CoreCtrl: https://gitlab.com/corectrl/corectrl
Sadly, it doesn't seem to work all that well for my use case, which I mentioned in my blog post when using Linux instead of Windows as my daily driver at home too: https://blog.kronis.dev/articles/a-week-of-linux-instead-of-...
> You see, by default the card controls its own GPU and memory clock values, which means that when idle the GPU draws around 40 W of power. However, if I want to set a limit for how much W in total it can use, it also makes me set the GPU and memory clock values, which will them be fixed: so at idle the GPU will use about 60 W of power.
Oh also ROCm makes me want to pull my hair out. Still use almost all AMD hardware though, except for low power Celeron in netbook for notes.
Nevertheless, I have used for twenty years many different NVIDIA cards under Linux, both GeForce and Quadro models, on many different desktop and laptop computers.
I have never seen any problem with the NVIDIA drivers and libraries, everything has worked fine after installation, without needing any special action beyond choosing to install the NVIDIA software. The same was also true under FreeBSD.
The only exception to this was some years ago, on a laptop with NVIDIA Optimus switchable GPUs, where I have lost a couple of days until succeeding to configure how to select between the Intel GPU and the NVIDIA GPU.
I also have some AMD GPUs, older models which still had great FP64 performance, so they are used for computational applications, but with those I had greater problems under Linux, when used with many monitors.
Therefore whether problems with the Linux NVIDIA drivers are encountered must be dependent on complex combinations of hardware and software, so it is impossible to predict whether they will be encountered or not.
Unexpected problems may always happen with any piece of hardware under an open-source operating system, because the manufacturers typically do not provide technical documentation like they did before 1995 and most of them test their hardware only with Windows. NVIDIA certainly provides much better software support for Linux and FreeBSD than the majority of the hardware vendors.
So my point is that it is incorrect to attempt to discourage the Linux users to use NVIDIA due to supposed driver problems, because many of them, perhaps most of them will never encounter any problem.
Only the Intel GPUs can be said to have better Linux support, and they also have the best GPU technical documentation, much better than that of AMD. While NVIDIA has the worst documentation for their hardware, they have excellent documentation for the huge amount of software that they provide freely for their GPUs under Linux.
What is wrong with NVIDIA is neither their software support for Linux nor the documentation for that software, but their pricing policy that always seems based on a greediness that is excessive even for a profit-oriented company.
There might have been NVIDIA GPUs which have been supported for less than 10 years, but I never happened to have one of those.
I have been using mostly Gentoo, and I never had to do anything besides "emerge nvidia-drivers", with the exception of the case that I have already mentioned with the laptop Optimus configuration, which required installing extra programs besides the official NVIDIA drivers.
In all these twenty years I have used only Linux on all desktops and laptops, both at home and at work, and I have also written various OpenGL and CUDA programs, so I have used the NVIDIA cards in many different circumstances, without encountering problems.
Some years ago, I was hoping that I would be able to get rid of the NVIDIA GPUs and use only AMD GPUs, which had a much better computational performance per dollar.
Unfortunately, AMD has split their GPUs into RDNA GPUs that are good only for gaming and CDNA GPUs that are much too expensive for small companies or individuals, so they no longer make any GPU model that could be an upgrade for my old AMD GPUs, so the only choice remains to buy overpriced NVIDIA GPUs, unless the next Intel generation of GPUs will become more competitive for computational tasks.
At least Intel makes a credible effort to compete with CUDA, with their oneAPI environment.
Very slowly, the AMD GPUs become usable with important applications, like Blender, but the problems that can be encountered when trying to use such applications with AMD GPUs and trying to accomplish something concrete are far more annoying than the fact that Wayland may not work well, because one can always choose to avoid Wayland without losing anything.
And may your maker help you if you want to do some HW accelerated ML but accidentally upgrade one of the many NVIDIA components (driver, CUDA, CuDNN) to a version not compatible with that one key Python package.
When I was using Nvidia GPU my experience that 50% after a system update which included kernel update, the Nvidia kmod didn't properly rebuild resulting in graphical interface completely non working next time I booted the system. In such situations I had to switch to terminal and enter a couple of commands to ensure the Nvidia driver is also properly updated and the glue layer between kernel and the driver rebuilt. Most of the time that helped but occasionally it didn't and I had to stay on previous kernel version for a week until the issues got solved.
That was a couple of years ago with fedora. On a different distro with less frequent kernel updates and Nvidia drivers being repackaged by the maintainers of distro instead of third party repo like rpmfusion, or a bigger distro that Nvidia tests ahead of time, the experience might have been slightly more smooth.
Currently with AMD open source driver's that's not an issue since the drivers are part of kernel so everything just works and always has compatible versions. I can install any recent distro and it will just work out of the box.
Last year Nvidia open sourced some parts of their driver, but not all of it (it still depends on large user space binary blobs), it might slightly help with the practical aspects of problem above. But I don't know whether distros embraced it and did it actually help (I dropped Nvidia before that).
I don't disagree that it's at least partially more of the fault of Linux kernel for not having stable API, not so much AMD or Nvidia. But for the end user it doesn't matter whose fault it is. AMD chose to play by the rules of Linux, which makes much better end user experience better.
All of this applies only to graphic driver part, GPU compute is a completely different story.
Another big part as others mentioned is wayland support. For a long time Nvidia drivers dindn't support it at all due to not providing certain interface. From what I understand currently it works on the major desktop environments like Gnome and KDE, but due to them adding support for Nvidia specific interface not the other way around. So it still doesn't work on more niche desktop environments which use the common interface supported by rest of drivers.
~12 years ago, before AMD made their official open source drivers situation was completely different. The choice then for AMD was between non official open source drivers which had 50% performance but worked correctly and the closed source AMD drivers that were 2x faster (when they worked) but otherwise buggy. Compared to that Nvidia closed source drivers worked.
A friend of mine has a similar issue on Ubuntu where the system only boots 2 out of 3 times.
I also recall having similar issues almost every time when I installed systems with NVIDIA GPUs in the last decade.
Checking the forums, other people are having similar issues.
https://forums.developer.nvidia.com/t/no-gui-or-display-afte...
https://forums.developer.nvidia.com/t/no-display-output-when...