每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
一个用Rust编写的、支持Arm Mali CSF架构GPU的Linux内核驱动程序。继上一篇对项目动机的介绍后，本文将进一步阐释GPU驱动的工作机制，并以一个经典示例程序 VkCube 为切入点进行讲解。VkCube利用Vulkan API在屏幕上渲染一个旋转立方体，结构简洁，非常适合作为理解GPU驱动工作流的教学范例。
文中首先会介绍用户态驱动（UMD）和内核态驱动（KMD）的基本概念，然后以简要形式解析VkCube如何通过Vulkan API向GPU传递渲染任务。最后，文章将展示Tyr提供的核心接口API，这套接口与其C语言版本驱动Panthor保持一致。
GPU驱动快速入门
要理解GPU驱动的工作机制，可以从一个简单的3D应用出发，例如绘制一个三角形，或运行VkCube程序，其主要任务是在屏幕上渲染一个旋转立方体。在此过程中，将用到两个术语：
-
UMD（User Mode Driver）用户态驱动 ：本项目中代表为
panvk，是Mesa项目中的一个Vulkan驱动； -
KMD（Kernel Mode Driver）内核态驱动 ：本项目中由Rust编写的内核驱动
Tyr负责。
在现代GPU栈中，KMD的角色是将较高层的UMD指令桥接到实际硬件。UMD实现如Vulkan、OpenGL等API，这些API再被应用程序调用，用于描述它们要交给GPU处理的任务。这包括几何体数据、纹理、着色器（shaders）等的配置与上传。
VkCube程序中用到的着色器尽管简单，却需访问外部数据才能正常运行，比如立方体的几何坐标、颜色信息以及描述其旋转的三维矩阵数据。
在拥有着色器代码和模型数据后，UMD将请求KMD将其加载至GPU内存，并通过构建VkCommandBuffers（GPU执行指令集）完成对绘制任务的描述。这些缓冲区不仅定义了如何执行，还需设置回调机制来通知主机任务完成状态，并预留内存以存放输出结果。
虽然初看之下流程较为复杂，但其实整合后非常有条理。一个合格的KMD必须提供如下核心能力：
-
内存管理：分配并映射GPU可访问的内存区域，确保任务执行时的上下文隔离；
-
任务提交与调度：向GPU的硬件队列提交指令并保证任务依赖的正确执行；
-
事件通知：处理异步与乱序执行的通知机制；
-
设备初始化与共享管理：启动设备并在多个任务之间公平分配GPU资源。
尤其重要的是调度机制。GPU作为大规模并行硬件，任务可同时进行，且执行顺序不固定。KMD需要负责所有依赖关系的解析和执行计划的调度。
一个重要的认识
可以看出，GPU驱动的大部分复杂性其实集中在用户态驱动。UMD负责将高级图形API转换为底层GPU命令，而KMD负责内存与硬件交互等关键支撑功能。KMD的任务是在不干涉UMD逻辑的前提下，提供一组标准、安全、高效的操作接口，便于上层构建。
Tyr 驱动接口简介
基于上述背景，Tyr内核驱动提供如下接口，与Panthor项目保持一致：
/** @DRM_PANTHOR_DEV_QUERY: 查询设备信息 */
DRM_PANTHOR_DEV_QUERY = 0,
/** @DRM_PANTHOR_VM_CREATE: 创建虚拟机上下文 */
DRM_PANTHOR_VM_CREATE,
/** @DRM_PANTHOR_VM_DESTROY: 销毁虚拟机上下文 */
DRM_PANTHOR_VM_DESTROY,
/** @DRM_PANTHOR_VM_BIND: 将内存绑定/解绑至虚拟机 */
DRM_PANTHOR_VM_BIND,
/** @DRM_PANTHOR_VM_GET_STATE: 获取虚拟机状态 */
DRM_PANTHOR_VM_GET_STATE,
/** @DRM_PANTHOR_BO_CREATE: 创建缓冲区对象（BO） */
DRM_PANTHOR_BO_CREATE,
/** @DRM_PANTHOR_BO_MMAP_OFFSET: 获取mmap文件偏移地址以映射GEM对象 */
DRM_PANTHOR_BO_MMAP_OFFSET,
/** @DRM_PANTHOR_GROUP_CREATE: 创建调度组 */
DRM_PANTHOR_GROUP_CREATE,
/** @DRM_PANTHOR_GROUP_DESTROY: 销毁调度组 */
DRM_PANTHOR_GROUP_DESTROY,
/** @DRM_PANTHOR_GROUP_SUBMIT: 向指定调度组提交作业 */
DRM_PANTHOR_GROUP_SUBMIT,
/** @DRM_PANTHOR_GROUP_GET_STATE: 获取调度组状态 */
DRM_PANTHOR_GROUP_GET_STATE,
/** @DRM_PANTHOR_TILER_HEAP_CREATE: 创建Tiler堆 */
DRM_PANTHOR_TILER_HEAP_CREATE,
/** @DRM_PANTHOR_TILER_HEAP_DESTROY: 销毁Tiler堆 */
DRM_PANTHOR_TILER_HEAP_DESTROY,这个API集合虽看起来简洁，但背后逻辑严密。我们可以将其分为如下功能模块：
1. 设备信息获取
DEV_QUERY：让UMD了解底层GPU配置（如读取ROM中信息）。
2. 内存管理与虚拟化隔离
-
VM_CREATE,VM_BIND,VM_DESTROY,VM_GET_STATE,BO_CREATE,BO_MMAP_OFFSET：创建隔离的内存上下文，管理缓冲对象，并实现mmap映射至用户空间。
3. 调度组管理
-
GROUP_CREATE,GROUP_DESTROY,GROUP_GET_STATE：调度组代表了工作提交的逻辑容器，未来文章将深入剖析。
4. 作业提交
GROUP_SUBMIT：唯一用于提交工作任务的接口。核心作用是将命令缓冲区提交至GPU执行队列。
5. Tiler堆管理
-
TILER_HEAP_CREATE,TILER_HEAP_DESTROY：面向Tile-Based渲染架构的专用内存区域，用于存储局部几何信息。
小结与展望
本文简要梳理了GPU驱动的分层结构、用户态与内核态职责划分、VkCube在GPU管线中运行的基本流程，并介绍了Tyr驱动对外暴露的核心API接口。核心思想是：用户态负责构建渲染任务，内核态负责管理资源与调度执行。
下一篇文章将正式进入 Arm CSF架构 的深入解析，介绍其核心组件，如微控制单元（MCU）、以及引导设备启动所需的关键步骤。
Rust在内核空间的应用仍处于早期阶段，而Tyr项目提供了宝贵的实践范式，也有望在未来引领GPU驱动开发的现代化方向。