LWN：Tyr （Arm Mali 的 Rust 驱动）的未来！

关注了就能看到更多这么棒的文章哦～

Daniel Almeida
 Gemini translation
 原文链接：https://lwn.net/Articles/1055590/ 

本文由 Daniel Almeida 投稿 

Tyr 团队在 2025 年初开始为 Arm Mali 硬件开发 Rust GPU 驱动程序时，几乎还拿不出什么像样的成果。然而到了年底，我们已经能够在 Linux Plumbers Conference (LPC) 大会上运行 SuperTuxKart（一款 3D 开源赛车游戏）了。我们的原型项目是 Arm、Collabora 和 Google 共同努力的结晶；它在整个活动期间运行良好，性能对于玩家来说也绰绰有余。值得庆幸的是，我们在恰当的时机发力了：Dave Airlie 刚刚在维护者峰会（Maintainers Summit）上宣布，DRM 子系统距离禁止使用 C 语言编写新驱动、转而要求使用 Rust 仅有大约一年的时间。现在是时候为 2026 年制定一份可能的路线图，以便将所有这些工作合并到主线中。 

我们试图通过 Tyr 实现什么目标？

Miguel Ojeda 今年在 LPC 上的演讲总结了 Rust 在 Linux 内核中的应用情况，诸如 Android 匿名共享内存子系统（ashmem）之类的驱动程序正迅速推广给数百万用户。鉴于 Mali 在手机市场拥有巨大的市场份额，支持这一领域是 Tyr 的自然愿望，其次是 Mali 同样存在的其他嵌入式平台。与此同时，我们绝不能忽视上游开发，因为我们的目标是与 Nova Rust GPU 驱动程序共同演进，并确保该生态系统对未来可能出现的任何新驱动程序都有所帮助。原型项目的目的是证明为 Arm Mali 开发具有可接受性能的 Rust 驱动程序是可以实现的，但现在我们应该对代码进行迭代，并在必要时进行重构。这将使我们能够从错误中吸取教训，并确定一个适用于上游驱动的设计方案。 

现状如何，还缺少什么

Tyr 驱动程序的一个版本已经合并到了 6.18 内核版本中，但它的功能还非常有限，因为还缺少一些关键的 Rust 抽象。我们的最新原型存放在下游分支（即尚未进入主线（mainline）内核的部分）中；它运行得足够好，可以驱动桌面环境和游戏，尽管仍有一些功耗和 GPU 恢复问题需要解决。这个原型将起到指导我们上游工作的作用，并让我们能够尝试不同的设计。 

像 Tyr 这样的内核模式 GPU 驱动程序只是一个较小组件，它支撑着一个实现 Vulkan 或 OpenGL 等图形 API 的、大得多的用户模式驱动程序。用户模式驱动程序将与硬件无关的 API 调用转换为可用于光栅化过程的 GPU 特定命令。内核的职责集中在应用程序之间共享硬件资源、强制执行隔离和公平性以及保持硬件正常运行。这包括向用户模式驱动程序提供 GPU 内存，告知提交的任务何时完成，并为用户空间提供一种描述任务之间依赖链的方法。我们在 LPC2025 上的演讲（YouTube 视频）详细介绍了这一点。 

然而，拥有一个工作的原型并不意味着它已经准备好投入实际使用，通过梳理缺失的部分就能明白原因。Mali GPU 通常出现在电力资源非常宝贵的移动设备上。节省能源和管理设备的散热特性对用户体验至关重要，而 Tyr 目前还没有任何电源管理或调频代码。事实上，支持这些功能的 Rust 抽象根本还不存在。 

另一个值得考虑的问题是如果 GPU 挂起（hang）会发生什么。系统必须尽力保持运行，否则用户可能会丢失所有工作。由于我们还处于原型阶段，目前还没有 GPU 恢复（GPU recovery）代码。这两点是可部署性的硬性要求。你根本无法部署一个会耗尽系统所有电池、在此过程中变得发烫且令人不快，或者会崩溃并带走用户工作的驱动程序。 

除此之外，Vulkan 必须能够在 Tyr 之上正确实现，否则我们可能无法实现与 Vulkan 驱动程序（PanVK）的掉头替换兼容性。这要求在使用 Tyr 替代 C 驱动程序时通过 Vulkan 一致性测试套件（Vulkan Conformance Testing Suite）。到那时，我们将有足够的信心在目前支持的 Mali-G610 之外增加对更多 GPU 型号的支持。最后，我们将转向基准测试，以确保 Tyr 在受益于 Rust 安全保证的同时，能够匹配 C 驱动程序的性能。我们已经演示了以可接受的性能运行复杂的游戏，因此到目前为止结果还不错。 

缺失了哪些 Rust 抽象

一些必需的 Rust 基础设施仍在开发中。这包括 Lyude Paul 在图形执行管理器（GEM）shmem 对象方面的工作，这是为没有独立显存的系统分配内存所必需的。Tyr 的情况正是如此，因为 GPU 被封装在一个更大的片上系统（SoC）中，必须共享系统内存。此外，还有一些悬而未决的问题，例如如何在不使用锁的情况下共享 GPU 缓冲区的非重叠区域，最好能在类型系统中编码并在编译时检查。 

除了分配 GPU 内存外，现代内核驱动程序还必须让用户模式驱动程序管理其自身的 GPU 地址空间视图。在 DRM 生态系统中，这项工作被委托给了 GPUVM，它包含了在提供类似于现代 CPU 的内存隔离能力的硬件上管理这些地址空间的公共代码。GPU 固件还期望控制内存中某些部分的放置位置，因此在这一功能可用之前，它将无法工作。Alice Ryhl 正在开发 GPUVM 的 Rust 抽象，以及操作 IOMMU 页表以强制执行内存隔离所需的 io-pgtable 抽象。这些都基于 Asahi Lina 之前的工作，她是 DRM 子系统首批 Rust 抽象的开拓者。 

另一个尚未解决的问题是 DRM 设备初始化。当前的代码需要驱动程序私有数据的初始化程序，以便返回一个 drm::Device 实例，但某些驱动程序首先需要 drm::Device 才能构建私有数据，这导致了一个无法满足的循环依赖。Tyr 的情况也是如此：通过 GEM shmem API 分配 GPU 内存需要一个 drm::Device，但 Tyr 私有数据中的某些字段需要存储 GEM 对象——例如，用于解析和启动固件。Lyude Paul 正在通过引入在类型系统中编码设备状态的 drm::DeviceCtx 来解决这个问题。 

情况与第一批 Tyr 补丁提交时一致：路线图的大部分仍受阻于 GEM shmem、GPUVM、io-pgtable 以及设备初始化问题。此外，还有整合 Nova 团队部分工作的空间：register! 宏和受限（bounded）整数。一旦我们能处理这些项目，我们预计将能很快启动 GPU 固件，然后无障碍地推进，直到讨论任务提交（job submission）的时候。 

另一个需要考虑的领域是驱动程序在完成 fence 方面取得进展的路径。fence 是 GPU 驱动程序在任务执行完成后发出的同步原语。这些路径必须经过仔细注释，否则系统可能会发生死锁，且驱动程序必须确保在信号路径中仅获取安全的锁。此外，DMA fence 必须始终在有限时间内发出信号，否则系统其他地方的某些进程可能会永远阻塞。除了 GFP_ATOMIC 之外，必须禁止使用任何其他方式分配内存，否则在内存压力下可能会触发内存回收（shrinker），从而等待触发它的那个任务完成。所有这些都在文档中有详细说明。我们在原型中很方便地忽略了这一点，这意味着它在内存压力下可能会随机死锁。解决这个问题很直接：只需仔细审查驱动程序的关键部分即可。然而，如何优雅地完成这一点，或许是以一种利用 Rust 类型系统优势的方式，仍有待讨论。 

展望未来

我们还没有触及 Linux GPU 驱动程序整体的下一步计划：用 Rust 重构任务提交逻辑。目前的设计假设使用 drm_gpu_scheduler，但在 GPU 固件可以自行调度任务的时代，这已成为某些驱动程序的障碍，并且一直受到难以解决的生命周期问题的困扰。2025 年的 X.Org 开发者大会（X.Org Developer's Conference）上花了相当多的时间讨论如何修复它。 

目前 Rust 的共识是编写一个新组件，该组件仅确保在任务有资格被分配到 GPU 的环形缓冲区（ring buffer）之前满足其依赖关系，随后由固件调度器接管。这似乎是 GPU 硬件的发展方向，因为大多数厂商近年来都转向了固件辅助调度。由于该组件不会调度任务，它可能会被命名为 JobQueue。这准确地表达了一个队列的含义：新工作被存入其中，并在满足依赖关系且任务准备就绪后被移除。Philip Stanner 一直在带头开展这项工作。 

该计划还打算使用我过去在这里描述过的一种技术为 C 驱动程序暴露一个 API。这可能是第一个可供 C 驱动程序使用的 Rust 内核组件，是 Rust 在内核中的又一个里程碑，也是 C 和 Rust 之间无缝互操作性的标志。 

Tyr 融入这一宏伟蓝图的一种方式是作为新设计的测试平台。如果能在原型中成功将旧的 drm_gpu_scheduler 替换为 JobQueue，将有助于证明其对 Nova 等其他更复杂驱动程序的适用性。预计这一讨论还将持续一段时间。 

总的来说，Tyr 在过去的一年里取得了很大进展。希望它能在 2026 年及以后继续保持这一势头。 

LWN 评论概述：

在“没多少功能”方面，一位匿名评论者指出，目前合并到主线的驱动代码仅包含绑定设备、启用电源、执行软重置以及查询设备信息等基础功能。 

关于自由固件的问题，有评论询问 Mali GPU 是否会对固件进行签名检查，或者未来是否有出现自由固件的机会。 

针对其他 Rust 驱动，有用户询问 Tyr 驱动与用于 Arm Linux Mac 的 Asahi 驱动之间有多大的相似性。 

欢迎分享、转载及基于现有协议再创作～