Dos desarrolladores pasaron un mes construyendo un controlador de GPU de Linux para el M4 Mac Mini desde cero, y ahora quieren que todos vean cómo lo hicieron. El resultado ejecuta Chrome, Firefox y Minecraft en la máquina, y la pareja publicó cada experimento a lo largo del camino para que cualquiera pueda verificar su trabajo.
El proyecto se llama «Construyendo un controlador de GPU de Linux para el M4 Mac Mini en un mes». Es la segunda parte de una serie, con la primera cubriendo un hipervisor construido para la ingeniería inversa de macOS. El objetivo era simple: un controlador de GPU totalmente compatible con OpenGL ES 3.0 para el M4 Mac Mini y el MacBook Neo, una tarea que normalmente toma años.
Lo que Realmente Construyeron
Niklas y el desarrollador detrás de la publicación del blog crearon una pila de controladores completa. En el lado del usuario, construyeron un compilador de sombreadores personalizado, un constructor de flujo de comandos y un controlador funcional que habla OpenGL ES 3.0. En el lado del kernel, hicieron ingeniería inversa de la ABI de firmware AGX desde cero, luego escribieron un controlador de Linux completo para él.
La prueba está en las demostraciones. Chrome y Firefox ejecutan WebGL en el M4 Mac Mini con composición funcional. Minecraft se ejecuta a 200 fotogramas por segundo. Ninguna de esas cosas debería funcionar en una caja de Linux sin un controlador, y ambas lo hacen ahora.
La pareja también documentó su trabajo en dos repositorios bajo Entregables, donde publicaron todos sus experimentos. El punto es la transparencia: cualquiera que quiera verificar la procedencia de su trabajo puede seguir los pasos ellos mismos.
Cómo Llegaron Ahí
El proyecto comenzó con un hipervisor que permitió al equipo observar lo que hace macOS cuando habla con la GPU. A partir de ahí, el enfoque fue simple: observar el sistema operativo, repetir sus acciones, luego intentar hacer lo mismo desde cero.
La herramienta de LLM, Codex, ayudó con el trabajo de repetición. Capturó todo el estado de la memoria de la GPU cuando ocurrió un «golpe» de firmware, luego copió ese estado de nuevo en la memoria del host después de un reinicio. La herramienta luego intentó reconstruir los objetos en código, siguiendo punteros y dándole sentido al contenido. Con el tiempo, Codex redujo la cantidad de estado reproducido hasta que todo fue construido desde la fuente.
El desarrollador notó que Codex tenía buen criterio sobre cuándo interactuar con el hardware y cuándo ejecutar el hipervisor y capturar el estado en sí mismo. Esa observación se convirtió en una parte clave del flujo de trabajo.
El Problema de la ABI del Firmware
La parte más difícil del proyecto fue la ABI del firmware. El firmware de la GPU de Apple ejecuta un RTOS personalizado llamado RTKit, y el controlador del kernel se comunica con él a través de memoria compartida. Eso significa que la ABI está dividida entre dos mundos: la memoria propia del firmware y la memoria del host.
Muchos de los structs compartidos tienen campos propiedad del firmware que el controlador nunca debe modificar. Esos campos deben ser aprendidos a través de ingeniería inversa. La ABI es lo suficientemente complicada que el desarrollador la comparó con el trabajo del controlador del kernel M1/M2 realizado por Asahi Lina, calificándolo de «asombroso».
Pero la ABI del firmware A18 Pro es aún más difícil. Tiene más structs que el M1, más punteros y un proceso más complicado para enviar trabajo. El desarrollador señaló la complejidad en una observación directa: «Pero, ¿qué demonios?, Apple».
El desarrollador tenía cierta documentación sobre la ABI del firmware, pero esta era altamente incompleta y poco útil. El enfoque permaneció igual: observar lo que hace macOS, reproducirlo y luego reconstruirlo desde cero.
Los Tres Grandes Problemas
El desarrollador identificó tres problemas mayores durante el proyecto, y todos ellos se reducían a una sola cosa: obtener una captura limpia del trabajo del host.
- El trabajo de renderizado enviado después de que el firmware de la GPU comenzara sería reconocido y archivado sin realmente hacer nada.
- El trabajo de renderizado enviado antes de que el firmware comenzara sería reconocido y archivado sin realmente hacer nada.
- El trabajo enviado durante la secuencia de inicio del firmware sería reconocido y archivado sin realmente hacer nada.
En cada caso, el problema era el mismo: el controlador podía enviar comandos, pero la GPU no los ejecutaba. La solución, en cada caso, era averiguar qué esperaba el firmware y proporcionárselo.
El Enfoque de la Habitación Limpia (
El dúo trató los «blobs» de Apple como objetos opacos durante todo el proyecto. Un amigo escribió documentación sobre estos «blobs», la cual el equipo utilizó para construir una implementación de habitación limpia. La mayor parte del trabajo en el espacio de usuario se realizó probando cosas al azar hasta que funcionaran.
El controlador del kernel, por el contrario, se construyó desde cero utilizando únicamente rastreos de hardware del hipervisor y shaders construidos por el equipo. No hubo “piar” a los binarios de Apple.
Esa distinción es importante. La ingeniería inversa de gráficos en el espacio de usuario es difícil porque los «blobs» están cerrados, pero la ABI del kernel es pública en espíritu si no en nombre. El enfoque del equipo fue mantener los dos lados separados: el espacio de usuario se mantiene limpio, el espacio del kernel se mantiene documentado.
Lo Que Viene a Continuación (
El controlador aún no está listo para usuarios finales. Pero el dúo busca entregárselo lo antes posible.
El trabajo tampoco está terminado. El plan incluye soporte Vulkan más allá de OpenGL. El equipo ha publicado todos sus experimentos, y los repositorios permanecen disponibles para cualquiera que quiera verificar la procedencia de su trabajo.
El enfoque del dúo merece ser mencionado. No ocultaron sus fracasos ni sus callejones sin salida. Publicaron todo, incluidos los experimentos que no funcionaron. Ese tipo de transparencia es rara en este campo.
Por Qué Esto Importa (
Un controlador de GPU para Linux en Apple Silicon es un gran acontecimiento. Significa que el mundo de código abierto puede comunicarse con estos chips sin depender de los binarios de Apple. Significa que el hardware no está bloqueado detrás de «blobs» no documentados.
El hecho de que haya tomado un mes es la verdadera sorpresa. Un mes es una mejora masiva con respecto a años, y el equipo admite que días fue demasiado optimista. Pero semanas sigue siendo una gran victoria.
El proyecto también muestra cómo se ve la ingeniería inversa moderna. No es un arte oscuro realizado en secreto. Es un proceso transparente y documentado que cualquiera puede seguir. El uso del hipervisor y Codex por parte del dúo es un ejemplo práctico de cómo el aprendizaje automático puede ayudar con el trabajo de sistemas de bajo nivel.
La obra es impresionante. La transparencia es admirable. Y el hecho de que Minecraft funcione a 200 fps en una caja Linux es solo la guinda del pastel.
Cualquiera que alguna vez haya querido ejecutar un juego en una plataforma no estándar conoce esa sensación. El dúo lo hizo posible y se llevaron todo el cuaderno para el viaje.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.