Driver GPU Linux para M4 Mac Mini: hecho por IA en un mes

Un driver OpenGL ES 3.0 para el M4 Mac Mini terminado en un mes

Cody Ho y Niklas Sheth publicaron el código fuente de un driver OpenGL ES 3.0 funcional para el M4 Mac Mini y el MacBook Neo, escrito en aproximadamente un mes. Según detallan en su blog personal, lo que normalmente toma años lo cerraron en semanas mediante una combinación poco habitual: un hipervisor propio para capturar trazas del firmware de Apple y un agente de codificación (OpenAI Codex con GPT-5.6 Sol) que asumió la mayor parte del trabajo de reverse engineering. Las pruebas que muestran incluyen Chrome y Firefox corriendo WebGL, y Minecraft a 200 fps sobre el M4.

Qué construyeron exactamente

El driver no es solo un prototipo: según los repositorios que ambos autores enlazan en su post (la rama niklassheth/mesa y GravityLinux/linux/gravity-m4 en GitHub), incluye:

Un kernel driver para Linux escrito en Rust, siguiendo el patrón del drm-shim original del proyecto Asahi.
Un controlador de user-space que traduce entre Gallium (la API interna de Mesa) y el ISA propietario de la GPU AGX de Apple.
Un compilador de shaders propio que toma el IR interno de Mesa (NIR, similar a LLVM IR) y lo convierte al set de instrucciones de Apple.
Implementación OpenGL ES 3.0 completa y conforme al test suite de Khronos; los tests que no pasan son extensiones opcionales.

Los autores explican que los renders parciales (partial renders) fueron el mayor dolor de cabeza técnico: ocurren cuando el Tiled Vertex Buffer no entra la geometría y el driver tiene que pausar, guardar y reanudar el render. Esa lógica es, en palabras de Ho, esencialmente «save and resume» aplicado a la GPU.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El método: hipervisor + agente de codificación

Ho construyó previamente un hipervisor sobre macOS que le permite capturar el estado completo de memoria que macOS presenta al firmware de Apple, sin inspeccionar binarios propietarios. Esa pieza ya existía y se describe en su post anterior.

Sobre esa base, el flujo con Codex consistió en:

Pedir al agente que reproduzca una captura del estado de la GPU y luego intente reconstruir los objetos en código hasta poder generarlos desde cero.
Aislar capturas pequeñas, arrancando en single-user mode para evitar trabajo del GUI, hasta que cada traza tuviera el mínimo ruido posible.
Dejar que el agente reduzca incrementalmente el estado copiado de la captura, hasta desaparecer y dejar solo el código generado.

El propio Ho describe a Codex como «pedante»: excelente cuando la tarea requiere meticulosidad, pero propenso a atascarse en minucias. La estrategia que mejor rindió fue dejar de intentar hacer reverse engineering «sobre metal» y construir Mesa primero, usando el software real como ancla, igual que la ingeniería inversa tradicional cuando tiene un test suite como referencia.

Por qué importa el stack de GPT-5.6 Sol

El modelo que Ho usó para la mayor parte del trabajo fue GPT-5.6 Sol, lanzado por OpenAI el 9 de julio de 2026 con precios de US$5 por millón de tokens de entrada y US$30 por millón de salida, según la nota de 9to5Mac sobre el anuncio. TechCrunch, citando al CEO Sam Altman, reportó que Sol es 54% más eficiente en tokens para tareas de coding que su predecesor.

Ho destaca en su post que GPT-5.6 Sol fue especialmente bueno para reverse engineering de ABI de firmware y para depurar de forma sistemática usando el propio hipervisor (capturar el address space completo y comparar con muestras conocidas como buenas). El autor tuvo incluso que implementar un daemon casero que tomaba capturas de pantalla cada minuto y reenviaba /goal resume cuando Codex se quedaba bloqueado por las restricciones de ciberseguridad del modelo.

El contexto: Apple Silicon en Linux lleva años en construcción

El proyecto Asahi Linux trabaja desde 2021 intentando llevar Linux a Macs ARM. Su mayor referente, Alyssa Rosenzweig, escribió el driver para M1 y M2 en jornadas de 12 horas, según reconocen Ho y Sheth en su blog. Hasta enero de 2026, Asahi había logrado arrancar Linux en chips M3 pero la GPU seguía usando LLVMpipe (renderizado por software), reportó AppleInsider el 27 de enero de 2026; esa misma nota señalaba que ya existían contribuidores intentando soporte básico en Alpine Linux para M4.

Lo publicado por Ho y Sheth es, en la práctica, el primer soporte de aceleración gráfica funcional sobre M4 corriendo Linux. Su propio roadmap incluye OpenGL 4.6, OpenGL ES 3.2, Vulkan 1.4, OpenCL 3.1, Direct3D 12 vía Proton y ray tracing.

El obstáculo humano: el upstream del kernel de Linux

Antes de distribuir el driver a usuarios finales queda un cuello de botella que la IA no puede destrabar: el upstream del kernel. Ho señala que el driver de Asahi para M1/M2 todavía no está en el kernel mainline y que cualquier intento de subir el suyo primero chocaría con la política de revisión.

La estrategia de los autores es esperar a que el driver de M1/M2 suba, después de meses o más de revisión y refactor, y entonces enviar el suyo. Anticipan un estándar de revisión más estricto del habitual: sospechan que, al ser posiblemente el primer driver de GPU completo escrito por una IA, el código será examinado con lupa, según detallan en el propio blog.

Qué significa esto para tu startup

Tu hardware Apple Silicon ya tiene un camino técnico para correr Linux con GPU acelerada. Si tienes un M4 Mac Mini infrautilizado, existe la base para correr carga Linux con aceleración gráfica. No es producto terminado: hoy corre Chrome, Firefox y Minecraft, no reemplaza la pila CUDA de NVIDIA ni ejecuta binarios propietarios de Apple. Pero el techo subió.
Los agentes de código ya operan en territorios que antes estaban reservados a especialistas. Reverse engineering de ABI, compilación de IR a ISA propietarios, kernels de baja latencia: tareas que requerían consultores senior y meses. Si tu producto choca con este tipo de problemas, vale la pena evaluar Codex sobre GPT-5.6 Sol (o superiores) antes de asumir que sigue siendo coto privado de ingeniería manual.
El «tiempo de proyecto» cayó, pero el «tiempo de aceptación» sigue ahí. El código estuvo listo en un mes; llevarlo a usuarios reales depende de reviewers humanos en Mesa y en el kernel de Linux. El cuello de botella se movió de la ingeniería al proceso.