Nvidia won, we all lost

> AMD GPUs aren't good enough.

Software. AMD has traditionally been really bad at their drivers. (They also missed the AI train and are trying to catch up).

I use Linux and have learned not to touch AMD GPUs (and to a lesser extent CPUs due to chipset quality/support) a long time ago. Even if they are better now, (I feel) Intel integrated (if no special GPU perf needed) or NVidia are less risky choices.

> I use Linux and have learned not to touch AMD GPUs (and to a lesser extent CPUs due to chipset quality/support) a long time ago. Even if they are better now, (I feel) Intel integrated (if no special GPU perf needed) or NVidia are less risky choices.

Err, what? While you're right about Intel integrated GPUs being a safe choice, AMD has long since been the GPU of choice for Linux -- it just works. Whereas Nvidia on Linux has been flaky for as long as I can remember.

They have never been flaky on the x11 desktop

Had major problems with xinerama, suspend/resume, vsync, probably a bunch of other stuff.

That said, I've been avoiding AMD in general for so long the ecosystem might have really improved in the meantime, as there was no incentive for me to try and switch.

Recently I've been dabbling in AI where AMD GPUs (well, sw ecosystem, really) are lagging behind. Just wasn't worth the hassle.

NVidia hw, once I set it up (which may be a bit involved), has been pretty stable for me.

This is wrong. For 14 years the recommendation on Linux is:

    * Purchase always AMD.      
    * Purchase never Nvidia.
    * Intel is also okay.

Because the AMD drivers are good and open-source. And AMD cares about bug reports. The one from Nvidia can and will create issues because they’re closed-source and avoided for years to support Wayland. Now Nvidia published source-code and refuses to merge it into Linux and Mesa facepalm

While Nvidia comes up with proprietary stuff AMD brought us Vulkan, FreeSync, supported Wayland well already with Implicit-Sync (like Intel) and used the regular Video-Acceleration APIs for long time.

Meanwhile Nvidia:

https://registry.khronos.org/OpenGL/extensions/NV/NV_robustn...

    It’s not a bug, it’s a feature!

Their bad drivers still don’t handle simple actions like a VT-Switch or Suspend/Resume. If a developer doesn’t know about that extension the users suffer for years.

Okay. But that is probably only a short term solution? It is Nvidias short term solution since 2016!

https://www.phoronix.com/news/NVIDIA-Ubuntu-2025-SnR

>Err, what? While you're right about Intel integrated GPUs being a safe choice, AMD has long since been the GPU of choice for Linux -- it just works. Whereas Nvidia on Linux has been flaky for as long as I can remember.

Not OP, I had same experience in the past with AMD,I bought a new laptop and in 6 months the AMD decided that my card is obsolete and no longer provided drivers forcing me to be stuck with older kernel/X11 , so I switched to NVIDIA and after 2 PC changes I still use NVIDIA since the official drivers work great, I really hope AMD this time is putting the effort to keep older generations of cards working on latest kernels/X11 maybe next card will be AMD.

But this is an explanations why us some older Linux users have bad memories with AMD and we had good reason to switch over to NVIDIA and no good reason to switch back to AMD

I run llama.cpp using Vulkan and AMD CPUs, no need to install any drivers (or management software for that matter, nor any need to taint the kernel meaning if I have an issue it's easy to get support). For example the other day when a Mesa update had an issue I had a fix in less than 36 hours (without any support contract or fees) and `apt-mark hold` did a perfect job until there was a fix. Performance for me is within a couple of % points, and with under-volting I get better joules per token.

I've been using a 4090 on my linux workstation for a few years now. Its mostly fine - with the occasional bad driver version randomly messing things up. I'm using linux mint. Mint uses X11, which, while silly, means suspend / resume works fine.

NVIDIA's drivers also recently completely changed how they worked. Hopefully that'll result in a lot of these long term issues getting fixed. As I understand it, the change is this: The nvidia drivers contain a huge amount of proprietary, closed source code. This code used to be shipped as a closed source binary blob which needed to run on your CPU. And that caused all sorts of problems - because its linux and you can't recompile their binary blob. Earlier this year, they moved all the secret, proprietary parts into a firmware image instead which runs on a coprocessor within the GPU itself. This then allowed them to - at last - opensource (most? all?) of their remaining linux driver code. And that means we can patch and change and recompile that part of the driver. And that should mean the wayland & kernel teams can start fixing these issues.

In theory, users shouldn't notice any changes at all. But I suspect all the nvidia driver problems people have been running into lately have been fallout from this change.

> I use Linux and have learned not to touch AMD GPUs

The situation completely changed with the introduction of the AMDGPU drivers integrated into the kernel. This was like 10 years ago.

Before then the AMD driver situation on Linux was atrocious. The open source drivers performed so bad you'd get better performance out of Intel integrated graphics than an expensive AMD GPU, and their closed source drivers were so poorly updated you'd have to downgrade the entire world for the rest of your software to be compatible. At that time Nvidia was clearly ahead, even though the driver needs to be updated separately and they invented their own versions of some stuff.

With the introduction of AMDGPU and the years after that everything changed. AMD GPUs now worked great without any effort, while Nvidia's tendency to invent their own things really started grating. Much of the world started moving to Wayland, but Nvidia refused to support some important common standards. Those that really wanted their stuff to work on Nvidia had to introduce entirely separate code paths for it, while other parts of the landscape refused to do so. This started improving again a few years ago, but I'm not aware of the current state because I now only use Intel and AMD hardware.

The AMD drivers are open source, but they definitely are not good. Have a look at the Fedora discussion forums (for example https://discussion.fedoraproject.org/t/fedora-does-not-boot-... ) to see what happens about each month.

I have no NVIDIA hardware, but I understand that the drivers are even worse than AMD's.

Intel seems to be, at the moment, the least worse compromise between performance and stability,

No browser on Linux supports any other backend for video acceleration except VAAPI, as far as I know. AMD and Intel use VAAPI, while Nvidia uses VDPAU, which is not supported anywhere. This single fact means that with Nvidia graphics cards on Linux, there isn't even such a simple and important feature for users as video decoding acceleration in the browser. Every silly YouTube video will use CPU (not iGPU, but CPU) to decode video, consuming resources and power.

Yes, there are translation layers[1] which you have to know about and understand how to install correctly, which partially solve the problem by translating from VAAPI to NVDEC, but this is certainly not for the average user.

Hopefully, in the future browsers will add support for the new Vulkan Video standard, but for now, unfortunately, one has to hardcode the browser launch parameters in order to use the integrated graphics chip's driver (custom XDG-application file for AMD APU in my case: ~/.local/share/applications/Firefox-amdgpu.desktop): `Exec=env LIBVA_DRIVER_NAME=radeonsi DRI_PRIME=0 MOZ_ENABLE_WAYLAND=1 __NV_PRIME_RENDER_OFFLOAD=0 __GLX_VENDOR_LIBRARY_NAME=radeons i /usr/bin/firefox-beta %u`.

[1] https://github.com/elFarto/nvidia-vaapi-driver/

VAAPI support in browsers is also bad and oftenly requires some forcing.

On my Steam deck, I have to use vulkan. AV1 decoder is straight up buggy, have to disable it with config or extensions.

I have zero sympathy for Nvidia and haven't used their hardware for about two decades, but amdgpu is the sole reason I stick to linux-lts kernels. They introduce massive regressions into every mainline release, even if I delay kernel updates by several minor versions (to something like x.y.5), it's still often buggy and crashy.

They do care about but reports, and their drivers — when given time to stabilize — provide the best experience across all operating systems (easy updates, etc), but IME mainline kernels should be treated as alpha-to-beta material.

They opened a tiny kernel level sliver of their driver, everything else (including OpenGL stack et al) is and will still be closed.

Sadly, a couple of years ago someone seriously misunderstood the news about "open sourcing" their drivers and spread that misunderstanding widely; many people now think their whole driver stack is open, when in reality it's like 1% of the code — the barest minimum they could get away with (I'm excluding GSP code here).

The real FOSS driver is Nova, and it's driven by the community with zero help from Nvidia, as always.

> I've been avoiding AMD in general

I have no opinion on GPUs (I don't play anything released later than about 2008), but Intel CPUs have had more problems over the last five years than AMD, including disabling the already limited support for AVX-512 after release and simply burning themselves to the ground to get an easy win in initial benchmarks.

I fear your perception of their products is seriously out of date.

> I fear your perception of their products is seriously out of date.

How's the chipset+linux story these days? That was the main reason for not choosing AMD CPU for me the last few times I was in the market.

I use the amdgpu driver and my luck has not been as good as yours. Can't sleep my PC without having it wake up to fill my logs with spam [0] and eventually crash.

Then there is the (in)famous AMD reset bug that makes AMD a real headache to use with GPU passthrough. The card can't be properly reset when the VM shuts down so you have to reboot the PC to start the VM a second time. There are workarounds but they only work on some cards & scenarios [1] [2]. This problem goes back to around the 390 series cards so they've had forever to properly implement reset according to the pci spec but haven't. nvidia handles this flawlessly

[0] https://gitlab.freedesktop.org/drm/amd/-/issues/3911

[1] https://github.com/gnif/vendor-reset

[2] https://github.com/inga-lovinde/RadeonResetBugFix

Although you get to set your own standards "A bug was discovered after upgrading software" isn't very illuminating vis a vis quality. That does happen from time to time in most software.

In my experience an AMD card on linux is a great experience unless you want to do something AI related, in which case there will be random kernel panics (which, in all fairness, may one day go away - then I'll be back on AMD cards because their software support on Linux was otherwise much better than Nvidia's). There might be some kernel upgrades that should be skipped, but using an older kernel is no problem.

I was under the impression that nvidia just didn't let consumer cards do GPU passthrough.

The open source driver for the Netboooks APU was never as good as either the Windows version, or the closed source that predated it.

Lesser OpenGL version, and I never managed to have hardware accelerated video until it died last year.

I never managed to get it working on my Netbook APU.

I believe this is correct. Linux drivers and support duration were garbage at least 2003-2015. AMD fanboys feveretly expressed opinions notwithstanding. Especially so when AMD started the process of open sourcing their drivers even though many chips already existing didn't qualify for the new upcoming open source drivers. 2015-2018 drivers were acceptable but performance was poorer than Nvidia and wayland support wasn't a notable for most parties.

Now wayland support is an important factor and AMD is a perfectly acceptable and indeed economical choice.

Basically 15 years inertia is hard to counter.

Just recently Alex Courbot with an @nvidia address have become co-maintainer of Nova. Apparently he has pushed open source inside nVidia before, so there's hope for the future.

I just read your comment today. And the good news is, someone just found the commit that triggered the sleep issue literally a couple hours ago. Fingers crossed a fix is incoming.

Yes, I saw that! No response from the devs yet. Hopefully this gets into the kernel soon as a bugfix.

For the longest time they had something in their driver that threw an error and bailed if it detected the GPU was being passed through to a VM but that was easily worked around in qemu or libvirt. nvidia must have realized that that check in the driver was pointless and removed it.