Hacker News Reader

Comment by andrewstuart | Hacker News Reader

The real problem is that AMD doesn't invest enough in the software.

Nvidia's Linux support absolutely puts AMD to shame.

The biggest lesson in hardware is that "it's the software support, stupid". Too many hardware manufacturers think they are selling hardware alone. They are selling hardware AND the software that makes it work.

A computer is useless without software support. Witness the vast array of essentially useless ARM devices out there because none of them have usable software drivers/Linux support.

View on HN

Nvidia's Linux support? AMD actually has open source drivers these days, just like Intel, Nvidia just gives you a binary module, which means in order to make use of that hardware you have to taint your kernel and aren't free to update it if the in-kernel ABI changes. It's basically on par with the vendors of all those "useless ARM devices out there", none of them with "usable Linux support".

AMD is finally approaching parity in the past year or two, but Nvidia is still ahead in terms of day-to-day usability. It sucks that they're closed, but if you just want to install a driver and have your system work, Nvidia is ahead.

Look at this mess: https://wiki.archlinux.org/index.php/Xorg#AMD Do you want AMDGPU, AMDGPU PRO, ATI, or Catalyst? How do you choose? Let's assume you want open source and recent, so probably AMDGPU. OK that's relatively straightforward, but now let's say you want Vulkan support. That's over here: https://wiki.archlinux.org/index.php/Vulkan#Installation and golly wouldn't you know it there are three choices, vulkan-radeon, amdvlk, and vulkan-amdgpu-pro. How do those relate to the radeon and amdgpu drivers mentioned earlier? Arrrrrrrrrrgh.

Meanwhile on nvidia, you install "nvidia" and you're done.

I've been working in gaming on Linux profesionally for ten years. If I were buying a new GPU today, I would pick nvidia.

I think you might be blinded by prior experiences (yes, that sounds illogical). The choice you have with AMD now is not bad for users, they get a working good and free driver with their distro out of the box. And people like you, who work in gaming under Linux and might use a more custom distro, can figure out which one is the best driver in your specific situation (it's AMDGPU always anyway).

I'd never buy a Nvidia card for Linux now. I wouldn't have done so three years ago, but now? That'd be a huge step backwards.

It's possible. The last time I bought an AMD GPU for my personal use was in 2009 or 2010. But I really do work with this stuff every day. In our QA lab, the AMD machines have far more problems than the Nvidia machines do. Valve's VR software works much less consistently; installing modern versions of the drivers on Ubuntu is a huge pain, you have to use 3rd party repos maintained by some random guy; missing features and driver bugs are much more common on AMD (though not unheard of on Nvidia either).

AMD is definitely getting better, and being open source is an enormous point in its favor, but it's still just less usable day-to-day for an end user. I hope this changes.

Unfortunately very few Linux people even see a point in actually using their GPU. As long as it can composite terminal emulators, they think everything is great. I've seen such reasoning in discussions about sway, where people are encouraged to throw out their $500+ GPU in favor of the on-die Intel GPU...

To be clear, I'm a gamer. The games I play would not run with Intel onboard gpus. And I'm very happy with the performance the AMD driver delivers.

> Look at this mess: https://wiki.archlinux.org/index.php/Xorg#AMD Do you want AMDGPU, AMDGPU PRO, ATI, or Catalyst? How do you choose?

You don't. Just use what your distribution uses for you. That's one less step, than

> you install "nvidia"

> If I were buying a new GPU today, I would pick nvidia.

I guess you don't mind the problem Nvidia has with Wayland.

> I guess you don't mind the problem Nvidia has with Wayland.

From my perspective of someone who dislikes Wayland, that is a feature of Nvidia's drivers :-P.

> but if you just want to install a driver and have your system work, Nvidia is ahead.

But if you want your driver to not break horribly whenever there's a xorg or kernel update, nvidia is behind

Or if you want your driver to just work 'out of the box' without needing to go out and install a binary driver nvidia is behind

Or if you want your driver to support newer technologies like DRI3 and wayland nvidia is behind

Also their OpenGL performance is abysmal. On windows isn’t not the biggest deal since everything is DX but on Linux?

...Vulkan? Proton? In terms of 3D acceleration libraries and support, its never been better on linux. I actually just switched to manjaro full-time because everything I wanted to play now works on linux, too.

Mesa drivers are fine. The one with horrid performance is their proprietary AMDGPU-PRO, but there's no reason to use it. (especially since Mesa now support GL compatibility profile)

Mesa drivers are far from fine, they only got rid of the "core only" braindead schism just last year (IIRC) and that was thanks to pressure from AMD to get games working. Even then a lot of Mesa's codepaths are downright awful.

Nvidia had OpenGL as a major focus for decades (it was even the first API to get new features introduced in their hardware via extensions - though nowadays they also seem to do the same with Vulkan) and their OpenGL implementation's quality shows.

Yes, Mesa is not perfect. (particularly annoying thing is that it is possible to lock up entire GPU by invalid memory accesses in shader, infinite loops not always recover cleanly and lock up GPU too, and these bugs are accessible through WebGL, etc.) But I prefer occasional crash in badly behaved software than abysmal performance of their proprietary implementation. (and it crashes too, usually on software using legacy pre-GL3 context).

And as to compatibility context, IMO OpenGL shouldn't have defined it at all. It is rather weird to have rendering code using both legacy fixed pipeline and modern shaders. From my experience it just causes problems everywhere, and I had encountered unexpectedly bad performance and glitches on Nvidia drivers too. (though maybe less often than on Intel/AMD)

This was an issue with the previous proprietary drivers, but the modern open source ones just use Mesa like everything else sane.

My experience with NV on Linux is out of date, from 2003-ish (?) when the binary driver was new, to 2010, but I remember a few drawbacks I couldn't overcome and happily made the switch to ATI/AMD:

1) Closed driver

2) Weird incompatible multimonitor support called twinview? Where windows would maximize to stretch across all your screens

3) Abusive on the PCI subsystem, so that my sound hardware would experience underruns, both spurious and reproducible events such as during workspace switches

4) Lockups

5) Corruption/lockups switching between FB terminals and the X terminal

I switched to ATI and the open source driver and all these problems went away.

> which means in order to make use of that hardware you have to taint your kernel and aren't free to update it if the in-kernel ABI changes.

I have difficulty placing all the blame on Nvidia here since it is the kernel developers long-held disdain for stable driver ABIs that Nvidia feels forces their hand. There are those who argue otherwise, but that argument is basically "all software should be open source". Even if we go with the more reasonable "all drivers should be open source" that still introduces problems because of bonkers patent law nonsense.

Nvidia can release an open-source kernel driver. They have just figured out that inconveniencing their customers is cheaper than paying developers.

AMD doesn’t support 8K monitors under Linux. I agree, NVIDIA has far better usability for most users. The fact that it’s a binary blob means nothing to anyone who isn’t an OSS activist.

Once again we see the unfortunate trend of downvotes used to censor unpopular opinions.

> aren't free to update it if the in-kernel ABI changes.

How often is that actually an issue? Last time I ran into that was when I was still running Debian Sid and NVIDIA was far from the only thing that ended up breaking.

I'm sorry but NVidia Linux support is really bad. I administer a few dozen machines and am really looking forward to tossing the NVidia cards into the dumpster where they belong.

NVidia Linux support has always been bad, we just didn't realize it because AMD's used to be worse. Luckily this has changed over the past few years and now we can spec in AMD or perhaps Intel's rumored Xe graphics card.

> I'm sorry but NVidia Linux support is really bad. I administer a few dozen machines and am really looking forward to tossing the NVidia cards into the dumpster where they belong.

I assume you're joking, but if not please don't junk them! I'm sure lots of people on HN would gladly pay for (at least) shipping.

Yes, it was hyperbole. The "dumpster" is an area in the office where employees can grab surplus hardware and supplies -- it'll be picked clean pretty quick if video cards show up there...

>Nvidia's Linux support absolutely puts AMD to shame.

Huh? AMD "just works". NVIDIA requires a dance of (Fedora) DKMS kernel modules and binary blobs. What am I missing? I buy AMD just because it's been frictionless to get working, I don't mind if theres a small performance penalty I pay for it.

This is repeated frequently, but I was never able to get my AMD 560 to work on Linux at 4k with MST (or turn down the fan speed). With Nvidia I installed the binary blob and 4k over MST “just worked”. I tried the amdgpu and Pro versions of the drivers.

Neither company is perfect with Linux support. As with most things, there are pros and cons to both sides. But for anyone else reading here, just because you pick AMD does not mean everything is magically trouble free on Linux.

Does MST even work 4k@60 over DP? 4k@60 requires so much bandwidth, that is uses both MST channels (it is internally handled as two monitors); if you want to use both channels separately, you are stuck with 4k@30 at most.

Yes, MST absolutely can do 4k at 60hz. This is what the first Dell 32" 4k used.

My rMBP has been able to do this since February, 2014. I was trying to get my RX 560 in mid 2018 to do this and it just was not possible via any means with Ubuntu 18.04. I ended up using an Nvidia 1040 with the binary drivers without issue. The nouveau driver for the 1040 was able to do it with a newer kernel than Ubuntu 18.04 had (I was using Arch for that test).

My rMBP is not capable of doing that; not with Dell P2715Q. It works without MST, or with lower resolutions.

Which rMBP do you have? I have the late 2013 with the dedicated Nvidia card.

13" early 2015, Intel Iris 6100.

To get two 4k@60 outputs, I have to run two cables (it has two TB2 ports). With daisy-chaining, I got mirroring at best (I didn't check refresh rate at the time, though).

I've never tried MST on AMD so I cannot comment. But of course it goes without saying that by picking NVIDIA it won't be magical and trouble free for everyone.

AMD's Linux support is terrific now. Nvidia is much more of a hassle and also impeding progress by insisting on their own window system - driver interface for Wayland.

> AMD's Linux support ist terrific now.

I think you have a typo, which unfortunately is half way between "is" and "isn't". Or your sentence is partially German.

Fixed. I'm German and this typo happens occasionally.

> Nvidia's Linux support absolutely puts AMD to shame

Is this meant seriously? Is it not the exact opposite?

I'm pretty sure neither manufacturer is really that worried about their Linux support. And, as far as my experience has gone with them both on Linux, they have both had their good years and their bad.

They are absolutely worried about Linux support. All high end computer graphics in large companies are done using Linux.

This is exactly true. Especially on CUDA and the deep learning front. Basically, only option is NVIDIA as the competition has almost nonexistent software framework (maybe OpenCL).

CUDA is a vendor lock-in scheme. Use OpenCL or Vulkan instead (yes, Vulkan includes support for compute, not just graphics!). AMD supports both, in addition to tools like HIP to help you port legacy CUDA code.

CUDA is result of being the first mover in an emerging field over a decade ago. It’s a lock in scheme the way Excel is a lock in scheme for Microsoft: a product that provides value which is used to generate revenue.

Using Vulkan(?) or OpenCL for deep learning is fine if your goal is helping get out the word that it’s at least possible to do so.

It’s not a great idea if you simply want to get your work done with a minimal amount of issues and with up to date support of all the prominent packages.

Both are valid objectives.

HIP won’t help you one bit if you use one of the many CUDA libraries.

"The prominent packages" for deep learning are all open source. If they don't support OpenCL or Vulkan yet, you can work on it and contribute the feature upstream. It's a matter of getting the ball rolling to start with, nothing more than that.

cuDNN isn’t open source.

> If they don't support OpenCL or Vulkan yet, you can work on it and contribute the feature upstream. It's a matter of getting the ball rolling to start with, nothing more than that.

And that’s exactly what I mean with the choice that you have to make.

You could do that, and win brownie points with some crowd, but let’s not pretend that doing so wouldn’t have an impact on your work as an AI researcher.

“Nothing more than that” is more than a little bit disingenuous when you take into account the actual work that involved, don’t you think?

It’s something a company like AMD could (and does?) sponsor by throwing paid employees at it. Or big companies like Alibaba who buy enough HW to trade off HW cost vs R&D spending.

But if your goal is to be a deep learning specialist (it’s where the money is today), spending time on these kind of infrastructure issues is a complete waste.

Reply on news.ycombinator.com