Le premier pilote GPU M1 certifié conforme OpenGL ES

 (rosenzweig.io)
1 points par GN⁺ 2023-08-23 | 1 commentaires | Partager sur WhatsApp
  • Un pilote Linux permet désormais d’exécuter des applications OpenGL ES 3.1 de manière conforme à la norme sur les GPU des familles M1 et M2
  • Le pilote libre et open source d’Asahi Linux, issu de l’ingénierie inverse, est la seule implémentation OpenGL ES 3.1 conforme aux tests Khronos sur le matériel graphique M1 et M2
  • La certification passe par la réussite des tests officiels, une soumission à Khronos et une période d’examen de 30 jours ; les entrées M1, M1 Pro/Max/Ultra, M2 et M2 Pro/Max sont désormais enregistrées
  • OpenGL ES 3.1 met à jour la prise en charge expérimentale d’OpenGL ES 3.0 et d’OpenGL 3.1 introduite en juin, en ajoutant les compute shaders et les opérations atomiques sur image
  • Le M1 ne disposant pas d’instruction dédiée pour les opérations atomiques sur image, le pilote a d’abord contourné cela par calcul d’adresse, avant de découvrir une instruction d’entrelacement de bits réduisant 10 instructions à 1

Certification de conformité OpenGL ES 3.1 pour M1 et M2

  • Un pilote certifié conforme OpenGL ES 3.1 pour les GPU des familles M1 et M2 est disponible
    • Compatible avec les applications OpenGL ES 3.1
    • Utilisable via une installation Linux
  • Les utilisateurs actuels d’Asahi Linux peuvent obtenir le dernier pilote avec la commande de mise à niveau propre à leur distribution
    • Fedora : dnf upgrade
    • Arch : pacman -Syu
  • Le pilote graphique libre et open source issu de l’ingénierie inverse est publié sur asahi/mesa
  • Ce pilote est la seule implémentation certifiée conforme OpenGL ES 3.1 au monde sur le matériel graphique des familles M1 et M2
    • Des dizaines de milliers de tests ont été réussis pour démontrer sa précision
    • Il a reçu la reconnaissance de l’organisme de normalisation du secteur

Procédure Khronos et familles de puces enregistrées

  • Pour obtenir la certification de conformité, l’implémentation doit réussir la suite officielle de tests de conformité
    • La suite de tests est conçue pour vérifier toutes les fonctionnalités de la spécification
    • Les résultats sont soumis à l’organisme de normalisation Khronos
    • En l’absence de problème pendant la période d’examen de 30 jours, l’implémentation devient certifiée conforme
  • Sur le site de Khronos, les pilotes suivants sont enregistrés comme implémentations conformes
  • Cette avancée ne se limite pas à OpenGL ES
    • Il s’agit de la première implémentation certifiée conforme de tout le paysage des standards graphiques sur M1

L’écart entre les pilotes du constructeur et les API standard

  • Le pilote M1 du constructeur n’a obtenu de certification de conformité pour aucune API graphique standard, y compris Vulkan, OpenGL et OpenGL ES
  • Sur les environnements M1 et M2 qui n’utilisent pas Linux, rien ne garantit le fonctionnement des applications fondées sur les standards
  • Dans le cas de Vulkan, MoltenVK superpose une partie de Vulkan au-dessus du pilote propriétaire
    • Il manque à ce pilote propriétaire des fonctionnalités essentielles
    • Des applications Vulkan valides peuvent donc dysfonctionner
    • Cela constitue un obstacle pour les développeurs comme pour les utilisateurs qui n’ont pas basculé leurs machines M1 ou M2 sous Linux
  • Le développement du pilote Asahi Linux vise à faire fonctionner les logiciels standards sur M1 sans hacks spécifiques ni portages dédiés
    • Il ne se satisfait ni des pilotes propriétaires, ni des API propriétaires, ni du refus d’implémenter les standards
    • Une implémentation d’un standard ouvert conforme à la spécification est considérée comme la direction souhaitable pour l’écosystème

Les principales nouveautés d’OpenGL ES 3.1

  • OpenGL ES 3.1 met à jour la prise en charge expérimentale d’OpenGL ES 3.0 et OpenGL 3.1 introduite en juin
  • La principale nouveauté est celle des compute shaders
    • Ils servent surtout à accélérer des calculs généraux au sein des applications graphiques
    • Les jeux 3D peuvent exécuter leurs simulations physiques dans des compute shaders
    • En utilisant directement les résultats de simulation pour le rendu, on réduit les blocages dus à la synchronisation entre le GPU et la simulation physique sur CPU
    • Les jeux peuvent ainsi s’exécuter plus rapidement

Pourquoi les opérations atomiques sur image sont nécessaires

  • Les versions précédentes d’OpenGL ES permettaient déjà aux applications de lire des images pour l’affichage à l’écran
  • ES 3.1 permet aux applications d’écrire dans les images, généralement depuis des compute shaders
    • Cela réduit la contrainte consistant à adapter les algorithmes de traitement d’image au pipeline 3D à fonction fixe
  • Le GPU est une architecture massivement parallèle qui exécute des milliers de threads simultanément
    • Si deux threads écrivent au même endroit, le résultat dépend de l’ordre d’exécution
    • Cette situation correspond à une condition de course
  • L’accès mémoire atomique est la solution de base pour traiter les conditions de course
    • Un matériel spécialisé du sous-système mémoire garantit un résultat cohérent pour certaines opérations, quel que soit l’ordre des threads
    • Le matériel graphique moderne prend en charge plusieurs opérations atomiques, comme l’addition
  • L’extension OpenGL ES OES_shader_image_atomic ajoute les opérations atomiques sur les pixels d’image
    • Cette extension est obligatoire dans ES 3.2
    • Par exemple, un compute shader peut incrémenter de façon atomique la valeur du pixel (10, 20)

Comment les opérations atomiques sur image ont été implémentées sur M1

  • D’autres GPU fournissent des instructions dédiées aux opérations atomiques sur image, ce qui simplifie l’implémentation du pilote
  • Le M1 ne dispose d’aucune instruction matérielle dédiée aux opérations atomiques sur image
    • Il existe des opérations atomiques hors image
    • Il existe aussi des fonctionnalités d’image non atomiques
  • Le choix a donc été de ne pas effectuer directement l’opération atomique sur le pixel, mais de calculer l’adresse mémoire du pixel, puis d’exécuter une opération atomique générique sur cette adresse
  • Si l’image était disposée de façon linéaire en mémoire, ce calcul d’adresse serait simple
    • On multiplie la coordonnée Y par le stride, c’est-à-dire le nombre d’octets par ligne
    • On multiplie la coordonnée X par le nombre d’octets par pixel
    • On additionne les deux pour obtenir le décalage en octets à partir du premier pixel
    • On ajoute ce décalage à l’adresse du premier pixel pour obtenir l’adresse finale
  • En pratique, les images ne sont généralement pas disposées de manière linéaire
    • Le matériel graphique moderne entrelace les coordonnées X et Y pour améliorer l’efficacité du cache
    • La disposition des pixels en mémoire ne suit donc pas des lignes successives, mais plutôt une courbe proche d’une spirale

Optimisation par entrelacement de bits et recherche d’une instruction cachée

  • Entrelacer les coordonnées X et Y en masquant et décalant un bit à la fois est inefficace
  • Un algorithme de manipulation de bits bien connu mélange les groupes de bits pour paralléliser le problème
    • Implémenter cet algorithme dans le code shader améliore les performances
  • En réalité, seuls les 7 bits de poids faible ou moins de chaque coordonnée sont entrelacés
    • Il est possible de placer X et Y dans les moitiés basse et haute d’un registre 32 bits, puis de traiter le tout en une instruction 32 bits
    • Cela réduit de moitié le nombre d’instructions
    • L’instruction combinée shift-and-add du GPU est également mise à profit
  • En combinant ces techniques, il a été possible d’effectuer l’entrelacement en 10 instructions d’assembleur GPU M1
  • L’étape suivante a consisté à examiner l’éventuelle existence d’une instruction dédiée d’entrelacement de bits
    • PowerVR dispose de l’instruction de shuffle shfl
    • Comme le GPU M1 reprend des éléments de PowerVR, l’hypothèse d’une instruction similaire a été étudiée
    • Le compilateur propriétaire n’utilisant pas cette instruction lors de la compilation d’un shader de test, il était difficile de l’identifier par simple observation du code généré

Confirmation de l’instruction d’entrelacement par hypothèse et vérification

  • Dougall Johnson a formulé une hypothèse à partir d’encodages d’instructions déjà connus
  • L’instruction d’inversion de bits contient un champ de 2 bits qui spécifie l’opération, avec la valeur 01
    • L’instruction de comptage des bits à 1 utilise 10
    • L’instruction de recherche du premier bit à 1 utilise 11
    • Les instructions complexes connues de manipulation de bits utilisent ces trois valeurs
  • La valeur restante, 00, n’avait encore jamais été observée
    • S’il existait une instruction d’entrelacement, elle pouvait ressembler à l’instruction d’inversion de bits tout en utilisant le code opération 00
  • Les trois instructions connues ne prennent qu’une seule source en entrée, alors qu’une instruction d’entrelacement en exige deux
    • Les instructions du GPU M1 encodent généralement les emplacements des sources de manière cohérente
    • Un espace vide apparaissait à l’emplacement attendu de la seconde source dans les instructions arithmétiques à deux sources, d’où l’hypothèse qu’il s’agissait du second opérande
  • La vérification a été menée en modifiant le compilateur afin de remplacer une opération entière à deux sources, comme une multiplication, par l’encodage supposé de l’instruction d’entrelacement
    • Cette opération a été utilisée dans un compute shader
    • Le shader de test vérifiait, pour chaque entrée possible, si l’instruction inconnue renvoyait bien le résultat d’entrelacement
    • L’instruction prenant deux sources 16 bits, cela représentait environ 4 milliards d’entrées
    • Grâce à la nouvelle prise en charge compute du pilote, le GPU M1 a pu vérifier l’ensemble en moins d’une seconde
  • Au final, les 10 instructions d’assembleur vectorisé ont été remplacées par une seule instruction d’entrelacement
    • Cette méthode est rapide et réussit aussi les tests de conformité

À lire aussi

1 commentaires

 
GN⁺ 2023-08-23
Avis de Hacker News

  • Comme Apple collabore avec nVidia, Adobe, Autodesk, Microsoft et d’autres autour d’OpenUSD, un format de scènes pour le rendu/l’animation/la CAO/la 3D, je me demande si la prise en charge d’OpenGL et de Vulkan va s’améliorer
    Si le cœur d’OpenUSD est « un format de fichier unique, rendu de manière cohérente partout », Apple pourrait s’en servir comme moyen d’attirer davantage d’éditeurs de logiciels 3D vers macOS
    À l’avenir, Apple semble avoir deux voies : suivre les standards OpenGL/Vulkan existants, qui tirent leur force des pipelines de production cinéma et jeu vidéo, ou au contraire pousser Metal encore plus fort pour emmener le monde vers Metal + macOS
    J’aimerais la première option, mais mon intuition est qu’Apple va tout miser sur la seconde ; et Apple n’est pas la seule : nVidia, Autodesk, Adobe et Microsoft n’aiment pas particulièrement les standards qu’ils ne contrôlent pas

    • J’aimerais ajouter une nuance du genre : « Apple aime les standards ouverts quand elle est en position de faiblesse »
      L’iMac et les débuts d’OS X mettaient fortement en avant des standards comme USB, JPEG, MPEG, mp3, PostScript, TCP/IP intégré ou .rtf, et Jobs insistait aussi là-dessus
      Ensuite, après être revenue du bord du gouffre, l’entreprise a recommencé à « ajouter de la valeur » ; l’iPhone aussi, au début, était présenté comme un appareil HTML, plutôt qu’un appareil fondé sur Flash, propriétaire et médiocre, ou sur le « HTML mobile » encore immature
      Aujourd’hui encore, dans les domaines où sa domination de marché est faible, Apple prend en charge des standards qu’elle ne contrôle pas, comme H.264 ou Matter/Thread
    • Apple prend en charge plusieurs standards ouverts, mais il me semble plus exact de dire qu’elle « ne veut pas dépendre de standards qu’elle ne contrôle pas »
      Comme elle combine fortement matériel et logiciel pour créer l’expérience utilisateur voulue, on comprend sa volonté d’implémenter des standards qu’elle peut contrôler dans une certaine mesure, afin que cette expérience ne dépende pas d’autrui
      Même pour des standards industriels dont la direction n’est pas encore figée, comme USB-C, Apple peut les adopter si elle bouge tôt, car cela lui permet d’influencer leur évolution
    • OpenUSD est une manière de regrouper et de spécifier les données à rendre ; c’est indépendant de l’API qu’une application utilise pour l’accélération du rendu
      Adobe, Autodesk, Blender et la plupart des autres prennent déjà en charge des backends différents selon le système d’exploitation, et cela inclut Metal sur macOS
    • Je ne pense pas qu’Apple revienne un jour à OpenGL
      OpenGL est trop ancien, écrire de bons pilotes est quasiment un cauchemar, et même écrire du code applicatif performant est difficile ; donc ce n’est pas vraiment une perte
      Cela dit, j’aurais préféré qu’Apple pousse Vulkan plutôt que de créer Metal, mais en dehors de Linux, Vulkan reste globalement un citoyen de seconde zone — même si c’est un citoyen de seconde zone plutôt correct à cibler
      Du point de vue des jeux ou de la prise en charge de Steam, beaucoup de jeux délèguent la gestion de l’API au moteur ; et si une équipe a les moyens de manipuler directement l’API, MoltenVK sera probablement acceptable tant qu’elle n’utilise pas des fonctionnalités très avancées
      J’ai beaucoup utilisé OpenGL toute ma vie pour le multiplateforme, mais entre l’état global, les fonctions à éviter, les pièges, les énormes en-têtes d’extensions et le débogage difficile, c’était vraiment une API médiocre ; Vulkan est verbeux, mais à bien des égards il est même plus facile
    • La situation Metal/Vulkan/OpenGL est regrettable et je ne comprends pas bien les motivations d’Apple
      Mais le Mac que j’utilise actuellement est connecté à plusieurs périphériques et à un grand moniteur uniquement via des ports USB-C, avec des protocoles standards
      Dans l’ensemble, Apple semble préférer les standards ouverts quand ils sont suffisants ; à l’époque où l’USB2 ne permettait pas de faire une grande partie de ce que faisait Lightning, Apple a créé Lightning, mais dès qu’USB-C est arrivé, elle l’a adopté sur Mac et iPad — et malheureusement, elle traîne encore des pieds sur l’iPhone

  • Asahi et Alyssa sont des géants de la rétro-ingénierie, et leur travail est presque incroyable
    Je pense qu’il est très probable qu’Apple ait essayé de les recruter, ou ait au moins voulu le faire, mais qu’ils aient refusé

    • Alyssa est déjà sous contrat avec Valve
      On peut même considérer que Valve a davantage de raisons commerciales qu’Apple d’exploiter ces compétences
    • Apple a probablement déjà essayé, mais ils ont peut-être refusé à cause de NDA et de clauses de non-concurrence ; ou alors les RH n’ont pas su évaluer correctement leurs profils
    • Un emploi salarié n’est pas une très bonne proposition
      En général, un salarié est rémunéré bien moins que les bénéfices qu’il génère, et c’est particulièrement vrai dans l’IT
      Les personnes talentueuses ont plutôt intérêt à créer une société et à vendre leurs services au juste prix, mais dans certains pays, les grandes entreprises ont fait du lobbying auprès des gouvernements pour bloquer ce genre de voie

  • Le truc avec les opérations atomiques était très satisfaisant, et déduire l’instruction de swizzle à partir de la lignée PowerVR était particulièrement impressionnant
    Les ingénieurs d’Apple eux-mêmes pourraient en tirer des enseignements, ou au moins apprécier l’intelligence de l’approche
    Cela me rappelle l’époque où, chez Accolade, des ingénieurs faisaient de la rétro-ingénierie du matériel vidéo de la Sega Genesis : ils étaient partis de la documentation publique du VDP Texas Instruments TMS9918 pour déduire le VDP dérivé du 9918 utilisé dans la Genesis/Mega Drive

    • Apple dispose de documentation interne sur ses propres puces ; donc même si elle apprécie sûrement le travail à sa juste valeur, elle n’est pas dans une situation où elle aurait conçu une boîte noire puis oublié comment elle fonctionne au moment d’écrire le logiciel

  • Pour être clair, ce n’est pas simplement le premier pilote Linux certifié conforme ; c’est plus important que cela
    Apple elle-même n’étant pas conforme à OpenGL ES 3.1, il s’agit littéralement du premier pilote OpenGL ES 3.1 certifié conforme pour la série M, tous systèmes d’exploitation confondus
    C’est pourquoi il y a un appel à faire des dons à l’équipe
    https://asahilinux.org/support/

    • J’aime vraiment ce qu’ils font, mais une fois, après avoir cliqué sur un lien asahilinux depuis Hacker News, une pop-up indiquait que les lecteurs de Hacker News n’étaient pas les bienvenus sur le site, et je n’ai pas pu lire le contenu
    • Je me demande si cela peut être utilisé sous macOS
    • Le lien GitHub qui s’y trouve renvoie vers marcan, qui dirige Asahi, mais j’aimerais surtout soutenir le développement des pilotes
      S’il existe une option pour cela, j’aimerais savoir où la trouver ; sinon, j’utiliserai simplement ce lien plus tard

  • Aujourd’hui, si l’on débogue une app OpenGL macOS qui n’est plus recommandée, le problème devient très évident
    C’est parce que la couche d’abstraction n’expose pas l’état réel d’OpenGL d’une manière lisible par l’ancien débogueur OpenGL d’Apple
    À moins d’avoir un vieux Mac avec une ancienne version de macOS où OpenGL ne fonctionnait pas en interne au-dessus de Metal, il est pratiquement impossible de déboguer OpenGL sur macOS avec le débogueur par défaut
    Le débogueur ou l’app plante tout simplement

  • Cela semble surtout aider les jeux, et pas beaucoup le deep learning
    Le principal attrait du Mac M1 est sa grande capacité mémoire ; ce n’est peut-être pas idéal pour l’entraînement, puisqu’on ne peut pas répartir la charge sur plusieurs cartes, mais c’est intéressant comme moteur d’inférence pour de grands modèles comme Stable Diffusion ou LLaMA

    • Les deux standards GPU généralistes cross-platform les plus récents qu’Apple Silicon pourrait théoriquement utiliser ou implémenter sont SYCL et Vulkan Compute
      SYCL est un framework de programmation haut niveau, neutre vis-à-vis des fournisseurs, du Khronos Group, mais le support côté applications reste limité ; on peut espérer qu’il s’améliore progressivement grâce au soutien d’Intel
      Vulkan Compute contourne le problème via les compute shaders, mais je connais mal l’état du support applicatif
      SYCL peut être implémenté au-dessus d’OpenCL et de son extension SPIR-V, mais à cause d’une forte dépendance aux fournisseurs, cette voie a été largement abandonnée en dehors d’Intel et de Mesa ; aujourd’hui, il est souvent implémenté via des backends pour les API de chaque fournisseur GPU, comme ROCm, HIP ou CUDA
      Appliquer la même approche à Metal serait très difficile ; Mesa dispose d’un support expérimental OpenCL+SPIR-V pour Intel et AMDGPU, qui pourrait en théorie être étendu à Apple Silicon, mais l’OpenCL d’Apple Silicon n’est actuellement pas du tout pris en charge et n’en était qu’au stade de la feuille de route
    • Exact
      Pour faire tourner du deep learning, il faut des backends comme CUDA, ROCm, MPS
      Il était relativement simple d’entraîner un modèle PyTorch sur un gros serveur CUDA et de faire tourner l’inférence sur un MacBook Air
    • La partie compute shaders est un bon progrès, mais elle ne fournit toujours pas l’interface attendue par ces outils de deep learning
      Cela dit, eiln a écrit un pilote pour l’Apple Neural Engine, ce qui permettra d’utiliser le matériel dédié au lieu du GPU, et il devrait être fusionné dans linux-asahi à l’avenir
    • TensorFlow Lite prend effectivement en charge OpenGL ES

  • Dire qu’Asahi Lina et deux personnes ont battu une grande entreprise avec un financement minimal, c’est une belle formule, mais en réalité, ce n’est pas tant qu’ils l’ont battue que le fait qu’Apple ne s’en préoccupait pas
    Apple n’a jamais pris part à cette course

  • J’aime bien l’euphémisme « deux personnes ont battu une grande entreprise avec un financement minimal »
    C’est clairement embarrassant pour Apple ; Apple ne s’intéresse pas aux standards ni à la conformité, et veut que les gens restent enfermés dans son jardin clos
    Si je n’étais pas développeur iOS, j’aurais quitté l’écosystème Apple depuis longtemps
    J’aime le matériel, et j’aimais aussi la marque qui, comme Apple dans les années 80-90, mettait en avant la créativité et l’humain ; mais l’entreprise actuelle semble pourrie par la cupidité derrière des vidéos marketing politiquement correctes

    • Je suis entièrement d’accord, mais trouver une alternative pertinente est, en pratique, presque impossible
      Lors de ma dernière mise à niveau, j’ai cherché des alternatives, mais sortir d’Apple impliquait d’accepter une succession infinie de compromis
      À la place d’un iPhone, j’ai regardé du côté du Pixel en espérant un Android stock et un long support, mais les problèmes de batterie revenaient sans cesse, et la finition logicielle, l’écosystème d’apps et la stabilité posaient aussi problème
      Il était aussi difficile de trouver un produit au rapport qualité-prix proche du MacBook Air M1 de base en matière de qualité de fabrication, d’autonomie et de stabilité
      Je lis aussi des mangas et des magazines sur iPad, mais sur le marché des tablettes, je ne vois toujours pas quelle serait l’alternative depuis des années ; je pourrais sans doute me passer de l’Apple Watch, mais elle fonctionne tout simplement bien et dispose d’un riche choix d’accessoires tiers
      L’époque où j’installais une nouvelle ROM tous les jours est désormais derrière moi, et il semble difficile de battre Apple sur la stabilité et la simplicité d’usage, ce qui est dommage
    • Le plus grand secret de cette industrie, c’est peut-être que deux personnes peuvent accomplir davantage que la plus grande entreprise
      La seule raison pour laquelle les emplois de tout le monde sont en sécurité, c’est que personne n’arrive à déterminer exactement qui sont ces deux personnes
    • Tout le monde semble oublier qu’Apple a laissé la porte ouverte à d’autres systèmes d’exploitation et à leur développement, alors qu’il aurait été relativement facile de verrouiller ses ordinateurs portables
      Apple conçoit son propre silicium et a construit toute la plateforme ; il est difficile de croire que le fait d’avoir laissé la possibilité d’exécuter d’autres systèmes d’exploitation soit une simple erreur
      Il est évident qu’ils ont consciemment laissé cette porte ouverte au développement tiers, donc l’ambiance qui consiste à accuser Apple est décevante
    • Je ne pense pas qu’Apple soit obligé d’implémenter un standard simplement parce qu’il existe
      Par exemple, prendre en charge une implémentation Vulkan durable demanderait des ressources considérables et pèserait sur le calendrier de sortie ; il faut donc une raison business
      « Éviter l’embarras » ne suffit probablement pas
      On pourrait invoquer la bonne volonté de la communauté, mais je doute qu’Apple cherche à plaire à des gens qui la décrivent comme une « entreprise pourrie par la cupidité derrière des vidéos marketing politiquement correctes »
    • OpenGL est une spécification mourante, fondée sur un modèle de programmation ancien et horrible, et les tests de conformité de Khronos ont aussi des aspects étranges et excessifs
      Les tests de conformité ne sont pas open source, et la « conformance suite » séparée présente sur GitHub est basée sur dEQP de Google, pas sur l’ensemble de tests interne de Khronos
      On peut obtenir une « certification de conformité au standard » même avec des bugs et des lacunes assez importants dans l’implémentation
      Apple n’a promis que le support d’OpenGL 3.1, et le pilote OpenGL pour M1 a été réécrit comme une couche d’émulation au-dessus de Metal afin que les apps existantes continuent de fonctionner, mais Apple n’implémentera pas de versions plus récentes d’OpenGL, et n’en a pas besoin
      Les critiques envers Apple ne manquent pas, et il y a largement de quoi améliorer l’API Metal et ses outils, mais ne pas se préoccuper d’OpenGL est ici une décision tout à fait raisonnable

  • Il est intéressant que le texte original ne mentionne jamais le mot « Apple » et parle seulement du « fabricant » et de la « grande entreprise »
    Si c’est intentionnel, je me demande si c’est pour des raisons juridiques

    • C’est probablement parce que l’article ne porte pas sur Apple
      Le sujet n’est pas Apple, mais le fait de faire correctement tourner Linux sur l’architecture M1/M2 ; si la cible avait été Microsoft, Amazon ou Google, elle aurait sans doute été traitée de la même manière

  • C’était intéressant de regarder les diffusions en direct montrant le processus de développement de ce pilote, et c’est vraiment un travail impressionnant

    • Pour celles et ceux qui ne connaissent pas, on peut les voir sur https://www.youtube.com/c/AsahiLina
      C’est l’un des travaux de programmation bas niveau les plus impressionnants que j’aie vus jusqu’ici