March 04, 2019
Following two months of work to develop a new kernel driver for Midgard and Bifrost GPUs, the kernel side of Panfrost is now in a form close to be acceptable in the mainline Linux kernel.
Below you can see the same scene that I recorded in January, which was rendered by Panfrost in Mesa but using Arm's kernel driver. This time, Panfrost is using a new kernel driver that is in a form close to be acceptable in the mainline kernel:
During the past two months Rob Herring and I have been working on a new driver for Midgard and Bifrost GPUs that could be accepted mainline.
Arm already maintains a driver out of tree with an acceptable open source license, but it doesn't implement the DRM ABI and several design considerations make it unsuitable for inclusion in mainline Linux.
The absence of a driver in mainline prevents users from keeping their kernels up-to-date and hurts integration with other parts of the free software stack. It also discourages SoC and BSP vendors from submitting their code to mainline, and hurts their ability to track mainline closely.
Besides the code of the driver itself, there's one more condition for mainline inclusion: an open source implementation of the userspace library needs to exist, so other kernel contributors can help verifying, debugging and maintaining the kernel driver. It's an enormous pile of difficult work to reverse engineer the inner workings of a GPU and then implement a compiler and command submission infrastructure, so big thanks to Alyssa Rosenzweig for leading that effort.
Most of the Panfrost code is already part of mainline Mesa, with the code that directly interacts with the new DRM driver being in the review stage. Currently targeted GPUs are T760 and T860, with the RK3399 being the SoC more often used for testing.
The kernel driver is being developed in the open and though we are trying to follow the best practices as displayed by other DRM drivers, there's a number of tasks that need to be done before we consider it ready for submission.
In the kernel:
The exact bits used for the demo recorded above are in various stages of getting upstreamed to the various upstreams, but here are in branches for easier reproduction:
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…
Introducing cmtp-responder - a permissively licensed Media Transfer Protocol (MTP) responder implementation which allows embedded devices…
Up until now, talking in-depth about userspace tracing was deliberately avoided because it merits special treatment, hence this part devoted…
After a successful team effort, the patch enabling the Chromium Embedded Framework (CEF) Ozone builds to run with different platform backends,…
Now that we've studied the mainstream way of developing and using eBPF programs on top of the low-level VM mechanisms, we'll look at projects…
A previous post introduced the SPURV Android compatibility layer for Wayland based Linux environment. In this post, we're going to dig into…