最近有新闻发布 已提议初步实施 drm-asahi 驱动程序 对于系列 GPU Apple M13 和 M14 芯片中使用的 Apple AGX G1 和 G2 在 Linux 内核开发者邮件列表上。
控制器是用 Rust 编写的 加, 包括一组关于 DRM 子系统的通用链接 (直接渲染管理器)可用于在 Rust 中开发其他图形驱动程序。
发布的补丁集 到现在 仅供讨论 由核心开发人员 (RFC) 提出,但在完成审查并消除已识别的缺陷后,可能会被核心团队接受。
这是我的第一个 DRM Rust 抽象版本 子系统。 包括抽象本身,一些次要的 C 端的先决条件更改以及 drm-asahi GPU 驱动程序 (用于参考如何使用抽象,但不一定 打算一起着陆)。
这些补丁应用在 [1] 中树的顶部,这是基于 6.3-rc1 添加了很多抽象/Rust 支持提交 多于。 其中大多数不是 DRM 抽象的先决条件。 他们自己,但只能来自司机。
自 XNUMX 月起,控制器包含在 内核包 适用于 Asahi Linux 发行版 并已通过该项目的用户进行测试。
该驱动程序可用于 Linux 发行版以 在 d 中组织图形环境配备 SoC M1、M1 Pro、M1 Max、M1 Ultra 和 M2 的 Apple 设备。 在开发驱动程序时,不仅尝试通过在 CPU 端执行的代码中使用内存时最大限度地减少错误来提高安全性,而且还尝试部分防止与固件交互时出现的问题。
特别是, 驱动程序为共享内存结构提供某些绑定 固件中用于与控制器交互的复杂指针字符串不安全。 建议的驱动程序与 asahi Mesa 驱动程序结合使用,后者提供用户空间 OpenGL 支持并通过 OpenGL ES 2 兼容性测试。 并且几乎准备好支持 OpenGL ES 3.0。
同时,工作在内核层的驱动程序 最初开发时考虑到未来对 Vulkan API 的支持,与用户空间交互的编程接口在设计时考虑了新的英特尔 Xe 驱动程序提供的 UAPI。
在 已知的问题 提到以下内容:
- 现有的 Rust 集成目前不支持将抽象构建为模块,因此 Rust 抽象仅适用于嵌入式 DRM 组件。
- DRM 在很大程度上依赖于控制器对象的“子类化”模式,而这与 Rust 不相适应。
- 目前,只实现了控制器所必需的(加上少量的
明显的附加功能,更好的 API 完整性是有意义的)。 - drm::mm 最终需要一个内置于抽象中的互斥体,而不是
使用通常的 Rust 可变性规则将其委托给用户。
这是因为可以随时删除节点,而那些操作
它需要同步。 - 在 Mesa 端,你目前拥有 Gallium 驱动程序,它大部分已经在上游(UAPI 位大多缺失)和
通过 dEQP GLES2/EGL 测试,大部分 GLES3.0 通过
上游分支工作正在进行中。 这是一个社区驱动逆向工程,所以提到这方面还有很多工作要做。
最后,如果你是 有兴趣了解更多,您可以在中查看详细信息 以下链接。