- Se ofrece un controlador para Linux capaz de ejecutar aplicaciones OpenGL ES 3.1 de forma estándar en GPUs de la familia M1·M2
- El controlador libre y de código abierto de Asahi Linux, basado en ingeniería inversa, es la única implementación de OpenGL ES 3.1 en hardware gráfico M1·M2 que ha superado las pruebas de conformidad de Khronos
- La certificación requiere aprobar las pruebas oficiales, presentar los resultados ante Khronos y pasar un periodo de revisión de 30 días; ya quedaron registrados M1, M1 Pro/Max/Ultra, M2 y M2 Pro/Max
- OpenGL ES 3.1 actualiza el soporte experimental de OpenGL ES 3.0 y OpenGL 3.1 lanzado en junio, y añade compute shaders y operaciones atómicas sobre imágenes
- Como el M1 no tiene instrucciones dedicadas para operaciones atómicas sobre imágenes, se recurrió a un cálculo de direcciones; después se encontró una instrucción de intercalado de bits que redujo 10 instrucciones a 1
Certificación de conformidad OpenGL ES 3.1 para M1·M2
- Ya está disponible un controlador con certificación de conformidad OpenGL ES 3.1 para GPUs de la familia M1·M2
- Es compatible con aplicaciones OpenGL ES 3.1
- Puede usarse con una instalación de Linux
- Los usuarios actuales de Asahi Linux pueden obtener el controlador más reciente con el comando de actualización correspondiente a su distribución
- Fedora:
dnf upgrade - Arch:
pacman -Syu
- Fedora:
- El controlador gráfico libre y de código abierto basado en ingeniería inversa está publicado en asahi/mesa
- Este controlador es la única implementación con certificación de conformidad OpenGL ES 3.1 del mundo sobre hardware gráfico de la familia M1·M2
- Superó decenas de miles de pruebas para demostrar su exactitud
- Recibió el reconocimiento del organismo de estándares de la industria
Proceso de Khronos y familias de chips registradas
- Para obtener la certificación de conformidad, una implementación debe superar el suite oficial de pruebas de conformidad
- El suite de pruebas está diseñado para verificar todas las funciones de la especificación
- Los resultados se envían al organismo de estandarización Khronos
- Si no hay problemas durante el periodo de revisión de 30 días, pasa a ser una implementación con certificación de conformidad
- En el sitio web de Khronos aparecen registrados como implementaciones conformes los siguientes controladores
- Este logro no se limita solo a OpenGL ES
- Es la primera implementación con certificación de conformidad en todo el ecosistema de estándares gráficos para M1
La brecha entre los controladores del fabricante y las API estándar
- El controlador del fabricante para M1 no ha obtenido certificación de conformidad en ninguna API gráfica estándar, incluyendo Vulkan, OpenGL y OpenGL ES
- En entornos M1·M2 que no usan Linux, no hay garantía de que las aplicaciones basadas en estándares funcionen correctamente
- En el caso de Vulkan, MoltenVK superpone parte de Vulkan sobre un controlador privativo
- A ese controlador privativo le faltan funciones esenciales
- Las aplicaciones Vulkan válidas pueden fallar
- Esto se convierte en un obstáculo tanto para desarrolladores como para usuarios que no han migrado sus equipos M1·M2 a Linux
- El desarrollo del controlador de Asahi Linux busca que el software estándar funcione en M1 sin hacks exclusivos ni ports específicos
- No se conforma con controladores privativos, API privativas ni con rechazar implementaciones estándar
- Considera que una implementación de estándar abierto es la dirección deseable para el ecosistema
Funciones clave añadidas en OpenGL ES 3.1
- OpenGL ES 3.1 actualiza el soporte experimental de OpenGL ES 3.0 y OpenGL 3.1 presentado en junio
- La principal función añadida son los compute shaders
- Se usan sobre todo para acelerar cálculos generales dentro de aplicaciones gráficas
- Los juegos 3D pueden ejecutar simulaciones de física en compute shaders
- Si el resultado de la simulación se usa de inmediato para el renderizado, se reducen las pausas causadas por la sincronización entre la GPU y la simulación física en la CPU
- Como resultado, el juego puede ejecutarse más rápido
Por qué se necesitan operaciones atómicas sobre imágenes
- Las versiones anteriores de OpenGL ES permitían que las aplicaciones leyeran imágenes para mostrarlas en pantalla
- ES 3.1 permite que las aplicaciones escriban en imágenes, normalmente desde compute shaders
- Esto reduce la necesidad de adaptar algoritmos de procesamiento de imágenes al pipeline 3D de función fija
- La GPU es una arquitectura masivamente paralela que ejecuta miles de hilos al mismo tiempo
- Si dos hilos escriben en la misma ubicación, el resultado cambia según el orden de ejecución
- A esta situación se le llama condición de carrera
- El acceso atómico a memoria es la solución básica para manejar condiciones de carrera
- Hardware especial del subsistema de memoria garantiza resultados consistentes para ciertas operaciones, sin importar el orden de los hilos
- El hardware gráfico moderno admite varias operaciones atómicas, como la suma
- La extensión de OpenGL ES OES_shader_image_atomic añade operaciones atómicas sobre píxeles de imagen
- Esta extensión es obligatoria en ES 3.2
- Por ejemplo, un compute shader puede incrementar de forma atómica el valor del píxel
(10, 20)
Cómo se implementaron las operaciones atómicas sobre imágenes en M1
- Otras GPUs ofrecen instrucciones dedicadas para operaciones atómicas sobre imágenes, lo que simplifica la implementación del controlador
- El M1 no tiene instrucciones de hardware dedicadas para operaciones atómicas sobre imágenes
- Sí tiene operaciones atómicas no relacionadas con imágenes
- También tiene funciones de imagen no atómicas
- Por eso, en lugar de realizar la operación atómica directamente sobre el píxel, se calcula la dirección de memoria del píxel y luego se aplica una operación atómica general sobre esa dirección
- Si la imagen estuviera organizada linealmente en memoria, calcular la dirección sería sencillo
- Se multiplica la coordenada Y por el stride, es decir, los bytes por fila
- Se multiplica la coordenada X por los bytes por píxel
- Se suman ambos valores para obtener el offset en bytes respecto al primer píxel
- Se suma ese offset a la dirección del primer píxel para obtener la dirección final
- En la práctica, las imágenes normalmente no se organizan de forma lineal
- El hardware gráfico moderno intercala coordenadas X·Y para mejorar la eficiencia de caché
- La disposición de los píxeles en memoria no sigue filas, sino una curva cercana a una espiral
Optimización con intercalado de bits y búsqueda de una instrucción oculta
- Intercalar las coordenadas X·Y enmascarando y desplazando un bit a la vez es ineficiente
- Un conocido algoritmo de manipulación de bits mezcla grupos de bits para paralelizar el problema
- Implementar este algoritmo en código de shader mejora el rendimiento
- En la práctica, solo se intercalan los 7 bits menos significativos o menos de cada coordenada
- Es posible colocar X·Y en las mitades baja y alta de un registro de 32 bits para procesarlos al mismo tiempo con una instrucción de 32 bits
- Eso reduce a la mitad la cantidad de instrucciones
- También se aprovecha la instrucción combinada de shift-and-add de la GPU
- Al combinar estas técnicas, se pudo realizar el intercalado con 10 instrucciones de ensamblador de la GPU M1
- Después se investigó la posibilidad de una instrucción dedicada de intercalado de bits
- PowerVR tiene la instrucción shuffle
shfl - Como la GPU M1 incorpora elementos tomados de PowerVR, se consideró posible la existencia de una instrucción similar
- El compilador privativo no usaba esa instrucción al compilar shaders de prueba, así que observar los resultados de compilación no bastaba para hacer ingeniería inversa
- PowerVR tiene la instrucción shuffle
Confirmación de la instrucción de intercalado mediante hipótesis y verificación
- Dougall Johnson dedujo un candidato a partir de codificaciones de instrucciones ya conocidas
- La instrucción de inversión de bits tiene un campo de 2 bits para especificar la operación, y su valor es
01- La instrucción para contar bits activados usa
10 - La instrucción para encontrar el primer bit activado usa
11 - Las instrucciones complejas de manipulación de bits conocidas usan esos tres valores
- La instrucción para contar bits activados usa
- El valor restante,
00, era un valor desconocido que no se había observado- Si existía una instrucción de intercalado, se consideró que podría parecerse a la de inversión de bits pero con código de operación
00
- Si existía una instrucción de intercalado, se consideró que podría parecerse a la de inversión de bits pero con código de operación
- Las tres instrucciones conocidas solo tienen una fuente de entrada, pero una instrucción de intercalado requiere dos
- Las instrucciones de la GPU M1 normalmente codifican las posiciones de origen de forma consistente
- En el lugar donde estaría la segunda fuente en una instrucción aritmética de dos fuentes había un espacio vacío, y se supuso que ese era el segundo origen
- La verificación se hizo modificando el compilador para reemplazar una operación entera de dos fuentes, como una multiplicación, por la codificación estimada de intercalado
- Se usó esa operación en un compute shader
- El shader de prueba comprobó si la instrucción desconocida devolvía el resultado de intercalado para cada entrada posible
- Como la instrucción recibe dos fuentes de 16 bits, había alrededor de 4 mil millones de entradas
- Gracias al nuevo soporte de cómputo del controlador, la GPU M1 verificó todas las entradas en menos de 1 segundo
- Al final, el ensamblador vectorizado de 10 instrucciones se reemplazó por 1 sola instrucción de intercalado
- Este método es rápido y además supera las pruebas de conformidad
1 comentarios
Opiniones de Hacker News
Me pregunto si el soporte de OpenGL/Vulkan mejorará ahora que Apple colabora con nVidia, Adobe, Autodesk, Microsoft y otros en OpenUSD, el formato para renderizado/animación/CAD/escenas 3D.
Si la esencia de OpenUSD es “un único formato de archivo que se renderiza de forma consistente en todas partes”, Apple podría usarlo como un medio para atraer a más empresas de software 3D a macOS.
De aquí en adelante, parece haber dos caminos: que Apple adopte los estándares OpenGL/Vulkan existentes, que tienen peso en los pipelines de producción de cine y videojuegos, o que, por el contrario, impulse Metal con más fuerza para llevar al mundo hacia Metal + macOS.
Mi corazón espera lo primero, pero mi intuición me dice que Apple empujará con todo lo segundo; y no solo Apple, sino también nVidia, Autodesk, Adobe y Microsoft tienden a no preferir estándares que no controlan.
El iMac y las primeras versiones de OS X destacaban mucho estándares como USB, JPEG, MPEG, mp3, PostScript, TCP/IP integrado y .rtf, y Jobs también hacía énfasis en eso.
Después, al recuperarse del borde del abismo, volvió a empezar a “agregar valor”; y el iPhone, al principio, también se promocionaba como un dispositivo HTML en lugar del Flash propietario y pésimo o del inmaduro “HTML móvil”.
Incluso ahora, en áreas donde su dominio de mercado es débil, da soporte a estándares que no controla, como H.264 y Matter/Thread.
Como integra fuertemente hardware y software para crear la experiencia de usuario que busca, se entiende su postura de querer implementar estándares que pueda controlar hasta cierto punto para que esa experiencia no quede a merced de otros.
También hay casos en los que Apple adopta estándares industriales cuyo rumbo aún no está definido, como USB-C, porque si se mueve temprano puede influir en su dirección.
La mayoría, como Adobe, Autodesk y Blender, ya soportan distintos backends según el sistema operativo, y en macOS eso también incluye Metal.
OpenGL es demasiado viejo, usar buenos drivers es casi una pesadilla, e incluso escribir código de aplicaciones con buen rendimiento es difícil, así que no lo lamento.
Eso sí, me habría gustado que impulsaran Vulkan en vez de crear Metal, pero fuera de Linux Vulkan suele ser casi un ciudadano de segunda clase; aun así, es un ciudadano de segunda bastante aceptable como objetivo.
Desde el punto de vista de los juegos o del soporte de Steam, muchos juegos dejan el manejo de la API en manos del motor, y si un equipo tiene la capacidad de tratar directamente con la API, probablemente le vaya bien con MoltenVK siempre que no use funciones de vanguardia.
He usado mucho OpenGL toda la vida por ser multiplataforma, pero por el estado global, las funciones que no deberías usar, las trampas, los enormes headers de extensiones y la dificultad para depurar, era una API realmente pésima; Vulkan es verboso, pero en muchos aspectos es incluso más fácil.
Pero la Mac que uso ahora está conectada a varios periféricos y a un monitor grande mediante protocolos estándar usando solo puertos USB-C.
En general, Apple parece preferir estándares abiertos cuando son lo suficientemente buenos; en la época en que USB2 no podía hacer muchas de las cosas que hacía Lightning, creó Lightning, pero cuando apareció USB-C lo adoptó de inmediato en Mac y iPad, y en el iPhone lamentablemente se está demorando.
Asahi y Alyssa son gigantes de la ingeniería inversa, y su trabajo es increíble.
Creo que es muy probable que Apple haya intentado contratarlos, o que ya lo haya intentado y la hayan rechazado.
También podría decirse que Valve tiene más razones de negocio que Apple para aprovechar esta capacidad.
Normalmente, los empleados reciben una remuneración baja en comparación con las ganancias que generan, y en TI esto es especialmente cierto.
Para las personas talentosas es mejor crear una empresa y vender sus servicios a un precio justo, pero en algunos países las grandes corporaciones han hecho lobby ante el gobierno para cerrar ese camino.
El truco de las operaciones atómicas fue muy satisfactorio, y deducir las instrucciones swizzle a partir del linaje de PowerVR fue especialmente impresionante.
Creo que los ingenieros de Apple también aprenderían de esto, o al menos valorarían mucho lo ingenioso que es.
Me recuerda a cuando, en Accolade, hicieron ingeniería inversa del hardware de video de Sega Genesis: los ingenieros tomaron como punto de partida la documentación pública del VDP Texas Instruments TMS9918 para deducir el VDP derivado del 9918 de la Genesis (Mega Drive).
Para dejarlo claro, esto no es solo el primer driver Linux con certificación de conformidad; tiene un significado mayor.
Como la propia Apple tampoco cumple con OpenGL ES 3.1, este es literalmente el primer driver OpenGL ES 3.1 con certificación de conformidad para la serie M en cualquier sistema operativo.
Por eso aparece el pedido de donar al equipo.
https://asahilinux.org/support/
Quisiera saber dónde hacerlo si existe esa opción; si no, más adelante simplemente usaré ese enlace.
Hoy, si se depuran apps OpenGL de macOS, que ya no se recomiendan, este problema se vuelve muy evidente.
Esto se debe a que la capa de abstracción no expone el estado real de OpenGL de una forma que el antiguo depurador de OpenGL de Apple pueda leer.
A menos que tengas una Mac vieja con una versión antigua de macOS donde OpenGL no corriera internamente sobre Metal, en la práctica no se puede depurar OpenGL en macOS con el depurador nativo.
El depurador o la app simplemente crashea.
Esto parece ayudar sobre todo a los juegos, y no tanto al deep learning.
Lo más atractivo de la Mac M1 es su gran capacidad de memoria y, aunque quizá no sea ideal para entrenamiento porque no se puede distribuir entre varias tarjetas, sí es buena como motor de inferencia para modelos grandes como Stable Diffusion o LLaMA.
SYCL es un framework de programación de alto nivel, neutral respecto del proveedor, del Khronos Group, pero el soporte en aplicaciones es limitado; se espera que mejore gradualmente con el apoyo de Intel.
Vulkan Compute esquiva el problema mediante compute shaders, pero no sé bien cuál es la situación del soporte en aplicaciones.
SYCL puede implementarse sobre OpenCL y la extensión SPIR-V de OpenCL, pero debido al fuerte acoplamiento con proveedores, esa vía fue abandonada en gran medida fuera de Intel y Mesa; hoy suele implementarse con backends para las API de cada proveedor de GPU, como ROCm, HIP y CUDA.
Aplicar el mismo enfoque a Metal sería muy difícil; Mesa tiene soporte experimental para OpenCL+SPIR-V en Intel y AMDGPU, por lo que en teoría podría extenderse a Apple Silicon, pero actualmente OpenCL en Apple Silicon no tiene soporte alguno y apenas estaba en la hoja de ruta.
Para correr deep learning se necesita un backend como CUDA, ROCm o MPS.
Entrenar un modelo de PyTorch en un servidor grande con CUDA y correr la inferencia en una MacBook Air fue relativamente fácil.
Sin embargo, eiln escribió un driver para Apple Neural Engine, lo que permite usar hardware dedicado en lugar de la GPU, y está previsto que se integre en linux-asahi más adelante.
Decir que Asahi Lina y dos personas vencieron a una gran empresa con financiamiento mínimo suena genial, pero en realidad no es tanto que la hayan vencido, sino que Apple no se preocupaba por eso.
Apple nunca participó en esa carrera.
Me gusta el eufemismo de “dos personas vencieron a una gran empresa con financiamiento mínimo”.
Esto es claramente vergonzoso para Apple, que no se interesa por los estándares ni por el cumplimiento, y quiere que la gente quede atrapada en su propio jardín cerrado.
Si no fuera desarrollador de iOS, habría dejado el ecosistema de Apple hace mucho.
Me gusta su hardware, y también me gustaba la marca que defendía la creatividad y lo humano, como la Apple de los 80 y 90, pero la empresa actual parece podrida por la codicia detrás de videos de marketing políticamente correctos.
En mi última actualización busqué alternativas, pero salir de Apple implicaba aceptar una cantidad interminable de compromisos.
En lugar del iPhone miré los Pixel, esperando Android puro y soporte prolongado, pero no dejaban de aparecer comentarios sobre problemas de batería, y también eran obstáculos la calidad del software, el ecosistema de apps y la estabilidad.
También fue difícil encontrar un producto con una relación precio-calidad cercana a la calidad de construcción, batería y estabilidad de una MacBook Air M1 básica.
También leo cómics y revistas en el iPad, y en el mercado de tablets desde hace años no sé cuál sería la alternativa; quizá podría dejar el Apple Watch, pero simplemente funciona bien y tiene muchos accesorios de terceros.
Ya pasó la época en que instalaba una ROM nueva todos los días, y me da pena que Apple parezca difícil de superar en estabilidad y facilidad de uso.
La única razón por la que el empleo de todos está a salvo es que nadie logra averiguar con exactitud quiénes son esas dos personas.
Apple fabrica su propio silicio y construyó toda la plataforma, así que cuesta creer que dejar la posibilidad de ejecutar otros sistemas operativos haya sido un simple error.
Es evidente que dejó la puerta abierta deliberadamente para el desarrollo de terceros, y aun así el ambiente de críticas hacia Apple resulta decepcionante.
Por ejemplo, dar soporte a una implementación de Vulkan sostenida implicaría bastantes recursos y presión sobre los calendarios de lanzamiento, así que necesitaría una razón de negocio.
“Para evitar pasar vergüenza” probablemente no sea suficiente.
Podría argumentarse buena voluntad hacia la comunidad, pero no creo que Apple vaya a buscar el aprecio de gente que la llama “una empresa podrida por la codicia detrás de videos de marketing políticamente correctos”.
Las pruebas de conformidad no son open source, y la “conformance suite” separada que está en GitHub se basa en dEQP de Google, no en el conjunto de pruebas interno de Khronos.
Una implementación puede obtener una “certificación de compatibilidad con el estándar” aun con bugs y huecos bastante grandes.
Apple solo prometió soporte para OpenGL 3.1, y aunque reescribió el driver OpenGL para M1 como una capa de emulación sobre Metal para que las apps existentes siguieran funcionando, no va a implementar versiones más nuevas de OpenGL, ni tiene por qué hacerlo.
Hay muchas críticas posibles hacia Apple, y mucho margen para mejorar la API Metal y sus herramientas, pero no preocuparse por OpenGL en este caso es una decisión bastante razonable.
Es interesante que en el texto original no aparezca ni una vez la palabra “Apple”, y que solo use “fabricante” y “gran empresa”.
Si fue intencional, me pregunto si habrá sido por razones legales.
El interés no es Apple, sino hacer que Linux corra bien en la arquitectura M1/M2, y si el objetivo hubiera sido Microsoft, Amazon o Google, se habría tratado de la misma manera.
Fue divertido ver las transmisiones en vivo que muestran el proceso de desarrollo de este driver, y es un trabajo realmente impresionante
Es uno de los trabajos de programación de bajo nivel más sorprendentes que he visto hasta ahora