I often see Linux users asking for advice when debating the purchase of a new graphics card for their system, wondering what would be easier or best supported under Linux. Far too often, people will respond with vague blanket statements suggesting an AMD graphics card because the drivers are open source and already in the kernel. While there is some validity to this, there is also a slew of details being left out that will impact the experience a user is going to have.
AMD is praised for their value proposition, their use of open source drivers, and their “underdog” status in contrast to Nvidia. What they leave out is Nvidia’s ability to deliver excellent performance, Nvidia’s better-supported proprietary drivers for Linux, and its incredibly useful feature set ranging from NVENC encoding to CUDA processing and more. It’s clear to me that the focus on software philosophy has left many people ignorant of real issues or considerations to be had. As someone who frequently hops between new AMD and Nvidia cards, I’m here to shed some light on the subject.
Open Source Is Ideal, But…
First, some of the good. There is real value to open source software, both for the users and the developers. AMD has done a fantastic job ensuring that their cards are functional with open source drivers in the Linux kernel, with performance for general and gaming use rivaling or exceeding the performance of their available proprietary “PRO” drivers. The fact that users have the opportunity to install an operating system that will provide them the best possible performance out of the box, without needing to manually install drivers, is incredibly appealing. This has not always been the case, but it’s been an increasingly more prominent focus in recent years.
It’s desirable to have open source software where possible as it promotes transparency and trust. The simplicity of in-kernel drivers for the end users is clearly very high.
Nvidia on the other hand, clearly doesn’t share these values. Linux users have to download and install a set of proprietary drivers for their GPUs to reach anything close to resembling peak performance.
By default, many distributions ship open source drivers for Nvidia GPUs known as “Nouveau.” These are not provided by Nvidia, and are a product of incredibly admirable reverse-engineering carried out by a group of talented developers. With the exception of really old cards that tend to be well out of the support range from Nvidia, these drivers tend to perform poorly for applications such as games and other accelerated tasks, but they are (for the most part) functional enough. That being said, searching for these drivers, or installing them manually, has become a normal ritual for Nvidia users and is almost unavoidable on Linux in particular. Surely, it’s safe to say that Nvidia is the obvious downside here, right?
Not really. As I hinted to earlier, Nvidia has a lot to offer that could potentially make up for these inconveniences, not to mention the amount of support that has been in the works from distribution developers and maintainers to mitigate this process.
Pop OS, Ubuntu And Others To The Rescue!
Since I’ve started using Linux, I’ve seen multiple distributions (like Ubuntu and Pop!_OS) work on solutions that provide the proprietary Nvidia drivers for their cards out of the box, or as an option in the boot settings or installer. Where distributions had previously dropped me into sessions incapable of scaling to my monitor’s native resolutions, or just black screens, I now find it more common that I boot into a system working at full capacity from the very start.
Some distributions reduce the complexity of enabling these drivers in situations where they cannot ship it themselves, such as Fedora, with their one-click enablement button in GNOME Software. In some cases, Linux distributions running on Nvidia cards provide experiences similar to or easier than Windows currently does, which is a very surprising and unusual condition.
An Early Adopter Nightmare
Now that I’ve positioned myself as an Nvidia apologist, I’ll dig into the bad sides of picking AMD. With open source drivers built into the Linux kernel, an AMD card is an obviously appealing choice, but there’s a catch. This approach means support for the card you pick is directly tied in to the kernel version shipped by your distribution.
At the risk of being assaulted by an army of Arch users, I’ll say that this is an incredibly restrictive approach. The majority of Linux users are going to be on Ubuntu (and typically an LTS), or a distribution based on Ubuntu such as Linux Mint or elementary OS. This means updates for something as critical as your kernel are not close to current stable releases from upstream at all. This is fine for older cards such as the RX 480 or RX 580, etc. This is a heartbreaking experience for those of us who prefer to purchase current generation cards, and I’m going to use the RX 5700 XT as a card to help me explain why this is.
On July 7, 2019, AMD released the RX 5700 XT and brought us a new champion. It’s to be expected that new cards are not going to have great support on any operating system, and that they will be constantly improved with aggressive driver revamps until it reaches a point of peak performance and stability.
Windows users have the advantage of software tools like Radeon Adrenalin to install and configure the newest available drivers for the cards. Linux users don’t have this luxury, and as I explained earlier, driver updates are tied to your kernel, which means without a kernel update, you’re not going to be seeing these improvements unless your distribution is delivering these to you. The 5700 XT suffered heavily on Linux for months, but was especially poor on the most popular distribution(s) out there, with everything from system crashes to in-game stuttering, to a plain inability to boot.
Kernel 5.4 was the first saving grace for this card, and didn’t make it out to these distributions until the card was already 11 months old. Yes, 11 months just to be at a point where the card works reliably and is performant. Even then, some systems required kernel parameter tweaks to avoid in-game stuttering or hanging issues.
I was pretty displeased with this experience, and I can’t imagine most users are going to be fond of it either. To make things worse, anyone that relies on their GPU for compute (think OpenCL, etc) is going to have a less than desirable experience as well. The PRO drivers for Linux tend to take months on top to find themselves ready for a current Ubuntu release, and Ubuntu is the only distribution it supports.
To reiterate: Ubuntu took nearly a year to have support for the card ready, and then users wait even longer to have support from AMD themselves for OpenCL functions. It’s issues like these that pain me when I hear people suggest AMD as the go-to for Linux, as it’s a very unrealistic image.
How does Nvidia avoid these problems? Well, even though it’s not always sunshine and rainbows, Nvidia’s drivers are offered as separate kernel modules, rather than bundled into the kernel itself. This means that you’re not reliant on this to use your card, even if you’re not running the most recent of kernels. These drivers can be built and installed against multiple versions of the kernel, making it far more accessible for users of different distributions from Ubuntu to Debian to Mint, and more.
I had purchased the Nvidia GTX 1660 less than a month after it had released, and just by installing the proprietary drivers using Ubuntu’s GUI or CLI tool, or on systems like Fedora with the toggle in the Software Center, I was up and running at full performance reliably on the desktop, in games, or with encoding and decoding with NVENC.
Will It Get Better?
Despite all of this, things are improving. AMD is still a very valid choice and even I, someone who has grappled with these issues for over a year now, still own and use AMD GPUs on Linux.
I’m assured that the next generation of AMD GPUs will be much better supported from the start than the current NAVI GPUs have been, and I believe it. However, it’s still going to struggle with the same issues. This isn’t just an AMD problem, or even an Ubuntu problem. It’s a community problem on top of that.
We’re in a position where being realistic about the ups and downs of our recommendations is critical, but so often brush it off because we want to support the underdog or satisfy our philosophical cravings. We’ve overpromised and underdelivered, leaving end users to struggle. We’ve painted Nvidia as the bad guy because it’s easy, and because we don’t like the idea of proprietary add-ons. Yet we refuse to just be honest and recognize that we can only partially deliver the wondrous and carefree experience via AMD on Linux, and that it’s just as plagued by issues as Nvidia is despite their polar-opposite approach. It’s not about Team Red or Team Green, it’s about what’s going to work for the user in need, and how that experience is going to be. It’s about not trying to force users onto other distributions to avoid addressing the real issues that exist.
Ubuntu has been working on delivering more recent kernel software with their HWE (hardware enablement) that offers newer kernel and graphics stack software to ensure that users with newer hardware aren’t left out for quite as long. This is a start, and it’s a step in the right direction for lovers of new hardware who don’t want to lose the comfort and support of their preferred distributions.
There’s still more work to be done, and while in-kernel drivers sound amazing, there’s the very real possibility that open source separate kernel module drivers are a much better approach as it harnesses the benefits of open source software and a modular approach that benefits Nvidia so much. We’ll have to see where this leads, but in the meantime, it’s worth considering that our own preferences aren’t always applicable to other users, and that it’s okay to be realistic about our recommendations even if it might not be the solution that we want.
