Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article décrit les concepts d’adresse virtuelle GPU (GPUVA) et leur gestion à partir de WDDM 2.0 (Windows 10).
Les GPUVA sont gérés dans des pages logiques de 4 Ko ou 64 Ko au niveau de l’interface de pilote de périphérique (DDI). L’utilisation de ces tailles de page permet aux GPUVAs de référencer :
- Mémoire système, qui est toujours allouée à une granularité de 4 Ko.
- Pages de segment de mémoire, qui peuvent être gérées à 4 Ko ou 64 Ko.
Le gestionnaire de mémoire vidéo (VidMm) prend en charge un schéma de traduction d’adresses virtuelles multiniveau, où plusieurs niveaux de tables de pages sont utilisés pour traduire une adresse virtuelle :
- Les niveaux sont numérotés de zéro. Le niveau zéro est affecté au niveau feuille.
- La traduction commence à partir de la table de pages de niveau racine.
Lorsque le nombre de niveaux de table de pages est de deux, la table de pages de niveau racine peut être redimensionnée pour prendre en charge un processus avec une taille d’espace GPUVA variable. Chaque niveau est décrit par la structure DXGK_PAGE_TABLE_LEVEL_DESC dans laquelle le pilote d’affichage en mode noyau (KMD) est renseigné lors d’un appel DxgkDdiQueryAdapterInfo . Le KMD remplit également la structure de capacités DXGK_GPUMMUCAPS pour expliquer la compatibilité avec le GPUVA.
Chaque processus a son propre espace GPUVA. Avant qu’un contexte graphique d’un processus puisse être défini pour l’exécution, la fonction DxgkDdiSetRootPageTable de KMD est appelée pour définir l’adresse de la table de pages racine.
La traduction d’adresses virtuelles pour le cas de deux niveaux de table de pages est illustrée dans le diagramme suivant.
L’appliance GPUVA a DXGK_GPUMMUCAPS ::VirtualAddressBitCount bits.
Les bits faibles [0 - 11] représentent un décalage en octets dans une page.
Les bits suivants de DXGK_PAGE_TABLE_LEVEL_DESC::PageTableIndexBitCount représentent l'index d'une entrée dans une table de page au niveau feuille.
Le nombre d’entrées d’une table de pages est de 2DXGK_PAGE_TABLE_LEVEL_DESC::PageTableIndexBitCount et la taille de la table de pages est DXGK_PAGE_TABLE_LEVEL_DESC::PageTableSizeInBytes octets.
Le reste des bits représentent un index à une entrée de table de page dans la table de page racine. La table de pages racine est redimensionnable pour le schéma de traduction à deux niveaux. Le DDI DxgkDdiGetRootPageTableSize détermine sa taille.
La structure DXGK_PTE est utilisée par le biais de la DDI pour représenter une entrée de table de pages. Cette structure représente des informations sur chaque entrée, que le noyau graphique DirectX (Dxgkrnl) gère. Le pilote utilise ces informations pour générer des entrées de table de pages spécifiques au matériel.
Création d’allocations de tables de pagination
Les tables de pages sont créées en tant qu’allocations implicites et n’ont pas de pilote en mode utilisateur (UMD) ou un handle KMD.
Pour allouer une table de pages, VidMm alloue une allocation de taille DXGK_PAGE_TABLE_LEVEL_DESC ::PageTableSizeInBytes à partir du segment, spécifiée dans DXGK_PAGE_TABLE_LEVEL_DESC ::PageTableSegmentId. Après la création, VidMm initialise chaque entrée de la table de pages comme non valide. Les tables de pages ne changent jamais de taille, à l’exception de la table de pages racine dans le schéma de traduction à deux niveaux.
VidMm prend en charge le redimensionnement de la table de pages racine dans le schéma de traduction à deux niveaux. Lorsqu’une table de pages racine, couvrant une quantité spécifiée d’espace d’adressage, est créée, VidMm appelle DxgkDdiGetRootPageTableSize pour déterminer la taille d’allocation requise pour celle-ci. VidMm alloue ensuite une allocation de cette taille dans le segment, spécifiée par DXGK_PAGE_TABLE_LEVEL_DESC ::PageTableSegmentId pour le niveau racine. Après la création, VidMm initialise chaque entrée de la table de pages de manière non valide à l’aide de la nouvelle opération de pagination UpdatePageTable . La table de pages racine peut croître ou réduire à mesure que la quantité d’espace d’adressage vidéo dont un processus a besoin se développe et diminue. Une fois la table de pages racine créée, VidMm appelle DxgkDdiSetRootPageTable pour associer la table de pages racine nouvellement créée aux différents contextes qui s’exécutent.
Dans les configurations d'adaptateurs d'affichage liés, les tables de pages racines sont créées en tant qu'allocations LinkMirrored. Ces allocations ont un contenu identique et se trouvent à la même adresse physique sur chaque GPU dans le lien. Les tables de pages de niveau inférieur sont allouées en tant qu’allocation LinkInstanced pour refléter le fait que leur contenu peut varier entre les GPU, généralement en raison d’un mappage d’homologue différent. Le contenu des tables de pages est mis à jour séparément sur tous les GPU.
Extension et réduction d’une table de pages racine
Cette section s’applique uniquement aux systèmes avec deux niveaux de tables de pages. Lorsque le nombre de niveaux de table de pages est supérieur à deux, la taille de la table de pages pour chaque niveau est définie par les limites d’adressage virtuelles et est fixe.
Lorsque l’UMD demande des GPUVAs, VidMm augmente la taille de l’espace d’adressage d’un processus pour prendre en charge la requête. Il le fait en augmentant la taille de la table de pages racine actuelle (si nécessaire) et en allouant de nouvelles tables de pages pour la nouvelle plage.
Pour développer une table de pages racine , VidMm crée une autre allocation de table de pages racine, la rend résidente, initialise ses entrées et détruit l’ancienne allocation. La fonction DxgkDdiGetRootPageTableSize permet d’obtenir la taille de la nouvelle table de pages en octets.
Pour réduire une table de pages racine, VidMm crée une allocation de table de pages, la rend résidente, copie une partie de l’ancienne table de page vers la nouvelle table et détruit l’ancienne allocation.
Une fois l’opération de redimensionnement terminée, VidMm appelle DxgkDdiSetRootPageTable pour associer les contextes affectés à leur nouvelle table de pages racine.
Mise à jour de la table de pages
À mesure que les surfaces se déplacent en mémoire, VidMm met à jour le contenu des tables de pages pour refléter le nouvel emplacement des surfaces.
Déplacement d’une table de pages
* VidMm peut déplacer ou supprimer des tables de pages lorsqu’un appareil est inactif ou suspendu. Lorsque VidMm déplace une table de pages, elle met à jour la table de pages de niveaux supérieurs pour référencer le nouvel emplacement de la table de pages.
Lorsque la table de page racine elle-même est déplacée, VidMm appelle DxgkDdiSetRootPageTable pour informer les contextes affectés du nouvel emplacement de leur répertoire de page.
Taille de page physique
Comme mentionné précédemment, VidMm prend en charge deux tailles de page. La mémoire système est toujours gérée dans des pages de 4 Ko, tandis que les segments de mémoire peuvent être gérés à une granularité de 4 Ko ou de 64 Ko, comme déterminé par le KMD.
Lorsque vous optez pour la mémoire virtuelle à gérer dans des pages de 64 Ko, toutes les allocations sont automatiquement alignées et dimensionnées pour être multiples de 64 Ko.
Le développement de toutes les allocations à 64 Ko peut avoir un effet significatif sur la mémoire. L’UMD est responsable de l’empaquetage de petites allocations dans une plus grande pour éviter de perdre de la mémoire.
Lorsque VidMm mappe une adresse virtuelle GPU à une grande page de segment de mémoire de 64 Ko, VidMm mappe les entrées de la table de pages de 4 Ko à 16 pages contiguës de 4 Ko dans le segment de mémoire. L’adresse virtuelle et l’adresse physique sont assurées d'avoir le même alignement de 64 Ko. Autrement dit, les 16 bits inférieurs de l’adresse virtuelle et de l’adresse physique sont garantis de correspondre.