Un driver GPU para el M4 en un mes: el truco es no entenderla entera

Cody Ho cuenta en I Came, I Prompted, I Left Part 2 que, con Niklas, montaron un driver GPU compatible con OpenGL ES 3.0 para el M4 Mac Mini y el MacBook Neo en aproximadamente un mes. El propio autor dice que ese trabajo suele llevar años.

La lectura fácil es que un modelo se comió la curva. El mismo relato apunta a otra palanca: no se sentaron a entender la GPU del M4 de punta a punta. Encogieron el problema hasta que cupiera en un compilador que ya existía y en una batería de tests que ya existía. El mes sale de lo que decidieron no aprender.

En Apple Silicon el driver de kernel no habla con el silicio. Habla con el firmware de la GPU, que corre un RTOS propio llamado RTKit. El primer paso no es el hardware: es el ABI de ese firmware y el user-space que lo alimenta. Eso lo hicieron, según Ho, en modalidad clean room verificable. Y deja una frase que debería ir en negrita en cualquier hilo de Hacker News: el código aún no está listo para usuarios finales.

Mesa ya había partido el trabajo

El stack se apoya en Mesa. Traducen de Gallium, la API interna de Mesa, y de NIR, el IR interno de Mesa, parecido a LLVM IR, a la ISA propietaria del AGX, el nombre de Apple para su GPU. Ese compilador, dice el post, es reutilizable para un futuro driver Vulkan. Vulkan no está hecho. El camino de traducción sí.

Gallium es el enchufe. NIR es el idioma intermedio. La ISA del AGX es el dialecto que no viene en ningún PDF. Si te tragas las tres capas a la vez, tienes un doctorado. Si Mesa te deja las dos primeras, te queda una traducción. Eso es lo que cabe en un mes con un agente que cierra huecos contra una prueba.

Niklas apostó por Mesa first: construir Mesa e invertir solo lo necesario. Ese enfoque, cuenta Ho, avanzó mucho más rápido que invertir primero todo el hardware y luego escribir una spec completa. En el segundo plan el agente se pierde persiguiendo completitud en tareas menores.

La palanca no es escribir más rápido. Es decidir qué no hace falta entender.

Quien venda esto como "la IA comprime años" está mirando el calendario y no el recorte. El recorte es editorial: qué capa ya está resuelta, qué ABI sí hay que pinchar, qué feature se deja para el test de mañana. Sin esa tijera, el modelo te genera una especificación infinita con cara de progreso.

El CTS como oráculo, no como diploma

El otro medio problema ya estaba resuelto desde fuera. La suite de tests de compatibilidad de Khronos (CTS) funcionó como corpus exhaustivo para validar el driver. Ho lo formula sin adorno: resolvía dar a los LLM buenos tests que los guíen.

Eso no es un truco de prompting. Es el mismo patrón de siempre con agentes que "hacen TDD": si el test lo escribe el propio modelo, el teatro sustituye a la prueba. Lo contamos cuando decirle TDD al agente no lo convierte en verificador. Aquí el CTS no es un ritual. Es un oráculo que ya existía, escrito por gente que no estaba en la habitación, con casos que el modelo no puede redefinir a su favor.

Sin ese arnés, el LLM genera driver con cara de driver. Con el arnés, cada instrucción inventada o cada flag mal alineado revienta un caso concreto. El trabajo humano se desplaza: elegir el siguiente fallo, no redactar las siguientes mil líneas. Quien no tenga un juez así no tiene un mes. Tiene un chatbot con opiniones sobre GPUs.

Lo que sí hubo que invertir

En esas semanas invirtieron el user-space del M4, del A18 Pro y, en gran parte, del M5 usando solo live probing. Descubrieron instrucciones y features de hardware que el driver oficial de Apple no emite. El alcance exacto de ese "en gran parte" del M5 no consta en las fuentes consultadas; el propio relato lo deja ahí.

Compute se resolvió por el lado estrecho. Arrancaron en single-user mode, sin render, instalaron un LaunchDaemon que ejecutara un programa Metal mínimo y capturaron ese trace puro. Codex lo descompuso en horas y tuvieron compute funcionando en días. Un único programa. Un único rastro. Generalizar ese mínimo al resto de compute es el trabajo que el mes no cierra.

Los partial renders fueron de lo más difícil. Cuando el Tiled Vertex Buffer no cabe la geometría, el driver tiene que guardar y reanudar: save and resume a escala de GPU. Los dominaron forzando partial renders con miles de triángulos en un solo tile y aprendiendo a hacer replay. Ahí Mesa no te regala el mecanismo. Ahí sí hay que mirar el hardware.

Ese es el inventario honesto: el ABI del firmware, el user-space que Apple no documenta, y los modos de fallo que el stack abierto no cubre. El resto es traducción y tests. Si tu plan empieza por "entender toda la GPU y luego programar", estás en el enfoque que aquí perdió.

Lo que el mes no entrega

Los entregables están en repos de los autores: Mesa en github.com/niklassheth/mesa y el driver de kernel Linux en github.com/GravityLinux/linux/gravity-m4, más documentación de ingeniería inversa de user-space. En las fuentes consultadas no consta que eso esté fusionado en Mesa upstream ni en el kernel Linux oficial. El repo no es una distro.

Tampoco hay, en lo publicado, Vulkan, OpenCL ni el resto de APIs más allá de OpenGL ES 3.0. El propio autor los deja como trabajo pendiente. El "un mes" es su versión del calendario; no hay verificación independiente del cronograma en las fuentes consultadas. Y Apple no documentó ni colaboró: todo salió de ingeniería inversa sin documentación útil de la compañía.

Quien lea el titular como "el hardware se escribió solo" se salta la deuda: compute nació de un único trace puro, los partial renders se aprendieron torturando un tile, y lo que queda es generalizar ese mínimo a cada ruta que el CTS todavía no ha obligado a tocar.

La IA no convierte años en un mes. Convierte un problema ya encogido, Mesa de arquitectura, CTS de juez, un humano decidiendo qué no invertir, en parches que se pueden verificar. Sin ese encuadre, el mismo músculo persigue una spec que no termina. Con él, un driver de prueba de concepto cabe en un repositorio. Usarlo el domingo en tu portátil es otra frase, y el autor no la dice.

Preguntas frecuentes

¿Se puede usar ya en Linux el driver GPU del M4 de Cody Ho?

Cody Ho y Niklas publicaron un driver compatible con OpenGL ES 3.0 para el M4 Mac Mini y el MacBook Neo, con código en repos propios. El autor dice que aún no está listo para usuarios finales. En las fuentes consultadas no consta que esté fusionado en Mesa upstream ni en el kernel Linux oficial.

¿El driver del M4 soporta Vulkan u OpenCL?

No consta soporte de Vulkan, OpenCL ni del resto de APIs más allá de OpenGL ES 3.0. El compilador de Mesa que traduce Gallium y NIR a la ISA del AGX se señala como reutilizable para un futuro driver Vulkan. Reutilizable no es que esas APIs ya corran.

¿Cómo se hace un driver GPU en un mes?

Según Cody Ho, el plazo salió de apoyarse en Mesa, usar el CTS de Khronos como batería de tests para los LLM, e invertir solo el ABI del firmware AGX y el user-space imprescindible. La