- Le pilote graphique noyau pour les GPU Apple M1/M2 se distingue par sa base Rust et élargit sa prise en charge des standards en atteignant la conformité OpenGL 4.6 et Vulkan 1.3
- La tessellation, élément central d’OpenGL 4.0, est difficile à rendre conforme au standard avec les seules capacités matérielles des GPU Apple ; elle est donc traitée en portant le tessellateur de référence de Microsoft en OpenCL C pour l’exécuter sur le GPU
- Dans une démo Vulkan sur Mac M2, la tessellation basée sur OpenCL atteint 265 fps, bien plus que l’implémentation purement logicielle à moins de 1 fps, mais en dessous des 820 fps d’un tessellateur matériel
- Faire tourner des jeux AAA impose d’adapter un environnement DirectX, Windows, x86 et pages de 4 Ko à Apple Silicon sous Linux, Arm64 et pages de 16 Ko, ce qui combine plusieurs couches de traduction et une configuration de machine virtuelle
- Des jeux comme Portal, The Witcher 3 et Cyberpunk 2077 ont effectivement été lancés, mais les besoins en mémoire et l’étendue de la prise en charge du ray tracing restent des contraintes importantes
Le pilote GPU Apple passe à OpenGL 4.6
- Le pilote graphique noyau pour les GPU Apple M1/M2 est écrit en Rust et a atteint la conformité avec plusieurs standards graphiques
- Alyssa Rosenzweig a fait le point sur l’état du pilote et les jeux pris en charge lors de la X.Org Developers Conference 2024
- Les supports de présentation sont disponibles sous forme de vidéo YouTube et de slides
- Lors du XDC de l’année précédente, le pilote avait atteint la conformité OpenGL ES 3.1, puis il est depuis arrivé jusqu’à la conformité OpenGL 4.6
- La tessellation), nécessaire à OpenGL 4.0, est une technique qui ajoute ou réduit dynamiquement le niveau de détail d’une scène
Les limites du tessellateur matériel des GPU Apple
- Les GPU Apple disposent d’un tessellateur matériel, mais certaines fonctions nécessaires à une implémentation conforme au standard OpenGL manquent, si bien que le pilote ne peut pas l’utiliser tel quel
- Le matériel ne semble pas prendre en charge le point mode ni les isolines, deux fonctions qui peuvent être émulées
- Le problème le plus important concerne le transform feedback et les geometry shaders
- Le matériel ne prend en charge ni l’un ni les autres
- Le pilote les émule avec des compute shaders
- Les différences d’algorithme de tessellation entre le tessellateur matériel et l’émulation peuvent provoquer des échecs d’invariance, il faut donc éviter cette combinaison
- Apple prend en charge OpenGL 4.1, mais sans conformité, et remplace par du logiciel les fonctions non prises en charge par le matériel
- Rosenzweig a indiqué qu’elle n’implémentait pas Metal et qu’elle n’emprunterait donc pas cette approche
Un tessellateur de référence porté en OpenCL C
- Le pilote s’appuie sur le tessellateur de référence publié par Microsoft il y a plus de dix ans
- Le code avait initialement pour but de montrer aux fabricants de matériel le comportement à implémenter lors de l’introduction de la tessellation
- Il compte environ 2 000 lignes de C++ et tesselle un seul patch
- Comme il n’est pas possible d’exécuter directement 2 000 lignes de C++ dans un pilote GPU, ce code a été porté en OpenCL C
- OpenCL C est très proche du C CPU classique, mais avec des restrictions et extensions propres au GPU
- L’objectif n’est pas de comprendre entièrement le code, mais de ne pas casser son comportement pendant le portage
- Le tessellateur CPU ne traite qu’un patch à la fois, alors qu’une scène peut contenir 10 000 patches
- Le fort parallélisme du GPU est utilisé pour tesseller via plusieurs threads
- Pendant le traitement parallèle, l’allocation du tampon de sortie est gérée au moyen d’instructions atomiques GPU
- La sortie du tessellateur doit être dessinée sous forme de commandes draw au format de structure de données packed exigé par le GPU
- Dans le code C classique du pilote, cela est généralement pris en charge par des fonctions générées par l’outil GenXML
- Comme le tessellateur reste sous forme de code C grâce à OpenCL, les fonctions générées peuvent être incluses dans le code exécuté sur le GPU
Performances de la tessellation
- La tessellation basée sur OpenCL est utilisée sur un Mac M2 pour exécuter la terrain tessellation d’une démo Vulkan
- La comparaison des performances est la suivante
- Terrain tessellation purement logicielle : moins de 1 fps
- Tessellation basée sur OpenCL : 265 fps
- Mesure obtenue en raccordant le tessellateur matériel : 820 fps
- Rosenzweig estime que les performances de l’approche OpenCL sont « correctes » et juge peu probable qu’elles deviennent un goulot d’étranglement dans les jeux réels
- Les performances du pilote peuvent encore être améliorées
Vulkan 1.3 et Honeykrisp
- Le pilote GPU Honeykrisp pour M1/M2 a atteint la conformité Vulkan 1.3
- Le point de départ consistait à copier le pilote Vulkan NVK pour GPU NVIDIA et à le combiner avec le pilote OpenGL 4.6
- Il a commencé à réussir la suite de tests de conformité en environ un mois
- Ce jalon datait de six mois avant la présentation
- Les fonctions suivantes ont ensuite été ajoutées
- geometry shader
- tessellation shader
- transform feedback
- shader object
- Le pilote prend désormais en charge toutes les fonctions nécessaires à plusieurs versions de DirectX
Couches de traduction pour lancer des jeux AAA
- Lancer des jeux AAA dans l’environnement Apple Silicon impose de gérer simultanément plusieurs différences d’environnement
- Environnement cible des jeux : DirectX, Windows, CPU x86, pages de 4 Ko
- Matériel cible réel : Apple Silicon sous Linux, Arm64 et pages de 16 Ko
- La traduction de DirectX vers Vulkan et l’exécution de Windows vers Linux sont assurées respectivement par DXVK et Wine
- Pour la traduction de x86 vers Arm64, il existe déjà des options comme FEX-Emu ou Box64
- Le principal obstacle est la différence de taille de page
- FEX-Emu exige des pages de 4 Ko
- Box64 dispose d’un hack utilisant des pages de 16 Ko, mais il ne fonctionne pas avec Wine et n’est donc pas utile ici
- macOS peut utiliser des pages de 4 Ko pour l’émulation x86, mais cela nécessite une prise en charge noyau très intrusive
- Asahi Linux compte déjà environ 1 000 patches en route vers le noyau mainline ; réécrire le gestionnaire de mémoire de Linux n’est donc pas une approche raisonnable
Configuration de VM avec noyau invité en 4 Ko
- Linux ne prend pas en charge des tailles de page hétérogènes entre différents processus, mais cela est possible entre différents noyaux, via la virtualisation
- Un noyau invité KVM peut avoir une taille de page différente de celle du noyau hôte
- L’architecture utilisée place FEX-Emu, Wine, DXVK, Honeykrisp, Steam et le jeu complet dans une machine virtuelle exécutant un noyau invité en 4 Ko
- La surcharge CPU devait rester faible grâce à la virtualisation matérielle, la vraie charge se situant du côté des périphériques
- Honeykrisp s’exécute dans l’invité, et non dans le noyau hôte, via les virtgpu native contexts
- La création du command buffer GPU final est effectuée dans l’invité
- Au lieu de faire franchir la frontière de la machine virtuelle à chaque appel Vulkan, le command buffer finalisé est transmis à l’hôte
- Le renderer VirGL de l’hôte le transmet au GPU
- Rosenzweig indique que cette approche n’atteint pas 100 % des performances natives, mais qu’elle dépasse clairement 90 %
- Les surcoûts CPU et GPU s’exécutent en parallèle, leurs coûts ne s’additionnent donc pas
Jeux effectivement lancés et disponibilité publique
- Cette configuration a réellement permis de lancer plusieurs jeux
- Portal
- Portal 2
- Castle Crashers
- The Witcher 3
- Fallout 4
- Control
- Ghostrunner
- Cyberpunk 2077
- Les composants concernés ont été publiés le 10 octobre, le jour de la présentation
- Les utilisateurs de Fedora Asahi Remix peuvent les recevoir immédiatement en effectuant une mise à jour
- Pendant la présentation, le lancement de Steam a pris du temps à cause de la machine virtuelle et de l’émulation x86 ; ensuite, Control a tourné à 45 fps sur un système M1 MAX
Contraintes de mémoire et de ray tracing
- Certains jeux peuvent fonctionner même sur des Mac avec 8 Go de RAM
- Rosenzweig a joué à Castle Crashers sur un système 8 Go pendant la conférence
- Portal fonctionne aussi sur un système 8 Go
- Les titres plus avancés ne fonctionneront probablement que sur des systèmes dotés de 16 Go ou plus
- Rosenzweig espère que les ressources nécessaires diminueront avec le temps
- La prise en charge du ray tracing n’est pas une priorité élevée
- Control peut utiliser cette fonctionnalité
- Le matériel Apple ne prend en charge le ray tracing qu’à partir du M3
- Le pilote actuel cible les GPU M1 et M2
- Rosenzweig prévoit de commencer bientôt le travail sur M3
1 commentaires
Avis de Hacker News
Le dévouement à aller jusqu’au bout du support des M1/M2 force vraiment le respect.
Il y a trop de projets qui sont abandonnés dès qu’un nouveau jouet brillant de ray tracing apparaît ; ce genre de travail est pénible à cause du matériel mal documenté, mais très gratifiant quand ça fonctionne.
J’ai aussi acheté mon M1 grâce à ce projet et au travail d’Alyssa sur OpenGL+ES, et je ne démarre que sur Asahi Linux.
Ces machines sont faites pour durer, et le support à long terme, à la fois par Apple elle-même et par la communauté Linux, mérite des éloges.
Comme c’est open source, il est très probable qu’Apple regarde aussi, et l’article parlait aussi du travail consistant à contourner les fonctions absentes de la puce.
Je code depuis plus de 20 ans, mais les moments les plus heureux comme les plus déprimants de ma carrière sont tous venus d’un projet matériel auquel je n’ai participé que quatre mois.
L’approche d’Alyssa, qui consiste à tout faire tourner dans une machine virtuelle pour gérer la différence entre les tailles de pages 4 Ko et 16 Ko, ressemble à un hack astucieux, mais aussi à un possible goulot d’étranglement de performances.
Je me demande ce que ce genre de contournement implique à long terme.
N’a-t-on pas atteint le point où la complexité nécessaire pour combler les écarts d’un matériel propriétaire conçu pour un écosystème fermé dépasse les bénéfices ?
Voir Control tourner à 45 fps sur un M1 MAX avec un pilote open source est encourageant, mais je me demande si la communauté doit continuer à investir de grosses ressources pour rendre des systèmes fermés plus ouverts, ou plutôt pousser des standards matériels plus ouverts.
Apple crée des obstacles inutiles pour les développeurs avec des limites GPU qui rendent difficiles des fonctionnalités standard comme les shaders de tessellation, ainsi qu’avec une taille de page non standard ; ce type d’écosystème fermé ne fait pas que compliquer la vie des contributeurs open source, il étouffe aussi l’innovation qui profiterait à tous les utilisateurs.
Il est évident que cela soutient son modèle économique fermé, et dans les faits ça fonctionne très bien pour Apple.
Ils fabriquent un excellent matériel, et même si leur logiciel est devenu un peu instable récemment, l’utilisateur moyen a généralement une bonne expérience avec l’ensemble matériel + logiciel.
Donc le fait qu’Apple conçoive son matériel comme elle le fait ne revient pas à placer des « obstacles inutiles » devant les développeurs ; elle se concentre simplement sur une conception matérielle adaptée à ses propres besoins.
Et puis, si le matériel n’était pas excellent, il n’y aurait pas autant d’intérêt à l’utiliser d’une manière qu’Apple n’avait pas prévue.
Il y a une assez grande différence entre ignorer les standards pour réinventer une meilleure roue, et s’écarter volontairement des standards afin d’empêcher la compatibilité.
La question clé est de savoir s’ils ne dépensent pas de ressources pour conserver le comportement standard, ou s’ils dépensent activement des ressources pour s’en écarter ; si c’est le premier cas, personnellement je ne pense pas qu’on puisse vraiment leur en vouloir.
Dans cet écosystème, les principales préoccupations d’Apple devraient être la compatibilité des apps natives et une expérience d’inférence IA d’un niveau comparable ; les deux semblent parfois être résolues par des efforts communs.
Pour le reste, Apple préfère verrouiller autant que possible, et la communauté, malheureusement, est davantage attirée par l’attrait global que par de bonnes initiatives ouvertes.
On peut faire les deux.
Au début, j’allais dire qu’Alyssa devrait travailler chez Valve pour aider Steam à fonctionner sous Linux sur Mac, mais il semble que ce soit déjà le cas [1].
[1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career
Cela soulève une question assez intéressante : que prévoit Valve ici ?
Ce serait difficile, mais faire tourner Steam/Proton sur Mac a beaucoup de sens pour Valve, et si les gens démarrent Linux sur leur Mac pour jouer, Apple risque d’être assez agacée.
Le travail d’Alyssa R et d’Asahi Lina est excellent.
Cela dit, si l’on n’est pas familier du code de pilotes, la majeure partie de tout cela est vraiment obscure, et le côté matériel comporte tellement de bizarreries qu’on aimerait que ce genre de code puisse être écrit beaucoup plus facilement.
J’ai aussi beaucoup apprécié le côté espiègle old school du costume de sorcière.
Je me demande s’il existe du matériel connu capable de faire ça.
J’ai cherché, mais il était difficile de trouver le résultat voulu au milieu du spam de blogs sur PowerPoint, et l’IA de Google n’a pas aidé non plus.
Je me demande si je suis le seul à être surpris de voir tout ce qui manque au matériel, et à quel point une grande partie est émulée.
On peut dire qu’en pratique tout est de l’émulation.
L’une des raisons pour lesquelles les fabricants de GPU ne veulent pas publier leurs pilotes en open source est aussi qu’une grande partie de la recette secrète se trouve dans le logiciel pilote qui tourne au-dessus de cette architecture de calcul massivement parallèle.
Les geometry shaders sont largement considérés comme une erreur qui n’aurait jamais dû être standardisée, et Metal ne les a jamais pris en charge du tout ; ils ne peuvent donc apparaître que dans de vieux codes OpenGL sur macOS, et il est difficile de reprocher à Apple de ne pas les prendre en charge matériellement.
https://x.com/pointinpolygon/status/1270695113967181827
Alyssa est impressionnante
Je me souviens de son premier article sur le travail GPU, puis d’avoir appris qu’elle n’avait que 17 ans, et ça m’avait fait l’effet d’une explosion dans la tête
Le simple fait que quelqu’un ait réussi à faire ça est étonnant ; qu’une adolescente y soit parvenue est carrément stupéfiant
Si porter les dernières versions d’OpenGL et de Vulkan sur Apple Silicon est de toute façon impossible sans couche d’émulation, serait-il théoriquement possible de créer une API Metal native pour Linux ?
Ou bien Metal est-il trop profondément intégré au SDK macOS ?
MoltenVK essaie aussi de résoudre le même problème que celui évoqué par Alyssa dans sa présentation [1, le dernier commentaire de l’issue est d’Alyssa]
[1] https://github.com/KhronosGroup/MoltenVK/issues/1524
C’était en fait la conclusion de la présentation d’Alyssa Rosenzweig
Apple connaît sa documentation interne, donc l’entreprise est la mieux placée pour produire une meilleure implémentation bas niveau
Le principal obstacle aujourd’hui est cette position obstinée selon laquelle le portage vers Metal est la seule voie officiellement prise en charge
Si Valve parvient à sortir de son chapeau une méthode quasi magique pour faire tourner des jeux AAA sur Mac sans le soutien d’Apple, la situation deviendra intéressante, et cela pourrait pousser Apple à repenser son approche si elle ne veut pas se retrouver acculée sur sa propre plateforme
Il existe aussi des implémentations de DirectX pour Linux, et Proton fonctionne de cette manière
La question est plutôt de savoir si cette API doit être une couche au-dessus de Vulkan, être entièrement gérée côté client comme MoltenVK ou dxvk, ou être intégrée plus profondément à Mesa
Pour commencer, la première option semble clairement la plus simple
Je suis désormais conditionné à m’attendre, avec des titres comme celui-ci, à lire quelque chose du genre « le support est abandonné et l’équipe est acqui-hirée »
Alyssa Rosenzweig mérite un Turing Award
Je me suis toujours interrogé sur ces liens /SubscriberLink/
Est-ce contraire à l’éthique de les partager ?
Les e-mails personnels, les messages sur les listes de diffusion de projets et les billets de blog sont tous appropriés ; ils disent accueillir favorablement leur partage tant que ce n’est pas utilisé comme moyen de contourner leurs efforts pour obtenir des abonnements
Elles ont toutefois demandé poliment de ne pas les diffuser de façon excessive, car il faut bien financer le site, les auteurs et les éditeurs, et, si je comprends bien, ce financement vient uniquement des abonnements
L’abonnement à LWN reste assez abordable et soutient l’une des meilleures couvertures techniques de fond sur Linux et les sujets associés
Je n’ai aucun lien avec LWN, je suis simplement un abonné satisfait, et je pense que les connaissances que j’ai tirées de leurs articles ont aussi contribué en partie à ma réussite professionnelle
Pour que les gens s’abonnent, il faut d’abord qu’ils connaissent l’existence de LWN
Il suffit de lire la FAQ : https://lwn.net/op/FAQ.lwn#slinks
Le paywall de LWN est particulier : tout le contenu devient gratuit au bout d’une semaine
Les liens abonnés existent pour encourager les personnes qui en ont les moyens à s’abonner
Je me trompe peut-être, mais on dirait qu’un financement est attaché à la mise à disposition, probablement article par article, de contenus auparavant payants
Je me demande si quelqu’un sait si c’est réellement le cas