- El driver gráfico de kernel para las GPU Apple M1/M2, además de estar basado en Rust, amplió su soporte de estándares al lograr conformidad con OpenGL 4.6 y Vulkan 1.3
- La teselación, pieza clave de OpenGL 4.0, es difícil de implementar solo con las capacidades de hardware de las GPU de Apple, por lo que se resolvió trasladando el teselador de referencia de Microsoft a OpenCL C para ejecutarlo en la GPU
- En una demo de Vulkan en una Mac M2, la teselación basada en OpenCL registró 265 fps, mucho más rápido que una implementación puramente por software con menos de 1 fps, aunque por debajo de los 820 fps de un teselador por hardware
- Ejecutar juegos AAA exige adaptar entornos DirectX, Windows, x86 y páginas de 4 KB al Apple Silicon basado en Linux, Arm64 y páginas de 16 KB, usando en conjunto varias capas de traducción y una configuración con máquina virtual
- Juegos como Portal, The Witcher 3 y Cyberpunk 2077 ya se ejecutaron de verdad, pero los requisitos de memoria y el alcance del soporte de ray tracing siguen siendo limitaciones importantes
El driver GPU de Apple llega hasta OpenGL 4.6
- El driver gráfico de kernel para las GPU Apple M1/M2 fue escrito en Rust y logró conformidad con varios estándares gráficos
- Alyssa Rosenzweig actualizó el estado del driver y los juegos que puede soportar en la X.Org Developers Conference 2024
- El material de la presentación está disponible como video en YouTube y diapositivas
- En la XDC del año anterior, el driver había logrado conformidad con OpenGL ES 3.1, y desde entonces avanzó hasta OpenGL 4.6
- La teselación), necesaria para OpenGL 4.0, es una técnica para agregar o reducir dinámicamente el detalle de una escena
Límites del teselador por hardware de las GPU de Apple
- Las GPU de Apple tienen un teselador por hardware, pero le faltan funciones necesarias para una implementación estándar de OpenGL, así que el driver no puede usarlo tal cual
- El hardware aparentemente no soporta point mode ni isoline, aunque ambas funciones pueden emularse
- El problema mayor es transform feedback y el geometry shader
- El hardware no soporta ninguno de los dos
- El driver los emula con compute shaders
- Las diferencias entre el algoritmo de teselación del hardware y el de la emulación pueden provocar fallos de invariancia, por lo que debe evitarse esa combinación
- Apple soporta OpenGL 4.1, pero sin conformidad, y reemplaza por software las funciones que el hardware no soporta
- Rosenzweig señaló que no está implementando Metal, así que no piensa seguir ese camino
El teselador de referencia llevado a OpenCL C
- El driver aprovecha el teselador de referencia que Microsoft publicó hace más de 10 años
- Originalmente era código para mostrar el comportamiento que los fabricantes de hardware debían implementar al introducir teselación
- Son unas 2000 líneas de código C++ que teselan un solo patch
- Como un driver GPU no puede ejecutar directamente 2000 líneas de C++, ese código se trasladó a OpenCL C
- OpenCL C es muy parecido al C común de CPU, pero con restricciones y extensiones para GPU
- El objetivo no era comprender el código por completo, sino no romper su comportamiento durante el port
- El teselador de CPU procesa un solo patch a la vez, pero una escena puede tener 10,000 patches
- Se aprovecha el paralelismo masivo de la GPU para que múltiples hilos hagan la teselación
- La asignación del buffer de salida durante el procesamiento en paralelo se maneja con instrucciones atómicas de la GPU
- La salida del teselador debe dibujarse con comandos en el formato de estructuras de datos empaquetadas que requiere la GPU
- Normalmente, en el código C del driver eso lo resuelven funciones generadas por la herramienta GenXML
- Como el teselador tiene forma de código C gracias a OpenCL, esas funciones generadas pueden incluirse en el código que corre en la GPU
Rendimiento de la teselación
- La teselación basada en OpenCL se usa para ejecutar terrain tessellation en una demo de Vulkan sobre una Mac M2
- La comparación de rendimiento es la siguiente
- Terrain tessellation solo por software: menos de 1 fps
- Teselación basada en OpenCL: 265 fps
- Medición conectando el teselador por hardware: 820 fps
- Rosenzweig evaluó que el rendimiento del enfoque con OpenCL es “aceptable” y cree que en juegos reales es poco probable que se convierta en cuello de botella
- Todavía hay margen para mejorar el rendimiento del driver
Vulkan 1.3 y Honeykrisp
- El driver Honeykrisp para GPU M1/M2 logró conformidad con Vulkan 1.3
- El punto de partida fue copiar el driver Vulkan NVK para GPU NVIDIA y combinarlo con el driver OpenGL 4.6
- En alrededor de un mes empezó a pasar el conjunto de pruebas de conformidad
- Eso ocurrió 6 meses antes de la presentación
- Después se agregaron las siguientes funciones
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Actualmente el driver soporta todas las funciones necesarias para varias versiones de DirectX
Capas de traducción para ejecutar juegos AAA
- Para ejecutar juegos AAA en Apple Silicon hay que manejar al mismo tiempo varias diferencias de entorno
- Entorno objetivo del juego: DirectX, Windows, CPU x86, páginas de 4 KB
- Hardware real de destino: Apple Silicon basado en Linux, Arm64 y páginas de 16 KB
- La traducción de DirectX a Vulkan y la ejecución de Windows sobre Linux quedan a cargo de DXVK y Wine, respectivamente
- Para la traducción de x86 a Arm64 existen opciones ya conocidas como FEX-Emu o Box64
- El mayor obstáculo es la diferencia en el tamaño de página
- FEX-Emu requiere páginas de 4 KB
- Box64 tiene un hack para usar páginas de 16 KB, pero no funciona con Wine, así que aquí no sirve
- macOS puede usar páginas de 4 KB para emulación x86, pero requiere soporte de kernel muy invasivo
- Asahi Linux ya tiene cerca de 1000 parches encaminados al kernel principal, por lo que reescribir el gestor de memoria de Linux no es una opción razonable
Configuración con VM y kernel invitado de 4 KB
- Linux no soporta tamaños de página heterogéneos entre procesos distintos, pero sí entre kernels distintos, y eso se resuelve con virtualización
- Un kernel invitado de KVM puede tener un tamaño de página distinto al del kernel anfitrión
- Se usa una arquitectura que mete FEX-Emu, Wine, DXVK, Honeykrisp, Steam y el juego completo dentro de una máquina virtual que ejecuta un kernel invitado de 4 KB
- Se esperaba que la sobrecarga de CPU fuera baja gracias a la virtualización por hardware, y la carga real está más del lado de los periféricos
- Honeykrisp se ejecuta en el invitado, no en el kernel anfitrión, mediante virtgpu native contexts
- La tarea de crear el command buffer final de la GPU se hace dentro del invitado
- En lugar de que cada llamada Vulkan cruce el límite de la máquina virtual, se envía al anfitrión el command buffer ya terminado
- El renderer VirGL del anfitrión lo entrega a la GPU
- Rosenzweig dijo que este enfoque no alcanza el 100% de velocidad nativa, pero supera claramente el 90%
- La sobrecarga de CPU y GPU se ejecuta en paralelo, por lo que sus costos no se acumulan entre sí
Juegos que ya se ejecutaron y estado de publicación
- Esta configuración ya ejecutó realmente varios juegos
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- Los componentes relacionados se publicaron el 10 de octubre, el mismo día de la presentación
- Los usuarios de Fedora Asahi Remix pueden actualizar de inmediato para recibir esos componentes
- Durante la presentación, ejecutar Steam tomó tiempo por la máquina virtual y la emulación x86, y luego Control corrió a 45 fps en un sistema M1 MAX
Limitaciones de memoria y ray tracing
- Algunos juegos pueden ejecutarse incluso en Macs con 8 GB de RAM
- Rosenzweig jugó Castle Crashers durante la conferencia en un sistema de 8 GB
- Portal también funciona en un sistema de 8 GB
- Es probable que los títulos más avanzados solo funcionen en sistemas con 16 GB o más
- Rosenzweig espera que con el tiempo bajen los recursos necesarios
- El soporte de ray tracing no es una prioridad alta
- Control puede usar esa función
- El hardware de Apple solo soporta ray tracing a partir del M3
- El driver actual es para GPU M1 y M2
- Rosenzweig planea empezar pronto el trabajo sobre M3
1 comentarios
Opiniones de Hacker News
La dedicación para completar hasta el final el soporte para M1/M2 es realmente admirable.
Hay demasiados proyectos que se abandonan en cuanto aparece el nuevo juguete brillante de ray tracing; este tipo de trabajo duele por el hardware mal documentado, pero cuando funciona, la recompensa es enorme.
Yo también compré mi M1 por este proyecto y por el trabajo de Alyssa en OpenGL+ES, y solo arranco Asahi Linux.
Estos equipos están hechos para durar, y el soporte a largo plazo tanto de la propia Apple como de la comunidad Linux es digno de elogio.
Al ser open source, es muy probable que Apple también lo esté mirando, y el artículo también hablaba del trabajo para rodear funciones que faltan en los chips.
Llevo más de 20 años programando, pero los momentos más felices y más depresivos de mi carrera salieron ambos de un proyecto de hardware en el que participé apenas 4 meses.
El enfoque de Alyssa de correr todo en una máquina virtual para resolver la diferencia entre tamaños de página de 4 KB y 16 KB se siente como un hack ingenioso, pero también como un posible cuello de botella de rendimiento.
Me pregunto qué implicaciones tendrá este tipo de workaround a largo plazo.
¿No habremos llegado al punto en que la complejidad de cerrar la brecha de hardware propietario diseñado para un ecosistema cerrado supera los beneficios?
Que Control corra a 45 fps en una M1 MAX con drivers open source es alentador, pero me pregunto si la comunidad debería seguir invirtiendo tantos recursos en abrir más sistemas cerrados, o si debería impulsar estándares de hardware más abiertos.
Apple crea obstáculos innecesarios para los desarrolladores con tamaños de página no estándar y limitaciones de GPU que vuelven difíciles funciones estándar como los tessellation shaders; estos ecosistemas cerrados no solo agotan a los contribuidores open source, sino que también reprimen innovaciones que beneficiarían a todos los usuarios.
Es evidente que eso sostiene su modelo de negocio cerrado, y de hecho a Apple le funciona muy bien.
Hacen hardware excelente y, aunque últimamente el software sea algo inestable, el usuario común suele tener una buena experiencia con la combinación de hardware y software.
Por lo tanto, no es que Apple ponga “obstáculos innecesarios” a los desarrolladores al diseñar su hardware como lo hace ahora; simplemente se enfoca en diseñar hardware adaptado a sus propias necesidades.
Además, si el hardware no fuera excelente, tampoco habría tanto interés en usarlo de formas que Apple no tenía previstas.
Hay una diferencia bastante grande entre ignorar un estándar y reinventar una rueda mejor, y apartarse deliberadamente del estándar para impedir la compatibilidad.
La clave es si no están destinando recursos a mantener el comportamiento estándar, o si están destinando recursos activamente a apartarse del estándar; si es lo primero, personalmente no lo culparía.
Dentro de este ecosistema, lo que probablemente le importe más a Apple será una experiencia de inferencia de IA de nivel similar a la compatibilidad con apps nativas, y ambas cosas parecen resolverse a veces mediante esfuerzos conjuntos.
Fuera de eso, prefieren cerrar todo lo más posible, y lamentablemente la comunidad suele sentirse más atraída por el atractivo general que por buenas iniciativas abiertas.
Se pueden hacer ambas cosas.
Al principio iba a decir que Alyssa debería trabajar en Valve para ayudar a que Steam corra en Linux en Mac, pero parece que ya es así [1].
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Esto plantea una pregunta bastante interesante sobre qué está planeando Valve aquí.
Aunque será difícil, hacer correr Steam/Proton en Mac tiene muchísimo sentido para Valve, y si la gente arranca Linux en sus Mac para jugar, a Apple probablemente le molestaría bastante.
El trabajo de Alyssa R y Asahi Lina es excelente.
Dicho eso, si no estás familiarizado con código de drivers, gran parte de esto es realmente difícil de entender, y el lado del hardware tiene tantas peculiaridades que ojalá fuera mucho más fácil escribir este tipo de código.
También disfruté bastante esa picardía old school del disfraz de bruja.
Me pregunto si hay algún hardware conocido que permita hacer eso.
Busqué, pero entre el spam de blogs sobre PowerPoint fue difícil encontrar el resultado que quería, y la IA de Google tampoco ayudó.
Me pregunto si a alguien más le sorprende que falten tantas cosas en el hardware y que tantas partes estén emuladas.
En la práctica, se puede decir que casi todo es emulación.
Una de las razones por las que los fabricantes de GPU no quieren publicar sus drivers como open source es que una parte importante de la salsa secreta ocurre en el software del driver sobre esa arquitectura de cómputo masivamente paralela.
Los geometry shaders son ampliamente considerados un error que nunca debió estandarizarse, y Metal nunca los soportó en absoluto, así que solo podrían aparecer en código OpenGL viejo de macOS; por eso es difícil culpar a Apple por no soportarlos en hardware.
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa es increíble
Recuerdo su primer artículo sobre trabajo en GPU y, cuando después me enteré de que apenas tenía 17 años, sentí que me explotaba la cabeza
Que cualquiera haya logrado algo así ya es sorprendente; que lo haya hecho una adolescente es realmente impactante
Si llevar OpenGL y Vulkan modernos a Apple Silicon de todos modos es imposible sin una capa de emulación, ¿en teoría se podría crear una API Metal nativa para Linux?
¿O Metal está demasiado incrustado en el SDK de macOS?
MoltenVK también está tratando de resolver el mismo problema del que habló Alyssa en su presentación [1, el último comentario del issue es de Alyssa]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
Esa fue, en la práctica, la conclusión de la presentación de Alyssa Rosenzweig
Apple conoce la documentación interna, así que está en la mejor posición para crear una mejor implementación de bajo nivel
El principal obstáculo ahora es su postura obstinada de que portar a Metal sea la única vía oficialmente soportada
Si Valve logra sacar adelante algún método de brujería para hacer correr juegos AAA en Mac sin soporte de Apple, sería un escenario interesante y quizá obligue a Apple a replantearse su enfoque si no quiere quedar arrinconada en su propia plataforma
También existen implementaciones de DirectX para Linux, y Proton funciona de esa manera
La cuestión es si esa API se haría como una capa sobre Vulkan, si se manejaría completamente del lado del cliente como MoltenVK o dxvk, o si se integraría más profundamente en Mesa
Para empezar, lo primero sin duda parece más fácil
Me han entrenado a esperar que un artículo con un título así diga algo como “se abandona el soporte y serán adquiridos para contratar al equipo”
Alyssa Rosenzweig merece ganar el Turing Award
Siempre me han dado curiosidad estos enlaces /SubscriberLink/
¿Será poco ético compartirlos?
Correos personales, mensajes en listas de correo de proyectos y entradas de blog son todos apropiados, y dicen que les gusta que se compartan siempre que no se usen como una forma de eludir sus intentos de conseguir suscriptores
Eso sí, pidieron amablemente que no se difundieran en exceso porque tienen que mantener el sitio y pagar a autores y editores, y según entiendo esos recursos vienen solo de las suscripciones
La suscripción a LWN es bastante accesible y apoya la mejor cobertura técnica en profundidad sobre Linux y temas relacionados
No tengo relación con LWN; solo soy un suscriptor satisfecho, y creo que el conocimiento que obtuve de sus artículos también contribuyó en parte al éxito de mi carrera
Para que la gente se suscriba, primero tiene que saber que LWN existe
Miren el FAQ: https://lwn.net/op/FAQ.lwn#slinks
El muro de pago de LWN es peculiar: todo el contenido queda disponible gratis una semana después
Los enlaces de suscriptor existen para animarte a suscribirte si puedes hacerlo
Puede que me equivoque, pero suena como si el contenido que antes era de pago estuviera financiado para abrirse, quizá artículo por artículo
Me da curiosidad si alguien sabe si realmente es así