Hacker News Reader

Comment by blickentwapft | Hacker News Reader

Could open source graphics drivers become a better option than proprietary?

As others have mentioned, on Linux they already are outside of Nvidia. As for whether proprietary on Windows/Mac is better than free on Linux, I'm not sure how you'd test but I'm also curious.

They are already the better option for Intel and AMD.

Re: AMD, my experience has been that one needs a very recent kernel (5.4+) for a good experience on Navi. Even with that, I'm getting some interesting errors in dmesg on a 5600 XT under Pop!_OS. I knew I'd be unstable on this system for a while when I built it, so for now it's relegated to gaming and web browsing, with any "real" work occurring on my increasingly aging but rock solid Core 2 Quad workstation.

>AMD, my experience has been that one needs a very recent kernel (5.4+) for a good experience on Navi.

I think needing a kernel released after the video card is a fairly reasonable demand.

5.4 was released in November 2019, while Navi with the 5x00 series was released in July 2019, so that's actually 2 release cycles or so of the kernel before hitting stable support. For comparison, Intel already has Gen12 graphics support in place across the entire software stack despite the fact Tiger Lake/Xe are not available until later this year (Mesa support for Gen12 was merged in Oct 2019!) AMD is just comparatively not as good about this, frankly, and I say that as someone who has the luxury to (and often does) run -rc kernels for latest hardware. This is not only true of their graphics cards, but to some extent their CPUs as well.

They need to get their software support up earlier. I get that there are issues like supply chains, OEM firmware, and all that jazz, but they aren't amateurs flying by the seat of their pants here, they're capable of doing this. If I had to guess I'd say it's simply because AMD's software department seems stretched pretty thin, where as the competitors have enormous software teams. Hopefully they can fix that.

>5.4 was released in November 2019, while Navi with the 5x00 series was released in July 2019

Their specific card was released in January 2020, and the only problems they list are some strange dmesg entries. They may be lagging a bit compared to Intel, I am not following closely enough to note, but is Intel even offering competitive GPUs?

>Is Intel even offering competitive GPUs?

Not yet, but they supposedly are supposed to start soon. I'm pretty happy with that, more competition is good for everyone.

I agree completely! Unfortunately that means either running a very recent distro release, a rolling distro, or upgrading the kernel on a stable distro like Slackware or Debian, currently at 4.4.x and 4.19.x respectively. I chose to run a recent distro release (Pop!_OS 20.04), with the caveat that overall stability is not up to par with traditionally stable distros like those mentioned above. My C2Q workstation runs Slackware 14.2 and, as mentioned before, is rock solid. It has an AMD FirePro "Turks" era card, and it's doing quite well with the open source driver.

Ubuntu LTS releases have an official "Hardware Enablement" kernel which is reasonably up to date. On 18.04 LTS, its currently using Kernel 5.3. New Desktop installs default to this updated stack.

https://wiki.ubuntu.com/Kernel/LTSEnablementStack

That's good to know, thanks. I had a lot of bugs with Ubuntu 20.04 that weren't present in Pop, so I stuck with the latter.

My goal is to reach stability with Slackware (probably when 15.0 is out) or Void (currently buggy on that build). I prefer KDE Plasma to Gnome, but System76's customizations really make it useful for now.

Requiring new kernels for hardware support is a permanent problem with the way linux is developed. Ubuntu was supposed to "solve" this with it's hardware support layer( basically backporting drivers) but I don't know how well that works.

Fwiw with an older amd gpu that got mainline support years after it's release I found that Fedora was a good balance for getting the new patches without breaking everything.

Depends on the GPU.

Some of them still have better support on Windows, while older ones were left behind with open source drivers reboot.

Could be, but it will require some heavy investment from the FOSS community first.

In general, drivers written by vendors have poor quality (tons of legacy code + the usual enterprise shenanigans) but benefit from having access to all documents and all silicon erratas.

If the community can get past that, I firmly believe that adding a couple of thousand fresh eyes will eventually lead to significantly improved performance.

edit on reflection, my information is both based on vague memories and outdated, I shouldn't have made this post.

??? I don't believe this was the case for RADV. AMD was dragging their feet on providing an open source Vulkan driver so the community created one in record time.

I do remember reading they were dragging their feet on releasing some newer documents but I also thought their team had primarily moved to the open source driver. I may be wrong, I'm a complete outsider who hasn't been paying attention for a year or two.

They have moved to the open source driver for openGL. Vulcan was delayed for long enough that a RedHat employee built a driver and mainlined it( using the documentation provided for the openGL driver). Eventually AMD ended up supporting that driver instead of open sourcing the proprietary one that was part of their proprietary stack.

Note that ARM, Nvidia and AMD consider newer architecture as trade secrets and make it really hard to access to certain information.

Some of the current open drivers are really watered down.

Are we talking about performance or user experience?

User experience seems given if it gets included in mainline

They are your only option. The only other "drivers" are never updated binary blobs, maybe from the vendor that sold you the hardware, possibly extracted from some years old Android firmware image.

Reply on news.ycombinator.com