3 ms·

The current title reads "Mesa 20.3 released with out-of-the-box support for [whatever GPU]" Can someone expand on why Mesa needs to "support" specific GPUs? I

The current title reads "Mesa 20.3 released with out-of-the-box support for [whatever GPU]" Can someone expand on why Mesa needs to "support" specific GPUs? I thought that supporting hardware under Linux was a kernel matter, and assumed that Mesa was an OpenGL implementation for Linux, so talking to kernel APIs in a hardware-independent way (since talking to the hardware is a kernel matter). Where am I wrong? What does "support for GPU xyz" mean in Mesa's case? Thanks.

MobiusHorizons 6y ago
My (admittedly limited) understanding is that in order to provide support for OpenGL, Mesa compiles code from OpenGL to some target backend. Mesa needs support for specific GPUs because it needs to be able to generate code that can be run on those architectures. In this way it is similar to adding support for a particular architecture in a C compiler. I believe that for open source GPU drivers, Mesa is the piece that is used to provide OpenGL support as part of that driver, whereas with proprietary drivers, OpenGL support is provided by other software. I'm sure this drastically oversimplifies the situation, so please correct / fill in what I'm missing, but I believe this will answer the OP's question.
- ronjouch 6y ago
  Thanks. So, the generated hardware-specific code emitted by Mesa is then mostly passed on intact by the kernel to the hardware?
  - LukeShu 6y ago
    Yes and no. Specifically with regard to compiling: OpenGL 2.0 introduced the "GLSL" shader language, which is a C-like language that compiles to run on specific GPUs. OpenGL has an API call that says "given this GLSL string, compile it for the current GPU", and the libGL driver compiles that string for the program at runtime. You don't compile it ahead-of-time. But also, the 3D APIs exposed by the kernel are pretty low-level, mostly just slightly abstracting over what the hardware itself exposes, essentially exposing a different API for each family of GPUs. The work of abstracting over those different low-level APIs in to a vendor-neutral API (in this case, the OpenGL API), is the job of a userspace library (in this case, libGL). (Now, 2D acceleration, the kernel does a lot more work to provide a consistent 2D API between different devices.)
    - ronjouch 6y ago
      Thanks, and thanks for the other long reply :) One thing that confuses me: we were talking about "compiled code", then your answer jumps to talking about shaders. Can all OpenGL code be represented as shaders? Or is the OpenGL code needing hardware-specific compilation shaders only? When the above poster said that Mesa "compiles code from OpenGL to some target backend", were they referring to shaders already? Said differently: if I import a C GL lib and use it to make a call to draw a triangle, is this a shader, and will Mesa do any hardware-specific compilation? Or is this compilation only happening when shaders are involved? I guess I'm confused about what shaders exactly are, and when they are used. I think I understand them as programs able to fiddle at each frame with how stuff (surface, pixels) is rendered, but for example, geometry (putting triangles in space) is OpenGL's job even though it isn't about shaders, is it? By the way, do you (or other passerbys) have courses recommendations to study this? (ideally interactive / tutorial-like / with exercises)
      - raphlinus 6y ago
        This is a pretty deep topic. The best resource I've found is: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... I'll also do my best to answer your questions, though I won't be able to do them justice in this space. A pretty good model for GPUs is remote procedure calls. When you want to do something like draw some triangles, you call a function in the GL API on the client side, and what the driver actually does under the hood is serialize the parameters of that call into some binary sequence, then at some point that "command buffer" is uploaded to the GPU, and a combination of hardware and software on the GPU side decodes it and uses it to set up the hardware pipeline that actually draws a triangle. There's a lot more to it than that, obviously. A very big deal is that if you did an actual RPC for every triangle draw, it would be hopelessly inefficient. So a large part of what OpenGL drivers do is use heuristics for batching up a bunch of calls into one actual request. In OpenGL, the details of that batching, and the way the command buffer is encoded, are completely hidden from the application. Shaders are basically small pieces of code that get run on the GPU hardware as part of the rendering pipeline. A vertex shader is a program that gets run every vertex in a mesh, and a fragment shader is another program that gets run for every fragment (pixel) that gets rasterized. There are other shaders that are run for other tasks, but those are the two biggies. In the early days of OpenGL, lighting calculations and so on were done by "fixed function" hardware, but these days it's programmable. In classic OpenGL, you call a function to compile a shader from a string containing GLSL source code, and the driver compiles it to machine language for the GPU hardware. You can use Radeon Shader Analyzer (available online at http://shader-playground.timjones.io/ http://shader-playground.timjones.io/) to see what that assembly language looks like. Even just to understand OpenGL better, it might make sense to learn about Vulkan. A good (though somewhat daunting) resource is "API without Secrets: Introduction to Vulkan": https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-1.html https://software.intel.com/content/www/us/en/develop/article... . In Vulkan, the batching and other aspects of resource management are much more explicit and under control of the application, though other details are still abstracted by the driver. For example, there is no one standard binary format for encoding command lists. Also, instead of the driver compiling shaders all the way from source, the application is responsible for compiling the shader into an intermediate language (SPIR-V), then the driver compiles that to the actual GPU machine language. There are some other low level GPU resources here: https://raphlinus.github.io/gpu/2020/02/12/gpu-resources.html https://raphlinus.github.io/gpu/2020/02/12/gpu-resources.htm... Best of luck, I find GPUs to be a fascinating journey!
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 ago
  Your 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.
deleted 6y ago
[deleted]

MobiusHorizons 6y ago

My (admittedly limited) understanding is that in order to provide support for OpenGL, Mesa compiles code from OpenGL to some target backend. Mesa needs support for specific GPUs because it needs to be able to generate code that can be run on those architectures. In this way it is similar to adding support for a particular architecture in a C compiler. I believe that for open source GPU drivers, Mesa is the piece that is used to provide OpenGL support as part of that driver, whereas with proprietary drivers, OpenGL support is provided by other software. I'm sure this drastically oversimplifies the situation, so please correct / fill in what I'm missing, but I believe this will answer the OP's question.

ronjouch 6y ago
Thanks. So, the generated hardware-specific code emitted by Mesa is then mostly passed on intact by the kernel to the hardware?
- LukeShu 6y ago
  Yes and no. Specifically with regard to compiling: OpenGL 2.0 introduced the "GLSL" shader language, which is a C-like language that compiles to run on specific GPUs. OpenGL has an API call that says "given this GLSL string, compile it for the current GPU", and the libGL driver compiles that string for the program at runtime. You don't compile it ahead-of-time. But also, the 3D APIs exposed by the kernel are pretty low-level, mostly just slightly abstracting over what the hardware itself exposes, essentially exposing a different API for each family of GPUs. The work of abstracting over those different low-level APIs in to a vendor-neutral API (in this case, the OpenGL API), is the job of a userspace library (in this case, libGL). (Now, 2D acceleration, the kernel does a lot more work to provide a consistent 2D API between different devices.)
  - ronjouch 6y ago
    Thanks, and thanks for the other long reply :) One thing that confuses me: we were talking about "compiled code", then your answer jumps to talking about shaders. Can all OpenGL code be represented as shaders? Or is the OpenGL code needing hardware-specific compilation shaders only? When the above poster said that Mesa "compiles code from OpenGL to some target backend", were they referring to shaders already? Said differently: if I import a C GL lib and use it to make a call to draw a triangle, is this a shader, and will Mesa do any hardware-specific compilation? Or is this compilation only happening when shaders are involved? I guess I'm confused about what shaders exactly are, and when they are used. I think I understand them as programs able to fiddle at each frame with how stuff (surface, pixels) is rendered, but for example, geometry (putting triangles in space) is OpenGL's job even though it isn't about shaders, is it? By the way, do you (or other passerbys) have courses recommendations to study this? (ideally interactive / tutorial-like / with exercises)
    - raphlinus 6y ago
      This is a pretty deep topic. The best resource I've found is: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... I'll also do my best to answer your questions, though I won't be able to do them justice in this space. A pretty good model for GPUs is remote procedure calls. When you want to do something like draw some triangles, you call a function in the GL API on the client side, and what the driver actually does under the hood is serialize the parameters of that call into some binary sequence, then at some point that "command buffer" is uploaded to the GPU, and a combination of hardware and software on the GPU side decodes it and uses it to set up the hardware pipeline that actually draws a triangle. There's a lot more to it than that, obviously. A very big deal is that if you did an actual RPC for every triangle draw, it would be hopelessly inefficient. So a large part of what OpenGL drivers do is use heuristics for batching up a bunch of calls into one actual request. In OpenGL, the details of that batching, and the way the command buffer is encoded, are completely hidden from the application. Shaders are basically small pieces of code that get run on the GPU hardware as part of the rendering pipeline. A vertex shader is a program that gets run every vertex in a mesh, and a fragment shader is another program that gets run for every fragment (pixel) that gets rasterized. There are other shaders that are run for other tasks, but those are the two biggies. In the early days of OpenGL, lighting calculations and so on were done by "fixed function" hardware, but these days it's programmable. In classic OpenGL, you call a function to compile a shader from a string containing GLSL source code, and the driver compiles it to machine language for the GPU hardware. You can use Radeon Shader Analyzer (available online at http://shader-playground.timjones.io/ http://shader-playground.timjones.io/) to see what that assembly language looks like. Even just to understand OpenGL better, it might make sense to learn about Vulkan. A good (though somewhat daunting) resource is "API without Secrets: Introduction to Vulkan": https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-1.html https://software.intel.com/content/www/us/en/develop/article... . In Vulkan, the batching and other aspects of resource management are much more explicit and under control of the application, though other details are still abstracted by the driver. For example, there is no one standard binary format for encoding command lists. Also, instead of the driver compiling shaders all the way from source, the application is responsible for compiling the shader into an intermediate language (SPIR-V), then the driver compiles that to the actual GPU machine language. There are some other low level GPU resources here: https://raphlinus.github.io/gpu/2020/02/12/gpu-resources.html https://raphlinus.github.io/gpu/2020/02/12/gpu-resources.htm... Best of luck, I find GPUs to be a fascinating journey!

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

deleted 6y ago

[deleted]