Pilotes GPU Apple maintenant dans Asahi Linux

Pilotes GPU Apple maintenant dans Asahi Linux

Bonjour à tous! Nous sommes ravis d’annoncer notre première version publique du pilote GPU Apple Silicon !

Nous avons travaillé dur ces deux dernières années pour proposer ce nouveau pilote à tout le monde, et nous sommes vraiment fiers d’être enfin là. Il s’agit toujours d’un pilote alpha, mais il est déjà suffisant pour exécuter une expérience de bureau fluide et certains jeux.

Lisez la suite pour en savoir plus sur l’état des choses aujourd’hui, comment l’installer (c’est un package opt-in) et comment signaler les bogues !

Cette version comprend la prise en charge en cours d’OpenGL 2.1 et d’OpenGL ES 2.0 pour tous les systèmes Apple de la série M actuels. C’est suffisant pour l’accélération matérielle avec des environnements de bureau, comme GNOME et KDE. C’est également suffisant pour les jeux 3D plus anciens, comme Quake3 et Neverball. Bien qu’il y ait toujours place à l’amélioration, le pilote est assez rapide pour exécuter tout ce qui précède à 60 images par seconde à 4K.

Remarque : ces pilotes n’ont pas encore passé les tests de conformité OpenGL (ES). Il y aura des bugs !

Et après? Prise en charge de plus d’applications. Alors qu’OpenGL (ES) 2 suffit pour certaines applications, les plus récentes (en particulier les jeux) exigent davantage de fonctionnalités OpenGL. OpenGL (ES) 3 apporte une multitude de nouvelles fonctionnalités, telles que plusieurs cibles de rendu, le multi-échantillonnage et le retour de transformation. Le travail sur ces fonctionnalités est en bonne voie, mais chacune d’entre elles nécessitera beaucoup d’efforts de développement supplémentaires, et toutes sont nécessaires avant qu’OpenGL (ES) 3.0 ne soit disponible.

Et Vulkan ? Nous y travaillons ! Bien que nous n’expédions que OpenGL pour le moment, nous concevons en pensant à Vulkan. La plupart du travail que nous consacrons à OpenGL sera réutilisé pour Vulkan. Nous avons estimé que nous pouvions livrer des pilotes OpenGL 2 fonctionnels beaucoup plus tôt qu’un pilote Vulkan 1.0 fonctionnel, et nous voulions mettre entre vos mains des ordinateurs de bureau à accélération matérielle dès que possible. Pour la plupart, ces ordinateurs de bureau utilisent OpenGL, donc la prise en charge d’OpenGL était d’abord plus logique pour nous que de plonger dans l’extrémité profonde de Vulkan, uniquement pour utiliser Zink pour traduire OpenGL 2 en Vulkan pour exécuter des ordinateurs de bureau. De plus, il existe un large éventail de supports OpenGL, avec OpenGL 2.1 contenant une fraction des fonctionnalités d’OpenGL 4.6. Il en va de même pour Vulkan : le profil Vulkan 1.0 de base est à peu près équivalent à OpenGL ES 3.1, mais les applications de nos jours veulent Vulkan 1.3 avec des tonnes d’extensions et de fonctionnalités « optionnelles ». La «superposition» d’OpenGL par Zink sur Vulkan n’est pas magique: elle ne peut exposer que les fonctionnalités OpenGL du pilote Vulkan sous-jacent. Un pilote Vulkan 1.0 de base n’est même pas suffisant pour obtenir OpenGL 2.1 sur Zink ! Zink lui-même annonce la prise en charge d’OpenGL 4.6, mais bien sûr, ce n’est que lorsqu’il est associé à des pilotes Vulkan qui prennent en charge l’équivalent d’OpenGL 4.6… et cela nous ramène à une quantité énorme de temps et d’efforts.

Lire aussi  Nouveaux portables | Les mobiles les plus avancés présentés au Mobile Word Congress 2023

Quand le support OpenGL 3 sera-t-il prêt ? OpenGL 4 ? Vulkan 1.0 ? Vulkan 1.3 ? Dans les projets open source communautaires, on dit que chaque fois que quelqu’un demande quand une fonctionnalité sera terminée, cela retarde cette fonctionnalité d’un mois. Eh bien, beaucoup de gens ont demandé…

Quoi qu’il en soit, pour un aperçu… voici le moteur de rendu différé de SuperTuxKart fonctionnant à pleine vitesse, utilisant généreusement les fonctionnalités d’OpenGL ES 3 comme plusieurs cibles de rendu ~

Le moteur de rendu différé de SuperTuxKart s'exécutant sur un Apple M1

Les GPU modernes se composent de nombreuses parties « en couches » distinctes. Il y a…

  • une unité de gestion de mémoire et une interface pour soumettre un travail mappé en mémoire au matériel
  • matériel 3D à fonction fixe pour pixelliser les triangles, effectuer des tests de profondeur/pochoir, etc.
  • des “cœurs de shader” programmables (comme de petits processeurs avec des jeux d’instructions sur mesure) avec un travail réparti par le matériel à fonction fixe

Ce matériel « en couches » exige une pile de pilotes graphiques « en couches ». Nous avons besoin…

  • un pilote de noyau pour mapper la mémoire et soumettre un travail mappé en mémoire
  • un pilote d’espace utilisateur pour traduire les appels OpenGL et Vulkan en structures de données spécifiques au matériel dans la mémoire graphique
  • un compilateur traduisant les langages de programmation d’ombrage comme GLSL vers le jeu d’instructions du matériel

C’est beaucoup de travail, qui demande un travail d’équipe ! Heureusement, cette superposition nous donne des limites naturelles pour répartir le travail au sein de notre petite équipe.

Entre-temps, Ella Stanforth travaille sur un pilote Vulkan, en réutilisant le pilote du noyau, le compilateur et du code partagé avec le pilote OpenGL.

Bien sûr, nous ne pouvions pas construire un pilote OpenGL en moins de deux ans nous-mêmes. Grâce à la puissance des logiciels libres et open source, nous nous appuyons sur les géants du FOSS. Le compilateur implémente un backend “NIR”, où NIR est une représentation intermédiaire puissante, y compris la traduction GLSL vers NIR. Le pilote du noyau utilise le sous-système “Direct Rendering Manager” (DRM) du noyau Linux pour minimiser le passe-partout. Enfin, le pilote OpenGL implémente l’API “Gallium3D” à l’intérieur de Mesa, la maison des pilotes open source OpenGL et Vulkan. Grâce à Mesa et Gallium3D, nous bénéficions de trente ans de développement de pilotes OpenGL, avec un code commun traduisant OpenGL en Gallium3D beaucoup plus simple. Grâce à l’incroyable ingénierie de NIR, Mesa et Gallium3D, notre équipe hétéroclite de rétro-ingénieurs peut se concentrer sur ce qui reste : le matériel Apple.

Lire aussi  Fonds FEMA disponibles pour la nation Navajo après le blizzard et les inondations

Pour obtenir les nouveaux pilotes, vous devez exécuter le linux-asahi-edge noyau et installez également le mesa-asahi-edge Forfait Mesa.

$ sudo pacman -Syu
$ sudo pacman -S linux-asahi-edge mesa-asahi-edge
$ sudo update-grub

Étant donné qu’une seule version de Mesa peut être installée à la fois, pacman vous demandera de remplacer mesa avec mesa-asahi-edge. C’est normal!

Nous vous recommandons également d’exécuter Wayland au lieu de Xorg à ce stade, donc si vous utilisez l’environnement KDE Plasma, assurez-vous d’installer la session Wayland :

$ sudo pacman -S plasma-wayland-session

Ensuite, redémarrez, choisissez la session Wayland en haut de l’écran de connexion (SDDM), et profitez-en ! Vous voudrez peut-être ajuster le facteur d’échelle de l’écran dans Paramètres système → Affichage et moniteur (Plasma Wayland est par défaut à 100% ou 200%, tandis que 150% est souvent plus agréable). Si vous avez activé “Forcer la police DPI” sous Apparence → Polices, vous devez le désactiver (il est enregistré séparément pour Wayland et Xorg, et ne devrait pas être nécessaire sur les sessions Wayland). Déconnectez-vous et reconnectez-vous pour que ces modifications s’appliquent pleinement.

Les environnements de bureau basés sur Xorg et Xorg devraient fonctionner, mais il existe quelques problèmes connus :

  • Attendez-vous à une déchirure de l’écran (cela pourrait être corrigé bientôt)
  • VSync ne fonctionne pas (certaines animations KDE seront trop rapides et les applications GL ne limiteront pas leur FPS même avec VSync activé). Il s’agit d’une limitation de Xorg sur les contrôleurs d’affichage Apple DCP, qui ne prennent pas en charge les interruptions VBlank.
  • Il y a encore des bogues de pilotes déclenchés par Xorg/KWin. Nous examinons cela.

La linux-asahi-edge noyau peut être installé côte à côte avec le standard linux-asahi package, mais les deux versions doivent être synchronisées, alors assurez-vous de toujours mettre à jour vos packages ensemble ! Vous pouvez toujours choisir le linux-asahi kernel dans le menu de démarrage GRUB, ce qui désactivera l’accélération GPU et le pilote d’affichage DCP.

Lorsque les packages sont mis à jour ultérieurement, il est possible que les applications graphiques cessent de démarrer après une mise à jour jusqu’à ce que vous redémarriez, ou elles peuvent revenir au rendu logiciel. C’est normal. Jusqu’à ce que l’UAPI soit stable, nous devrons rompre la compatibilité entre Mesa et le noyau de temps en temps, vous devrez donc redémarrer pour que les choses fonctionnent après les mises à jour. En général, si les applications fais continuez à travailler avec l’accélération après une mise à jour particulière de Mesa, alors il est probablement prudent de ne pas redémarrer, mais vous devriez quand même le faire pour vous assurer que vous utilisez le dernier noyau !

Lire aussi  Plongez dans la Samsung Digital City : un campus R&D monumental et symbole de la puissance coréenne

Étant donné que le pilote est encore en développement, il existe de nombreux problèmes connus et nous travaillons toujours dur pour améliorer les résultats des tests de conformité. S’il vous plaît, n’ouvrez pas de nouveaux bogues pour des applications aléatoires qui ne fonctionnent pas ! Nous n’en sommes encore qu’aux premiers jours et nous savons qu’il y a beaucoup de travail à faire. Voici un guide rapide sur la façon de signaler des bugs :

  • Si vous trouvez une application qui ne démarre pas du tout, veuillez ne pas la signaler comme un bogue. De nombreuses applications ne fonctionneront pas car elles nécessitent une version GL plus récente que celle que nous prenons en charge. Veuillez définir le LIBGL_ALWAYS_SOFTWARE=1 variable d’environnement pour que ces applications reviennent au rendu logiciel. S’il s’agit d’une application populaire qui fait partie du référentiel Arch Linux ARM, vous pouvez faire un commentaire sur ce problème à la place, nous pouvons donc ajouter des bizarreries Mesa à la solution de contournement.
  • Si vous rencontrez des problèmes causés par linux-asahi-edge sans rapport avec le GPU, veuillez ajouter un commentaire à ce problème. Cela inclut les problèmes de sortie d’affichage ! (Résolutions, contrôle du rétroéclairage, contrôle de l’alimentation de l’affichage, etc.)
  • Si le GPU se bloque et que toutes les applications GPU cessent de fonctionner, exécutez asahi-diagnose (par exemple, depuis une session SSH), ouvrez un nouveau bogue sur AsahiLinux/linuxjoignez le fichier généré par cette commande et dites-nous ce que vous faisiez qui a causé le blocage.
  • Pour les autres problèmes de GPU (problèmes de rendu, applications qui se bloquent après un démarrage correct, etc.), exécutez asahi-diagnose et faire un commentaire sur ce problème, en joignant le fichier généré par cette commande. N’oubliez pas de nous parler de votre environnement !
  • À l’avenir, si une mise à jour du pilote provoque une régression (problèmes de rendu ou plantages pour les applications qui fonctionnaient auparavant correctement), vous pouvez ouvrir un bogue directement dans le tracker Mesa.

Nous espérons que vous apprécierez notre chauffeur ! N’oubliez pas que les choses évoluent toujours rapidement, alors assurez-vous de mettre à jour vos packages régulièrement pour obtenir des mises à jour et des corrections de bugs !

Alyssa Rosenzweig & Asahi Lina · 2022-12-07

Facebook
Twitter
LinkedIn
Pinterest

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.