37 ms·
The kernel mediates access to the GPU, isolating between processes, but it doesn't abstract over them very much to provide a uniform API for wildly different GP
by LukeShu 6y ago
The kernel mediates access to the GPU, isolating between processes, but it doesn't abstract over them very much to provide a uniform API for wildly different GPUs. The kernel exposes more-or-less the low-level API of the GPU chip itself. So, an application that wants to use the GPU without tying itself to a specific GPU will use the OpenGL API/ABI, and link against libGL, and then when installing drivers you'd install the appropriate libGL for whichever graphics card you have, and libGL would implement OpenGL on top of the low-level API exposed by the in-kernel driver for that GPU. (The assumption that most platforms will work this way, not just the Linux kernel, is baked in to the spec of OpenGL.)
On Windows (at least back in the days when I was kinda familiar with Windows), that's pretty much how it really worked: when you installed the drivers for your GPU, a large part of that was just it plopping in its own libGL. A growing part of libGL is actually hardware-neutral OpenGL-related code, and most hardware vendors hold their libGL close to their chest because they're competing on optimizing the hardware-neutral OpenGL code in their libGLs almost as much as they're competing on actual hardware. But in the FOSS world, where the code isn't a secret, all that hardware-neutral OpenGL code can actually be shared between the libGLs for different GPUs, so we've ended up with pretty much just one libGL that supports all the GPUs: Mesa. So Mesa is both the graphics card driver and the hardware-neutral part of OpenGL.
Now, as much as I would like it to be, GNU/Linux isn't just the "FOSS world", we still have proprietary things here: For many years you had to choose between Mesa or your hardware vendor's proprietary libGL, most notably NVIDIA's. Eventually NVIDIA realized that it was problematic to ask users to remove Mesa, especially with the growing occurrence of multi-GPU systems. So NVIDIA coordinated with Mesa to create libglvnd (lib GL vendor neutral dispatch), which can be the libGL, but is thin shim that will dispatch to the "real" libGL implementation (NVIDIA's or Mesa's) as appropriate, so that they can be installed side-by-side.
- atq2119 6y agoYour statement about how the kernel only mediates access to the GPU is exactly right. GPU drivers have long followed an "exokernel" approach: the kernel just ensures that access to the hardware is multiplexed with enforced security boundaries, everything else -- the actual abstracting over hardware differences -- is done by userspace libraries. It's somewhat amusing to me that the people who discuss exokernels rarely talk about GPUs, even though that's the one area of computing where exokernel ideas are universally deployed today.