- Cet article se concentre sur le développement de Tyr, un nouveau pilote GPU en Rust pour le noyau Linux, et sur les principes de fonctionnement d’un pilote GPU
- Il explique la distinction des rôles et les interactions entre l’UMD (User Mode Driver) et le KMD (Kernel Mode Driver) dans le développement d’un pilote GPU, à travers l’exemple VkCube
- L’UMD convertit les API de haut niveau en commandes de bas niveau compréhensibles par le GPU, tandis que le KMD assure des rôles clés comme l’allocation mémoire, la planification des tâches et l’initialisation du périphérique
- L’API fournie par le pilote Tyr est la même que celle de Panthor, avec des fonctions de requête de périphérique, de gestion mémoire, de gestion de groupes, de soumission de travaux et de gestion du tas Tiler
- Le prochain article abordera l’architecture matérielle Arm CSF, les composants clés (par ex. MCU) et le processus de boot
Introduction : développement d’un pilote GPU noyau moderne avec Rust
- Cet article est le deuxième volet de la série de développement du pilote Tyr, un pilote moderne GPU pour le noyau Linux prenant en charge les GPU Arm Mali CSF
- Comme exemple concret, VkCube, un simple programme 3D qui rend un cube tournant en utilisant l’API Vulkan, a été retenu pour expliquer le fonctionnement interne d’un pilote GPU
- La simplicité de VkCube en fait un bon cas d’usage pour apprendre les principes de base du fonctionnement d’un pilote GPU
Bases d’un pilote GPU : rôles et structure de l’UMD et du KMD
- Un pilote GPU est constitué d’un User Mode Driver (UMD) et d’un Kernel Mode Driver (KMD)
- UMD : implémente les API des programmes classiques, comme panvk (le pilote Vulkan de Mesa, entre autres)
- KMD : Tyr, etc., pilote au niveau du noyau avec des privilèges sur le matériel, fonctionnant comme partie du noyau Linux
- Le pilote GPU en mode noyau fait le lien entre l’UMD et le GPU réel, et l’UMD interprète les commandes d’API pour les convertir en un ensemble de commandes compréhensibles par le GPU
- L’UMD prépare les données nécessaires à la construction de la scène (géométrie, textures, shaders, etc.) et demande au KMD d’allouer ces ressources en mémoire GPU avant exécution
- Le shader est un programme autonome exécuté sur le GPU ; dans VkCube, il gère la mise en place du cube, la coloration et la logique de rotation, entre autres. Son exécution nécessite des données externes (géométrie, couleur, matrice de rotation, etc.)
- L’UMD transmet les commandes préparées (ex. : VkCommandBuffers) au KMD pour les exécuter, puis reçoit une notification à la fin de l’exécution afin de pouvoir enregistrer les résultats en mémoire
Responsabilités principales du KMD (Kernel Mode Driver)
- Allocation et mapping de la mémoire GPU (avec isolation par application)
- Soumission des travaux à la file d’attente matérielle et notification des utilisateurs à la complétion
- Dans un environnement matériel asynchrone et parallèle, la gestion des dépendances de travail est essentielle ; pour garantir des résultats corrects, le KMD joue un rôle clé dans la planification et la validation des dépendances
- Cela inclut aussi l’initialisation du périphérique, l’activation des régulateurs d’horloge/tension, l’exécution du code de démarrage et la gestion de la rotation d’accès afin de permettre à plusieurs clients de partager équitablement le matériel
Où se situe la complexité : séparation des tâches entre UMD et KMD
- La complexité d’un pilote GPU est majoritairement concentrée au niveau de l’UMD
- UMD : conversion des commandes API de haut niveau en commandes matérielles
- KMD : fournit les fonctions essentielles comme l’isolation mémoire, le partage et l’accès équitable pour que l’UMD fonctionne correctement
Structure de l’interface API fournie par Tyr
- L’API du pilote Tyr (identique à Panthor) peut être divisée en 5 grands groupes
- Requête d’informations de périphérique : DEV_QUERY (lecture d’informations matérielles GPU via IOCTL, en tirant parti de la zone ROM)
- Allocation et isolation mémoire : VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET, etc.
- Gestion des groupes de planification : GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (plus de détails dans un prochain article)
- Soumission de travaux : GROUP_SUBMIT (demande d’exécution de buffers de commandes appareil vers le GPU)
- Gestion du tas Tiler : TILER_HEAP_CREATE, TILER_HEAP_DESTROY (pour répondre aux besoins mémoire des GPU de rendu tuilé)
- Ces API sont relativement éloignées du dessin direct, tandis que l’UMD prend en charge l’exécution effective des commandes et que le KMD n’offre que l’interface ci-dessus pour accéder au matériel
Conclusion et perspectives
- Cet article a couvert la structure globale et le flux interne d’un pilote GPU, ainsi que les API clés fournies par Tyr
- Sur la base de ces éléments, les prochains articles de la série traiteront de l’architecture matérielle Arm CSF, du microcontroller unit (MCU) et du processus d’initialisation du pilote
Aucun commentaire pour le moment.