Tyr, a new Rust DRM driver targeting CSF-based ARM Mali GPUs

原始链接: https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html

Collabora, in collaboration with Arm and Google, is developing Tyr, a new Rust-based DRM driver for CSF-based Arm Mali GPUs, a port of the existing C-based Panthor driver. This makes Collabora the first consultancy to formally join the Rust-for-Linux initiative. Tyr aims for API compatibility with Panthor, allowing it to be a drop-in replacement for the PanVK Vulkan driver. While Panthor will remain supported for the foreseeable future, Tyr is expected to take a couple of years to fully mature. The initial upstream submission of Tyr allows powering up the GPU, probing the device on an RK3588 SoC, and reading ROM information accessible to userspace via a DRM_IOCTL call. This initial step is necessary to integrate with the upstream kernel infrastructure. The project aims to incrementally contribute small parts of the driver upstream to evolve alongside other Rust DRM initiatives like Nova and rvkms, ensuring compatibility and demonstrating practical use of new abstractions. Future blog posts will delve into the inner workings of Tyr, GPU driver development, and the specifics of the Mali CSF architecture.

该黑客新闻线程讨论了ARM Mali GPU的新的基于Rust的直接渲染经理(DRM)驱动程序“ Tyr”。讨论的关键点是令人困惑的首字母缩写“ DRM”,它通常与数字权利管理相关。几位评论者建议使用诸如“ GPU驱动程序”之类的替代方案为了清楚起见。 该驾驶员旨在改善对ARM Mali GPU的开源支持,由于文档有限和所需的逆向工程工作,历史上一直存在问题。一位评论者强调了在没有制造商支持的情况下访问专业GPU功能的困难。他们主张开源GPU计划,并对基于RISC-V的解决方案(例如基于RISC-V的解决方案)表示兴奋。该线程还提到了驾驶员为GPU供电并探测设备的能力,从而实现ROM数据检索。还解释了与北欧神话相关的驾驶员的命名公约。
相关文章

原文

Daniel Almeida
July 07, 2025

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.

 

联系我们 contact @ memedata.com