Il est extrêmement important ici que la prise en charge de l'architecture matérielle-logicielle du calcul parallèle NVIDIA CUDA arrive à WSL .
Le matériel que nous publions a été traduit par des experts NVIDIA. Ici, nous allons parler de ce que vous pouvez attendre de CUDA dans la version Public Preview de WSL 2.
Exécution de frameworks Linux AI dans des conteneurs WSL 2
Qu'est-ce que WSL?
WSL est une fonctionnalité de Windows 10 qui vous permet d'utiliser les outils de ligne de commande Linux directement sur Windows sans avoir à gérer les complexités de l'application d'une configuration à double démarrage. WSL est un environnement conteneurisé étroitement intégré à Microsoft Windows. Cela vous permet d'exécuter des applications Linux avec des applications Windows traditionnelles et avec des applications modernes distribuées via le Microsoft Store.
WSL est avant tout un outil destiné aux développeurs. Si vous travaillez sur certains projets dans des conteneurs Linux, cela signifie que vous pouvez faire les mêmes choses localement, sur un ordinateur Windows, en utilisant des outils Linux familiers. Habituellement, pour exécuter de telles applications sous Windows, vous devez passer beaucoup de temps à configurer le système, vous avez besoin de frameworks tiers, de bibliothèques. Maintenant, avec la sortie de WSL 2, tout a changé. Grâce à WSL 2, la prise en charge complète du noyau Linux est arrivée dans le monde Windows.
WSL 2 et la technologie de paravirtualisation GPU (GPU-PV) ont permis à Microsoft de porter la prise en charge de Linux pour Windows à un nouveau niveau, permettant d'exécuter des charges de calcul basées sur le GPU. Ci-dessous, nous examinerons de plus près à quoi ressemble le GPU dans WSL 2.
Si vous êtes intéressé par le sujet de la prise en charge des accélérateurs vidéo dans WSL 2, jetez un œil à ce matériel et à ce référentiel.
CUDA dans WSL
Afin de tirer parti des capacités GPU dans WSL 2, un pilote vidéo prenant en charge Microsoft WDDM doit être installé sur l'ordinateur . Ces pilotes sont créés par des fabricants de cartes vidéo tels que NVIDIA.
La technologie CUDA permet de développer des programmes pour les accélérateurs vidéo NVIDIA. Cette technologie est prise en charge dans WDDM sous Windows depuis de nombreuses années. Le nouveau conteneur WSL 2 de Microsoft fournit des capacités de calcul accélérées par GPU dont la technologie CUDA peut tirer parti, permettant aux programmes basés sur CUDA de s'exécuter dans WSL. Pour plus d'informations, consultez le Guide de l'utilisateur WSL CUDA.
La prise en charge CUDA dans WSL est incluse dans les pilotes NVIDIA pour WDDM 2.9. Ces pilotes sont assez faciles à installer sur Windows. Les pilotes en mode utilisateur CUDA dans WSL (libcuda.so) sont automatiquement rendus disponibles à l'intérieur du conteneur et peuvent être détectés par le chargeur.
L'équipe de développement de pilotes NVIDIA a ajouté la prise en charge WDDM et GPU-PV au pilote CUDA. Cela est fait pour que ces pilotes puissent fonctionner dans un environnement Linux fonctionnant sous Windows. Ces pilotes sont toujours en statut Aperçu, leur sortie n'aura lieu que lorsque la sortie officielle WSL avec prise en charge GPU aura lieu. Les détails sur la version du pilote peuvent être trouvés ici .
La figure suivante montre un schéma de connexion du pilote CUDA à WDDM à l'intérieur d'un invité Linux.
Pilote WDDM en mode utilisateur compatible CUDA exécuté sur un système invité Linux
Supposons que vous soyez le développeur qui a installé la distribution WSL sur la dernière version de Windows à partir du Fast Ring (build 20149 ou version ultérieure) Microsoft Windows Insider Program (WIP). Si vous êtes passé à WSL 2 et que vous disposez d'un GPU NVIDIA, vous pouvez tester le pilote et exécuter votre code de calcul GPU dans WSL 2. Pour ce faire, installez simplement le pilote dans le système hôte Windows et ouvrez le conteneur WSL. Ici, vous pourrez travailler avec des applications utilisant CUDA sans aucun effort supplémentaire. La figure suivante montre comment une application TensorFlow utilisant les capacités CUDA s'exécute dans un conteneur WSL 2.
Conteneur TensorFlow fonctionnant en WSL 2
Le fait que la technologie CUDA soit désormais disponible en WSL permet d'exécuter des applications en WSL qui auparavant ne pouvaient s'exécuter que dans un environnement Linux classique.
NVIDIA travaille toujours activement sur ce projet et y apporte des améliorations. Entre autres choses, nous travaillons à l'ajout d'API à WDDM qui étaient auparavant conçues exclusivement pour Linux. Cela conduira au fait qu'en WSL, sans efforts supplémentaires de la part de l'utilisateur, de plus en plus d'applications pourront fonctionner.
Une autre question qui nous intéresse est la performance. Comme mentionné, la prise en charge GPU dans WSL 2 prend la technologie GPU-PV au sérieux. Cela peut avoir un impact négatif sur la vitesse d'exécution de petites tâches sur le GPU, dans des situations où le pipelining ne sera pas utilisé. Nous travaillons actuellement pour réduire ces effets autant que possible.
NVML
La technologie NVML n'est pas incluse dans le package de pilotes d'origine, nous essayons de la corriger, prévoyant d'ajouter la prise en charge de NVML et la prise en charge d'autres bibliothèques dans WSL.
Nous avons commencé avec le pilote CUDA principal, qui permettra aux utilisateurs d'exécuter la plupart des applications CUDA existantes, même aux premiers stades de la prise en charge de CUDA dans WSL. Mais il s'est avéré que certains conteneurs et applications utilisent NVML pour obtenir des informations GPU avant même de charger CUDA. C'est pourquoi l'ajout de la prise en charge NVML au WSL est l'une de nos principales priorités. Il est tout à fait possible que nous puissions bientôt partager de bonnes nouvelles concernant la solution de ce problème.
Conteneurs GPU en WSL
En plus de prendre en charge WSL 2 DirectX et CUDA, NVIDIA travaille sur l'ajout de la prise en charge de NVIDIA Container Toolkit à WSL 2 (anciennement appelé nvidia-docker2). Les applications GPU en conteneur que les scientifiques des données créent pour s'exécuter sur un environnement Linux local ou cloud peuvent désormais, sans y apporter de modifications, s'exécuter dans WSL 2 sur des ordinateurs exécutant Windows.
Aucun package WSL spécial n'est requis pour cela. La bibliothèque d'exécution NVIDIA (libnvidia-container) peut détecter dynamiquement libdxcore et l'utiliser lorsque le code s'exécute dans un environnement WSL 2 accéléré par GPU. Cela se produit automatiquement après l'installation des packages Docker et NVIDIA Container Toolkit, tout comme sous Linux. Cela vous permet d'exécuter des conteneurs à l'aide des fonctionnalités GPU de WSL 2 sans effort supplémentaire.
Nous recommandons fortement à ceux qui souhaitent utiliser l'option d'
--gpusinstaller les derniers outils Docker (03/19 ou version ultérieure). Pour activer la prise en charge de WSL 2, suivez les instructions de votre distribution Linux et installez la dernière version disponible nvidia-container-toolkit.
Comment ça fonctionne? Toutes les tâches spécifiques à WSL 2 sont résolues à l'aide de la bibliothèque libnvidia-container . Désormais, cette bibliothèque peut, lors de l'exécution, détecter la présence de libdxcore.so et utiliser cette bibliothèque pour détecter tous les GPU visibles sur cette interface.
Si vous devez utiliser ces GPU dans le conteneur, puis en utilisant libdxcore.so, vous accéderez à l'emplacement de stockage du pilote, au dossier qui contient toutes les bibliothèques de pilotes pour le système hôte Windows et WSL 2. La bibliothèque libnvidia-container.so est responsable de la configuration du conteneur afin que vous puissiez accéder correctement au référentiel de pilotes. Cette même bibliothèque est responsable de la configuration des bibliothèques de base prises en charge par WSL 2. Ceci est schématisé dans la figure suivante.
Le schéma de détection et de mappage du conteneur de référentiel de pilotes utilisé par libnvidia-container.so dans WSL 2
En outre, cela diffère de la logique utilisée en dehors de WSL. Ce processus est complètement abstrait à l'aide de libnvidia-container.so et il doit être aussi transparent que possible pour l'utilisateur final. L'une des limites de cette première version est que vous ne pouvez pas sélectionner de GPU dans des environnements qui ont plusieurs GPU. Tous les GPU sont toujours visibles dans le conteneur.
Tous les conteneurs NVIDIA Linux que vous connaissez déjà peuvent s'exécuter dans un conteneur WSL. NVIDIA prend en charge les outils et les workflows spécifiques à Linux les plus intéressants utilisés par les professionnels. Téléchargez le conteneur qui vous intéresse depuis NVIDIA NGC et essayez-le.
Nous allons maintenant vous montrer comment exécuter les conteneurs TensorFlow et N-body dans WSL 2, qui sont conçus pour utiliser les GPU NVIDIA pour accélérer les calculs.
Exécution du conteneur N-body
Installez Docker à l'aide du script d'installation:
user@PCName:/mnt/c$ curl https://get.docker.com | sh
Installez NVIDIA Container Toolkit. La prise en charge de WSL 2 est disponible à partir de nvidia-docker2 v2.3 et de la bibliothèque d'exécution libnvidia-container 1.2.0-rc.1.
Configurez les référentiels
stableet la experimentalclé GPG. Les modifications apportées au code d'exécution pour prendre en charge WSL 2 sont disponibles dans le référentiel expérimental.
user@PCName:/mnt/c$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
user@PCName:/mnt/c$ curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
user@PCName:/mnt/c$ curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
user@PCName:/mnt/c$ curl -s -L https://nvidia.github.io/libnvidia-container/experimental/$distribution/libnvidia-container-experimental.list | sudo tee /etc/apt/sources.list.d/libnvidia-container-experimental.list
Installez les packages d'exécution NVIDIA et leurs dépendances:
user@PCName:/mnt/c$ sudo apt-get update
user@PCName:/mnt/c$ sudo apt-get install -y nvidia-docker2
Ouvrez le conteneur WSL et exécutez le démon Docker dedans. Si tout est fait correctement, vous pouvez voir les messages de service
dockerd.
user@PCName:/mnt/c$ sudo dockerd
Démarrage du démon Docker
Dans une autre fenêtre WSL, chargez et démarrez le conteneur de simulation N-body. Il est nécessaire que l'utilisateur effectuant cette tâche dispose des droits suffisants pour charger le conteneur. Les commandes suivantes devront peut-être être exécutées à l'aide de sudo. Dans la sortie, vous pouvez voir des informations sur le GPU.
user@PCName:/mnt/c$ docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark
Lancer le conteneur N-body
Exécution d'un conteneur TensorFlow
Essayons dans Docker, dans l'environnement WSL 2, un autre conteneur populaire - TensorFlow.
Téléchargez l'image Docker TensorFlow. Afin d'éviter des problèmes de connexion à Docker, exécutez la commande suivante en mode sudo:
user@PCName:/mnt/c$ docker pull tensorflow/tensorflow:latest-gpu-py3
Sauvegardons la version légèrement modifiée du didacticiel GPU du didacticiel TensorFlow 15 sur le disque du
Csystème hôte. Ce lecteur, par défaut, est monté dans le conteneur WSL 2 en tant que /mnt/c.
user@PCName:/mnt/c$ vi ./matmul.py
import sys
import numpy as np
import tensorflow as tf
from datetime import datetime
device_name = sys.argv[1] # Choose device from cmd line. Options: gpu or cpu
shape = (int(sys.argv[2]), int(sys.argv[2]))
if device_name == "gpu":
device_name = "/gpu:0"
else:
device_name = "/cpu:0"
tf.compat.v1.disable_eager_execution()
with tf.device(device_name):
random_matrix = tf.random.uniform(shape=shape, minval=0, maxval=1)
dot_operation = tf.matmul(random_matrix, tf.transpose(random_matrix))
sum_operation = tf.reduce_sum(dot_operation)
startTime = datetime.now()
with tf.compat.v1.Session(config=tf.compat.v1.ConfigProto(log_device_placement=True)) as session:
result = session.run(sum_operation)
print(result)
#
print("Shape:", shape, "Device:", device_name)
print("Time taken:", datetime.now() - startTime)
Voici les résultats de l'exécution de ce script à partir d'un disque monté dans un conteneur
C. Le script a été exécuté, d'abord, en utilisant le GPU, puis en utilisant le CPU. Pour plus de commodité, la sortie ici a été réduite.
user@PCName:/mnt/c$ docker run --runtime=nvidia --rm -ti -v "${PWD}:/mnt/c" tensorflow/tensorflow:latest-gpu-jupyter python /mnt/c/matmul.py gpu 20000
Résultats de l'exécution du script matmul.py
Lors de l'utilisation d'un GPU dans un conteneur WSL 2, une accélération significative de l'exécution du code est observée par rapport à son exécution sur un CPU.
Réalisons une autre expérience conçue pour étudier les performances de l'informatique GPU. Il s'agit du code du manuel Jupyter Notebook. Après avoir démarré le conteneur, vous devriez voir un lien vers le serveur Jupyter Notebook.
user@PCName:/mnt/c$ docker run -it --gpus all -p 8888:8888 tensorflow/tensorflow:latest-gpu-py3-jupyter
Exécution de Jupyter Notebook
Vous devriez maintenant pouvoir exécuter les démos dans l'environnement Jupyter Notebook. Veuillez noter que pour vous connecter au Jupyter Notebook à l'aide du navigateur Microsoft Edge, vous devez utiliser, au lieu de 127.0.0.1
localhost.
Accédez à
tensorflow-tutorialset lancez le bloc-notesclassification.ipynb.
Pour voir les résultats de l'accélération GPU, accédez au menu
Cell, sélectionnezRun Allet affichez le journal dans le conteneur WSL 2 Jupyter Notebook.
Jupyter Notebook Journal
Cette démo, et quelques autres dans ce conteneur, vous permettent de voir les problèmes avec la couche de virtualisation liés à la charge supplémentaire déraisonnablement élevée sur le système lors de la résolution de petits problèmes. Nous en avons déjà parlé ci-dessus. Comme nous exécutons ici de très petits modèles de didacticiels, le temps d'exécution sur le GPU est inférieur au temps requis pour résoudre les problèmes de synchronisation. Lors de la résolution de tels problèmes de «jouet» dans WSL 2, le processeur peut être plus efficace que le GPU. Nous nous efforçons de résoudre ce problème en nous efforçant de limiter ses manifestations à de très petites charges de travail, auxquelles le pipeline n'est pas appliqué.
Présentation de WSL
Pour comprendre comment le support GPU a été ajouté dans WSL 2, nous parlons maintenant de ce que c'est que d'exécuter Linux sur Windows et comment les conteneurs voient le matériel.
Microsoft a présenté la technologie WSL lors de Build en 2016. Cette technologie a rapidement trouvé une large utilisation et est devenue populaire parmi les développeurs Linux qui avaient besoin d'exécuter des applications Windows comme Office, ainsi que des outils de développement Linux et des programmes associés.
WSL 1 vous permettait d'exécuter des exécutables Linux non modifiés. Cependant, il a utilisé une couche d'émulation de noyau Linux qui a été implémentée en tant que sous-système de noyau NT. Ce sous-système traitait les appels des applications Linux, les redirigeant vers les mécanismes Windows 10 appropriés.
WSL 1 était un outil utile, mais il n'était pas compatible avec toutes les applications Linux car il devait émuler absolument chaque appel système Linux. En outre, les opérations du système de fichiers ont été lentes, ce qui a entraîné des performances inacceptablement faibles pour certaines applications.
Dans cet esprit, Microsoft a décidé d'aller dans l'autre sens et a publié WSL 2, une nouvelle version de WSL. Les conteneurs WSL 2 exécutent des distributions Linux complètes dans un environnement virtualisé, tout en tirant pleinement parti du nouveau système de conteneurisation Windows 10.
Bien que WSL 2 utilise les services Windows 10 Hyper-V, il ne s'agit pas d'une machine virtuelle traditionnelle, mais plutôt d'un moteur de virtualisation d'assistance léger. Ce mécanisme est responsable de la gestion de la mémoire virtuelle associée à la mémoire physique, permettant aux conteneurs WSL 2 d'allouer dynamiquement de la mémoire en accédant au système hôte Windows.
Parmi les principaux objectifs de la création de WSL 2, il est possible de noter une augmentation des performances de travail avec le système de fichiers et d'assurer la compatibilité avec tous les appels système. De plus, WSL 2 a été conçu pour améliorer le niveau d'intégration entre WSL et Windows. Cela vous permet de travailler facilement avec un système Linux s'exécutant dans un conteneur à l'aide des outils de ligne de commande Windows. Cela améliore également la convivialité du système de fichiers hôte, qui est automatiquement monté dans les répertoires sélectionnés du système de fichiers du conteneur.
WSL 2 a été introduit dans le programme Windows Insider en tant que fonctionnalité de prévisualisation et a été publié dans la dernière mise à jour de Windows 10, version 2004.
Dans WSL 2, à partir de la dernière version de Windows, il y a encore plus d'améliorations qui affectent beaucoup de choses - des piles réseau aux mécanismes VHD de base du système de stockage. Une description de toutes les nouvelles fonctionnalités de WSL 2 dépasse le cadre de ce document. Vous pouvez en apprendre plus à leur sujet sur cette page, qui compare WSL 2 et WSL 1.
Linux core WSL 2
Le noyau Linux utilisé dans WSL 2 est compilé par Microsoft à partir de la branche stable la plus récente, en utilisant le code source disponible sur kernel.org. Ce noyau a été spécialement réglé pour WSL 2, optimisé en termes de taille et de performances pour garantir que Linux fonctionne sous Windows. Le noyau est pris en charge via le mécanisme Windows Update. Cela signifie que l'utilisateur n'a pas à se soucier du téléchargement des dernières mises à jour de sécurité et des améliorations du noyau. Tout cela se fait automatiquement.
Microsoft prend en charge plusieurs distributions Linux dans WSL. La société, suivant les règles de la communauté open source, a publié dans le référentiel WSL2-Linux-Kernel GitHub le code source du noyau WSL 2 avec les modifications nécessaires à l'intégration avec Windows 10.
Prise en charge GPL dans WSL
Les développeurs Microsoft ont ajouté la prise en charge des vrais GPU à l'aide de la technologie GPU-PV dans les conteneurs WSL 2. Ici, le cœur graphique du système d'exploitation (dxgkrnl) rassemble le pilote en mode noyau qui se trouve sur l'hôte avec des appels de composants en mode utilisateur qui sont exécutés dans la machine virtuelle invitée.
Microsoft a développé cette technologie en tant que fonctionnalité WDDM et depuis sa création, il existe plusieurs versions de Windows. Ce travail a été réalisé avec l'aide de fournisseurs de matériel indépendants (Independent Hardware Vendor, IHV). Les pilotes graphiques NVIDIA prennent en charge GPU-PV depuis les débuts de cette technologie dans les versions de prévisualisation des produits disponibles dans le programme Windows Insider. Tous les GPU NVIDIA actuellement pris en charge sont accessibles par un système d'exploitation Windows s'exécutant en mode invité sur une machine virtuelle exécutant Hyper-V.
Afin de tirer parti des capacités GPU-PV de WSL 2, Microsoft a dû créer la base de son framework graphique pour l'invité Linux: WDDM avec prise en charge du protocole GPU-PV. Le nouveau pilote Microsoft est derrière dxgkrnl, le système responsable de la prise en charge de WDDM sous Linux. Le code du pilote se trouve dans le référentiel WSL2-Linux-Kernel.
Dxgkrnl devrait fournir une prise en charge de l'accélération GPU dans les conteneurs WSL 2 dans WDDM 2.9. Microsoft dit que dxgkrnl est un pilote de GPU Linux basé sur le protocole GPU-PV et qu'il n'a rien à voir avec un pilote Windows portant un nom similaire.
Vous pouvez actuellement télécharger la version préliminaire du pilote NVIDIA WDDM 2.9. Au cours des prochains mois, ce pilote sera distribué via Windows Update dans la version WIP de Windows, ce qui rend inutile le téléchargement et l'installation manuels du pilote.
Principes de base du GPU-PV
Le pilote dxgkrnl met à disposition, en mode utilisateur du système invité Linux, le nouveau périphérique / dev / dxg. La couche de service du noyau D3DKMT, qui était disponible sur Windows, a également été portée dans le cadre de la bibliothèque dxcore vers Linux. Il communique avec dxgkrnl à l'aide d'un ensemble d'appels IOCTL privés.
La version Linux invité de dxgkrnl se connecte au noyau dxg sur un hôte Windows en utilisant plusieurs canaux de bus VM. Le noyau dxg sur l'hôte gère ce qui vient du processus Linux de la même manière que ce qui vient des applications Windows normales utilisant WDDM. A savoir, le noyau dxg envoie ce qu'il a reçu à KMD (Kernel Mode Driver, un pilote en mode noyau unique à chaque VIH). Le pilote en mode noyau prépare ce qu'il reçoit pour l'envoi au GPU matériel. La figure suivante montre un diagramme simplifié de l'interaction entre le périphérique Linux / dev / dxg et KMD.
Un diagramme simplifié de la façon dont les composants hôtes Windows permettent au périphérique dxg de fonctionner dans un invité Linux
Lorsqu'il s'agit de fournir ce comportement aux invités Windows, les pilotes NVIDIA prennent en charge GPU-PV dans Windows 10 depuis un certain temps. Les GPU NVIDIA peuvent être utilisés pour accélérer la sortie informatique et graphique dans toutes les applications Windows 10 à l'aide de la couche de virtualisation Microsoft. L'utilisation de GPU-PV vous permet de travailler avec vGPU. Voici quelques exemples d'applications similaires:
Voici à quoi cela ressemble d'exécuter une application DirectX dans un conteneur Windows Sandbox à l'aide de l'accélérateur vidéo NVIDIA GeForce GTX 1070.
Accélération graphique dans le conteneur Windows Sandbox par NVIDIA GeForce GTX 1070
Prise en charge du mode utilisateur
Afin d'ajouter la prise en charge de la sortie graphique vers WSL, l'équipe de développement Microsoft correspondante a également porté le composant en mode utilisateur dxcore sur Linux.
La bibliothèque dxcore fournit une API qui vous permet d'obtenir des informations sur les cartes graphiques compatibles WDDM disponibles sur votre système. Cette bibliothèque a été conçue comme un remplacement multiplateforme de bas niveau de l'outil adaptateur DXGI sous Windows et Linux. La bibliothèque fait également abstraction de l'accès aux services dxgkrnl (appels IOCTL sur Linux et appels GDI sous Windows) à l'aide de la couche API D3DKMT, qui est utilisée par CUDA et d'autres composants en mode utilisateur qui reposent sur la prise en charge de WDDM dans WSL.
Selon Microsoft, la bibliothèque dxcore (libdxcore.so) sera disponible sur Windows et Linux. NVIDIA prévoit d'ajouter la prise en charge de DirectX 12 et les API CUDA au pilote. Ces modules complémentaires ciblent les nouvelles fonctionnalités WSL disponibles avec WDDM 2.9. Les deux bibliothèques représentant l'API seront connectées à dxcore afin qu'elles puissent donner des instructions à dxg sur la façon de marshaler leurs requêtes KMD sur le système hôte.
Essayez les nouvelles fonctionnalités de WSL 2
Vous souhaitez utiliser votre PC Windows pour de véritables tâches d'apprentissage automatique et d'intelligence artificielle tout en profitant de la commodité d'un environnement Linux? Si tel est le cas, le support CUDA de WSL vous offre une excellente opportunité de faire exactement cela. L'environnement WSL est l'endroit où les conteneurs CUDA Docker se sont avérés être l'environnement informatique le plus populaire parmi les scientifiques des données.
- Pour accéder à la version WSL 2 Preview avec prise en charge de l'accélération GPU, vous pouvez rejoindre le programme Windows Insider .
- Téléchargez les derniers pilotes NVIDIA , installez-les et essayez d'exécuter un conteneur CUDA dans WSL 2.
Ici, vous pouvez en savoir plus sur l'utilisation de la technologie CUDA dans le WSL. Ici , sur le forum dédié à CUDA et WSL, vous pouvez partager avec nous vos impressions, observations et idées sur ces technologies.
Avez-vous déjà essayé CUDA dans WSL 2?
