They propose the implementation of a GPU driver written in Rust, for the Apple AGX G13 and G14

Linux Apple Rust

This is a fairly comprehensive driver for the Apple AGX G13 and G14 series GPUs.
Today's controller is compatible with SoCs

The news was released recently that a preliminary implementation of the drm-asahi driver has been proposed for series GPUs Apple AGX G13 and G14 used in the Apple M1 and M2 chips on the Linux kernel developer mailing list.

The controller is written in Rust plus, includes a set of universal links about the DRM subsystem (Direct Rendering Manager) that can be used to develop other graphics drivers in Rust.

The released patch set until now has been proposed for discussion only by the core developers (RFC), but may be accepted into the core team after the review is completed and identified deficiencies are fixed.

This is my first version of the Rust abstractions for DRM subsystem. Includes the abstractions themselves, some minor prerequisite changes on the C side as well as the drm-asahi GPU driver (for reference on how abstractions are used, but not necessarily intended to land together).

These patches are applied at the top of the tree in [1], which is based on 6.3-rc1 with a lot of abstraction/Rust support commits added in above. Most of these are not prerequisites for DRM abstractions. themselves, but only from the driver.

Since December, the controller is included in the package with the kernel for the Asahi Linux distribution and has been tested by the users of this project.

The driver can be used on Linux distributions to organize the graphical environment in dApple devices with SoC M1, M1 Pro, M1 Max, M1 Ultra and M2. When developing the driver, an attempt was made not only to increase security by minimizing errors when working with memory in code executed on the CPU side, but also to partially protect against problems that arise when interacting with firmware.

En particular, the driver provides certain bindings for shared memory structures unsafe with complex strings of pointers used in the firmware to interact with the controller. The proposed driver is used in conjunction with the asahi Mesa driver, which provides user-space OpenGL support and passes OpenGL ES 2 compatibility testing. and is almost ready to support OpenGL ES 3.0.

At the same time, the driver that works at the kernel level is initially developed with future support for the Vulkan API in mind, and the programming interface for interacting with the user space is designed with the UAPI provided by the new Intel Xe driver in mind.

About the known issues the following are mentioned:

  • The existing Rust integration currently does not support building abstractions as modules, so Rust abstractions are only available for embedded DRM components.
  • DRM relies heavily on the "subclassing" pattern for controller objects, and this doesn't sit well with Rust.
  • Currently, only what is necessary for the controller is implemented (plus a small amount of
    obvious extras where better API integrity makes sense).
  • drm::mm ends up requiring a mutex built into the abstraction, instead
    to delegate that to the user with the usual Rust mutability rules.
    This is because nodes can be dropped at any time and those operations
    it needs to be in sync.
  • On the Mesa side you currently have the Gallium driver which is mostly already upstream (UAPI bits mostly missing) and
    passes the dEQP GLES2/EGL tests, with most of GLES3.0 passing in
    Upstream branches of work in progress. This is a community driver reverse engineering, so it is mentioned that there is still a lot to be done in this aspect.

finally if you are interested in knowing more about it, you can check the details in the following link.


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.