5 ms·

Mesa 20.3 released with out-of-the-box support for Arm's Mali Bifrost GPUs

143 points by mfilion 6y ago

desine 6y ago
A big release grows bigger. Personally, I was excited about Mesa 20.3 because Vulkan meets baseline conformance on the Raspberry Pi: https://www.raspberrypi.org/blog/vulkan-update-were-conformant/ https://www.raspberrypi.org/blog/vulkan-update-were-conforma...
robert_foss 6y ago
Mesa has been growing into a powerhouse of an open source project, much along the lines of the Linux Kernel.
CameronNemo 6y ago
One of the Bifrost GPUs supported is the G52, which is going to appear on the upcoming Rockchip RK3566 SoC. Pine64 has said about this SoC: "Next year you will see us introduce two single board computers based on the RK3566" and "it is our choice for NON-Pro PINE64 devices to come" I am really looking forward to these SBCs! Should be cool (although a PINE64 rep has also said "Also, realistically, I think that it will be 2-3 years before mainline is usable in a desktop application on the RK3566."). Source: https://www.pine64.org/2020/11/15/november-update-kde-pinephone-ce-and-a-peek-into-the-future/ https://www.pine64.org/2020/11/15/november-update-kde-pineph...
- k_sze 6y ago
  I'm really looking forward to 8GB of RAM. 4GB feels pretty anemic nowadays when you know that Firefox or Chrome will happily eat up the RAM with a moderate number JavaScript-laden tabs open.
ronjouch 6y ago
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)
FloatArtifact 6y ago
Without complete vertical integration this is what makes me wonder about fracturing of software ecosystems each time a new SOC is released. If Google can't avoid it how can Microsoft and other platforms sidestep it as well besides throwing tremendous amounts of resources. No matter what the developer will have to consistently update for these changes for their software to be compatible correct? This is one of the reasons why x86 is still a great platform for backwards compatibility.
- Ericson2314 6y ago
  Well, this is always been the problem with graphics. The situation with Mesa is not perfect, but strictly better than it used to be.
- wmf 6y ago
  Windows is easy because it's a non-modifiable binary image. You build a computer that either runs stock Windows or it doesn't run Windows at all. Your UEFI has to provide boot support for all the stuff in your SoC and you also have to provide WHQL drivers.
raphlinus 6y ago
I'm interested in using this to test piet-gpu on single board computers, as I think having super performant 2D graphics on low-ish end hardware is interesting. Lazy HN: does this support Vulkan 1.2? Descriptor indexing? Memory model? Subgroup size control? Will it work on a Pine RockPro64? If so, what's the least-hassle way to get up-to-date drivers? If someone is interested in helping get piet-gpu running on the hardware, let me know.
- CameronNemo 6y ago
  The rockpro64 is midgard, not bifrost. Its been supported for quite a while. Edit: I see you are specifically asking about vulkan. I don't think vulkan is supported in panfrost right now. Just OpenGL.

143 points by mfilion 6y ago

A big release grows bigger. Personally, I was excited about Mesa 20.3 because Vulkan meets baseline conformance on the Raspberry Pi: https://www.raspberrypi.org/blog/vulkan-update-were-conformant/ https://www.raspberrypi.org/blog/vulkan-update-were-conforma...

robert_foss 6y ago

Mesa has been growing into a powerhouse of an open source project, much along the lines of the Linux Kernel.

CameronNemo 6y ago

One of the Bifrost GPUs supported is the G52, which is going to appear on the upcoming Rockchip RK3566 SoC. Pine64 has said about this SoC: "Next year you will see us introduce two single board computers based on the RK3566" and "it is our choice for NON-Pro PINE64 devices to come" I am really looking forward to these SBCs! Should be cool (although a PINE64 rep has also said "Also, realistically, I think that it will be 2-3 years before mainline is usable in a desktop application on the RK3566."). Source: https://www.pine64.org/2020/11/15/november-update-kde-pinephone-ce-and-a-peek-into-the-future/ https://www.pine64.org/2020/11/15/november-update-kde-pineph...

k_sze 6y ago
I'm really looking forward to 8GB of RAM. 4GB feels pretty anemic nowadays when you know that Firefox or Chrome will happily eat up the RAM with a moderate number JavaScript-laden tabs open.

ronjouch 6y ago

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)

FloatArtifact 6y ago

Without complete vertical integration this is what makes me wonder about fracturing of software ecosystems each time a new SOC is released. If Google can't avoid it how can Microsoft and other platforms sidestep it as well besides throwing tremendous amounts of resources. No matter what the developer will have to consistently update for these changes for their software to be compatible correct? This is one of the reasons why x86 is still a great platform for backwards compatibility.

Ericson2314 6y ago
Well, this is always been the problem with graphics. The situation with Mesa is not perfect, but strictly better than it used to be.
wmf 6y ago
Windows is easy because it's a non-modifiable binary image. You build a computer that either runs stock Windows or it doesn't run Windows at all. Your UEFI has to provide boot support for all the stuff in your SoC and you also have to provide WHQL drivers.

raphlinus 6y ago

I'm interested in using this to test piet-gpu on single board computers, as I think having super performant 2D graphics on low-ish end hardware is interesting. Lazy HN: does this support Vulkan 1.2? Descriptor indexing? Memory model? Subgroup size control? Will it work on a Pine RockPro64? If so, what's the least-hassle way to get up-to-date drivers? If someone is interested in helping get piet-gpu running on the hardware, let me know.

CameronNemo 6y ago
The rockpro64 is midgard, not bifrost. Its been supported for quite a while. Edit: I see you are specifically asking about vulkan. I don't think vulkan is supported in panfrost right now. Just OpenGL.