Construir un controlador de GPU funcional para hardware moderno es una hazaña de ingeniería ardua que a menudo requiere años de ingeniería inversa manual. Para el Silicon de Apple, el desafío se ve agravado por la arquitectura de GPU 'AGX', que utiliza una ABI (Interfaz de Aplicación Binaria) de firmware compleja. En este sistema, el controlador del kernel de Linux no se comunica directamente con el hardware; en su lugar, interactúa con el firmware de la GPU que ejecuta un sistema operativo en tiempo real personalizado (RTKit). Los desarrolladores de un nuevo controlador para el Mac Mini M4 y el MacBook Neo se enfrentaron a un obstáculo particularmente desalentador: la ABI del firmware del A18 Pro es significativamente más compleja que las generaciones anteriores, con 1.5 veces más estructuras y el doble de punteros, lo que hace que la reconstrucción manual sea extremadamente difícil.
El artículo describe el desalentador obstáculo de la complejidad de la ABI del firmware del A18 Pro en comparación con las generaciones anteriores.
Para superar esto, el equipo empleó una metodología centrada en el rastreo de hardware y las mecánicas de 'reproducción'. Al utilizar un hipervisor construido a medida, pudieron observar exactamente cómo macOS interactuaba con la GPU y luego reproducir esas trazas de hardware. Esto les permitió alimentar capturas específicas y aisladas en un LLM (Codex) para deconstruir las estructuras de memoria compartida del firmware. Por ejemplo, cuando se enfrentaron a una traza de computación masiva de 336 MB que inicialmente era imposible de reproducir, el equipo cambió a una estrategia de 'modo de usuario único'. Al arrancar sin una interfaz gráfica y ejecutar un programa de computación puro y pequeño, capturaron una traza mucho más pequeña y manejable que el LLM pudo deconstruir en código utilizable en pocos días. Este proceso se dividió en dos mitades: el espacio del kernel, que gestiona la interfaz con el firmware y la asignación de búferes, y el espacio de usuario, que maneja el compilador de sombreadores y la construcción del flujo de comandos.
El proyecto también destacó las distintas compensaciones de utilizar agentes de IA para ingeniería compleja. El autor señaló que, si bien el LLM fue muy eficaz en la depuración sistemática —como comparar espacios de direcciones completos con muestras conocidas buenas— también podía ser 'pedante'. Un desarrollador descubrió que un agente centrado en la integridad del hardware a menudo se quedaba atascado en detalles menores e insignificantes. En contraste, un segundo desarrollador vio un progreso más rápido al usar un agente 'anclado' por la necesidad de construir primero la pila gráfica Mesa, realizando ingeniería inversa solo cuando era necesario para desbloquear funcionalidades específicas. Aunque el controlador resultante es lo suficientemente rápido como para ejecutar Minecraft a 200 fps y es compatible con WebGL en Chrome y Firefox, los autores aclaran que el código aún no está listo para usuarios finales generales y que funciones complejas como los 'renderizados parciales' siguen siendo muy difíciles de estabilizar.
El texto menciona que el controlador es lo suficientemente rápido como para ejecutar Minecraft a 200 fps.
El artículo señala que el controlador es compatible con WebGL en Chrome y Firefox.
Este rápido desarrollo ha generado debate sobre la procedencia y el futuro de dicho código. Debido a que el proyecto utilizó LLMs para navegar por hardware propietario, enfrenta posibles fricciones con proyectos como Asahi Linux, que mantienen una política estricta de 'no IA' para la integración de código en el flujo principal. Además, el uso de código generado por IA para interactuar con hardware propietario plantea interrogantes sobre la naturaleza 'contaminada' de los binarios resultantes y si este tipo de trabajo podrá alguna vez ser aceptado oficialmente en el kernel de Linux. Por ahora, el proyecto sirve como una prueba de concepto de que la ingeniería inversa asistida por IA puede reducir el cronograma de portabilidad de hardware de años a semanas.