Prise en charge compatible d’OpenGL 4.6 sur M1

Prise en charge d’OpenGL 4.6 et d’OpenGL® ES 3.2

• Le M1 n’a longtemps pris en charge que OpenGL 4.1, mais prend désormais entièrement en charge OpenGL® 4.6 et OpenGL® ES 3.2.
• Il suffit d’installer Fedora pour les pilotes récents des séries M1/M2.
• Si c’est déjà installé, une simple mise à niveau via la commande dnf upgrade --refresh suffit.
• Contrairement aux pilotes 4.1 non standard des fournisseurs existants, ces pilotes Linux open source sont certifiés pour les versions récentes d’OpenGL, ce qui promet une large compatibilité avec des charges de travail OpenGL modernes comme Blender, Ryujinx et Citra.

Certification des pilotes et prise en charge des standards

• Les pilotes certifiés 4.6/3.2 doivent réussir plus de 100 000 tests pour garantir leur exactitude.
• La liste des pilotes officiellement certifiés inclut désormais OpenGL 4.6 et ES 3.2.
• Les fournisseurs ne prennent toujours pas en charge des standards graphiques modernes comme OpenGL moderne, mais cette société, si.
• Cette société affiche publiquement son attachement aux standards ouverts interopérables et veut offrir aux utilisateurs comme aux développeurs la liberté d’exécuter leurs applications où ils le souhaitent, sans portage spécifique.

Nouvelles fonctionnalités d’OpenGL 4.6

• OpenGL 4.6 ajoute des dizaines de fonctionnalités obligatoires par rapport à 4.1 :
  • Robustness
  • SPIR-V
  • Clip control
  • Cull distance
  • Compute shaders
  • Transform feedback amélioré

Problèmes de compatibilité du M1 avec les standards graphiques

• Le M1 s’adapte mal aux standards graphiques plus récents que OpenGL ES 3.1.
• Vulkan rend certaines fonctionnalités optionnelles, mais les couches destinées à DirectX et OpenGL n’ont pas certaines fonctions nécessaires.
• Sur M1, il n’existe pas de solution antérieure dépassant l’ensemble de fonctionnalités d’OpenGL 4.1.

Comment surmonter la barrière de 4.1

• De nouvelles méthodes sont nécessaires pour implémenter les nouvelles fonctionnalités sans prise en charge matérielle.
• Les geometry shaders, la tessellation et le transform feedback sont remplacés par des compute shaders.
• Le cull distance est remplacé par des valeurs interpolées transformées.
• Le clip control est remplacé par un épilogue de vertex shader.

Défis liés à la robustness

• Traditionnellement, les GPU privilégient les performances brutes à la sécurité.
• Pour des applications comme les navigateurs web, ce compromis n’est pas souhaitable.
• Les fonctionnalités de robustness permettent de réduire la surface d’attaque au prix d’un léger sacrifice de performances, en permettant à l’application de choisir un comportement défini lorsque le shader accède à un buffer hors limites.

Robustness des buffers

• D’autres API définissent différemment ce que retournent les lectures hors limites d’un buffer lorsque la robustness est activée.
• OpenGL impose qu’une lecture hors limites retourne le dernier élément du buffer.
• Les opérations supplémentaires nécessaires à la robustness sont déplacées dans le préambule du shader, ce qui n’entraîne aucun coût pour le shader principal.

Robustness des images

• La robustness des images exige que les lectures d’image hors limites retournent 0.
• Sur le GPU du M1, un test unique échoue sur les lectures d’images mipées.
• Les contournements pour la robustness consistent à ne pas charger depuis un niveau invalide, ou à effectuer un chargement spéculatif puis à utiliser des opérations de comparaison et de sélection.

Avis de GN⁺

• Cet article traite d’une avancée importante dans la prise en charge des standards OpenGL récents sur les appareils M1. Cela apportera une compatibilité plus large et de meilleures performances aux utilisateurs et développeurs Linux.
• Les nouvelles fonctionnalités d’OpenGL 4.6 peuvent améliorer de manière significative les performances et la robustness des applications graphiques, ce qui est particulièrement important dans le développement de jeux et le calcul haute performance.
• Cet article montre bien comment des pilotes open source peuvent offrir une meilleure conformité aux standards et une meilleure compatibilité que certaines solutions commerciales.

[GN⁺]

Commentaires sur Hacker News

• Alyssa Rosenzweig est une personne qui contribue continuellement à la communauté, et lire ses billets de blog permet d’apprendre des choses qu’on ignorait sur les entrailles du matériel graphique moderne. Ce type d’effort prouve que les compétences comptent plus que les paroles, et la simple lecture de son blog donne matière à réflexion. Le message important se trouve dans l’avant-dernière phrase plutôt que dans la dernière, et le lecteur se laisse entraîner dans un terrier de lapin pour savourer l’univers de la manipulation de bits.
• La puce M1 s’accorde mal avec des standards graphiques plus récents qu’OpenGL ES 3.1, et Vulkan permet d’utiliser certaines fonctionnalités de manière optionnelle, mais il lui manque les capacités nécessaires aux couches d’abstraction pour DirectX et OpenGL. Sur le M1, il n’existe pas de solution qui dépasse l’ensemble de fonctionnalités d’OpenGL 4.1. Il y a une curiosité quant à l’impact sur les performances, surtout par rapport à Metal sur macOS.
• En programmation graphique, je trouve amusant qu’on appelle « robustesse » le fait de remplacer un accès hors limites qui déclenche un trap par un retour de données aléatoires.
• Un jour, Apple abandonnera probablement OpenGL 3.3 core, et à cause de cela tout le monde pourrait aussi l’abandonner. On dit généralement qu’OpenGL est plus facile à utiliser que Vulkan, mais si tout devient trop complexe, cela peut devenir un obstacle à l’utilisation du GPU pour les développeurs moins expérimentés, et décourager certains développeurs de jeux indépendants. Utiliser Unity et Unreal est courant, mais créer un jeu à partir de zéro est perçu comme étrange. L’état du développement de jeux open source semble parfois très désespérant, et l’arrivée des API graphiques de nouvelle génération rend encore les choses plus difficiles.
• Cela concerne Fedora pour la puce M1, et le voir implémenté sur macOS serait impressionnant. Il y a de la curiosité sur le travail nécessaire pour y parvenir.
• Je me demande pourquoi ne pas cibler Vulkan en premier. Vulkan semble aujourd’hui être une cible plus importante, et il existe déjà des implémentations d’OpenGL.
• Comment franchir la barrière de la 4.1 ? Implémenter de nouvelles fonctionnalités sans support matériel exige de nouvelles approches. Les geometry shaders, la tessellation et le transform feedback sont implémentés avec des compute shaders, les cull distances avec des valeurs interpolées transformées, et le clip control avec un épilogue du vertex shader. Je me demande dans quelle mesure ce travail est déjà fait dans le code GPU du M1, et dans quelle mesure l’implémentation de fonctionnalités via d’autres fonctionnalités peut être réutilisée.
• Encore une recommandation, encore un article que j’aimerais mieux comprendre dans son contexte avec davantage de connaissances et de patience. Malgré cela, les textes d’Alyssa restent agréables à lire.
• C’est fou de penser que la seule raison pour laquelle OpenGL a été utilisé pour le jeu 3D est que John Carmack s’y est accroché pour Quake II dans les années 90.