We're hiring!
*

GNOME meets Panfrost

Alyssa Rosenzweig avatar

Alyssa Rosenzweig
June 26, 2019

Share this post:

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 (20)

  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


Add a Comment






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


Search the newsroom

Latest Blog Posts

GStreamer in Oslo

18/07/2019

A little over a month and a half ago, Collaborans including Aaron Boxer, George Kiagiadakis, Guillaume Desmottes, Stéphane Cerveau and myself…

GNOME meets Panfrost

26/06/2019

In my last Panfrost blog post, I announced my internship goal: improve Panfrost to run GNOME3. GNOME is a popular Linux desktop making heavy…

Using dummy-hcd to play with USB gadgets

24/06/2019

Dummy_hcd which consists of a software-emulated host controller and a UDC chip. In other words, this means you can play with USB gadgets…

Building Debian images for Le Potato and OrangePi with debos

18/06/2019

Both the Le Potato and OrangePi Zero Plus2 boards are already supported by Armbian. But how do you get a minimal Debian upstream image with…

Joining Collabora for a summer of Panfrost

05/06/2019

Years ago, I joined the open-source community with a passion and a mission: to enable equal access to high-quality computing via open-source…

Testing Video4Linux2 drivers like a boss

23/05/2019

With virtme, you can run a custom built kernel on top of our running root filesystem. In this post, we explore another example of virtme…

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-2019. All rights reserved. Website sitemap.