Vulkan 1.3 implémenté sur M1 en un mois
Présentation du pilote Honeykrisp
- Pilote Honeykrisp : premier pilote à implémenter la spécification complète de Vulkan 1.3 sur du matériel Apple.
- État du développement : pas encore publié pour les utilisateurs finaux, avec des ajouts de fonctionnalités et des améliorations de performances toujours en cours. Le code source est accessible aux développeurs.
Processus de développement
2 avril
- Début : lancement du développement d’un pilote Vulkan pour M1 basé sur le pilote NVK.
3 avril
- Jeux de descripteurs : adaptation aux besoins de NVK des jeux de descripteurs du M1, différents de ceux de NVIDIA.
4 avril
- Compute shaders : implémentation de la compilation des compute shaders et de la copie de buffers et d’images à l’aide de commandes Vulkan.
6 avril
- Gestion de l’état graphique : écriture du code de gestion de l’état graphique, en reprenant du code du pilote OpenGL et en le combinant avec NVK.
7 avril
- État dynamique : adoption d’une stratégie où tous les états sont gérés dynamiquement, avec ajout du code pour compiler et mettre en cache les prologues et les épilogues.
8 avril
- Résultats de test : premiers résultats avec 149 770 tests réussis, 7 741 échecs et 2 396 plantages.
9 avril
- Vulkan 1.3 : après avoir atteint un taux de réussite de 99,6 % sur Vulkan 1.1, passage à Vulkan 1.3 avec un taux de réussite de 98,3 %.
10 avril ~ 12 avril
- Tests supplémentaires : vérification du bon fonctionnement du moteur de rendu Vulkan dans SuperTuxKart et Zink, puis correction de bugs dans les tests.
16 avril ~ 17 avril
- Correction de bugs du compilateur : correction de bugs du compilateur découverts dans les tests d’indexation des descripteurs, y compris un problème de boucle infinie.
18 avril
- Rendu zero-copy : implémentation de l’extension EXT_image_drm_format_modifier pour des layouts de surface plus efficaces.
22 avril
- Revue de l’architecture du pilote : optimisation après examen de l’architecture du pilote, avec 100 millions d’appels de draw par seconde atteints dans le test vkoverhead.
24 avril ~ 25 avril
- Prise en charge de YCbCr : ajout des fonctionnalités YCbCr en réutilisant du code NVK de Mohamed Ahmed.
- Copie de requêtes : implémentation de la copie de requêtes GPU.
26 avril
- Couleur de bordure : implémentation de l’extension EXT_custom_border_color pour la compatibilité Direct3D, avec résolution des problèmes liés à la couleur de bordure.
27 avril
- Tests finaux : tous les tests sont passés, avec 686 930 réussites et 0 échec.
Plans à venir
- Prise en charge de DXVK et vkd3d-proton : implémentation prévue de fonctionnalités supplémentaires pour le layering Direct3D.
- Exécution de jeux Windows : projet d’exécuter des jeux Windows sur Asahi Linux à l’aide de Wine et d’un émulateur x86 open source.
L’avis de GN⁺
- Défi technique : implémenter Vulkan 1.3 sur M1 est un travail extrêmement ambitieux sur le plan technique, en raison de l’architecture particulière du matériel Apple.
- Utile pour les développeurs de jeux : une fois le pilote Vulkan finalisé, les développeurs de jeux pourront faire tourner leurs jeux sur davantage de plateformes.
- Besoin d’optimisation des performances : à ce stade initial, des optimisations de performances peuvent encore être nécessaires, notamment pour résoudre la surcharge CPU liée à la gestion dynamique des états.
- Contribution de la communauté : en tant que projet open source, la contribution de la communauté est importante. Des tests et retours sont nécessaires dans des environnements matériels et logiciels variés.
- Produits concurrents : au-delà de DXVK et vkd3d-proton, il existe d’autres couches de compatibilité comme Wine. Il est important de comparer les avantages et inconvénients de chaque solution avant de choisir.
1 commentaires
Avis Hacker News
Un travail impressionnant qui démontre la valeur des composants partagés, itératifs et ouverts. Je me demande combien de temps il faudra pour porter Proton. Il est possible que beaucoup de jeux ne fonctionnent pas correctement à cause des différences d’architecture GPU et du surcoût de la traduction ARM. Malgré tout, je reste optimiste : à mesure que les SoC deviennent plus courants, davantage de jeux viseront la mémoire unifiée et ARM.
Je me demande si les efforts pour ajouter Vulkan à Linux et traduire DirectX sur Asahi Linux auront un impact sur le rêve d’Apple d’amener les jeux AAA sur Apple Silicon. Apple veut que les développeurs AAA portent leurs jeux vers Metal afin qu’ils tournent sur iPhone, iPad, Mac et Vision Pro. Il est aussi possible que des joueurs Mac installent Asahi Linux pour jouer à des titres AAA PC.
Si vous ne connaissez pas bien Vulkan 1.3 mais que le travail sur les API graphiques bas niveau vous intéresse, cela vaut le détour. Une fois les premiers obstacles franchis, c’est agréable à utiliser. Tous les états dynamiques et les render passes sans présélections rendent le travail bien plus simple. C’est disponible sur toutes les plateformes desktop disposant d’un GPU de moins de 10 ans. En revanche, il n’existe pas de framework avec des « valeurs par défaut raisonnables », mais il y a beaucoup de bibliothèques utilitaires utiles dans plusieurs langages.
J’aimerais avoir ne serait-ce que la moitié de ses compétences en programmation. C’est vraiment impressionnant.
L’incroyable magie de codage d’Alyssa. Je ne sais pas comment elle fait, mais je suis heureux qu’elle mène ce bon combat.
Les bugs de compilateur n’arrivent jamais. Sauf qu’en fait, c’était vraiment un bug de compilateur. Je n’en ai jamais rencontré en carrière, mais à certains niveaux d’abstraction, cela peut être moins rare.
Je viens justement de voir la mise à jour de la prise en charge d’ES 3.2, et le M1 a l’air d’avoir été conçu pour Asahi. macOS n’a démarré qu’une seule fois, lors de l’installation. Je me demande si les navigateurs prennent en charge le « rendu zero-copy ». Je me souviens être resté bloqué sur un problème où le transform feedback de WebGL2 déclenchait une opération de lecture.
Il y a une structure de shader inhabituelle. La condition est toujours fausse, mais le compilateur ne peut pas le savoir. Je me demande quel est l’objectif de cette structure.
Utilisable dans une VM ? Je développe sur macOS et j’utilise une image VMware pour tester Ubuntu. Je développe une application graphique 3D, mais je ne sais pas à quel point le passthrough de VMware est bon. Je me demande si le GPU Apple Silicon est virtualisé dans une VM, et s’il serait possible d’exécuter cette distribution pour obtenir de meilleures performances graphiques.
Je me demande si quelqu’un pourrait expliquer la relation avec MoltenVK. Est-ce que ce travail supprime le besoin de MoltenVK ? Est-ce un pilote natif ?