- Honeykrisp n’est pas encore disponible pour les utilisateurs finaux ; seul le code source destiné aux développeurs a été publié
- Honeykrisp pour M1 est la première implémentation Vulkan conforme sur du matériel Apple, et implémente l’intégralité de la spécification Vulkan 1.3 sans waiver de
portability - Honeykrisp ne part pas des travaux Vulkan existants sur M1, mais du driver NVK open source pour GPU NVIDIA ; le projet a commencé en ajoutant le code M1 et en supprimant les parties liées à NVIDIA
- Le résultat final de la suite de tests de conformité Vulkan 1.3 est enregistré à Pass 686930, Fail 0
- Tous les états sont gérés comme des états dynamiques, et du code a été ajouté pour construire, compiler et mettre en cache les prologues et épilogues, en vue d’une implémentation orientée full dynamic state et
EXT_shader_object EXT_image_drm_format_modifierest implémenté pour le rendu zero-copy- Pour la compatibilité Direct3D, Honeykrisp prend en charge
EXT_custom_border_color, requis par DXVK et vkd3d-proton, et la correction de la border colour est émulée via l’injection de code dans le shader - L’émulation de custom border colour est décrite comme « simple, correct, and slow », avec l’intention d’améliorer les performances plus tard via des astuces côté driver
- La prochaine étape consiste à implémenter les éléments requis par DXVK et vkd3d-proton pour la couche Direct3D ; transform feedback est cité comme exemple
1 commentaires
Avis sur Hacker News
Un travail vraiment impressionnant, qui montre bien la valeur de composants ouverts, partagés et améliorés de façon itérative
Je me demande combien de temps il faudra pour que Proton soit porté, mais même avec une implémentation Vulkan optimale, beaucoup de jeux risquent d’avoir de mauvaises performances à cause des différences d’architecture GPU, du surcoût de traduction ARM et du coût propre à Proton
Cela dit, je reste optimiste : si des SoC comme Snapdragon deviennent plus courants sur desktop, davantage de jeux viseront à l’avenir la mémoire unifiée et ARM
Cela montrerait à quel point le fait qu’Apple ait ignoré Vulkan ces dix dernières années a été une grosse erreur, mais ils ne l’admettront probablement jamais avant qu’il ne soit trop tard
Alyssa travaille aussi récemment sur des améliorations de performances pour FEX
Je me demande si ce travail consistant à ajouter Vulkan à Linux et à traduire DirectX sur Asahi Linux influencera le rêve d’Apple d’attirer des jeux AAA sur Apple Silicon
Apple voudrait probablement que les développeurs AAA portent leurs jeux vers Metal afin qu’ils tournent sur iPhone, iPad, Mac et Vision Pro avec une seule base de code
Peut-être que des joueurs Mac finiront par installer Asahi Linux pour jouer à des titres AAA PC
Ce qu’ils veulent vraiment, ce n’est ni Steam ni l’Epic Games Store, mais des jeux AAA dans l’App Store ; c’est pour ça que GPTK est à moitié abouti et que sa licence empêche Valve de l’intégrer directement à Steam
J’ai essayé Diablo II Resurrected sur M1 avec Whiskey, et le fait qu’un jeu Windows natif fonctionne aussi directement était assez impressionnant. Actuellement, c’est juste une stupide mise à jour du lanceur Blizzard qui plante et empêche le jeu de se lancer
C’est un ancien jeu DX9, mais EverQuest II tournait aussi très bien en 1440p sur un Mac mini M1, et Asahi Linux pourrait aussi aider avec d’anciens titres 32 bits comme Guild Wars
Je ne connais pas très bien Vulkan 1.3, mais si vous vous intéressez au travail sur les API graphiques bas niveau, ça vaut vraiment le coup d’y jeter un œil. Ce n’est plus du tout la même chose que Vulkan 1.0, et ça change la donne
Une fois la barrière initiale franchie, c’est agréable à utiliser, et grâce à tous les états dynamiques et à la suppression de la configuration préalable des render passes, c’est devenu bien plus maniable. C’est même plus simple qu’OpenGL, que j’utilise depuis 20 ans, et la programmation graphique redevient amusante
Tant qu’on a un pilote récent, on peut utiliser la plupart des fonctionnalités sur à peu près toutes les plateformes desktop dotées d’un GPU de moins de 10 ans
Malheureusement, il n’existe pas de framework à valeurs par défaut raisonnables pour démarrer immédiatement, mais il y a beaucoup de bibliothèques utilitaires utiles dans plusieurs langages
Je n’avais jamais pris le temps de passer à Vulkan, mais au final il semble qu’il suffise de franchir la barrière de l’initialisation et de la configuration. Après ça, je ne pense pas revenir à OpenGL
Cet article me motive un peu à m’y mettre pour de vrai
OpenGL était déjà comme ça à l’origine, donc ce n’est peut-être pas si différent, mais on a quand même l’impression que Khronos a vraiment bien fait les choses
Je viens justement de faire la mise à jour pour la prise en charge d’ES 3.2, et je suis déjà impressionné. J’ai l’impression que mon M1 a été conçu pour Asahi
Honnêtement, il est très probable que macOS ne soit lancé que pendant l’installation, ou une seule fois par erreur. J’apprécie ce genre de mises à jour détaillées
Je me demande s’il existe un navigateur qui prend en charge le rendu sans copie, ou si on se retrouve encore avec plusieurs couches de compositeur empilées. Je me souviens aussi que le transform feedback de WebGL2 était bloqué parce qu’il déclenchait un readback
Quand quelque chose plantait, je pensais que ça ne pouvait absolument pas être un bug du compilateur, mais le 16 avril, c’en était vraiment un
Je peux dire avec confiance que ça ne m’est jamais arrivé dans ma carrière, mais plus on descend dans le niveau d’abstraction, moins ce genre de cas est rare
Sauf si on est développeur kernel bas niveau, auquel cas les deux peuvent être vrais
Blague à part, dans la pratique c’est bien plus souvent autre chose, mais ça arrive bel et bien
Si c’est un compilateur en cours de développement, qui est justement votre propre travail en phase de test, l’adage "ça ne peut pas être un bug du compilateur" s’applique beaucoup moins
Il y a une structure étrange dans le shader :
if (condition) { while (true) { } }conditionest toujours fausse, mais le compilateur ne le sait pasAu-delà du fait que ce soit une entrée toxique pour embêter les auteurs de compilateurs de shader conformes au standard, je me demande quel est le but de cette structure
Même si ce code en lui-même n’est pas particulièrement utile en pratique, si une partie d’un shader peut, dans certaines situations, être simplifiée fonctionnellement sous cette forme, alors le compilateur doit la traiter correctement
Si l’idée ne vous est pas familière, voir ces fonctionnalités en C++, LLVM et Rust :
https://en.cppreference.com/w/cpp/utility/unreachable
https://en.cppreference.com/w/cpp/language/attributes/assume
https://en.cppreference.com/w/cpp/memory/assume_aligned
https://llvm.org/docs/LangRef.html#unreachable-instruction
https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
Une boucle infinie est en pratique une instruction inatteignable, et une instruction inatteignable après une branche revient en pratique à une instruction
assumeJe me demande si on peut utiliser ça dans une VM. Je développe sur macOS et j’en suis globalement satisfait, mais je fais tourner une image Ubuntu dans VMware pour les tests
Je fais une application graphique 3D, donc je ne sais pas trop jusqu’où va le passthrough de VMware. Je me demande si le GPU Apple Silicon est virtualisé dans la VM, et si faire tourner cette distribution pourrait améliorer les performances graphiques
Quelqu’un peut expliquer le lien avec MoltenVK ? Comme c’est un pilote natif, est-ce que MoltenVK devient inutile ?
Asahi Linux est une distribution en cours de développement qui vise à rendre Linux compatible avec les processeurs Apple série M, et cet article parle de faire fonctionner Vulkan avec accélération GPU sur Asahi
L’article le dit d’ailleurs explicitement. Ça ne peut pas s’exécuter directement sur OS X, donc cela ne supprime pas le besoin de MoltenVK