WSL : comment Microsoft a intégré les applications Linux graphiques

Les applications graphiques sur WSL ? On s’en approche. Leur prise en charge devrait être effective avec Windows 10 2004. En attendant, Microsoft propose un aperçu sur le canal dev, avec la build 21364.

La vidéo de présentation postée en parallèle illustre les progrès effectués depuis la première démo publique, réalisée il y a près d’un an. On nous y montre notamment une application JavaScript sur Edge, un enregistrement sur Audacity et de la simulation 3D avec Gazebo.

On aura constaté qu’il n’est pas nécessaire de lancer un serveur d’affichage. Ni, d’ailleurs, un serveur audio. L’un et l’autre sont « prêts à l’emploi », au sein de CBL-Mariner. Microsoft connaît bien ce Linux léger. Non seulement pour en être à l’origine. Mais aussi pour l’utiliser abondamment en interne, essentiellement sur des services Azure.

Orienté headless, CBL-Mariner a fait l’objet d’une adaptation pour les applications graphiques. Il vient s’exécuter sur les distributions installées dans WSL. Ce de façon transparente* (la commande wsl -l -v ne signale pas sa présence) et partiellement isolée, à la manière d’un conteneur.

Au cœur de cette adaptation de CBL-Mariner, il y a le compositeur graphique Weston, qui assure la prise en charge des applications Wayland. Microsoft a choisi d’assurer également une compatibilité X11, à travers l’implémentation XWayland.

Weston n’est pas tout à fait intégré tel quel. On a, en particulier, étendu son back-end RDP. Par exemple, pour pouvoir utiliser les protocoles RAIL et VAIL. Lesquels permettent de gérer des applications individuelles et non simplement des bureaux. Autres extensions : le support du multi-écran, du raccourci Alt-Tab et du copier-coller (hors glisser-déplacer). Microsoft a aussi fait en sorte d’intégrer les applications Linux dans l’interface Windows (barre des tâches, menu Démarrer).

Les GPU, grand chantier de WSL

Il reste encore bien des choses à améliorer. Par exemple, la gestion du déplacement et du redimensionnement des fenêtres. Pour le moment, elle se fait côté serveur. En plus d’être moins fluide qu’en natif, cela empêche d’épingler des fenêtres aux coins de l’écran ou dans des zones personnalisées.

De manière générale, le chantier est important sur la partie GPU. Depuis l’an dernier, on peut en exploiter les capacités de calcul via CUDA et DirectML. Étape suivante : les utiliser pour le rendu 3D. Solution retenue : ajouter à la bibliothèque Mesa un back-end DirectX 12.
Cette démarche avait déjà mené au lancement d’un « pack de compatibilité » qui rendait OpenCL et OpenGL accessibles avec Windows sur Arm. La prise en charge de Linux a été ajoutée il y a quelques semaines, dans Mesa 21.0.

La plupart des distributions Linux utilisables sur WSL n’ont pas encore basculé vers cette release. Aux intéressés, Microsoft suggère deux options : soit concevoir leur version privée de Mesa, soit installer Ubuntu on Windows Community Preview.

Pour le moment, sur les GPU autonomes, Mesa communique avec Weston en passant par la mémoire système. Sur les GPU intégrés, la présentation se fait de manière synchrone (rendu image par image). Le tableau ci-dessous donne une idée du coût en performances. Les mesures sont faites sur le benchmark Geeks3D GpuTest.

* Bien qu’on puisse accéder à CBL-Mariner par le terminal, on n’est pas censé en faire directement usage. Chacune de ses instances (une par distribution utilisateur) se charge en mémoire et en lecture seule. Toute modification effectuée disparaît à la fermeture de WSL.

Illustration principale ©