4 ms·

NVIDIA cards have better Linux support roughly up until you connect a display output to the machine. AMD's issues are more general and not really a particular

by jchw 3y ago

NVIDIA cards have better Linux support roughly up until you connect a display output to the machine. AMD's issues are more general and not really a particular problem with their Linux support: they're spotty in general (bad drivers on card release, spotty OS support a la no ROCm on Windows.) In practice it obviously matters if you still can't get the features you need, but in my experience trying to run a modern Linux desktop setup with NVIDIA cards is absolutely second-class at this point. I tried my hand at it with a 2060 and the card was out of the machine in a month so I could have a stable desktop that actually resumed from sleep properly again. Granted, issues like that are very much case-by-case. Still; I can't even run SwayWM with NVIDIA as I do with AMD and Intel; even with patches to "fix" the flickering issues, XWayland stuff is broken. This makes no sense of course. It shouldn't need to be a snowflake case.

nsajko 3y ago
> I can't even run SwayWM with NVIDIA as I do with AMD and Intel How do you know this is an NVIDIA issue, as opposed to a Wayland or wlroots issue?
- bombela 3y ago
  Same experience here. I get 4k 120hz over HDMI with my puny AMD laptop embedded GPU without tearing on Wayland. Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.
- jchw 3y ago
  Wayland does not contain any NVIDIA defeat devices, and neither does SwayWM. They just use standard Linux GPU interfaces. What I do know is that you can't use the same codepaths you'd use with countless other GPUs, again including AMD and Intel: NVIDIA cards need special cases. This is just as true for KDE and GNOME, which also do not work as well with NVIDIA under Wayland, despite having special codepaths for NVIDIA cards specifically. This issue isn't new either. In fact, until very recently, it was significantly worse. But progress on NVIDIA's end has been slow, it seemingly gets completely stalled for years at a time. On the other hand, Nouveau works quite well with Wayland compositors if your card is well-supported, AND you never have to wait on a kernel upgrade because NVIDIA's shim hasn't been updated yet. There's basically exactly one driver that works this way. It's not a hardware problem, it's not a general GPU issue. There's just one thing it could be.
- chlorion 3y ago
  This is from a maintainer of wlroots: >Maintainer of sway and wlroots here. The Nvidia proprietary driver does not support sway, not the other way around. >Their standard, EGLStreams, is only implemented by their proprietary drivers, so in order to test that codepath we'd have to use a famously broken and undebuggable driver, which we're not interested in - and make no mistake, we get our hands dirty in the drivers all the time. Their standard also has serious technical problems - lots of really important features simply are not possible to implement based on the proprietary driver. We can't export buffers to clients, overlay planes don't work, buffer presentation timings are impossible... Supporting this driver would be a massive overhaul and would probably make the good drivers worse. https://news.ycombinator.com/item?id=21628494 https://news.ycombinator.com/item?id=21628494
  - jchw 3y ago
    To be fair, they did actually abandon EGLStreams. It took far too long, but it did happen.
- kaba0 3y ago
  Because wlroots and most Wayland implementations strictly use the kernel abstractions for buffer management, nothing else. They run on literally anything that supports linux’s abstractions, but nvidia drivers did not (it changed recently, not sure about its current state). Also, xserver used to work with nvidia cards due to goddamn proprietary binary patching done by drivers.
deleted 3y ago
[deleted]
kaetemi 3y ago
So safest to put both an AMD card in for display, and an Nvidia card for compute?
- jchw 3y ago
  Actually, this might not really be that bad of an idea. Certainly for headless CUDA, it has a lot of potential to be useful. That said, in practice I expect this to suck. There's probably a lot of stuff in the Linux desktop stack that does not deal with heterogeneous graphics cards well right now.
charcircuit 3y ago
I have had no issues resuming from sleep on my 2000 series card.

by jchw 3y ago

nsajko 3y ago

> I can't even run SwayWM with NVIDIA as I do with AMD and Intel How do you know this is an NVIDIA issue, as opposed to a Wayland or wlroots issue?

bombela 3y ago
Same experience here. I get 4k 120hz over HDMI with my puny AMD laptop embedded GPU without tearing on Wayland. Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.
jchw 3y ago
Wayland does not contain any NVIDIA defeat devices, and neither does SwayWM. They just use standard Linux GPU interfaces. What I do know is that you can't use the same codepaths you'd use with countless other GPUs, again including AMD and Intel: NVIDIA cards need special cases. This is just as true for KDE and GNOME, which also do not work as well with NVIDIA under Wayland, despite having special codepaths for NVIDIA cards specifically. This issue isn't new either. In fact, until very recently, it was significantly worse. But progress on NVIDIA's end has been slow, it seemingly gets completely stalled for years at a time. On the other hand, Nouveau works quite well with Wayland compositors if your card is well-supported, AND you never have to wait on a kernel upgrade because NVIDIA's shim hasn't been updated yet. There's basically exactly one driver that works this way. It's not a hardware problem, it's not a general GPU issue. There's just one thing it could be.
chlorion 3y ago
This is from a maintainer of wlroots: >Maintainer of sway and wlroots here. The Nvidia proprietary driver does not support sway, not the other way around. >Their standard, EGLStreams, is only implemented by their proprietary drivers, so in order to test that codepath we'd have to use a famously broken and undebuggable driver, which we're not interested in - and make no mistake, we get our hands dirty in the drivers all the time. Their standard also has serious technical problems - lots of really important features simply are not possible to implement based on the proprietary driver. We can't export buffers to clients, overlay planes don't work, buffer presentation timings are impossible... Supporting this driver would be a massive overhaul and would probably make the good drivers worse. https://news.ycombinator.com/item?id=21628494 https://news.ycombinator.com/item?id=21628494
- jchw 3y ago
  To be fair, they did actually abandon EGLStreams. It took far too long, but it did happen.
kaba0 3y ago
Because wlroots and most Wayland implementations strictly use the kernel abstractions for buffer management, nothing else. They run on literally anything that supports linux’s abstractions, but nvidia drivers did not (it changed recently, not sure about its current state). Also, xserver used to work with nvidia cards due to goddamn proprietary binary patching done by drivers.

deleted 3y ago

[deleted]

kaetemi 3y ago

So safest to put both an AMD card in for display, and an Nvidia card for compute?

jchw 3y ago
Actually, this might not really be that bad of an idea. Certainly for headless CUDA, it has a lot of potential to be useful. That said, in practice I expect this to suck. There's probably a lot of stuff in the Linux desktop stack that does not deal with heterogeneous graphics cards well right now.

charcircuit 3y ago

I have had no issues resuming from sleep on my 2000 series card.