They were referencing a time, in the middle of the 2010's, when "amdgpu" was released. It is a completely rewritten, different driver, and is mostly open source [0]. Before that, the driver was named "radeon" and it was very shaky. I can speak to this personally. I had desktop Linux systems with both AMD/ATI and Nvidia GPUs, and while there were some issues with Nvidia, the AMD/ATI drivers gave me nightmares.
Once the rewritten "amdgpu" driver came out, things got much better. The first few cards created after that (IIRC the Polaris GPUs, RX 400's), the situation reversed. I still have had occasional issues with various Nvidia cards (normally driver updates breaking things), but for almost a decade now, I have not had issues with AMD GPUs under Linux.
[0] Except for pro features while using workstation cards. You need to use a proprietary driver for those, but even those share a lot of code with the open source driver.
You have this largely right, but I need to defend the Radeon driver a bit here. The driver that caused all the problems was the proprietary fglrx driver, not the open source Radeon driver. The issue with the Radeon driver wasn’t stability, it was that it was 2d acceleration only.
And with that release, my ASUS 1215B was downgraded from OpenGL 4.1 into OpenGL 3.3, it took several years for the open source driver to catch up in features to the old closed source driver, and when it finally did, my netbook was at the end of its life.
Ah and hardware video decoding never ever worked again.
So much for the so called advantages of an open source driver.
AMDgpu is the driver for newer GPUs, radeon is for the older GPUs. This is like circa 7 or 10 years ago.
So it is both driver changes and architectural changes.
There is also AMDGPU-PRO, which is the proprietary version based on AMDGPU. Used to be you'd need it for ROCm, but that hasn't been true for a while not. There really isn't any reason to use the "pro" version anymore, unless you have a some special proprietary app that requires it.
Open source GPU drivers are based on Mesa stack. So they share a common code base and support for things like Vulkan.
So it is sorta similar to how DirectX works. With old-school OpenGL drivers each stack was proprietary to the GPU manufacturer so there was lots of quirks and extensions that applied to only one or another GPU. That is one of the reasons DirectX displaced OpenGL in gaming... Microsoft 'owned' DirectX/Direct3d stack.
Well the open source equivalent to that is Mesa. Mesa provides APi support in software and it is then ported to each GPU with "dri drivers".
For gaming things have improved tremendously with "Proton", which is essentially Wine with vastly improved Direct3D support.
This is accomplished with "DXVK", which is a Direct3D to Vulkan translator.
This way Linux essentially gets close to "native windows speed" for most games that support proton in one way or another.
Which means that most games run on Linux now. Probably over 75% that are available on Steam, although "running" doesn't mean it is perfect.
One of the biggest problems faced with Linux gaming nowadays is anti-cheat features for competitive online games. Most of the software anti-piracy and anti-cheating features games use can technically work on Linux, but it is really up to the game manufacturer to make it work and support it. Linux gamers can sometimes make it work, but also they get flagged and booted and even accounts locked for being suspected of cheating.
It's a completely different driver for a different architecture. The biggest reason it works so much better is that it's open source (with some blobs, of course) and part of the mainline kernel, unlike its predecessor which was developed downstream and fully proprietary.
amdgpu replaced both the in-kernel open-source "radeon" driver, which was already open source, and the proprietary "fglrx" driver.
But the user-space portions are probably more significant for performance than the kernel drivers. Here we have:
- r300 and r600 (open source OpenGL backend for older hardware, sits on top of the radeon kernel driver, not much development happening)
- radeonsi (open source OpenGL backend for newer hardware, sits on top of either the radeon or amdgpu kernel drivers depending on hardware version and kernel configuration)
- fglrx (closed source OpenGL driver on top of the fglrx kernel driver, both obsolete now)
- radv (open source Vulkan driver on top of amdgpu)
- amgpu-pro (closed source Vulkan driver on top of amdgpu) - not sure if there is also still a proprietary OpenGL driver but if there is no one should care since radeonsi works well enough
- amdvlk (open source dumps of amdgpu-pro without proprietary shader compiler on top of amdgpu)
Then you have different shader compilers which also significantly affect both shader compile time and runtime performance:
- internal compiler used by r600
- LLVM (used by radeonsi and amdvlk)
- ACO (used by radv and possibly radeonsi these days)
- AMD's proprietary compiler (used by fglrx and amdgpu-pro)
And for X.org you also have different display drivers (fglrx, radeon, modesetting).
chao-|6 months ago
Once the rewritten "amdgpu" driver came out, things got much better. The first few cards created after that (IIRC the Polaris GPUs, RX 400's), the situation reversed. I still have had occasional issues with various Nvidia cards (normally driver updates breaking things), but for almost a decade now, I have not had issues with AMD GPUs under Linux.
[0] Except for pro features while using workstation cards. You need to use a proprietary driver for those, but even those share a lot of code with the open source driver.
trws|6 months ago
microtonal|6 months ago
Even Sea Islands/Southern Islands were much better with amdgpu (but you have to use a module parameter to enable support).
pjmlp|6 months ago
Ah and hardware video decoding never ever worked again.
So much for the so called advantages of an open source driver.
bsimpson|6 months ago
lotharcable|6 months ago
So it is both driver changes and architectural changes.
There is also AMDGPU-PRO, which is the proprietary version based on AMDGPU. Used to be you'd need it for ROCm, but that hasn't been true for a while not. There really isn't any reason to use the "pro" version anymore, unless you have a some special proprietary app that requires it.
Open source GPU drivers are based on Mesa stack. So they share a common code base and support for things like Vulkan.
So it is sorta similar to how DirectX works. With old-school OpenGL drivers each stack was proprietary to the GPU manufacturer so there was lots of quirks and extensions that applied to only one or another GPU. That is one of the reasons DirectX displaced OpenGL in gaming... Microsoft 'owned' DirectX/Direct3d stack.
Well the open source equivalent to that is Mesa. Mesa provides APi support in software and it is then ported to each GPU with "dri drivers".
For gaming things have improved tremendously with "Proton", which is essentially Wine with vastly improved Direct3D support.
This is accomplished with "DXVK", which is a Direct3D to Vulkan translator.
This way Linux essentially gets close to "native windows speed" for most games that support proton in one way or another.
Which means that most games run on Linux now. Probably over 75% that are available on Steam, although "running" doesn't mean it is perfect.
One of the biggest problems faced with Linux gaming nowadays is anti-cheat features for competitive online games. Most of the software anti-piracy and anti-cheating features games use can technically work on Linux, but it is really up to the game manufacturer to make it work and support it. Linux gamers can sometimes make it work, but also they get flagged and booted and even accounts locked for being suspected of cheating.
rnhmjoj|6 months ago
account42|6 months ago
But the user-space portions are probably more significant for performance than the kernel drivers. Here we have:
- r300 and r600 (open source OpenGL backend for older hardware, sits on top of the radeon kernel driver, not much development happening)
- radeonsi (open source OpenGL backend for newer hardware, sits on top of either the radeon or amdgpu kernel drivers depending on hardware version and kernel configuration)
- fglrx (closed source OpenGL driver on top of the fglrx kernel driver, both obsolete now)
- radv (open source Vulkan driver on top of amdgpu)
- amgpu-pro (closed source Vulkan driver on top of amdgpu) - not sure if there is also still a proprietary OpenGL driver but if there is no one should care since radeonsi works well enough
- amdvlk (open source dumps of amdgpu-pro without proprietary shader compiler on top of amdgpu)
Then you have different shader compilers which also significantly affect both shader compile time and runtime performance:
- internal compiler used by r600
- LLVM (used by radeonsi and amdvlk)
- ACO (used by radv and possibly radeonsi these days)
- AMD's proprietary compiler (used by fglrx and amdgpu-pro)
And for X.org you also have different display drivers (fglrx, radeon, modesetting).