Hacker News new | ask | show | jobs
by ho_schi 349 days ago
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

3 comments

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.

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.

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.

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.
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 never managed to get it working on my Netbook APU.
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,

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.