Rationale:

Both AMD and Intel provide well maintained open-source drivers for many years[1]. Nvidia doesn't. You need to use closed-source drivers with Nvidia in practice, which causes issues with kernel upgrades, various issues (for which you don't get help, because the kernel is now marked as tainted) and problems with Wayland. The later are caused by the fact, that Nvidia refused[2][3] to support Wayland for a long time. Blaming that implicit sync was a disadvantage for Nvidia is not appropriate. They could've participated a long time ago and either adapt to implicit sync or help adding explicit sync years ago.

Furthermore:

  * AMD gave us Vulkan as standard, which builds upon AMD's Mantle.
  * AMD gave us FreeSync i.e. VRR, which is usable by others.
  * AMD gave us FSR, which is usable by others.

  * High prices.
  * Proprietary and expensive GSYNC.
  * Refused to publish documentation and open-source drivers for many years.
  * Own video-decoding libraries.

[1] Well. Decades?

[2] https://web.archive.org/web/20101112213158/http://www.nvnews...

[3] https://www.omgubuntu.co.uk/2010/11/nvidia-have-no-plans-to-...

[4] https://www.youtube.com/watch?v=tQIdxbWhHSM

Is that what this is? https://github.com/NVIDIA/open-gpu-kernel-modules

Nvidia has open-sourced the kernel module "driver", which recently have been declared stable enough for general consumption.

But the kernel-mode driver is only a small part of what you would call the graphics card driver, and the bulk of it is still very much a proprietary blob.

The true open source driver for NV cards is Noveau[1] which works ok with older cards but is slow to support newest cards and features. Performance, power mgmt and hw acceleration are usually worse or not working at all compared to the official drivers.

[1] https://nouveau.freedesktop.org/FeatureMatrix.html

It has only been a year since NVIDIA actually recommended using the open-source drivers and that's only for Turing (NV160/TUXXX) and newer. It's easier to use my AMD integrated GPU on (wayland) Linux than it is dealing with bugs from NVIDIA drivers.

* since 20 years ECC on simple unbuffered RAM on Desktop.

There's that new NVIDIA driver cooking, but I'm not sure what the status is on it.

BTW, even Ryzen 3 is a substantial upgrade over 1. Any X3D processor (I think 5 is when they first appeared) is even more so. Ryzen 5 is also less sensitive to RAM timings. I applaud you for avoiding latest-and-greatest syndrome, but even upgrading to an older CPU generation would be a significant boost.

Being out of a job for a while makes me very loathe to upgrade hardware that still works OK. That 1800X still does what I want it to do, and does it 'fast enough', though how far into the future that will last is unclear. Cyberpunk 2077 being the most demanding game that I've played probably helps. :D

It's difficult to justify any new hardware until I'm in a better place; while it'd be nice, I'm not suffering enough to /need/ a new system.

Until the beginning of 2020, during university, I was still on a 3930K from launch-day in ~2011 and GTX 680. Honestly, I'm not sure I would've bothered if it weren't also for the fact that I wanted to be able to test AVX2 implementations of some of my code without relying on an emulator or someone else's machine every time.

It probably helped that I mostly only care about Source games and RuneScape. But I haven't really played anything since my ex-girlfriend and I broke up in ~2022.

I took his RX 480 to have a display-out and gave him my 2070 Super so it wouldn't go to waste.

Brand new AMD cards have great support -- in mainline Linux and MESA. But if you're using a kernel and MESA from a distro, you're gonna have a hard time for the first ~8 months. You'll either have to run a rolling release distro or make your own kernel, linux-firmware and MESA packages. I had to do this when I got a 7900XT card a few months after launch while running Ubuntu.

This is the Linux driver model working as intended, and it sucks.

I suspect you may also encounter issues with Flatpaks, since from my understanding, these use the MESA userspace from a runtime so they wont work until the Flatpak runtime they use updates their MESA. I don't think it helps to have a working MESA on the host system. I'm not 100% certain about this though, would love some feedback from people with a better understanding of these things.

But instead of random anecdotes, here's valves word on it: https://www.pcguide.com/news/nvidia-drivers-are-holding-back...

Radeon overall offers a smoother desktop experience, and works fine with gaming, including proton-enabled games on Steam. OpenCL via rocm works decent, with some occasional crashes, in Darktable. Support for AI-frameworks like jax is however very lacking, and I spent many days struggling to get it to work well, before giving up and buying a nvidia card. geohot's rants on X are indicative of my experience.

The nvidia card works great for AI-acceleration. However, there is micro-stuttering when using the desktop (gnome shell in my case) which I find extremely annoying. It's a long-known issue related to the power manager.

In the end, I use the nvidia card as a dedicated AI-accelerator and the Radeon for everything else. I think this is the optimal setup for Linux today.

I've tried using the triple buffering mutter patch[0] and still was experiencing issues. COSMIC is looking great but I have some weird screen artifacts randomly.

Hyprland is the only environment that hasn't had any performance issues with my 4070 Super.

[0] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441

I've played quite a few games on Linux. Performance is still better on Windows though.

It isn’t just I that have observed this. I have a friend using Arch and he noticed there is a higher input latency and worse performance.

I’ve also noticed some weird mouse behaviour in Doom Eternal.

It is enough of a difference that I just reboot into Windows now to play games.

Wayland on Nvidia was a mess, though.

But as time goes by, things get better and better.

I got rid of it and built myself a PC (not just because of Nvidia, gaming laptops are just a disappointing experience). And went all in with Team Red - Ryzen and Radeon. It's a joy to run Linux on, I work on it and have played several games - 0 problems.

Nvidia may be the leader in performance, but if it means you're stuck with Windows - I'd say it's not worth it.

Ubuntu seems to be even better. I turned my system into a Frankendebian for a day to try out ROCm, the AMD install scripts work out of the box on newer Ubuntus.

I wonder if the Radeon driver has gotten reliable GPU restart support. The GPU becoming unrecoverable if a shader crashed was long a major issue on Radeon on Linux, and I am not sure if valve fixed it for AMD.

Depends on a metric. I found Nvidia drivers to be better on every platform. It's just because it's closed-source it's PITA to install and update, but everything in between is great.

I've switched to AMD for religious reasons, tho. Even update story is worse on Windows for AMD, at least it was when I had RX 6900 XT.

I had several bad updates (this was when using Fedora) and was left with graphics 30 minutes before I had to start work, I ended up plugging in a really old AMD GPU to be able to work for the day and then spent several hours faffing to get graphics back up.

I will only buy AMD/Intel cards now because it is plug and play on Linux. I've had no problems with the AMD card on Debian 12. On Debian 11 I had to enable a non-free repo to install the relevant firmware. The 1080Ti as awesome at the time as it was, only worked properly and reliably under Windows.

The other issue with Nvidia is when they stop supporting your card, their drivers will sooner or later not work with the kernel. I have an older machine that works quite well and I had to buy another GPU as the legacy Nvidia drivers do not work with new kernels. The hardware itself works fine.

Anyway, Valve has improved things on Linux, but I have yet to hear any news on RADV being able to recover from GPU hangs. Nvidia’s driver can. The last I looked a few years ago, the security guys were begging the AMD driver developers to look at static analyzer reports. Meanwhile, the open source driver that Nvidia released shows that Nvidia uses static analyzers given that it has preprocessor directives from Coverity. I really would not regard AMD as being at Nvidia’s level yet on Linux, even if it is coming close.

This is not true. There were many differences with how Nvidia had been doing things in their drivers (partially due to them reusing code on all platforms) and how Mesa/Wayland was already doing things, namely with explicit/implicit sync and GBM/EGL streams, but there was no intention to make things hard for Nvidia.

Mesa/Wayland ended up supporting explicit sync so Nvidia's driver could work.

Reusing code on all platforms is a reason why the Nvidia driver has long been so good. It deduplicated effort so that they could focus on making the driver better. AMD avoided this prior to vulkan and their drivers had long been a disaster until Valve started helping on Linux. AMD tried copying the unified driver approach for the vulkan portion of their driver with AMDVLK and had some minor success, although the community driver developed by valve is better and they would be better off porting that to Windows.

That's what happens when you try and shoe horn non-GPL code into the kernel.

The userland libraries are MIT because everything links to them, including propriety software.

I have had a good experience with Nvidia and when there is an issue, I report it and Nvidia fixes it within months. The only time I have seen a better turn around was Intel graphics, where they fixed things within 24 hours after I pointed out a bug in their kernel driver. AMD graphics on the other hand seems unresponsive to community reports or outright refuses to handle issues.

For example, they refused to implement VK_EXT_fragment_shader_interlock in AMDVLK despite implementing the equivalent for D3D12 on Windows:

https://github.com/GPUOpen-Drivers/AMDVLK/issues/108

The damage in that case is limited to Windows, as the community driver for Linux implemented it, but it made cross platform support in emulators more difficult. If it were not for Valve working on the community driver, the Linux experience on AMD graphics would be no where near how good it is on Nvidia graphics.

I do not know what you mean by “issues with newer hardware”. It has always worked just as well on Linux as it worked on Windows as far as I know.

In the past, anyone experiencing that sort of thing had a MTRR issue from how the BIOS set things up that could be fixed by setting NVreg_UsePageAttributeTable=1 on the Nvidia kernel module, but I have not heard of anyone in that situation for a few years now. I had been under the impression that the setting was obsolete as Nvidia had made it the default behavior.

I am definitely not buying an nVidia GPU ever again.

It sounds like your issue is related to the dma buf issue that the kernel developers created. I thought that was fixed in recent versions of the open source Nvidia driver. What was the last driver you tried?

Yeah the drivers aren't open source but, like, they work?

Yeah I may have been held back from switching to Wayland for a while but... honestly I did not care.

With all that said, I would really like to see AMD compete particularly in the AI space where nvidia seems to be able to charge totally wild prices that don't seem justified...

CUDA vs ROCm (Rusticl?) is probably another story, though.

Could that maybe be because Nvidia now has almost an order of magnitude more customers? I think they closed 2024 with 90% market share.

In a commercial setting, with a supported distro, it's really very solid for desktop use.