- Tyr es un driver DRM para GPUs Arm Mali CSF reescrito en Rust como port de Panthor, manteniendo la misma API de usuario para facilitar su adopción.
- El desarrollo se organiza en una rama upstream básica ya integrada en Linux 6.18 y una rama downstream
tyr-devmás completa, capaz de ejecutar GNOME y SuperTuxKart. - El prototipo downstream demuestra rendimiento comparable al driver en C, sirve como banco de pruebas para las abstracciones Rust del kernel y se centra por ahora en SoCs Rockchip RK3588.
- Tyr aún es experimental y no apto como driver diario, pero es clave en la expansión de Rust dentro del kernel Linux y en el futuro del soporte abierto para GPUs Mali.
Si sigues de cerca la evolución del soporte de GPUs en Linux, seguro que te suena el nombre de Tyr. Estamos hablando de un nuevo driver DRM para GPUs Arm Mali basado en Rust, pensado para los modelos con Command Stream Firmware (CSF). No es un experimento aislado: es el resultado de un trabajo conjunto entre Collabora, Arm y Google, que quieren llevar la experiencia acumulada con el driver Panthor en C a un entorno más moderno y seguro con Rust.
La idea de fondo es sencilla, pero ambiciosa: Tyr pretende convertirse en una alternativa «drop-in» a Panthor, manteniendo la misma API de espacio de usuario para que todo el ecosistema (incluyendo el driver Vulkan PanVK) pueda funcionar sin cambios grandes. Mientras tanto, Panthor seguirá siendo el caballo de batalla durante bastante tiempo, porque es un driver muy asentado, con alta adopción y ya con conformidad oficial de OpenGL ES 3.1 desde 2024.
Qué es Tyr y por qué importa en el ecosistema Mali
Tyr es, en esencia, un port a Rust del driver Panthor, el cual fue desarrollado originalmente en C para las GPUs Arm Mali basadas en CSF. Panthor entró en el kernel Linux en la versión 6.10, y ha ido madurando como driver DRM para estas GPUs. Tyr hereda el diseño conceptual de Panthor, pero reescrito en Rust y apoyándose en las nuevas abstracciones de Rust para el kernel Linux.
Con esto se persigue aprovechar las ventajas de seguridad de memoria y robustez que ofrece Rust, manteniendo el mismo comportamiento de cara a las aplicaciones. Al tener la misma API desde el punto de vista del espacio de usuario, el objetivo es que Tyr pueda ser un reemplazo directo en componentes como PanVK (el driver Vulkan para Mali), sin obligar a rehacer el stack gráfico.
Ahora bien, nadie espera que esto ocurra de la noche a la mañana. La previsión más realista es que Tyr tarde varios años en estar listo para sustituir a Panthor en producción. En ese intervalo, Panthor seguirá recibiendo soporte y siendo la opción recomendada en la mayoría de dispositivos, mientras Tyr madura y se va integrando mejor con el resto de piezas del kernel Rust.
Desarrollo en paralelo: rama upstream y rama downstream
Una de las particularidades de Tyr es su modelo de desarrollo. Por motivos prácticos, el equipo ha optado por mantener dos ramas diferenciadas: una upstream y otra downstream. Esto permite avanzar más rápido en funcionalidades experimentales sin bloquearse por las limitaciones actuales del ecosistema Rust en el kernel principal.
Tyr upstream en el kernel Linux
El esqueleto inicial de Tyr ya forma parte del kernel Linux, introducido en la versión 6.18 del kernel Linux. En esta fase, el foco está puesto en establecer una base sólida en Rust dentro del subsistema DRM, parecida a la aproximación que ya siguieron otros proyectos como el driver Nova para GPUs NVIDIA.
El código upstream cubre actualmente tareas relativamente básicas pero fundamentales: encender la GPU, detectar el dispositivo (probe) en SoCs RK3588 y leer ciertas secciones de la ROM interna de la GPU. Esa información se expone a espacio de usuario a través de una llamada IOCTL específica, DRM_IOCTL_PANTHOR_DEV_QUERY, que utiliza la estructura drm_panthor_dev_query para trasladar esos datos.
Quien quiera contribuir al código principal de Tyr debe enviar parches a las listas de correo dri-devel y rust-for-linux. Para cambios grandes o que requieran revisión previa, la vía recomendada es abrir una merge request contra la rama tyr-for-upstream del repositorio panfrost/linux. Esta rama actúa como staging area para lo que luego se propondrá oficialmente al kernel.
En esta fase, no todo lo que existe en la rama downstream puede subir aún a mainline. Hay partes, como el soporte avanzado de memoria GPU (GPUVM) o algunas abstracciones de planificación (scheduler), que todavía dependen de trabajo previo en la infraestructura Rust del kernel. Hasta que esas piezas no estén maduras, el driver upstream se queda en una versión recortada de lo que ya es capaz de hacer el prototipo downstream.
Rama downstream: tyr-dev como prototipo avanzado
En paralelo, Collabora mantiene una rama downstream llamada tyr-dev, donde se integra una implementación bastante más completa del driver. Es aquí donde se ven las capacidades más llamativas de Tyr: soporte para GNOME, Weston y juegos 3D como SuperTuxKart, con un desempeño comparable al de Panthor escrito en C.
La rama tyr-dev es el lugar adecuado para quienes quieran probar el driver en un entorno real o contribuir con código experimental. Las aportaciones se hacen abriendo merge requests directamente sobre tyr-dev. Eso sí, está asumido que esta rama sufrirá refactorizaciones profundas antes de que sus cambios viajen a upstream, precisamente para adaptarlos a las abstracciones y estándares que el kernel Linux vaya marcando.
Este enfoque de doble rama es, en parte, una solución de compromiso. La infraestructura necesaria para un desarrollo 100 % upstream aún no está lista, por lo que se ha optado por avanzar en paralelo: upstream como base sólida y estable, downstream como banco de pruebas para las nuevas ideas y el código más arriesgado.
Arquitectura: relación entre UMD y KMD en Tyr
Para entender por qué Tyr es importante, conviene repasar rápidamente la típica división entre user-mode drivers (UMD) y kernel-mode drivers (KMD) en el mundo de las GPUs. El grueso de la lógica complicada suele vivir en el UMD: es el que traduce APIs de alto nivel como Vulkan u OpenGL en comandos concretos que la GPU puede ejecutar.
El KMD, en cambio, se ocupa de hacer que el hardware esté listo y gestionar la parte crítica de recursos y seguridad. Esto incluye encender y apagar la GPU, cargar y validar el firmware, gestionar la memoria de la GPU asegurando aislamiento entre distintos contextos, y proporcionar mecanismos de envío de trabajos (jobs) y sincronización para que varios procesos puedan convivir sin pisarse.
En Tyr, toda esa responsabilidad de KMD se está trasladando a Rust. Durante muchos meses, el foco del desarrollo fue precisamente poner en marcha la GPU y habilitar la asignación de memoria GPU desde espacio de usuario, verificando mediante tests que las llamadas IOCTL se comportaban como se esperaba. Para ello se ha recurrido extensivamente al framework IGT, muy utilizado en el ecosistema de drivers DRM para validar funcionalidades básicas y detectar regresiones.
De un entero en memoria a un cubo 3D
Primeros pasos: ejecutar un único job simple
Antes de lanzarse a escenas 3D complejas, el equipo de Tyr se centró en validar que el camino más básico de ejecución de trabajos funcionaba. El experimento inicial fue un job mínimo que solo escribe un entero en una dirección de memoria usando una instrucción MOV de la GPU. El test IGT correspondiente bloquea hasta que el driver indica que el trabajo ha terminado, y luego comprueba si el valor escrito coincide con el esperado.
Con este tipo de prueba, se puede confirmar que el comando ha llegado correctamente al ring buffer de la GPU, que el hardware lo ha ejecutado y que la ruta de notificación de finalización (señalización al UMD) está operando de manera correcta. Esta validación es crucial antes de intentar cargas más complejas donde depurar se volvería extremadamente difícil.
kmscube: el clásico cubo girando
Una vez verificado que se podía enviar y completar un job sencillo, llegó el siguiente hito: renderizar una escena 3D mínima con kmscube. Esta herramienta dibuja un cubo rotando en pantalla y es un clásico para probar aceleración 3D porque es simple, auto-contenida y no requiere compositor: la imagen se pasa directamente al driver KMS de pantalla.
Lograr que kmscube funcionara sobre Tyr implicó demostrar varias cosas a la vez: gestión correcta de dependencias entre jobs, sincronización adecuada y manejo fluido de la cola de trabajos. Para esto se apoyaron en una versión ligeramente modificada de las abstracciones de scheduler DRM en Rust propuestas por Asahi Lina tiempo atrás, integrándolas con el diseño particular de Mali CSF.
Además, al mover el renderizado a un contexto offscreen, se pudo medir mejor el rendimiento. En estas pruebas, Tyr fue capaz de alcanzar más de 500 fotogramas por segundo, en línea con el driver en C, lo que refuerza la idea de que la elección de Rust no introduce una penalización significativa en rendimiento a este nivel.
De la demo al escritorio completo: Weston y GNOME
Superada la fase de demos básicas, la siguiente pregunta era evidente: ¿puede Tyr con un escritorio completo? La progresión lógica fue lanzar primero Weston (un compositor Wayland ligero) y más tarde GNOME, que ya es un entorno de escritorio complejo con bastantes elementos gráficos y animaciones.
La sorpresa positiva llegó cuando GNOME mostró correctamente la pantalla de login utilizando Tyr. A partir de ahí, fue posible iniciar sesión, abrir Firefox y reproducir vídeos de YouTube, así como ejecutar vkcube sobre Weston. Todo ello apoyado en el stack gráfico habitual, sin necesidad de modificar Mesa, ya que el prototipo está pensado para trabajar sobre una pila de usuarios estándar y sin parches específicos.
SuperTuxKart: un juego 3D a pantalla completa
El último gran hito de la rama downstream ha sido conseguir que SuperTuxKart, un juego 3D relativamente exigente, se ejecute de forma fluida sobre Tyr. En modo pantalla completa, el juego se renderiza bien y es perfectamente jugable, sin caídas apreciables de rendimiento ni problemas serios de estabilidad durante las pruebas.
No todo está pulido: en modo ventana aún aparecen algunos glitches gráficos, un síntoma claro de que siguen existiendo detalles por ajustar en la integración con el compositor y en la gestión de superficies. Aun así, el hecho de que un juego entero y complejo funcione es una validación muy potente de que el pipeline UMD-KMD-GPU está bien encaminado.
Estado actual en el kernel y funcionalidades pendientes
En la versión 6.18 del kernel, el código upstream de Tyr se describe claramente como un esqueleto inicial de driver Rust para GPUs Arm Mali CSF. Lo que ya está integrado puede encender la GPU, hacer probing del dispositivo, leer metadatos de la ROM vía MMIO y exponer esa información a espacio de usuario por medio de IOCTL.
Sin embargo, gran parte de las capacidades avanzadas del prototipo downstream todavía no son portables a upstream. El bloqueo principal está en la necesidad de introducir más abstracciones en Rust para cosas como la virtualización de memoria de la GPU (GPUVM), la gestión de rangos de direcciones virtuales y el arranque y control del MicroController Unit (MCU) de las GPUs Mali CSF.
Hasta que no exista una infraestructura estable de GPUVM en Rust para el kernel, hay funciones que simplemente no se pueden implementar de forma aceptable upstream. Por eso, de momento, el driver principal no puede arrancar el MCU ni ejecutar trabajos complejos, y el uso real de Tyr en producción sigue limitado a entornos de pruebas y a la rama downstream.
Hardware soportado y cómo probar Tyr
En esta etapa temprana, el soporte de hardware de Tyr se concentra en el SoC Rockchip RK3588, un chip muy popular en placas de desarrollo y dispositivos ARM orientados a multimedia y mini PCs. Un ejemplo concreto y recomendado por los desarrolladores es la placa Radxa ROCK 5B, que combina este SoC con buenas opciones de conectividad y memoria.
La rama downstream tyr-dev se ha probado precisamente sobre un Rock 5B, ejecutando GNOME, Weston y juegos como SuperTuxKart. Es posible que Tyr funcione también en otros dispositivos basados en RK3588, aunque el equipo deja claro que el soporte oficial está centrado en esta plataforma concreta por ahora, y que la compatibilidad con más modelos se irá ampliando progresivamente.
Quien tenga una placa compatible y quiera experimentar con Tyr debe compilar un kernel con las opciones CONFIG_TYR_DRM_DEPS y CONFIG_DRM_TYR activadas. El código se encuentra alojado en la infraestructura de GitLab de Freedesktop y en los repositorios mantenidos por el equipo de Panfrost/Collabora, donde también se detallan las instrucciones para clonar las ramas adecuadas y aplicar los parches necesarios.
En cuanto a pruebas, un buen punto de partida es usar Tyr para ejecutar los tests de IGT desarrollados originalmente para Panthor. En la rama upstream solo pasa un subconjunto, por las limitaciones ya mencionadas. En cambio, ejecutados sobre tyr-dev, deberían superarse todos, lo que ofrece una buena referencia de estabilidad y compatibilidad básica.
Tyr como banco de pruebas para Rust en el kernel
Más allá de la GPU concreta que soporte, Tyr tiene una relevancia especial en el contexto más amplio de la «rustificación» del kernel Linux. Proyectos como el driver Nova para GPUs NVIDIA o el driver NVMe en Rust han demostrado que es viable escribir componentes críticos del kernel en este lenguaje sin sacrificar rendimiento.
Tyr se suma a esta tendencia centrándose en un área especialmente compleja: los controladores gráficos con planificación de trabajos, gestión fina de recursos y fuertes requisitos de seguridad y aislamiento. El prototipo downstream actúa como un laboratorio donde se pueden probar nuevas abstracciones en Rust —para el scheduler, la gestión de memoria, la sincronización o el modelo de drivers de plataforma— y ver cómo se comportan bajo cargas reales.
En este sentido, Tyr también bebe de experiencias anteriores, como el driver Nova y el uso del módulo rust_platform_driver.rs, reutilizando ideas y patrones que ya han demostrado ser útiles. El objetivo es que las lecciones aprendidas no se queden encerradas en un único driver, sino que nutran un conjunto de herramientas y APIs Rust comunes para todo el ecosistema del kernel.
Aunque hoy por hoy Tyr no está listo para ser el driver de uso diario en un escritorio, su existencia demuestra que los drivers de GPU escritos en Rust pueden igualar el rendimiento de sus equivalentes en C y sirven como referencia para futuros desarrollos en otras familias de hardware gráfico, de almacenamiento o de red.
Cómo contribuir y seguir la evolución del proyecto
El proyecto Tyr es software libre y se desarrolla de forma abierta. Cualquier persona interesada puede seguir el estado de las tareas en el issue board del proyecto, donde se irán publicando también trabajos etiquetados como «buenos para empezar» cuando el equipo los tenga listos.
Para colaborar de forma efectiva, se recomienda asignarse una tarea en el tablero y, una vez completada, enviar una merge request a la rama que corresponda: tyr-for-upstream para cambios pensados en el código que acabará en el kernel principal, o tyr-dev para mejoras y experimentos en la rama downstream. En ambos casos, es muy importante acompañar las contribuciones con tests adecuados en IGT u otras suites de pruebas, para garantizar que el nuevo código no rompe funcionalidades existentes.
Además del propio repositorio, el blog de Collabora publica una serie de artículos técnicos donde se explica en profundidad la arquitectura de Mali CSF, la interacción entre aplicaciones Vulkan/OpenGL y el hardware, y el proceso de escritura de un driver en Rust apoyándose en las abstracciones del kernel. Estos artículos son una referencia muy valiosa para cualquiera que quiera entender el stack abierto de Mali desde la aplicación hasta el silicio.
La comunicación técnica con el ecosistema del kernel se canaliza también a través de las listas de correo dri-devel y rust-for-linux, donde se discuten las decisiones de diseño más delicadas, se revisan parches y se coordinan cambios con otros proyectos que están usando Rust en distintas partes del kernel.
A día de hoy, Tyr se encuentra en un punto interesante: ya ha demostrado que puede mover escritorios completos y juegos en su prototipo downstream, pero aún le falta recorrido para ofrecer la misma robustez y compatibilidad que Panthor en entornos de producción. Sin embargo, el camino que está trazando —tanto en términos técnicos como de modelo de colaboración— lo convierte en una pieza clave dentro del movimiento que está llevando Rust al corazón del kernel Linux y, de paso, abriendo una nueva etapa para los drivers de GPU de código abierto en plataformas Arm Mali.
