>because of better Linux support
In my experience nvidia has better Linux support. Just look at how many projects are using Linux and cuda and don't support AMD.
In my experience nvidia has better Linux support. Just look at how many projects are using Linux and cuda and don't support AMD.
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.
How do you know this is an NVIDIA issue, as opposed to a Wayland or wlroots issue?
Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.
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.
>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.
Also, xserver used to work with nvidia cards due to goddamn proprietary binary patching done by drivers.
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.
Just for reference, what setup are you using? (Linux kernel, drivers, GPU, etc.)
https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
From the repo readme[1], "GeForce and Workstation support is still considered alpha-quality."
Hopefully now that AMD has money they can afford the headcount to fix their bugs and some more headcount to make up for 15 years of lost time in the applications that matter. Hopefully. But I trusted them twice and got burned, so this time I need to see proof before I jump. I need to see blender renders, I need to see torch trainings, I need to see NAMD (or insert science code here) running on a compatibility layer. It is unfortunate that the actual compatibility situation seems to have hardly moved at all in 10 years (it was right around the corner in 2013 too, you see) but the fundamentals are different now so I hold out hope.
OpenCL1.2 worked fine for all the test code I made for myself. But OpenCL 2.0 was... horrid. Unworkable.
--------
My next step personally is to give DirectX 12 computer shaders a serious try. A lot of people are also talking about Vulkan shaders, as apparently that works well on Linux too.
ROCm on Linux is fine enough. But this weirdness of having a feature on ROCm Windows (when ROCm Windows isn't even public yet?) is well... weird. I guess its cool that AMD has worked with the Windows team to get everything squared up, but it'd be nice if ROCm on Windows were available to the masses.
That's because of the CUDA api specifically.
For the display support it's very hit/miss. Somethings work fine, then you want to try Wayland and things get odd...
When working correctly they Nvidia is mostly fine - Xorg games have support for everything except dlss3 AFAIK.
No, if they wanted to support AMD they would provide an alternative GPU implementation that worked on their. It's like saying an app only supports Windows because of the Windows API. If someone wanted to support multiple apps they wouldn't just use the Windows API.
AMD's implementation (ROCm) has historically been incredibly difficult to work with. As in their own examples won't compile.
Historically if you even wanted to _touch_ data-science you had to have CUDA hardware/software (it's been improving a bit but alternatives are still lacking).
> It's like saying an app only supports Windows because of the Windows API.
It's a little more nuanced than that because the CUDA api is specifically for one set of tasks - data science.
Nobody uses nvidia for their wide desktop support on linux - because it's terrible. Literally the only benefit of using nvidia + linux is either because of raw performance of the hardware and/or the cuda support. If you look at the arch wiki (applies to other OSes too) for anything graphics related you'll almost always seen specific sections dedicated to workarounds and fixes for nvidia hardware.
If you don't believe me then try setting up wayland with nvidia drivers. Steam just had a fun issue where they were crashing on nvidia hardware with their latest redesign (no idea how they didn't catch that?!). These types of issues are commonplace, and are largely avoided by using AMD.
thus why I say it's only really because of the cuda support.
Nvidia handled it ok.