Soporte compatible con OpenGL 4.6 en el M1

Soporte para OpenGL 4.6 y OpenGL® ES 3.2

• Durante mucho tiempo, el M1 solo fue compatible con OpenGL 4.1, pero ahora ya ofrece soporte completo para OpenGL® 4.6 y OpenGL® ES 3.2.
• Basta con instalar Fedora para usar los drivers más recientes de la serie M1/M2.
• Si ya está instalado, se puede actualizar simplemente con el comando dnf upgrade --refresh.
• A diferencia de los drivers 4.1 no estándar del proveedor original, estos drivers Linux de código abierto están certificados para las versiones más recientes de OpenGL, lo que promete una amplia compatibilidad con cargas de trabajo modernas de OpenGL como Blender, Ryujinx y Citra.

Certificación de drivers y soporte de estándares

• Los drivers certificados 4.6/3.2 deben pasar más de 100,000 pruebas para garantizar su exactitud.
• La lista de drivers oficialmente certificados ahora incluye OpenGL 4.6 y ES 3.2.
• El proveedor todavía no soporta estándares gráficos modernos como OpenGL moderno, pero esta empresa sí.
• Esta empresa expresa públicamente su aprecio por los estándares abiertos e interoperables, y busca dar a usuarios y desarrolladores la libertad de ejecutar aplicaciones donde quieran sin ports especiales.

Qué hay de nuevo en OpenGL 4.6

• OpenGL 4.6 agrega decenas de funciones obligatorias frente a 4.1:
  • Robustness (robustez)
  • SPIR-V
  • Clip control
  • Cull distance
  • Compute shaders
  • Transform feedback mejorado

Problemas de compatibilidad entre el M1 y los estándares gráficos

• El M1 no se adapta bien a estándares gráficos más nuevos que OpenGL ES 3.1.
• Vulkan vuelve opcionales algunas funciones, pero en las capas para DirectX y OpenGL faltan funciones necesarias.
• En el M1 no existe una solución previa que vaya más allá del conjunto de funciones de OpenGL 4.1.

Cómo se superó la barrera de 4.1

• Se necesitó un nuevo método para implementar funciones nuevas sin soporte de hardware.
• Los geometry shaders, tessellation y transform feedback fueron reemplazados por compute shaders.
• Cull distance fue reemplazado por valores interpolados transformados.
• Clip control fue reemplazado por un epílogo del vertex shader.

Desafíos de robustez

• Tradicionalmente, los GPU priorizan el rendimiento bruto por encima de la seguridad.
• En aplicaciones como los navegadores web, ese intercambio no resulta deseable.
• Las funciones de robustez permiten reducir la superficie de ataque con un pequeño costo de rendimiento, al permitir que la aplicación elija un comportamiento definido cuando ocurre un acceso fuera de los límites del búfer dentro de un shader.

Robustez de búferes

• Otras API tienen definiciones distintas sobre qué devuelven las lecturas fuera de rango de un búfer cuando la robustez está activada.
• OpenGL hace que una lectura fuera de rango devuelva el último elemento del búfer.
• Las operaciones adicionales para la robustez se movieron al preámbulo del shader, por lo que no agregan costo al shader principal.

Robustez de imágenes

• La robustez de imágenes exige que las lecturas de imagen fuera de rango devuelvan 0.
• En la GPU del M1 hay una sola prueba que falla con lecturas de imágenes con mipmapping.
• Las soluciones alternativas para la robustez incluyen no leer niveles inválidos, o leer de forma especulativa y luego usar operaciones de comparación y selección.

Opinión de GN⁺

• Este artículo trata un avance importante para soportar el estándar moderno de OpenGL en dispositivos M1. Esto traerá una compatibilidad más amplia y mejoras de rendimiento para usuarios y desarrolladores de Linux.
• Las nuevas funciones de OpenGL 4.6 pueden mejorar de forma importante el rendimiento y la robustez de las aplicaciones gráficas, algo especialmente relevante en desarrollo de juegos y computación de alto rendimiento.
• Este artículo es un buen ejemplo de cómo los drivers de código abierto pueden ofrecer un mejor cumplimiento de estándares y compatibilidad que las soluciones comerciales.

[GN⁺]

Comentarios de Hacker News

• Alyssa Rosenzweig es una persona que contribuye de forma constante a la comunidad, y al leer sus publicaciones del blog se puede aprender sobre el interior del hardware gráfico moderno que uno no conocía. Este tipo de esfuerzo demuestra que la habilidad importa más que las palabras, y solo con leer el blog ya da mucho en qué pensar. El mensaje importante está en la segunda oración, no en la última, y el lector termina cayendo por la madriguera del conejo para disfrutar el mundo de la manipulación de bits.
• El chip M1 no encaja bien con estándares gráficos más nuevos que OpenGL ES 3.1, y aunque Vulkan puede usar algunas funciones de forma opcional, le faltan capacidades necesarias para el uso de capas para DirectX y OpenGL. En el M1 no existe una solución que vaya más allá del conjunto de funciones de OpenGL 4.1. Hay curiosidad sobre el impacto en el rendimiento de esto, especialmente en comparación con Metal de macOS.
• Me parece curioso que en programación gráfica se llame "robustez" a cambiar un acceso fuera de límites de una trampa a la devolución de datos aleatorios.
• Algún día Apple va a eliminar OpenGL 3.3 core, y por eso todos podrían terminar abandonándolo también. Normalmente se dice que OpenGL es más fácil de usar que Vulkan, pero si todo se vuelve demasiado complejo, puede convertirse en una barrera para que desarrolladores con menos experiencia aprovechen la GPU, y eso podría desanimar a algunos desarrolladores indie de videojuegos. Usar Unity y Unreal es lo normal, pero hacer un juego desde cero pasa a verse como algo extraño. El estado del desarrollo de videojuegos de código abierto a veces se siente bastante desolador, y la llegada de las API gráficas de nueva generación hace que la situación sea todavía más difícil.
• Esto trata sobre Fedora para el chip M1, y sería sorprendente implementarlo en macOS. Hay curiosidad sobre qué trabajo haría falta para lograrlo.
• Me pregunto por qué no apuntar primero a Vulkan. Hoy en día Vulkan parece un objetivo más importante, y ya existen implementaciones de OpenGL.
• ¿Cómo van a romper la barrera de 4.1? Para implementar funciones nuevas sin soporte de hardware hace falta encontrar métodos nuevos. Los geometry shaders, tessellation y transform feedback se implementan con compute shaders, las distancias de culling con valores interpolados transformados, y el clip control con el epílogo del vertex shader. Da curiosidad cuánto de este trabajo ya está hecho en el código GPU del M1 y cuánto de la implementación de funciones mediante otras funciones puede reutilizarse.
• Otra recomendación más, otro artículo que quisiera entender mejor en contexto con más conocimiento y paciencia. Aun así, los textos de Alyssa se leen con gusto.
• Es una locura que la única razón por la que OpenGL se usó para gaming 3D haya sido que John Carmack se aferró a ello para Quake II en los 90.