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.
À compter de WDDM 2.0, un modèle de segmentation est utilisé pour extraire l’accès GPU à la mémoire physique. Le pilote en mode noyau (KMD) exprime les ressources de mémoire physique disponibles pour un GPU en énumérant un ensemble de segments. Le gestionnaire de mémoire vidéo (VidMm) gère ensuite ces segments.
Types de segments
Il existe trois types de segments :
Segments de mémoire
Un segment de mémoire représente la mémoire dédiée à un GPU. Il peut s’agir de VRAM sur un GPU discret ou une mémoire réservée au microprogramme/pilote sur un GPU intégré. Un pilote peut énumérer plusieurs segments de mémoire.
À compter de WDDM 2.0, VidMm gère un segment de mémoire en tant que pool de pages physiques dont la taille est de 4 Ko ou 64 Ko. Les données Surface sont copiées vers et depuis un segment de mémoire à l'aide des opérations de pagination Fill/Transfer/Discard/FillVirtual/TransferVirtual.
Le processeur peut accéder au contenu d’un segment de mémoire de l’une des deux manières suivantes :
- Un segment de mémoire peut être visible dans l’espace d’adressage physique du processeur, auquel cas VidMm associe simplement les adresses virtuelles du processeur directement aux allocations au sein du segment.
- À compter de WDDM 2.0, VidMm prend également en charge l’accès au contenu d’un segment de mémoire par le biais d’une ouverture d’hôte de processeur programmable associée à ce segment.
Segments d’ouverture
Un segment d'ouverture d'aperture est une table de pages globale utilisée pour faire en sorte que les pages de mémoire système discontinues semblent contiguës du point de vue d'un moteur graphique de GPU.
Dans WDDM 2.0, un segment d’ouverture unique doit être signalé.
Segments de mémoire système
Le segment de mémoire système est un segment implicite représentant les références de mémoire système (autrement dit, une adresse physique invitée). Le KMD n’énumère pas directement un segment de mémoire système. Au lieu de cela, VidMm l'énumère implicitement et l'affecte toujours SegmentId==0. Pour placer une allocation dans le segment de mémoire système, le KMD doit utiliser l’ID du segment d’ouverture.
Informations de référence sur la mémoire physique
Dans la DDI, les références de mémoire physique prennent toujours la forme d’une paire de décalage de segment ID-segment.
Accès aux allocations par adresse physique
Les moteurs GPU qui ne prennent pas en charge l'adressage virtuel de GPU doivent accéder aux allocations par le biais de leurs adresses physiques. Cette exigence a des implications sur la façon dont une allocation obtient les ressources affectées à partir d’un segment. Les références physiques impliquent qu'une allocation doit être allouée de manière contiguë dans un segment de mémoire ou occuper une plage contiguë dans le segment d'ouverture.
Pour éviter les allocations contiguës inutiles et coûteuses, le KMD doit identifier explicitement les allocations qui nécessitent un moteur de rendu pour y accéder physiquement. KMD le fait en définissant l’indicateur DXGK_ALLOCATIONINFOFLAGS2 ::AccessedPhysical lors de la création de l’allocation.
Ces allocations seront mappées au segment d'aperture lorsqu'elles résident dans la mémoire système. Les allocations seront contiguës lorsqu’elles se trouvent dans un segment de mémoire. Les allocations créées de cette façon peuvent être référencées via la liste d’allocations sur les moteurs, fonctionnant en mode d’adressage physique.
Pour les allocations qui n’ont pas ce drapeau, VidMm les alloue comme un ensemble de pages dans un segment de mémoire ou un ensemble de pages dans la mémoire système, les deux étant accessibles via des adresses virtuelles GPU. Les allocations créées de cette façon ne peuvent pas être référencées par le biais de la liste d’allocations. Toute soumission de mémoire tampon de commande référençant l’allocation de cette façon sera rejetée.
Les surfaces principales, qui sont les images principales affichées par un ordinateur, sont implicitement accessibles physiquement par le contrôleur d’affichage. Ces surfaces sont allouées contiguëment dans un segment de mémoire ou mappées dans le segment d’ouverture lorsqu’elles sont affichées. Le KMD ne doit définir que les indicateurs AccessPhysical lorsque son moteur de rendu accède physiquement à l’allocation. La différence entre l'accès physique implicite à la surface primaire et les drapeaux explicites réside dans le moment où l'allocation est cartographiée dans l'ouverture :
Lorsque les indicateurs AccessedPhysical sont définis, l’allocation est mappée à l’ouverture chaque fois qu’elle est résidente.
Les surfaces principales qui n’ont pas ce drapeau sont mappées dans la fenêtre uniquement lorsqu’elles sont affichées. Cette approche permet de supprimer la pression sur le segment d’ouverture. Autrement dit, il n’y a généralement que quelques surfaces principales affichées activement, tandis qu’un grand nombre d’entre elles peuvent exister et être rendues graphiquement. Par exemple, toutes les chaînes d’échange FlipEx sont créées en tant que surfaces primaires et potentiellement affichables dans les scénarios dFlip/iFlip .
Le tableau suivant résume la façon dont différents types d’allocations au sein des segments GPU sont accessibles en fonction de leurs exigences d’accès physique.
| Type de segment | AccèsPhysique==0 | AccédéPhysiquement==1 | Primary && AccessedPhysically == 0 |
|---|---|---|---|
| Segment de mémoire | Ensemble de pages. Seul l’accès virtuel GPU est autorisé. | Contiguë. L’accès physique GPU est autorisé | Contigu. Seul l’accès virtuel GPU est autorisé par les moteurs de rendu. |
| Segment d’ouverture | Non mappé. Pages de mémoire système, mappées uniquement par les tables de pages GPU et non par le segment d'aperture. Seul l’accès virtuel GPU est autorisé. | Cartographié lorsqu'il est résident. L’accès physique GPU est autorisé. | Mappé lorsqu’il est affiché. Seul l’accès virtuel GPU est autorisé par les moteurs de rendu. |