Bien qu'organisée en ligne, cette édition 2020 de la Build « envoie du lourd ». Ne serait-ce que pour le sous-système Linux et les outils annexes consacrés aux développeurs, les nouveautés sont aussi importantes que nombreuses. Un véritable gestionnaire de paquets est même au programme !
Avec l'intégration d'un bash via différentes distributions puis d'un noyau Linux complet dans Windows 10, Microsoft lançait une petite révolution. L'entreprise qui avait passé des années à combattre l'open source a, sous la direction de Satya Nadella, complètement revu sa position en allant toujours plus loin... jusqu'à s'en payer des tranches.
Derniers exemples en date : le rachat de GitHub, toujours indépendant mais de plus en plus intégré aux produits maison... ou de npm, gestionnaire de paquets JavaScript. Vu le niveau des rapprochements avec Canonical ces dernières années, certains se demandent d'ailleurs si ce n'est pas le prochain sur la liste.
Lors de la Build 2020, Linux était à nouveau à l'honneur, et pas qu'un peu. Car Microsoft s'inspire de plus en plus de ce qui fait l'intérêt et la force des grandes distributions, tout en permettant l'utilisation de ces systèmes sans jamais avoir à quitter le sien. Objectif : faire de Windows 10 l'OS à tout faire des développeurs.
CUDA et DirectML dans WSL 2
La première annonce est un changement de taille : le sous-système Linux (v2) va désormais profiter de l'accélération matérielle des GPU et afficher des interfaces graphiques (GUI), donc des applications complètes. Des améliorations très demandées depuis l'arrivée de WSL, certains allant jusqu'à bidouiller pour en profiter.
Désormais, ce sera natif, officiel et même un peu plus que ça. Tout d'abord, Microsoft confirme que le support de CUDA et WinML sera proposé dans une prochaine version du sous-système. Aucune date n'est pour le moment donnée, l'équipe parlant simplement d'une disponibilité d'ici quelques mois via le canal rapide du programme Insiders. Il passera bientôt sur la branche Manganese (Mn, 20H2) puis Iron (Fe, 21H1) d'ici fin juin.
Cela permettra à la fois de gérer l'écosystème énorme de NVIDIA en la matière (dont nvidia-docker), tout en plaçant WinML comme alternative ouverte à tous. Une version spécifique de TensorFlow l'exploitant sera d'ailleurs proposée en préversion (sous la forme d'un paquet PyPI), pour ceux voulant produire du code exploitant n'importe quel accélérateur compatible, plutôt que les seules GeForce/Quadro/Tesla. Ces dernières bénéficient déjà de TensorRT.
NVIDIA a développé une version de sa librairie CUDA pour l'accès au GPU tel qu'implémenté dans WSL 2 (voir ci-dessous) : libcuda.so. Un programme d'accès préliminaire en ligne est également disponible. Aucune limitation aux seules cartes professionnelles n'est pour le moment évoquée, ce qui serait une bonne chose mais une nouveauté. En effet, l'accès au GPU dans des environnement virtualisés est en général la chasse gardée des Quadro et autres Tesla.
Canonical a de son côté annoncé que des services qu'elle développe pour Ubuntu (comme Kubeflow ou microK8s) seront compatibles. Une vidéo de LXD sous WSL 2 a d'ailleurs été publiée. Microsoft a pour sa part détaillé sur la chaîne de l'entreprise le fonctionnement de ses outils Sysinternals pour Linux. Bien d'autres vantant WSL sont disponibles.
Un pilote open source pour l'accès GPU aux hôtes Linux
Tout cela est rendu possible par l'évolution de la couche de gestion du GPU, précise Microsoft. Avec WDDM 2.5, l'entreprise avait introduit GPU Paravirtualization (GPU-PV), permettant d'utiliser ce composant dans des environnements virtualisés et exploité dans sa Sandbox, l'émulateur HoloLens 2 ou encore Windows Defender Application Guard.
Avec WDDM 2.9, sa prochaine évolution, elle deviendra accessible aux hôtes Linux via un pilote open source placé au niveau du noyau : Dxgkrnl. Il expose (via /dev/dxg) le GPU et ses fonctionnalités à WSL 2. Un niveau d'intégration qui permet une adaptation rapide selon l'équipe. Mais aussi de fonctionner aussi bien sur les hôtes à un ou plusieurs GPU.
« Les applications fonctionnant dans un environnement Linux ont le même accès au GPU que les applications natives sous Windows » précise Steve Pronovost, un des responsables du projet. « Il n'y a aucun partitionnement des ressources entre Linux et Windows, ou de limite imposée aux applications sous Linux ». Le message est clair : les performances seront là.
Il sera d'ailleurs intéressant de tester l'écart de temps de rendu sur GPU avec des applications telles que Blender, entre la version Windows et celle lancée dans WSL 2, qui peut être facilement compilée dans cet environnement. L'accès au GPU sera direct pour toute distribution exploitant la v2 du sous-système Linux, l'utilisateur n'aura rien de spécifique à faire.
Cette simplicité d'accès au GPU sera-t-elle également permise aux applications de virtualisation classiques ?
Direct3D 12 dans un environnement Linux
L'autre gros morceau des annonces concerne DirectX. On apprend ainsi que l'API en charge de toute la gestion du rendu 3D est désormais disponible dans une version Linux (via WSL) : libd3d12.so. « Elle est compilée depuis le même code source que d3d12.dll pour Windows » précise Pronovost.
Elle offre les mêmes fonctionnalités et le même niveau de performances – modulo l'impact de la virtualisation – mais ne pourra pas être utilisée dans tous les cas, Present() étant absent. « Elle peut être utilisée pour le rendu offscreen et le calcul, mais il n'y a pas de support de swapchain permettant de copier des pixels directement à l'écran (pour le moment 😊) ».
Les constructeurs fournissent de leur côté un pilote utilisateur (UMD) spécifique, permettant l'échange entre leur GPU et la version adaptée à WSL de Direct3D12. Les pilotes WDDM 2.9 fourniront ainsi la version classique et celle compilée pour l'utilisation dans le sous-système Linux, de manière à rendre tout cela le plus transparent possible pour l'utilisateur.
Le composant DxCore a également été porté (libdxcore.so), là aussi de manière complète, excepté quelques simplifications, notamment de fonctionnalités anciennes ayant été modernisées. Ces deux éléments ne sont pas ouverts. Ils sont compilés et distribués sous forme de binaires compatibles avec les distributions exploitant glibc et montés dans /usr/lib/wsl/lib précise Microsoft. L'amour de l'open source a ses limites.
Cette annonce ne semble d'ailleurs pas mener à une disponibilité de Direct3D 12 sous Linux de manière plus générale.
OpenCL, OpenGL, Vulkan et applications avec GUI
Tout ce travail d'accès au GPU profitera aux applications exploitant des API ouvertes, comme celles poussées par le Khronos Group. Un travail là aussi au long cours, dont les premières briques ont été annoncées il y a peu.
Ces améliorations n'arriveront que dans un second temps. Comme l'accès aux applications avec interface graphique (GUI). passant par l'intégration d'un serveur Wayland au sein de WSL 2, communicant avec l'hôte via RDP. Des démonstrations ont été effectuées avec Gedit ou le gestionnaire de fichiers de GNOME.
Objectif : que les développeurs puissent utiliser leurs applications CLI et celles dotées d'une interface graphique. Ce, sans avoir à quitter Windows 10 et avec de bonnes performances.
Ces autres améliorations de WSL 2
Si WSL 2 doit faire son entrée avec la mise à jour de mai de Windows 10 (2004) – intégrant un noyau Linux complet et permettant l'accès à Docker (entre autres) – la suite est d'ores et déjà prévue. Microsoft a profité de ses annonces du jour pour faire un petit point sur la feuille de route.
Ainsi, plutôt que de devoir passer par les paramètres des fonctionnalités complémentaires, WSL pourra « prochainement » être installé d'une seule ligne de commande : wsl.exe --install. La v2 du sous-système Linux sera alors utilisée par défaut, alors qu'il faut pour le moment passer là aussi par une procédure manuelle.
Terminal 1.0 et Gestionnaire de paquets en preview
Autre changement très inspiré de Linux et de l'open source : le nouveau Terminal. Capable de gérer plusieurs onglets et panneaux, différents interpréteurs (CMD, PowerShell, Bash Linux ou Azure Cloud Shell), pouvant être personnalisé, il gère UTF-8/Unicode, profite d'une accélération GPU et... passe en v1.0.
Disponible via GitHub ou le Microsoft Store, il dispose désormais de sa propre documentation (en français). L'équipe vante son approche ouverte pour cet outil, intégrant plusieurs fonctionnalités proposées pour la communauté, parfois plus « fun » qu'utiles. Microsoft précise qu'il continuera d'évoluer en préversion, des nouveautés étant annoncées pour le mois de juin, sans plus de précisions pour le moment.
Une vidéo de présentation a été publiée à l'occasion de la BUILD 2020 :
Enfin, Microsoft nous revient avec un projet de... gestionnaire de paquets. L'idée n'est pas nouvelle, puisque l'on nous promet une telle révolution depuis 2014 et les débuts de OneGet, devenus un gestionnaire de modules PowerShell.
Mais cette fois, ce sera la bonne avec winget, accessible en ligne de commandes et pour le moment proposé sous forme de préversion (open source). On retrouve les bases de ce qui fait le succès de ces outils, comme Chocolatey sous Windows, avec des commandes relativement basiques, donc faciles à retenir :
winget install // Installer un paquet
winget show // Afficher les informations sur un paquet
winget source // Gérer les sources de paquets
winget search // Rechercher un paquet
On note des manques pour le moment, comme la désinstallation ou la mise à jour qui seront sans doute proposés dans un second temps. Microsoft dit ne pas avoir contribué à un projet existant, préférant miser sur une solution maison pour des raisons de sécurité notamment. Cela lui évite surtout d'avoir à gérer un héritage ou une communauté déjà bien établie.
Les autres projets sont néanmoins invités à supporter les dépôts mis en place par l'éditeur s'ils le souhaitent.
winget sera compatible avec les versions 1709 de Windows 10 et supérieures. La documentation est disponible ici. Pour le moment, aucune intégration spécifique au Microsoft Store ne semble prévue, mais on imagine qu'il sera proposé aux développeurs de déployer leurs applications via ces deux canaux de manière unifiée à terme, l'un ne pouvant remplacer l'autre, car ne visant pas les mêmes usages, besoins et publics.
D'ici là, vous pourrez installer cet outil de trois manières. En téléchargeant le client via son dépôt GitHub bien entendu. Il sera également mis en place dans les prochaines préversions du programme Insider de Windows (canal rapide). Un programme spécifique est également mis en place. Il faudra dans tous les cas passer par l'App Installer distribué sur le Microsoft Store pour en profiter pleinement.
Notre dossier sur la Build 2020 de Microsoft :
- WSL 2 gérera les GPU et les interfaces Linux, Terminal 1.0, winget en preview
- Reunion d'UWP et Win32, Visual Studio, Live Share et Codespaces
- Au sein de Microsoft 365, Teams reste la star
- C# 9.0 : de nombreuses nouveautés, souvent inspirées de la programmation fonctionnelle
- Du machine learning « responsable » aux nouveautés Azure
