- Este artículo se centra en el proceso de desarrollo de Tyr, el moderno driver de GPU para kernel Linux desarrollado en Rust, y en el principio de funcionamiento de los controladores GPU
- En el desarrollo de drivers GPU, se explica la distinción y la interacción entre UMD (controlador en modo usuario) y KMD (controlador en modo kernel) a través del ejemplo VkCube
- El UMD convierte APIs de alto nivel en comandos de bajo nivel que la GPU puede entender, mientras que el KMD se encarga de funciones críticas como la asignación de memoria, la planificación de trabajos y la inicialización del dispositivo
- La API que ofrece el driver Tyr es idéntica a la de Panthor y se compone de consultas de dispositivo, gestión de memoria, gestión de grupos, envío de trabajos y administración del heap de Tiler
- En el siguiente texto se abordará la arquitectura de hardware Arm CSF y sus componentes principales (por ejemplo, el MCU) junto con el proceso de arranque
Introducción: Desarrollo de un driver moderno de kernel GPU basado en Rust
- Este es el segundo artículo de la serie de desarrollo de Tyr, un driver de GPU en Rust de última generación para Linux que soporta GPUs basadas en Arm Mali CSF
- Se eligió como ejemplo real VkCube, un programa 3D simple que renderiza un cubo rotando con la API de Vulkan, para explicar cómo funciona internamente un driver de GPU
- La estructura simple de VkCube lo hace apto para aprender los principios de operación de un driver GPU
Fundamentos del driver GPU: rol y estructura de UMD y KMD
- Se compone de User Mode Driver (UMD) y Kernel Mode Driver (KMD)
- UMD: implementa API de aplicaciones normales (como Vulkan, OpenGL), como panvk (el driver de Vulkan de Mesa)
- KMD: drivers de nivel kernel con privilegios sobre el hardware, como Tyr, que funcionan como parte del kernel de Linux
- El driver GPU en modo kernel conecta el UMD con la GPU real, mientras que el UMD interpreta instrucciones de la API y las convierte en un conjunto de comandos entendible por la GPU
- El UMD prepara datos necesarios para componer la escena, como geometría, texturas y shaders, y antes de ejecutar solicita al KMD que los asigne en la memoria de la GPU
- Los shaders son programas independientes que se ejecutan en la GPU; en VkCube se encargan del posicionamiento del cubo, coloreado y rotación. La ejecución del shader necesita datos externos (geometría, color, matriz de rotación, etc.)
- El UMD envía al KMD comandos preparados (por ejemplo, VkCommandBuffers) para ejecutarlos; cuando el trabajo termina, recibe una notificación para poder guardar el resultado en memoria
Responsabilidades principales del KMD (Kernel Mode Driver)
- Asignación y mapeo de memoria de GPU (proporcionando aislamiento por aplicación)
- Envío de trabajos a la cola de hardware y notificación al usuario al completarse
- En entornos hardware asíncronos y paralelos, la gestión de dependencias de trabajo es esencial, y para obtener resultados correctos el KMD realiza la programación y validación de dependencias
- También incluye inicialización del dispositivo, operación de reguladores de reloj/voltaje, ejecución de código de arranque y gestión de rotación de acceso para que múltiples clientes compartan el hardware de forma justa
Dónde está la complejidad: la división de trabajo entre UMD y KMD
- La complejidad de un driver GPU se concentra principalmente en el UMD
- UMD: convertir comandos de API de alto nivel en instrucciones de hardware
- KMD: proveer funciones clave para que el UMD funcione correctamente, como aislamiento de memoria, compartición y acceso justo
Estructura de la interfaz del driver (API) que provee Tyr
- La API del driver Tyr (igual a la de Panthor) se puede clasificar en 5 grupos grandes
- Consulta de información del dispositivo: DEV_QUERY (consulta de información de hardware de la GPU mediante IOCTL, aprovechamiento del área ROM)
- Asignación y aislamiento de memoria: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET, etc.
- Gestión de grupos de scheduling: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (se explicará con más detalle en el siguiente artículo)
- Envío de trabajos: GROUP_SUBMIT (solicita ejecución en la GPU mediante el buffer de comandos del dispositivo)
- Gestión de heap de Tiler: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (para cubrir los requisitos de memoria de una GPU de renderizado con tileado)
- Estas APIs están algo alejadas del trabajo de dibujar directamente en pantalla: el UMD maneja la ejecución real de los comandos y el KMD únicamente expone esta interfaz para permitir el acceso al hardware
Conclusión y próximos pasos
- En este texto se revisó la estructura general y el flujo interno de los drivers GPU, así como la API clave que provee Tyr
- Partiendo de esto, en los próximos artículos de la serie se abordarán elementos centrales como la arquitectura de hardware Arm CSF, el MCU (unidad de control micro) y el proceso de inicialización del driver
Aún no hay comentarios.