We're hiring!

An overview of the Panfrost driver

Robert Foss avatar

Robert Foss
March 13, 2019

Share this post:

During the past few months significant progress has been made on the Open Source Arm Mali GPU driver front, culminating in the Panfrost driver targeting Mali T and G-series of GPUs being available now.

Arm driver timeline

The process of reverse engineering Arm GPUs has been going on for a long time, starting with Luc Verhaegens work on the low-end Mali 2/3/400 series of GPUs based on the Arm Utgard family of GPUs.

This driver has recently seen a lot new attention and is itself progressing quickly, which means it will be soon accepted in the kernel. A piece of trivia is that this GPU architecture was what Arm received when they purchased the Norwegian GPU IP vendor Falanx Microsystems.

The Mali T and G-series of GPUs are based on the Midgard and Bifrost architectures respectively, both of which are quite different from the 2/3/400 series. However the T and G-series are somewhat similar at least when it comes to the way a driver can be built for them. This is why the Panfrost driver is aiming to support both architectures with one driver.

At Embedded World 2019 Collabora demoed the Panfrost driver running kmscube (video below, on the right). The singleboard computer used was a Radxa Rock Pi 4, which was generously sent to us by Tom Cubie.

Panfrost currently runs simple 3D applications like kmscube, the Wayland based Weston desktop and even more complex 3D benchmarks like glmark2.

This is still a new driver and it is in heavy development currently.

Current status

There are two semi-parallel parts under development currently; the new kernel driver and the Mesa userspace driver.

Current status of the Panfrost driver

The new kernel driver is intended to replace the Open Source driver that Arm provides for its Mali GPUs (mali_kbase). Up until recently the Mesa Panfrost has been used with a shim between the Arm kernel driver and the userspace driver. While the Arm kernel driver exists, it cannot accepted into the upstream Linux kernel project for multiple reasons, but most importantly it doesn't expose the DRM API that userspace expects of modern GPU drivers in the kernel.

As for the Panfrost Mesa driver, this driver is under heavy development and is seeing fixes, improvements to the compiler and new features added at a rapid pace. This driver is being built on top of the common Gallium driver framework in Mesa, which means that it will be relatively easy to move features from other drivers to the Panfrost driver.

Additionally the Panfrost driver uses the NIR intermediate representation (IR) for its compiler, which is the most common and most modern IR that Mesa implements. This again means that new and upcoming features like OpenCL for example, will be portable from the other Gallium/NIR drivers to Panfrost.


These drivers are community drivers, but have been spearheaded by Alyssa Rosenzweig, Lyude Paul, Connor Abott, Rob Herring and Collabora's very own Tomeu Vizoso.

I would also like to thank Tom Cubie for sending out Rock Pi 4 boards to not just me, but the wider Panfrost development community.

Visit Robert's blog.

Comments (11)

  1. Semepe Maple:
    Mar 28, 2019 at 12:03 AM

    Great work! Does panfrost support the Mali G76 MP12 GPU?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Mar 28, 2019 at 08:56 AM

      Hey Semepe,

      I haven't personally tested Panfrost on Mali G76, but it is one of the
      targets of the driver.
      Currently the Bifrost (G-XX) series of GPUs are not quite as well
      supported as the Midgard (T-XXX) ones.


      Reply to this comment

      Reply to this comment

      1. Semepe Maple:
        Mar 28, 2019 at 02:56 PM

        Good to know, thanks.
        What's ARM position when it comes to having an opensource (but reverse engineered) driver in mainline? I understand you guys work very close with them, so I'm curious about how that conversation is developing, if any.

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Mar 28, 2019 at 04:50 PM

          I don't really know what the ARM position is, but some vendors do choose to start contributing once an Open Source driver has been made available.

          Reply to this comment

          Reply to this comment

          1. Semepe:
            Mar 28, 2019 at 06:04 PM

            Yeah, definitely. What's your estimate as for when this should be hitting mainline? Also, are there any RFCs or patchsets out there on the mailing lists already?

            Reply to this comment

            Reply to this comment

            1. Robert Foss:
              Mar 28, 2019 at 06:41 PM

              The only estimate I can give you for the kernel driver is soon-ish, an RFC has been sent out to the kernel mailing list.

              Reply to this comment

              Reply to this comment

  2. Michal Lazo:
    Apr 02, 2019 at 01:39 PM

    I would like to see working gnome shell in middle of this year :)
    weston is working.
    what about mutter ?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 02, 2019 at 02:41 PM


      I would think running mutter can't be that far away.
      A post related to that was written by Alyssa yesterday.



      Reply to this comment

      Reply to this comment

      1. MICHAL LAZO:
        Apr 02, 2019 at 05:16 PM

        I read that blog post.
        I really miss old Panfrost gitlab. so All related discussion was on one place.
        What do you use now for coordinating Panfrost development?

        thx for all work

        Reply to this comment

        Reply to this comment

  3. Pietre:
    Sep 23, 2019 at 12:36 PM

    Hi, I like the blog and I think your work is incredible, I hope you keep improving, I have a question, would this driver work without problems in allwinner or another SoC manufacturer? To make it work properly, it would be necessary to define it in the device tree with the following documentation ???: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpu/arm%2Cmali-midgard.txt a hug from Spain

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Sep 23, 2019 at 06:04 PM

      Yeah, a DT entry would be needed. As for which SOCs you can use it with, the Mali-TXXX series of GPUs are the ones that a targeted at the moment.

      Reply to this comment

      Reply to this comment

Add a Comment

Allowed tags: <b><i><br>Add a new comment:

Search the newsroom

Latest Blog Posts

Mainline Linux gains accelerated video decoding for Microchip's SAMA5D4


The Hantro Video4Linux2 (V4L2) kernel module has gained support for another SoC! The Microchip SAMA5D4 features a single decode unit supporting…

Quick hack: Patching kernel modules using DKMS


DKMS is a framework that is mostly used to build and install external kernel modules. It can also be used to install a specific patch to…

Build your own application with GTK 4 as a Meson subproject!


Building GTK 4 as a Meson subproject for your own application is not only useful for Windows builds, but also for many Linux distributions…

Profiling virtualized GPU acceleration with Perfetto


Recently, we have been using Perfetto to successfully profile Apitrace traces in crosvm through VirGL renderer. We have now added perfetto…

Continuous 3D Hand Pose Tracking using Machine Learning & Monado OpenXR


As part of a project backed by INVEST-AI, a program managed by IVADO Labs, we have developed a multi-stage neural network-based solution…

An easy to use MTP implementation for your next embedded Linux project


Did you know you could run a permissively-licensed MTP implementation with minimal dependencies on an embedded device? Here's a step-by-step…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2021. All rights reserved. Privacy Notice. Sitemap.

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.