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?
In a commercial setting, with a supported distro, it's really very solid for desktop use.
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.
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...