8 ms·

Open Source OpenGL ES 3.1 on Mali GPUs with Panfrost

126 points by CameronNemo 5y ago

pabs3 5y ago
It feels like we now have open drivers (at some stage of the development process) for all the relevant GPUs that are sold today, are there any still missing? Even the Apple M1 GPU has reverse engineering work being done on it.
- slezyr 5y ago
  Yes, but not a single open-source driver can make a render with Blender 3D.
  - robert_foss 5y ago
    I assume that's because Blender uses OpenCL? I think a lot of progress is being made on that front.
    - Kelteseth 5y ago
      Well, they just removed in entirely... https://code.blender.org/2021/04/cycles-x/ https://code.blender.org/2021/04/cycles-x/ > Deprecation As part of the new architecture, we are removing some functionality. Most notably: OpenCL rendering kernels. The combination of the limited Cycles split kernel implementation, driver bugs, and stalled OpenCL standard has made maintenance too difficult. We can only make the kinds of bigger changes we are working on now by starting from a clean slate.
      - Doxin 5y ago
        Note that they are not removing GPU rendering. Just the OpenCL kernels. They'll still have NVIDIA and AMD kernels. As long as the open source drivers keep working towards supporting the required features those will eventually work on them.
        slezyr 5y ago
        > They'll still have ... and AMD kernels. Do they? Blender uses OpenCL implementation for AMD GPUs.
        Doxin 5y ago
        Oh did I misremember that? It has been a hot minute since I last owned an AMD card. Apologies for the misinformation.
      - zozbot234 5y ago
        Vulkan Compute shaders (or GLSL compute shaders, if supported by the OpenGL version) should be quite a bit more robust than OpenCL kernels. The main issue w/ shaders compared to OpenCL kernels is some missing features in the former, that will have to be optionally supported via standard extensions. The programming model is also quite different, so code will have to be rewritten.
        0-_-0 5y ago
        Do you know what the missing features are? I'm very interested, I'm rewriting code from ocl to vulkan.
        zozbot234 5y ago
        See https://news.ycombinator.com/item?id=27396634 https://news.ycombinator.com/item?id=27396634 for a basic intro, but IIRC the main differences involved are (1) support for general pointers in OpenCL, whereas data indirection in compute shaders involves varying levels of messiness, and (2) OpenCL introduces support for some mathematical functions, that is not in Vulkan Compute. (However, note that OpenCL 3.0 has also made many features optional, so the basic featureset may be more comparable as a result.)
        gspr 5y ago
        I'll piggyback on your comment for a question: I only very recently started getting into the basic of GPGPU coding. I hate vendor lock in, so I started out with OpenCL. I had a good time, but I do understand that more and more of non-CUDA world (however small that may be) is moving away from OpenCL. What are they moving to? Where should one direct one's "compute learning energy" (if one already excludes CUDA or other proprietary solutions)?
        fsloth 5y ago
        Not OP, but: Unfortunately you need to pick a platform and target that. Which API you use depends on the platform. DirectX, OpenGL, Vulkan and Metal all have compute capability. So, I think you need to abstract your code at the services level, and provide an implementations for each platform you need to support (the number may be 1 or more than 1). I think you need to direct your "compute learning" energy at the algorithm level. Numerics and all that. The GPU API:s are just the obtuse implementation detail, but not the meat of the thing.
  - mappu 5y ago
    The default renderer Eevee is a GPU-only renderer that works fine on my RX 570 with the FOSS amdgpu driver. You can also run Cycles' CUDA backend with ROCm on amdgpu (somewhat..).
    - slezyr 5y ago
      > The default renderer Eevee is a GPU-only renderer that works fine on my RX 570 with the FOSS amdgpu driver. However, you need Cycles, and not Eevee. They have very significant difference in quality. https://all3dp.com/2/blender-render-from-eevee-simply-explained/ https://all3dp.com/2/blender-render-from-eevee-simply-explai... > You can also run Cycles' CUDA backend with ROCm on amdgpu (somewhat..). No. No. No, you can't. They support only some GPUs !!!AND CPUs!!!. No support for RX 5xxx-6xxx XT. They are very picky about the hardware they support. https://github.com/ROCm/ROCm.github.io/blob/master/hardware.md https://github.com/ROCm/ROCm.github.io/blob/master/hardware.... https://github.com/ROCm/ROCm.github.io/blob/master/hardware.md https://github.com/ROCm/ROCm.github.io/blob/master/hardware....
      - zamadatix 5y ago
        570 is in that list so it seems they can?
ncmncm 5y ago
This is such great work! All praise to Alyssa R. (and to whoever else she credits).
- Aissen 5y ago
  If I might add: kudos to Collabora, and its customers who were crazy enough to fund this.
flakiness 5y ago
The opaque, undocumented nature of mobile GPU is outstanding (not in a good sense). Intel CPUs are well document both by their documentation or by third party docs (like Patterson-Hennessy.) Although NVIDIA is less document than these CPUs, there are some well-written whitepapers including one for academic conferences. And these are the basis for the textbook coverage. Compared to that, ARM or Qualcomm GPUs are totally a blackbox. I'd love to learn the specifics of mobile GPUs but there is no clue. I wonder how Collabora folks have figure out the instruction set architecture and other details.
- nix23 5y ago
  I really wished that Intel and AMD took a leading role in ARM, things would be so much more open in the mobile space.
  - qwertox 5y ago
    Interesting point of view, this sounds plausible.
  - pjmlp 5y ago
    As if they don't have their own commercial agenda, like having used PowerVR SGX545 on their CPUs.
    - nix23 5y ago
      Ah yeah the cheap atom-intel way...
  - CameronNemo 5y ago
    Intel and AMD, which have entirely closed source coprocessors on their chips.
    - nix23 5y ago
      But not drivers. >entirely closed source coprocessors on their chips Like every single Arm chip?
someperson 5y ago
I found this interesting YouTube talk from a few months ago titled "Open drivers for Arm GPUs" from the author of this article: https://www.youtube.com/watch?v=ZYCGVzkSIpg&list=PLZjq3una5SrBQ4J1erd88Cs3cA0GvUY4W&index=2 https://www.youtube.com/watch?v=ZYCGVzkSIpg&list=PLZjq3una5S... The key thing about open-source drivers is they retain compatibility with newer Linux kernels, and receive bug fixes and improvements long after the original vendor has lost interest. This reduces e-waste and allows system integrators (like Google with Chromebooks) to easily maintain their hardware far longer than Broadcom, Qualcomm and ARM itself ever would. It's great that shipping open-source drivers over the proprietary one is fast becoming the norm not the outlier. And this change is not because of hippie free software ideals, but because of cold-hearted business reasons.
- IntelMiner 5y ago
  I was surprised to find a while back that Google's now ancient "Nexus 7" tablet is allegedly able to run a mainline Linux kernel! Unfortunately the one I built and "flashed" to it never booted and I lack the soldering skills to build the modified headphone connector/serial TTL cable thing it needs, so it sits in my drawer unused I really wish we could get to a better upstream ecosystem with ARM devices but it just never seems to happen
  - rjsw 5y ago
    Is the headphone/serial cable the same as those used on Pine64 products ? You may be able to buy one for fairly low cost.
  - megous 5y ago
    You don't need soldering skills, just by a jack with screws. https://www.aliexpress.com/item/10000133366659.html https://www.aliexpress.com/item/10000133366659.html
- rjsw 5y ago
  Is Broadcom bad at this ? I thought the VC4 (RPi) DRM code was officially supported by them.
rjsw 5y ago
It would be nice if the Panfrost DRM code could be dual licenced like the Lima stuff.
deleted 5y ago
[deleted]
ece 5y ago
This really makes Samsung Exynos chips with Mali GPUs appealing for Linux use, and hopefully when Exynos with RDNA2 comes out, support will be great there as well. I'm not really seeing Mali GPUs and unlocked bootloader phone options in the US (other than the PinePhone), but I'll have to look more another time. Thanks Collabora! edit: The Dimensity SoCs also have Mali GPUs, but no US phones options as far as I can see.. https://www.anandtech.com/show/16436/mediatek-announces-dimensity-1100-1200-socs-a78-on-6nm https://www.anandtech.com/show/16436/mediatek-announces-dime...

126 points by CameronNemo 5y ago

It feels like we now have open drivers (at some stage of the development process) for all the relevant GPUs that are sold today, are there any still missing? Even the Apple M1 GPU has reverse engineering work being done on it.

slezyr 5y ago
Yes, but not a single open-source driver can make a render with Blender 3D.
- robert_foss 5y ago
  I assume that's because Blender uses OpenCL? I think a lot of progress is being made on that front.
  - Kelteseth 5y ago
    Well, they just removed in entirely... https://code.blender.org/2021/04/cycles-x/ https://code.blender.org/2021/04/cycles-x/ > Deprecation As part of the new architecture, we are removing some functionality. Most notably: OpenCL rendering kernels. The combination of the limited Cycles split kernel implementation, driver bugs, and stalled OpenCL standard has made maintenance too difficult. We can only make the kinds of bigger changes we are working on now by starting from a clean slate.
    - Doxin 5y ago
      Note that they are not removing GPU rendering. Just the OpenCL kernels. They'll still have NVIDIA and AMD kernels. As long as the open source drivers keep working towards supporting the required features those will eventually work on them.
      - slezyr 5y ago
        > They'll still have ... and AMD kernels. Do they? Blender uses OpenCL implementation for AMD GPUs.
        Doxin 5y ago
        Oh did I misremember that? It has been a hot minute since I last owned an AMD card. Apologies for the misinformation.
    - zozbot234 5y ago
      Vulkan Compute shaders (or GLSL compute shaders, if supported by the OpenGL version) should be quite a bit more robust than OpenCL kernels. The main issue w/ shaders compared to OpenCL kernels is some missing features in the former, that will have to be optionally supported via standard extensions. The programming model is also quite different, so code will have to be rewritten.
      - 0-_-0 5y ago
        Do you know what the missing features are? I'm very interested, I'm rewriting code from ocl to vulkan.
        zozbot234 5y ago
        See https://news.ycombinator.com/item?id=27396634 https://news.ycombinator.com/item?id=27396634 for a basic intro, but IIRC the main differences involved are (1) support for general pointers in OpenCL, whereas data indirection in compute shaders involves varying levels of messiness, and (2) OpenCL introduces support for some mathematical functions, that is not in Vulkan Compute. (However, note that OpenCL 3.0 has also made many features optional, so the basic featureset may be more comparable as a result.)
      - gspr 5y ago
        I'll piggyback on your comment for a question: I only very recently started getting into the basic of GPGPU coding. I hate vendor lock in, so I started out with OpenCL. I had a good time, but I do understand that more and more of non-CUDA world (however small that may be) is moving away from OpenCL. What are they moving to? Where should one direct one's "compute learning energy" (if one already excludes CUDA or other proprietary solutions)?
        fsloth 5y ago
        Not OP, but: Unfortunately you need to pick a platform and target that. Which API you use depends on the platform. DirectX, OpenGL, Vulkan and Metal all have compute capability. So, I think you need to abstract your code at the services level, and provide an implementations for each platform you need to support (the number may be 1 or more than 1). I think you need to direct your "compute learning" energy at the algorithm level. Numerics and all that. The GPU API:s are just the obtuse implementation detail, but not the meat of the thing.
- mappu 5y ago
  The default renderer Eevee is a GPU-only renderer that works fine on my RX 570 with the FOSS amdgpu driver. You can also run Cycles' CUDA backend with ROCm on amdgpu (somewhat..).
  - slezyr 5y ago
    > The default renderer Eevee is a GPU-only renderer that works fine on my RX 570 with the FOSS amdgpu driver. However, you need Cycles, and not Eevee. They have very significant difference in quality. https://all3dp.com/2/blender-render-from-eevee-simply-explained/ https://all3dp.com/2/blender-render-from-eevee-simply-explai... > You can also run Cycles' CUDA backend with ROCm on amdgpu (somewhat..). No. No. No, you can't. They support only some GPUs !!!AND CPUs!!!. No support for RX 5xxx-6xxx XT. They are very picky about the hardware they support. https://github.com/ROCm/ROCm.github.io/blob/master/hardware.md https://github.com/ROCm/ROCm.github.io/blob/master/hardware.... https://github.com/ROCm/ROCm.github.io/blob/master/hardware.md https://github.com/ROCm/ROCm.github.io/blob/master/hardware....
    - zamadatix 5y ago
      570 is in that list so it seems they can?

ncmncm 5y ago

This is such great work! All praise to Alyssa R. (and to whoever else she credits).

Aissen 5y ago
If I might add: kudos to Collabora, and its customers who were crazy enough to fund this.

flakiness 5y ago

The opaque, undocumented nature of mobile GPU is outstanding (not in a good sense). Intel CPUs are well document both by their documentation or by third party docs (like Patterson-Hennessy.) Although NVIDIA is less document than these CPUs, there are some well-written whitepapers including one for academic conferences. And these are the basis for the textbook coverage. Compared to that, ARM or Qualcomm GPUs are totally a blackbox. I'd love to learn the specifics of mobile GPUs but there is no clue. I wonder how Collabora folks have figure out the instruction set architecture and other details.

nix23 5y ago
I really wished that Intel and AMD took a leading role in ARM, things would be so much more open in the mobile space.
- qwertox 5y ago
  Interesting point of view, this sounds plausible.
- pjmlp 5y ago
  As if they don't have their own commercial agenda, like having used PowerVR SGX545 on their CPUs.
  - nix23 5y ago
    Ah yeah the cheap atom-intel way...
- CameronNemo 5y ago
  Intel and AMD, which have entirely closed source coprocessors on their chips.
  - nix23 5y ago
    But not drivers. >entirely closed source coprocessors on their chips Like every single Arm chip?

someperson 5y ago

I found this interesting YouTube talk from a few months ago titled "Open drivers for Arm GPUs" from the author of this article: https://www.youtube.com/watch?v=ZYCGVzkSIpg&list=PLZjq3una5SrBQ4J1erd88Cs3cA0GvUY4W&index=2 https://www.youtube.com/watch?v=ZYCGVzkSIpg&list=PLZjq3una5S... The key thing about open-source drivers is they retain compatibility with newer Linux kernels, and receive bug fixes and improvements long after the original vendor has lost interest. This reduces e-waste and allows system integrators (like Google with Chromebooks) to easily maintain their hardware far longer than Broadcom, Qualcomm and ARM itself ever would. It's great that shipping open-source drivers over the proprietary one is fast becoming the norm not the outlier. And this change is not because of hippie free software ideals, but because of cold-hearted business reasons.

IntelMiner 5y ago
I was surprised to find a while back that Google's now ancient "Nexus 7" tablet is allegedly able to run a mainline Linux kernel! Unfortunately the one I built and "flashed" to it never booted and I lack the soldering skills to build the modified headphone connector/serial TTL cable thing it needs, so it sits in my drawer unused I really wish we could get to a better upstream ecosystem with ARM devices but it just never seems to happen
- rjsw 5y ago
  Is the headphone/serial cable the same as those used on Pine64 products ? You may be able to buy one for fairly low cost.
- megous 5y ago
  You don't need soldering skills, just by a jack with screws. https://www.aliexpress.com/item/10000133366659.html https://www.aliexpress.com/item/10000133366659.html
rjsw 5y ago
Is Broadcom bad at this ? I thought the VC4 (RPi) DRM code was officially supported by them.

rjsw 5y ago

It would be nice if the Panfrost DRM code could be dual licenced like the Lima stuff.

deleted 5y ago

[deleted]

ece 5y ago

This really makes Samsung Exynos chips with Mali GPUs appealing for Linux use, and hopefully when Exynos with RDNA2 comes out, support will be great there as well. I'm not really seeing Mali GPUs and unlocked bootloader phone options in the US (other than the PinePhone), but I'll have to look more another time. Thanks Collabora! edit: The Dimensity SoCs also have Mali GPUs, but no US phones options as far as I can see.. https://www.anandtech.com/show/16436/mediatek-announces-dimensity-1100-1200-socs-a78-on-6nm https://www.anandtech.com/show/16436/mediatek-announces-dime...