I'm about to buy a high-end Radeon card myself, gambling that AMD is serious about this and will get it right, and that it won't be a wasted purchase. So yeah, if I seem like an AMD fan-boy (I am, somewhat) at least I'm putting my money where my mouth is. :-)
AMD’s software stacks for each class of product are separate: ROCm (short for Radeon Open Compute platform) targets its Instinct data center GPU lines (and, soon, its Radeon consumer GPUs),
They've been saying this for a while, and I'm encouraged by reports that people "out there" in the wild have actually gotten this to work with some cards, even in advance of the official support shipping. So here's hoping they are really serious about this point and make this real.
Wayland and many things outside of GPGPU are much better; ie: power control/gating/monitoring are all available over sysfs. You can over/underclock a fleet of systems with traditional config management.
GPGPU surely deserves some weight given the context of the thread, but let's not ignore the warts Nvidia shows elsewhere.
It feels great finally having bleeding edge kernels and Wayland compositors, with the guarantee of a Linux or Windows VM’s stable driver if something breaks for the NVIDIA blob, and my desktop stays operational regardless.
The vast majority of my experience has been with discrete (desktop) cards and very new kernels/mesa. It's been great, here - on a number of hardware configs.
I gave Linux/the ecosystem at large a chance with a couple of those and was generally disappointed.
No good way to be sure which card was used... the control mechanism was a bunch of glue/tape.
I've been burned by enough laptops with mobile cards that I just stick with integrated; Linux does/did so poorly with Optimus or whatever dual high/low power GPU tech that I never bought another.
I'm a little doubtful, largely because AMD contributes to the kernel/mesa far more than Nvidia. There's no Linux monolith to support this; not all distributions are equally current.
I've had discrete cards from all of the major vendors for the last few generations for VFIO testing on Linux on mainline kernels.
Intel/AMD have generally been more reliable (for me) and quicker to adopt standards.
If you run an LTS or something with generally older software, Nvidia is probably fine and dandy.
It's a regular routine to have to wait for them to support new kernels. Yes, I know about DKMS, no it isn't always sufficient.
It seems like that on paper, but in practice I've been getting constant GPU crashes and freezes on both my personal and work pc. No one seems to know what this is about and may be multiple issues, but it's been like this for a long time now.
https://gitlab.freedesktop.org/drm/amd/-/issues/1974#note_21...
I've had the exact opposite experience; from way back since the 4870 series was common to now with RX6000, AMD has been great for me with Linux. More systems than I can really count, Intel/AMD have been great - while Nvidia, not so much.
Most recently I've not used the 'auto' method of DPM (mentioned in that issue).
I've deliberately set this to 'manual' since at least picking up RX6000 for undervolting/overclocking. Perhaps this is part of why I've been so pleased.
I'm curious on the software levels you run - what distributions do you tend to prefer?
Eg I can write my cuda code with my 3090s, my boss can test it on his laptop's discrete graphics, and then after that we can take the time to bring it to our V100s and A100s and nothing really has to change.
But if AMD really wants a market impact - which is what this submission is about - getting good support across a decent range of consumer GPUs is absolutely required. They cannot win this ecosystem battle with only datacenter mindshare.
I keep close & cherish a small hope that for some use-cases we might get a soft virtualization-alike that just works. I don't know enough to say how likely this is to adequately work, but in automotive & some other places there are nested Waylands, designed to share hardware. You still need a shared OS layer, a shared kernel, and a compositor that manages all the subdesktops - this isn't full virtualization - but hypothetically you get something very similar to virtualized/VDI gpus, if you can handle the constraints.
This is really a huge huge huge shift that Wayland has potentially enabled, by actually using kernel resources like DMA-BUFs and what not, where apps can just allocate whatever & pass the compositor filehandles to the bufs. Wayland is ground up, unlike X's top down. So it's just a matter of writing compositors smart enough to push what data from whom needs to get rendered and sent out where.
I would love to know more about what hardware virtualization really buys, know more about the limitations of what VDI is possible in software. But my hope is, in not too long, there's good enough VDI infrastructure that it's basically moot whether a gpu has hardware support. There will be some use cases where yes every users needs to run their own kernel & OS, and that won't be supported (albeit virtio might workaround even that quite effectively), but for 95% of use cases the more modern software stack might make this a non-issue. And at that point, these companies might stop having such expensive-ass product segmentation, charging 3x as much to have a couple hardware virtual devices, since in fact it costs them essentially nothing & the software virtualization is so competitive.