We're hiring!
*

GNOME meets Panfrost

Alyssa Rosenzweig avatar

Alyssa Rosenzweig
June 26, 2019

Share this post:

Reading time:

In my last Panfrost blog post, I announced my internship goal: improve Panfrost to run GNOME3. GNOME is a popular Linux desktop making heavy use of OpenGL; to use GNOME with only free and open source software on a machine with Mali graphics, Panfrost is necessary.

Two months ahead of schedule, here I am, drafting this blog post from GNOME on my laptop running Panfrost!

Screenshot of GNOME with Panfrost.

A tiled architecture

Bring-up of GNOME required improving the driver's robustness and performance, focused on Mali's tiled architecture. Typically found in mobile devices, tiling GPU architectures divide the screen into many small tiles, like a kitchen floor, rendering each tile separately. This allows for unique optimizations but also poses unique challenges.

One natural question is: how big should tiles be? If the tiles are too big, there's no point to tiling, but if the tiles are too small, the GPU will repeat unnecessary work. Mali offers a hybrid answer: allow lots of different sizes! Mali's technique of "hierarchical tiling" allows the GPU to use tiles as small as 16x16 pixels all the way up to 2048x2048 pixels. This "sliding scale" allows different types of content to be optimized in different ways. The tiling needs of a 3D game like SuperTuxKart are different from those of a user interface like GNOME Shell, so this technique gets us the best of both worlds!

Although primarily handled in hardware, hierarchical tiling is configured by the driver; I researched this configuration mechanism in order to understand it and improve our configuration with respect to performance and memory usage.

Tiled architectures additionally present an optimization opportunity: if the driver can figure out a priori which 16x16 tiles will definitely not change, those tiles can be culled from rendering entirely, saving both read and write bandwidth. As a conceptual example, if the GPU composites your entire desktop while you're writing an email, there's no need to re-render your web browser in the other window, since that hasn't changed. I implemented an initial version of this optimization in Panfrost, accumulating the scissor state across draws within a frame, rendering only to the largest bounding box of the scissors. This optimization is particularly helpful for desktop composition, ideally improving performance on workloads like GNOME, Sway, and Weston.

…Of course, theory aside, mostly what GNOME needed was a good, old-fashioned bugfixing spree, because the answer is always under your nose. Turns out what really broke the desktop was a trivial bug in the viewport specification code. Alas.

Scoreboarding

Looking forward to sophisticated workloads as this open driver matures, I researched job "scoreboarding". For some background, the Mali hardware divides a frame into many small "jobs". For instance, a "vertex job" executes a vertex shader; a "tiler job" executes tiling (sorting geometry job into tiles at varying hierarchy levels). Many of these jobs have to execute in a specific order; for instance, geometry has to be output by a vertex job before a tiler job can read that geometry. Previously, these relationships were hard-coded into the driver, which was okay for simple workloads but does not scale well.

I have since replaced this code with an elegant dependency management system, based on the hardware's scoreboarding. Instead of hard-coding relationships, the driver can now specify high level dependencies, and a generic algorithm (based on topological sorting) works out the order of submission and scoreboard flags necessary to actualize the given requirements. The new scoreboarding implementation has enabled new features, like rasterizer discard, to be implemented with ease.

With these improvements and more, several new features have landed in the driver, fixing hundreds of failing dEQP tests since my last blog post, bringing us nearer to conformance on OpenGL ES 2.0 and beyond.

Comments (27)

  1. Ikbel BOULABIAR:
    Jun 26, 2019 at 07:26 PM

    Big up for the hard work!
    I would love to test this as soon as it gets possible.

    Reply to this comment

    Reply to this comment

    1. Alyssa Rosenzweig:
      Jun 27, 2019 at 09:32 PM

      Thank you! As for testing yourself, keep an eye on this blog! :)

      Reply to this comment

      Reply to this comment

  2. Marian:
    Jun 27, 2019 at 04:36 PM

    Huge news! Is there any goal of running KDE Plasma with Panfrost as well?

    Reply to this comment

    Reply to this comment

    1. Alyssa Rosenzweig:
      Jun 27, 2019 at 09:24 PM

      I don't know if anyone has tried KDE Plasma with Panfrost yet, but there's a good chance it should "just" work! It's likely the features it needs are similar to those GNOME needs. :)

      Reply to this comment

      Reply to this comment

      1. stuart naylor:
        Jul 11, 2019 at 09:31 AM

        Manjaro have for rk3399 boards rockpro64 and rockpi4.

        Been trying to get Glmark2 to finnish but bugs out on the above terrain bench.
        Its very close and in comparison to others seems very fast approx 200% on the new Pi4 on average.

        Reply to this comment

        Reply to this comment

  3. Jonathan Bayer:
    Jun 27, 2019 at 08:29 PM

    Awesome work ! This has been so needed for so long to make proper use of SBC's. How do you expect performance/power usage to compare between the OSS/Closed source driver?

    Reply to this comment

    Reply to this comment

    1. Alyssa Rosenzweig:
      Jun 27, 2019 at 09:24 PM

      We've been focused on making the driver work well, so we haven't been too focused on performance yet. In limited testing, we're sometimes slower than the proprietary driver and sometimes slower. There are a few missing features which would help performance (job pipelining and compression, for instance) -- these are on the road map! Once those are implemented, performance and power consumption should be comparable to the proprietary stack, but it's difficult to predict this early.

      Reply to this comment

      Reply to this comment

  4. KM:
    Jun 27, 2019 at 10:41 PM

    Quick silly question on your work with GNOME: are you using GNOME-Wayland, GNOME-Xorg, or GNOME Fallback for your testing? Regardless, awesome work all around!

    Reply to this comment

    Reply to this comment

    1. Alyssa Rosenzweig:
      Jun 27, 2019 at 11:26 PM

      GNOME-Wayland, thank you for asking!

      Reply to this comment

      Reply to this comment

  5. Demetris:
    Jun 28, 2019 at 10:18 AM

    You are really making history here! Million devices are waiting to implement your amazing work.
    What troubles me is the next step. Are there any thoughts about OpenGL ES 3.0 and Vulkan support after your work ended at collabora?

    Reply to this comment

    Reply to this comment

    1. Alyssa Rosenzweig:
      Jul 16, 2019 at 04:20 PM

      Thank you! We've begun work on OpenGL ES 3.0 already; in fact, a few ES 3.0 features like instanced rendering have already landed in mesa master. Vulkan is a possibility, but for now, we're focused on perfecting OpenGL ES, including ES 3.0.

      Reply to this comment

      Reply to this comment

      1. Demetris Ierokipides:
        Jul 16, 2019 at 05:01 PM

        Thank you for the very good news. Ogles 3.x support would be more than enough atm for these socs.
        Vulkan is not a priority but good to be on the to do list when all are said and done.
        Have a wonderful life.

        Reply to this comment

        Reply to this comment

  6. techguru:
    Jul 08, 2019 at 11:44 PM

    any chance of vulkan being added to this?
    obviously not soon...but eventually

    Reply to this comment

    Reply to this comment

    1. Alyssa Rosenzweig:
      Jul 16, 2019 at 04:21 PM

      Vulkan is a possibility, but at the moment, we're focused on polishing our OpenGL implementation. Stay tuned!

      Reply to this comment

      Reply to this comment

      1. Stuart Naylor:
        Jul 16, 2019 at 04:24 PM

        Many thanks Alyssa any chance of you doing a quick blog on what to compile and try?

        Strangely with 19.2.0-devel x11 seems faster than wayland is that what you expected?

        Reply to this comment

        Reply to this comment

  7. Ikbel BOULABIAR:
    Jul 17, 2019 at 04:12 PM

    I think the priority of the open source driver is not supporting everything at once.
    (Vulkan, 4K hdr, ...)
    The priority is to be able to run a linux distribution with good enough stability and performance (opengl es 2.0).
    This alone is a huge game changer (like running linux on cheap Android ARM boxes).

    All other non critical features can come later.

    Reply to this comment

    Reply to this comment

  8. Reset AOL Mail Password:
    Jul 31, 2019 at 08:53 AM

    Great work! i would love to test this as soon as possible.

    Reply to this comment

    Reply to this comment

  9. Walter Zambotti:
    Aug 02, 2019 at 08:44 AM

    Is there a a time frame for merging all your work into mainline linux?

    Otherwise are there links and pointers to resources (git etc)?

    Reply to this comment

    Reply to this comment

    1. Stuart Naylor:
      Aug 02, 2019 at 02:39 PM

      Already is panfrost was 5.2.
      Much is mesa which is outside of the kernel

      Reply to this comment

      Reply to this comment

  10. Walter ZAMBOTTI:
    Aug 03, 2019 at 04:27 AM

    Is there a compatibility list of the supported bifrost devices in the panfrost driver?

    I am using the Amlogic S922X with the Mali G52 I would like to know if that is supported!

    Reply to this comment

    Reply to this comment

  11. Walter ZAMBOTTI:
    Aug 04, 2019 at 04:03 AM

    Do the panfrost drivers support the Mali-G52?

    Or is there a list of supported hardware?

    Reply to this comment

    Reply to this comment

  12. Walter ZAMBOTTI:
    Aug 05, 2019 at 05:05 AM

    Is bifrost supported or is only for midgard?

    Reply to this comment

    Reply to this comment

  13. Sagittarius:
    Aug 17, 2019 at 02:33 PM

    Fantastic.
    This is a very large technology transfer to the world of free software and it could well have a global impact. In particular, I think that it can make linux desktops accessible to everyone.

    Thank you so much Alyssa !

    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

Automatic regression handling and reporting for the Linux Kernel

14/03/2024

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!

21/02/2024

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?

19/02/2024

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

08/02/2024

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

23/01/2024

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:…

How to share code between Vulkan and Gallium

16/01/2024

One of the key high-level challenges of building Mesa drivers these days is figuring out how to best share code between a Vulkan driver…

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.