We're hiring!

Opening up Mali T720

Alyssa Rosenzweig avatar

Alyssa Rosenzweig
December 20, 2019

Share this post:

Reading time:

Panfrost, Lima, and Arm developers together in Montreal during XDC 2019. From left to right: Lyude Paul (Panfrost), Ryan Houdek (Panfrost), Tomeu Vizoso (Panfrost, Collabora), Alyssa Rosenzweig (Panfrost, Collabora), John Einar Reitan (Arm), Rohan Garg (Panfrost, Collabora), Boris Brezillon (Panfrost, Collabora), Erico Nunes (Lima), Connor Abbott (Lima, Panfrost), Rob Herring (Panfrost)

If you have a device with a Mali T720 or T820 GPU, you’re in luck – your device is now supported in upstream Mesa at feature parity with other GPUs. Get out your Allwinner H6 or Amlogic S912 board, grab the latest Mesa, and enjoy a match of SuperTuxKart with fully free and open source mainline drivers!

When Panfrost began, we focused on the highest performance Mali GPUs found in Chromebooks. By contrast, Mali GPUs like T720 are designed for simplicity, where minimizing size is more important than maximizing performance.

Simplicity for the hardware, that is. For us, those changes mean new complexity – but we’re up to the challenge. Over the past month, Collaboran Tomeu Vizoso and I reverse-engineered the Mali T720 and adapted Panfrost for the new devices.

Much of our work focused on the tiler. As I blogged about over the summer, Mali GPUs are “tiling” architectures, meaning they divide the screen into many small “tiles” or “bins” and operate on those smaller sections of the screen to save memory bandwidth and improve power efficiency. The fastest Mali architectures use “hierarchical tiling”, where many different sizes of tiles are used at once. But this tiler is simplified, with no support for hierarchical tiling. Instead, the driver selects a single tile size used for the entire screen; the new model requires new driver changes. Fortunately after my work on hierarchical tiling over the summer, we were able to figure out the non-hierarchical tiler and then implement our findings in Panfrost with ease.

On the compiler side, these GPUs feature another simplification. Most instruction sets, including Midgard, are based on “registers”, where data can be written and read for computation. On Midgard, there are three types of registers: work registers, load/store registers, and texture registers. Work registers are general purpose, used for arithmetic. Load/store registers and texture registers, however, are special, used with load/store and texture instructions respectively. On most Mali chips, there are three separate sets of registers for each of the three types. But the simplified GPUs are a bit special, diffusing the texture registers into the work and load/store register spaces – a surprising and rather confusing discovery at first. Nevertheless, once we understood this unique phenomenon known as “interpipe register aliasing”, we were able to modify our compiler accordingly, fixing assorted issues relating to textures.

One final focus area surrounded Mali’s framebuffer descriptors. OpenGL features “multiple render target” support, allowing an app to render to different render targets (surfaces) at once, useful for effects like deferred shading. Mali GPUs support this feature in hardware since Mali T760, via the “multiple framebuffer descriptor”. Nevertheless, earlier Mali GPUs do not support this feature in hardware, instead emulating support in software. These GPUs use the simplified “single framebuffer descriptor”. We improved support for handling these simplified descriptors, reverse-engineering and integrating features like transaction elimination. As a bonus, this work also benefits anyone with T6xx GPUs.

With these improvements and many other minor features and bug fixes, we brought T720 and T820 up to feature parity with our existing boards, and added these into our continuous integration infrastructure to ensure Panfrost continues to work beautifully. Panfrost is now ready for daily use on Mali GPUs from T720 to T860. All of the source code is upstream… so happy hacking :-)

Comments (4)

  1. Kokowawa:
    Dec 23, 2019 at 06:34 AM

    Thank you very mu h guys for this work, you made my day :)

    Reply to this comment

    Reply to this comment

  2. Jonathan:
    Dec 27, 2019 at 05:57 PM

    Thanks so much for your incredible work in getting open-source support for Mali GPUs,

    Do you know if chromium or any browser with graphical hardware acceleration is supported using the latest version of Mesa on T820 gpus ?

    Reply to this comment

    Reply to this comment

  3. josh:
    Jan 17, 2020 at 11:01 PM

    amazing work! this news makes me optimistic about things like the the pinebook pro (rk3399). with these developments, that hardware is looking very attractive

    Reply to this comment

    Reply to this comment

  4. Jacques:
    Feb 28, 2020 at 05:53 PM

    Thanks for all the hard work!

    Would it be possible to summarise the required kernel version and/or patches that are required for relatively stable T720 support? Kernel 5.5.0 seems pretty unstable, especially when it comes to textures. I know Boris posted quite a few related kernel patches, but I don't know which ones are required. I don't think they have been merged into 5.6 yet, have they?

    Let me know if you would need any logs to pinpoint issues.


    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

Re-converging control flow on NVIDIA GPUs - What went wrong, and how we fixed it


While I managed to land support for two extensions, implementing control flow re-convergence in NVK did not go as planned. This is the story…

Automatic regression handling and reporting for the Linux Kernel


In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…

Almost a fully open-source boot chain for Rockchip's RK3588!


Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…

What's the latest with WirePlumber?


Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…

DRM-CI: A GitLab-CI pipeline for Linux kernel testing


Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…

Persian Rug, Part 4 - The limitations of proxies


This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…

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-2024. All rights reserved. Privacy Notice. Sitemap.