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!
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.
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.
08/10/2024
Having multiple developers work on pre-merge testing distributes the process and ensures that every contribution is rigorously tested before…
15/08/2024
After rigorous debugging, a new unit testing framework was added to the backend compiler for NVK. This is a walkthrough of the steps taken…
01/08/2024
We're reflecting on the steps taken as we continually seek to improve Linux kernel integration. This will include more detail about the…
27/06/2024
With each board running a mainline-first Linux software stack and tested in a CI loop with the LAVA test framework, the Farm showcased Collabora's…
26/06/2024
WirePlumber 0.5 arrived recently with many new and essential features including the Smart Filter Policy, enabling audio filters to automatically…
12/06/2024
Part 3 of the cmtp-responder series with a focus on USB gadgets explores several new elements including a unified build environment with…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (27)
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
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
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
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
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
Ishan Madhusanka:
Jun 27, 2019 at 05:39 PM
Super awesome work!
Reply to this comment
Reply to this comment
Alyssa Rosenzweig:
Jun 27, 2019 at 09:16 PM
Thank you!
Reply to this comment
Reply to this comment
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
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
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
Alyssa Rosenzweig:
Jun 27, 2019 at 11:26 PM
GNOME-Wayland, thank you for asking!
Reply to this comment
Reply to this comment
Mathias:
Jun 28, 2019 at 09:43 AM
Thanks for this great job!!
Reply to this comment
Reply to this comment
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
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
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
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
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
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
Kyle:
Jul 17, 2019 at 02:23 AM
Any update on HDR 4K content?
Reply to this comment
Reply to this comment
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
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
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
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
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
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
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
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