Differences

This shows you the differences between two versions of the page.

--- linux:gpu:about [2023/08/05 10:28] – peter
+++ linux:gpu:about [2023/08/05 10:32] (current) – peter
@@ Line 9: / Line 9: @@
   * So you could say, "let us create a vendor-neutral interface for graphics so that apps can ignore the GPU-specific bits and get right to the drawing!" - which is what OpenGL is.  User-space drivers implement the OpenGL specification and expose it as an OpenGL library (libGL) to apps (like games, browsers, etc) instead of the GPU tidbits.  **Mesa** is the most popular collection of open-source user-space drivers, Nvidia has their own proprietary user-space driver for their GPUs, AMD has proprietary AMDGPU-PRO (which requires the amdgpu kernel-space driver).
-  * Mesa is a collection, because it contains a few user-space drivers for different GPU families: radeonsi for most modern AMD GPUs (and r600g, r300g and others for older ones), i915/i965 for old/new Intel GPUs and nouveau for Nvidia GPUs.  There is also Gallium, which is a bunch of utilities and common code shared among these drivers - if certain things can be done once and work everywhere (assuming the drivers follow a few rules), they will land in Gallium and benefit all the drivers.  Most Mesa drivers use Gallium (radeonsi, nouveau, software renderers), some do not (intel), basically up to the devs whenever they wanted to use it in the first place and if it was worth it.
+  * Mesa is a collection, because it contains a few user-space drivers for different GPU families: radeonsi for most modern AMD GPUs (and r600g, r300g and others for older ones), i915/i965 for old/new Intel GPUs and nouveau for Nvidia GPUs.  There is also **Gallium**, which is a bunch of utilities and common code shared among these drivers - if certain things can be done once and work everywhere (assuming the drivers follow a few rules), they will land in Gallium and benefit all the drivers.  Most Mesa drivers use Gallium (radeonsi, nouveau, software renderers), some do not (intel), basically up to the devs whenever they wanted to use it in the first place and if it was worth it.
   * That is for 3D acceleration - what about just displaying 2D windows and such?  X.org supports device-specific 2D drivers as well, but nowadays most of these are no longer needed as the modesetting can handle most hardware on its own.  As the DRM/DRI got some additional interfaces for what used to be hardware-specific (setting resolutions, refresh rates, etc) and software requiring accelerated 2D drawing was optimized to hell and back or moved to OpenGL-based renderers, 2D acceleration is slowly going away.  They are still there in xf86-something packages if you want or need them, though.
@@ Line 26: / Line 26: @@
 Out of a few interesting tidbits that come to mind:
-  * Other graphics APIs like Vulkan or Direct3D would be implemented as separate user-space drivers. (Mesa actually supports Direct3D 9 on Gallium drivers if you compile it with that option, and apps running on Wine can utilise that.)  You could also skip graphics APIs entirely and talk directly to the GPU... if you are brave enough.
+  * Other graphics APIs like **Vulkan** or **Direct3D** would be implemented as separate user-space drivers. (Mesa actually supports Direct3D 9 on Gallium drivers if you compile it with that option, and apps running on Wine can utilise that.)  You could also skip graphics APIs entirely and talk directly to the GPU... if you are brave enough.
   * This stack is actually very tightly integrated and is generally a moving target.  Various component interfaces change quite often and proprietary stacks historically have had a problem with this as they target specific component versions (often the ones available at the stack's release) and that will be it, good enough, am I right? - so many legacy mobile chip-sets with proprietary Linux drivers are pretty much MIA: the rest of the stack moved on and will not talk to older, less popular hardware despite drivers being out there.
@@ Line 32: / Line 32: @@
   * Mobile GPUs like Adrenos (built into the Qualcomm Snapdragon CPUs) and VideoCore (in Raspberry Pis, basically Broadcom CPUs) also are starting to be supported on modern open-source graphics stacks.  It is a bit hard to install regular Linux distros on most mobile devices (not in a chroot, but rather natively), so it will not matter for a while, but what used to be a strictly proprietary ground is now worked on in open projects - that is, once they are ready, they will be supported for as long as they're humanly usable and someone bothers to keep them updated, not when their manufacturers slap "EOL" on the package and call it a day.  Ancient GPUs like Voodoo still work under modern distros (that's stretching the definition of "humanly usable", but hey, it works).
-  * AMD had their own fully-proprietary driver stack (kernel + user-space components, like the current NVIDIA stack) called fglrx back in the day... haha, funny thing, let us forget about it as soon as possible because holy hell that was not good.
+  * AMD had their own fully-proprietary driver stack (kernel + user-space components, like the current NVIDIA stack) called **fglrx** back in the day... haha, funny thing, let us forget about it as soon as possible because holy hell that was not good.