The only complaint I had with NVidia was that a long time ago I had one of the first consumer-grade 4k displays, and it exposed itself as 2 1920x2160 displays. That all worked ... "great". X thought the monitor was two displays, and so anything that cares about the calculation of display boundaries (say, full screen video), didn't work correctly; it would just show on half the monitor. One day I found that a config parsing bug could cause the xrandr extension to be disabled while keeping everything else working, and then full screen worked. (The options to just lie to xrandr or disable it were of course broken, which is why bugs interacting with bugs was the fix. They never fixed the bugs or the bugged bugs, so shrug I guess.) It took me months of pulling out my hair to find that workaround, and having used X since before xrandr was invented it drove me crazy. In a past life, I also pulled out all my hair to get xrandr to work. It never fucking worked. And then the one time you don't want it to work, it works and can't be made not to work. Argh!!! Just send me back to 2000 please!

(Since then I've switched to Windows, and I still have that monitor. It works perfectly under Windows. You wouldn't even know that it uses the hacky Displayport MST stuff. Probably have a nice hack hard-coded right into the driver, and if it doesn't activate for some reason, you're completely screwed.)

I've heard AMD's drivers are OK these days but haven't tried them myself because I care about ML.

They are OK but with some caveats like VP9 HW decode not being available in Linux AMD iGPU drivers for reasons, which won't be a problem if you're running an AMD desktop tower PC, but if you're gonna watch Youtube on your AMD laptop, your battery will take a hit along with possible extra fan noise, which is unacceptable for a great media content consumption experience in Linux when even no-name Android phones and tablets have VP9 HW decode in Youtube out of the box. No bueno.

This is such a mess, as VP9 & AV1 HW video decode is not an issue under linux for Intel iGPUs, but AMD seems to not give a shit to expose VP9 decode on linux for their iGPUs. Also, unlike with Intel iGPUs, under linux, radeon-top does not show GPU decode usage for easy diagnostic purposes. I assume it's because AMD bought the video codec engine IP from some third party fabless IP vendor and they don't have the permission to open source the drivers for the video engine block as part of the licensing agreement, like they do for their in house developed GPU block. But still, regardless of the reason, it sucks for the linux end-users.

And another important issue nobody seems to talk about but one should be aware of, AMD APUs (at least to 5000 series) don't have unified memory between CPU and iGPU like Intel and Apple do, so you have to configure in your laptop BIOS how much of your system RAM you want allocated to your iGPU (512MB/1GB/2GB/4GB), with the rest remaining for the CPU. This sucks big time if you're switching between productivity where you need more memory for applications, and playing video games where you need as much memory as possible for the GPU, so you need to keep rebooting and changing in the BIOS the amount of memory you allocate to your iGPU, vs on Intel chips where the whole system memory is unified and shared dynamically between the CPU and iGPU, and it boils my blood as the whole marketing gimmick of AMD's APUs was the seamless merger between CPU and GPU resources together, while in practice their (5000 series) APUs are just a Ryzen CPU with a Vega GPU glued on the same die without them actually sharing any of the resources properly. Maybe the new 6000 series with RDNA2 changed that but I couldn't find any detailed info.

Honestly, as a laptop owner with AMD APU, if you're planning to go Linux, just get one with an Intel chip instead. Much less head aches as Intel Linux drivers and apps are second to none and have a unified memory model.

The performance and efficiency of AMD APUs is still great though, especially under Windows, but the overall implementation as a whole package seems poorly thought out and rushed out the door, especially under Linux compared to Intel.

VP9 should be available since Mesa 18.1 (or so) for VCN-based GPUs (i.e. Raven Ridge and newer). VP9 is not supported in hardware on UVD-based GPUs (i.e. discrete Vega).

VCN 3.0-based GPUs (i.e. RDNA2, the 6000-series APUs) also support AV1 decoding.

Yeah, in theory it's available, but good luck actually getting your browser to use it to HW decode YouTube videos under linux out of the box.

It usually works fine with video players like mplayer but not in browsers.

There are endless threads online about this not working. I for one, never managed to get it to work in any browser. What a mess.

Chrome doesn't support VA-API, so do not bother trying.

Some distributions do have Chromium builds with VA-API support enabled, but YMMV. Chromium uses X11 only and libva requires dri2, so it doesn't work under XWayland, which supports only dri3. (=> Chromium with VA-API works only in native X11 session)

Firefox does support VA-API. There was a period of time, when it did only under Wayland, but nowadays both X11 and Wayland should work. When running under Wayland, use the native version and /not/ via XWayland, because the same thing as with Chromium applies.

On the Firefox side, Redhat and Suse people did the work to support video acceleration.

Seamlessly sharing memory between the two chips works fine with the compute toolchain (rocm), I don't know how transparent it is for games.

Maybe in ROCM, but not in generic Windows and Linux apps and video games that I've tried. They all cap out at whatever you set in BIOS for the iGPU VRAM reservation and don't go beyond that into system RAM. If ROCM has this ability how come AMD's driver, at least in Windows, doesn't do this memory overflow thing for VRAM hungry apps like video games, as that would certainly alleviate this issue.

IMHO, still a worse implementation than the unified model of Intel. Having a large chunk of memory constantly blocked for a HW component, regardless if it's currently needed or not is just horribly inefficient, especially when you're on a mobile device and have 16GB of RAM or less to play with.

Disappointing.

Linux has no issue with drivers and/or video cards in particular, people just need to pay some attention when buying components, saying that linux has issues with graphics because of nvidia it's a bit unfair, nouveau is not able to use acceleration because the videocard doesn't activate it if it isn't loaded by the official nvidia blob, so if linux is supposed to have issues with graphic card while vendors actively create obstacles, we will never figure the real issue and hold the right people accountable: It's nvidia that has still issues with linux

The AMD drivers runs fine. They're functionally inferior to the Nvidia ones (in several aspects), but I had no big problems. I don't play on Linux, though.

I think open source makes a significant the difference - with Nvidia, issues often can't be solved by software devs (e.g. Libreoffice Calc running updating the screen very slowly). I suppose that with open source drivers, devs can at least get an idea of what's going on.

However, there's one dealbreaker with Nvidia - they have such "blob of a cards", that Linux, on a default configuration (which means, ISO with Nouveau) can't run at all with many Nvidia card series. I couldn't even boot with a GT 1030 (among the others).

I actually have no idea how people can install Linux on Nvidia systems, since I had to create an adhoc iso with the binary drivers preinstalled.

To this day I cannot think of a good reason to ship nouveau outside of "lets make users with nvidia cards suffer". I get the idea behind the nouveau project, but pushing an experimental driver that cannot work with 99% of the hardware it latches onto and forces users to disable it if they want a basic working system is actively malicious.

is it feature complete ? no, but to go ahead and say it's not working for 99% is just lying here is the list: https://nouveau.freedesktop.org/FeatureMatrix.html

what you can say though is that it is a bad idea for GPU that are relatively recent. wont block you from booting or displaying to screen but would probably be slow.

also this is distro dependent, I remember being given the choice with no default one (mean chosen automatically) when installing Manjaro (a derivative of arch linux).

I chose the proprietary driver since they are feature complete but later switched to nouveau driver since they are not prone to breaking on every other update. that was 2 years ago, zero problems since.

since it doesn't do CUDA either, nouveau is useless to me. next Linux build I'll either use Intel or AMD, but can't economically do ML on AMD still.

It isn't that hard to write a manual. It isn't that hard to respect user freedom to use tge device they purchased. It isn't that hard to just leave well enough alone.

But no.... Nvidia just couldn't.

Meanwhile the company responsible for the biggest security issues in the last decade still provides its CPU microcode as signed binary blob and the FLOS community is fine with that because someone at the FSF drew a random line to stand on. I will accept the FLOS communities hatred of NVIDIA the moment it stops bending over backward for the company that brought us Meltdown, Spectre, RowHammer (who needs consumer grade ECC anyway), etc. .