The last year has seen substantial progress on the DRM infrastructure required to write GPU drivers in Rust. While a great part of it was fueled by the development of Nova (the new driver for GSP-based NVIDIA GPUs), and by AGX (the driver for the GPUs on Apple's M-series chip that preceded Nova), a few components were being worked on to cater to a then undisclosed driver that was being prototyped behind the scenes. A driver that we now introduce to the community at large in a very early stage.

Tyr is a new Rust-based DRM driver for CSF-based Arm Mali GPUs, making Collabora the first consultancy to formally join the Rust-for-Linux initiative, a testament to our commitment to advancing Rust development within the kernel community. It is a port of Panthor - which is a mature driver written in C for the same hardware - and a joint effort between Collabora, Arm, and Google.

In this sense, Tyr aims to eventually implement the same userspace API offered by Panthor for compatibility reasons, so that it can be used as a drop-in replacement in our Vulkan driver, called PanVK. We foresee Panthor being used - and of course supported - for a relatively long time, as it is a mature driver with a large adoption in the ecosystem. It will probably take a couple of years for Tyr to fully pick up.

Over the course of the next few weeks, we will be releasing a series of blog posts that explain in detail the inner workings of Tyr and its components. This will be a walk-through for GPU drivers on Linux, so stay tuned! For now, we will address why we are submitting a patch to add an initial version of Tyr upstream and what exactly is contained in that submission.

What's the purpose of the current upstream submission?

This question will be easier to answer once we discuss how GPU drivers work. As we uncover the components that make up a kernel-mode driver and how they interact with the rest of the kernel, it will become clear that we simply cannot write a Rust GPU driver with the infrastructure that is currently available upstream. We will discuss, for example, the central role of the Micro Controller Unit (or MCU) within the Arm Mali architecture and then explain why we cannot make it boot without landing some pre-requisite code first, as well as discuss various other components that also cannot be written before landing even more code.

The issues outlined above led us to develop Tyr on a downstream branch. Doing so lets us prototype much faster, which is the reason why we are much further ahead in our downstream code. In fact, we are able to submit small parcels of work to the GPU already.

We will also address this later, but I believe that we will achieve a working driver in our downstream code soon, for a given definition of "working" anyway. In any case, our downstream branch will be invaluable to test the surrounding, work-in-progress code that is needed to support not only Tyr, but also other Rust DRM drivers.

Unfortunately, reconciling the current development model with upstream has been somewhat challenging recently, so a change in the overall strategy that we have been using to develop Tyr was needed.

By submitting small parts of the driver upstream iteratively, we hope to evolve alongside Nova and rvkms, which should help us avoid regressions from upstream changes that might otherwise break our code simply because we weren't part of the upstream conversation yet. This approach also lets us prove that work-in-progress abstractions actually function correctly on real hardware with a real driver, rather than just in theory.

Perhaps most importantly, having Tyr as a concrete user of these abstractions gives the community a compelling reason to work on and review them. After all, it's much easier to motivate development when there's an actual driver that depends on the code. Lastly, developing code in the open and with the upstream community also aligns with our philosophy here at Collabora overall.

What's in the current upstream submission?

The current submission can power up the GPU and probe the device on an RK3588 system-on-chip. This lets us read a few sections of ROM in the GPU, which in turn lets us provide this information to userspace by means of a DRM_IOCTL_PANTHOR_DEV_QUERY call.

This is all that can be done for now, at least until the MCU can be made to work. More on that will be discussed during the subsequent posts.

What's next?

This is just the first installment in a series that will dive much further into GPU driver development. We will begin by discussing the role of GPU drivers in general by exploring a simple yet very instructional application known as VkCube, which is available on the Vulkan-Tools repository, as we need to build this background before we can segue into the specifics of Mali's CSF architecture. Feel free to compile and explore the code beforehand if you would like to follow along.