Modèle GpuMmu

Dans le modèle GpuMmu , l’unité de traitement graphique (GPU) a sa propre unité de gestion de la mémoire (MMU) qui traduit les adresses virtuelles GPU par processus en adresses physiques.

Chaque processus a des espaces d’adressage virtuels PROCESSEUR et GPU distincts qui utilisent des tables de pages distinctes. Le gestionnaire de mémoire vidéo gère l’espace d’adressage virtuel GPU de tous les processus et est chargé d’allouer, de développer, de mettre à jour, de garantir la résidence et de libérer les tables de pages. Le format matériel des tables de pages, utilisé par le MMU GPU, est inconnu du gestionnaire de mémoire vidéo et est extrait par le biais d’interfaces de pilote de périphérique (DDIs). L’abstraction prend en charge une traduction de niveau multiniveau, y compris une table de page de taille fixe et une table de page racine redimensionnable.

Bien que le gestionnaire de mémoire vidéo soit responsable de la gestion de l’espace d’adressage virtuel GPU et de ses tables de pages sous-jacentes, le gestionnaire de mémoire vidéo n’affecte pas automatiquement des adresses virtuelles GPU aux allocations. Cette responsabilité incombe au pilote de mode utilisateur.

Le gestionnaire de mémoire vidéo offre deux ensembles de services au pilote en mode utilisateur. Tout d’abord, le pilote en mode utilisateur peut allouer de la mémoire vidéo via le rappel d’allocation existant et libérer cette mémoire via le rappel de désallouer existant. Tout comme aujourd’hui, cela retourne au pilote en mode utilisateur un handle à une allocation de gestionnaire de mémoire vidéo, qui peut être utilisée par un moteur GPU. Cette allocation représente uniquement la partie physique d’une allocation et peut être référencée par un moteur, fonctionnant physiquement, par le biais d’une référence de liste d’allocation.

Pour les moteurs s’exécutant en mode virtuel, une adresse virtuelle GPU doit être affectée explicitement à une allocation avant d’y accéder virtuellement. À cet effet, le gestionnaire de mémoire vidéo propose aux services de pilote en mode utilisateur de réserver ou de libérer des adresses virtuelles GPU et de mapper des plages d’allocation spécifiques dans l’espace d’adressage virtuel GPU d’un processus. Ces services sont très flexibles et permettent au pilote en mode utilisateur de contrôler finement un espace d’adressage virtuel GPU de processus. Le pilote de mode utilisateur peut décider d’affecter une adresse virtuelle GPU très spécifique à une allocation, ou de laisser le gestionnaire de mémoire vidéo en choisir automatiquement une disponible, en spécifiant éventuellement quelques contraintes d’adresse virtuelle GPU minimales et maximales. Une allocation unique peut être associée à plusieurs mappages d’adresses virtuelles GPU et des services sont fournis au pilote de mode utilisateur pour implémenter le contrat de ressource de vignette.

De même, dans une configuration d’adaptateur d’affichage liée, le pilote en mode utilisateur peut mapper explicitement l’adresse virtuelle GPU à des instances d’allocation spécifiques et choisir pour chaque mappage si le mappage doit être à lui-même ou à un GPU homologue spécifique. Dans ce modèle, les adresses virtuelles PROCESSEUR et GPU affectées à une allocation sont indépendantes. Un pilote en mode utilisateur peut décider de les conserver dans les deux espaces d’adressage ou de les garder indépendants.

Les adresses virtuelles GPU sont gérées logiquement à une granularité de page fixe de 4 Ko via l’interface DDI. Les adresses virtuelles GPU peuvent référencer des allocations, qui sont résidentes dans un segment de mémoire ou dans la mémoire système. La mémoire système est gérée à une granularité physique de 4 Ko, tandis que les segments de mémoire sont gérés à 4 Ko ou 64 Ko au choix du pilote. Toutes les allocations de gestionnaire de mémoire vidéo sont alignées et dimensionnées pour être un multiple de la taille de page choisie par le pilote.

L’accès à une plage d’adresses virtuelles GPU non valides entraîne une violation d’accès et l’arrêt du contexte et/ou de l’appareil à l’origine de la panne d’accès. Pour récupérer après une telle erreur, le gestionnaire de mémoire vidéo lance une réinitialisation du moteur qui est promue en récupération de détection de délai d’attente large (TDR) de l’adaptateur en cas d’échec.

Le modèle GpuMmu est illustré ci-dessous :