I do love AMD because its drivers are open source as opposed to nVidia. However, is "less issues" really the case? I sure hope not, for nVidia's sake.
My AMD graphics experience, on APUs and dedicated GPUs, has been plagued with basic issues and random crashes. AMD cards and their driver/firmware issues are without a question the IT product that affects my daily life most.
I tried AMD exactly once for Linux graphics, it was so unstable that I bought a NVIDIA card within a month and have never looked back. Potentially NVidias approach of staying as far away as possible from the Linux kernel abstractions is much saner than to play ball with them.
The immense majority of Linux users use these "abstractions". Even on the steam survey which is going to be extremely biased to favor nvidia users Intel/AMD GPUs are the majority, and if you include the Steam Deck then it's a no contest.
Compare the number of issues here: https://wiki.archlinux.org/title/Vulkan. The only issue with the Nvidia driver is that there might be another (open-source) driver installed. AMD has several drivers which fail in different situations. The same has been true for OpenGL implementations, the only truly good implementation is the one by Nvidia, this is even well known in the PC game development industry.
What is this trying to prove? It's just one random page of a publicly editable wiki. AMD/Intel having more entries may just be because it is more popular (which it is indeed), or because (being opensource) it is actually easier to debug+solve problems, and/or a million other reasons.
Frankly, I think all the argument you need is that despite the huge advantage nvidia has on other platforms, it is almost completely reversed (even on steam) for Linux. It conveys very heavily that at least nvidia has a very poor reputation on Linux desktops.
In my experience, AMD still has some massive stability issues with the VBIOS of their GPUs. But it's not a component that the users can officially update on their own (whichever version the graphic card comes with when you receive it, is what you are stuck with), and most users are not even aware of its existence (even on Windows, the official driver doesn't provide any way to update it, or even check its version). Resulting in two seemingly similar cards, with the same drivers and firmware, behaving wildly differently in some case depending on the production batches the card was part of. Ask me how I know.
From what I remember from the ATI days (aah, sweet memories), it was often the case of either you card was working great and the driver was much more up to date with the latest kernel tech, or the card was a mess to make work under linux.
With NVidia, you were more sure that your car was going to work, but they were often not implementing certain kernel tech, or they had their own weird way to do things, which often mean that you had to configure Xorg and some app with some weird workaround for NVidia.
> I do love AMD because its drivers are open source as opposed to nVidia.
AMD's drivers are not really more open that Nvidia's. Similar to Nvidia's Open GPU Kernel Module's[0], AMD's opensource drivers are mostly a shim that wrap firmware blobs[1] in which the functionality you really care about is contained.
That's still a huge difference though. You get in kernel drivers that properly support wayland and don't require recompiling modules all the time. Plus all the hacks one has to go through to run wlroots based compositors with nvidia.
Normally, firmware does not make the driver itself less open source.
I get it and I'd also like for all components of my devices to be open source. Still, the parts I really care about and have any idea of how to fix stuff in, are open source.
For nvidia devices there is (or was? It's been a while) a whole other set of horrible user-space closed-source stuff.
> AMD's opensource drivers are mostly a shim that wrap firmware blobs
I went and checked the size of AMDs vs NVs firmware blobs and the 2 GSP firmware that are used for new NV cards in the linux-firmware package (https://archlinux.org/packages/core/any/linux-firmware as references for what I checked) result in it being the single largest folder in there (40MiB). Compare that to the largest amdgpu firmware file which is at 392KiB with the entire folder of 562 items being <20MiB.
Not to say that AMDs firmware is open source or so, it certainly isn't, but even comparing the amount that is possibly done is somewhat laughable.
AMD _has_ open drivers which include not only the kernel parts but also DRM, video acceleration, and mesa/llvm backends. NVIDIA doesn't release any of this.
Are you going to claim that because both have proprietary firmware, it doesn't matter if you are forced to run proprietary software to use it?
Using Mesa is already an order of improvement of openness, and frankly, calling it "a shim which wraps firmware" is a ridiculous thing to say.
As far as I am aware, ROCm itself has been open since its release in 2016. Whatever they were trying to convey will have little impact on ROCm being a valid competitor. Frankly, AMD should just trash ROCm and go all in on Intel's oneAPI. AMD seems helpless on software and reports are Google and Qualcomm have interest in pushing oneAPI.
Hopefully this will let ROCm be a valid competitor.