They are, Intel and AMD have shown that it can be done and it can be done excellently. NVIDIA just decided they do not want to be part of the solution.

Ever since, I have only bought CPU-integrated graphics (an Intel desktop and an AMD laptop for my cousin). Proud to say I have never sponsored the mandatory signed firmware devices.

The difference is that free drivers don't have access to changing the GPU frequency in newer cards. Newer means anything above NV110, that is, 900-series.

I don't know about Minecraft, but Minetest runs well for me on Nouveau, on a 7-year old i7 with a GTX 850M.

I tried RimWorld and Factorio, but they were unplayable due to I believe missing OpenGL features.

I have not tried Cities: Skylines.

It's still not as egregious as Nvidia's though, which is specifically designed as a defeat device to frustrate the use of third-party drivers. You at least don't need ME/PSP access to boot into a Free OS.

[0] ME/PSP are technically separate processors, but they have full control over the x86 cores. Their firmware can be minimized but they are integral to the boot process and enforce code signing on the BIOS. Speaking of, the BIOS gets to load into SMM, which has been around since the 386 and runs above both ring 0 and hypervisors.

It’s really interesting to see the difference between Linux and FreeBSD (which doesn’t break kernel APIs for shit and giggles). The damn Nvidia kernel module is still a bloated closed source blob, but not once in >10 years did it break. The largest problems I had with this driver under FreeBSD was after the adoption of KMS because Linux locked away the new memory management API required for efficient tearing free frame swapping behind GPL only macros resulting in massive tearing (there were workarounds like using a vsync enabled compositor adding latency and wasting enough power to cost me 30-60 min battery runtime).

This is not a Linux (or BSD) problem but purely a Nvidia Issue. After my last issue with an embedded Nvidia GPU in my motherboard (~10 years ago), I stay far away from Nvidia, I will never but anything remotely associated with Nvidia until they Open Source their drivers. I knew someone who worked there as an engineer and told him that, he just smiled with me knowing I knew it is really beyond his control.

This is 2022, we should be well beyond the point of worrying about Video Hardware in Linux/BSD.

When I used it, ironically, NVidia was the way to go on Linux and ATI/AMD was a shit show. Is AMD ok nowadays ? My needs are mostly confortable casual gaming where I don’t care having more than 60fps and I don’t play online (so this anti cheats situation doesn’t really bother me other than ideological issues).

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. .

Indeed and still nothing has changed. Last time I checked, installing a Nvidia driver crashed the whole desktop and every-time you boot you Linux distro, it gives you a black screen with X11 or Wayland pop ups.

A magnificent waste of time that was fixing things in order to do basic work. I ended up using Windows with WSL2 and waiting for the new Macbook Air. I never saw the point of dealing with anything Nvidia on Linux these days.

However, during my time at Uni I maintained over the course of a couple of month a patchset against a kernelmodule for my research, and I remember what a mess it was. Slightest kernel updates broke it, and even supporting just 1-2 distros we used in our lab was very time consuming. Even after I left I got a couple of mails from researchers whether I could assist getting it to build on newer versions of the kernel. And even though I had a fraction of funcitonality compared to what NVidia provides, I absolutely understand how difficult it is to maintain a non-upstreams patchset over time - so I definetely believe all bad I hear about nvidia on various distros/setup is 100% true. It is just NVidias fault not to go the AMD route and at least try to get as much as possible upstreamed and open source.

On a sidenote, the only reason I went with NVidia was that at the time due to crypto-hype, a competetive AMD card was 50-70% more expensive (in retail, not the manufacturer suggested price). I'd definitely would go AMD next time.

Every other driver update breaks the system in unexpected ways, Wayland wasn't supported for the longest time, switching GPUs had no support at all for quite a while and still is a bad joke compared to Windows (e.g. you have to log out and log in again to switch the graphics processor unless you use 3rd party tools).

That's almost surely your distro's fault. I used to ran Nvidia for well over a decade on Arch with zero issues, and it's far from the only distro that properly handles Nvidia drivers.

If your distro doesn't distribute an Nvidia driver on their repos and maintains it accordingly with the kernel it ships, it is not an option you can consider if you are using Nvidia.