Partager via

Vue d’ensemble de la résidence

  • Article

Aperçu

Aujourd’hui, le pilote en mode utilisateur génère des informations sur l’allocation et la liste des emplacements des correctifs, ainsi que chaque mémoire tampon de commandes générée. Ces informations sont utilisées par le gestionnaire de mémoire vidéo à deux fins :

  • La liste d’allocation et la liste d’emplacements des correctifs sont utilisées pour corriger les mémoires tampons de commande avec des adresses de segment réelles avant qu’elles ne soient envoyées à un moteur d’unité de traitement graphique (GPU). La prise en charge des adresses virtuelles GPU dans le modèle de pilote d’affichage Windows (WDDM) v2 supprime la nécessité de cette mise à jour corrective.
  • La liste d’allocation et la liste des emplacements des correctifs sont utilisées par le gestionnaire de mémoire vidéo pour contrôler la résidence de l’allocation. Le gestionnaire de mémoire vidéo garantit que toutes les allocations référencées par une mémoire tampon de commande sont rendues résidentes avant l’envoi de la mémoire tampon de commande à l’exécution d’un moteur particulier.

Avec l’introduction du nouveau modèle de résidence, la résidence est déplacée vers une liste explicite sur l’appareil au lieu de la liste de mémoires tampons par commande. Le gestionnaire de mémoire vidéo s’assure que toutes les allocations sur une liste d’exigences de résidence d’appareil particulière sont résidentes avant que les contextes appartenant à cet appareil soient planifiés pour l’exécution.

Pour gérer la résidence, le pilote en mode utilisateur a accès à deux nouvelles interfaces de pilote de périphérique (DDIs), MakeResident et Evict, et doit également implémenter un nouveau rappel TrimResidency . MakeResident ajoute une ou plusieurs allocations à une liste des conditions de résidence des appareils. L’évicte supprimera l’une des autres allocations de cette liste. Le rappel TrimResidency est appelé par le gestionnaire de mémoire vidéo lorsqu’il a besoin du pilote du mode utilisateur pour réduire son besoin de résidence.

MakeResident et Evict ont également été mis à jour pour conserver un nombre de références internes, ce qui signifie que plusieurs appels à MakeResident nécessitent un nombre égal d’appels d’évictage pour effectivement supprimer l’allocation.

Dans le nouveau modèle de résidence, l’allocation de mémoire tampon par commande et la liste des emplacements des correctifs sont progressivement supprimées. Bien que ces listes existent dans certains scénarios, elles n’auront plus aucun contrôle sur la résidence.

Important La résidence dans WDDM v2 est contrôlée exclusivement par la liste des conditions de résidence de l’appareil. Cela est vrai sur tous les moteurs du GPU et pour chaque API.

Suppression progressive de l’allocation et de la liste des emplacements des correctifs

Le rôle de la liste des emplacements d’allocation et de correctif sera considérablement réduit avec l’introduction du nouveau modèle de résidence et disparaîtra complètement avec l’introduction de la planification assistée par le matériel.

Sous le modèle de planification basée sur les paquets, la liste d’allocation continue d’exister comme suit :

  • Pour les moteurs qui ne prennent pas en charge l’adressage virtuel GPU, la liste d’allocation et la liste des emplacements des correctifs continueront d’exister, mais ils seront utilisés uniquement à des fins de mise à jour corrective et n’auront plus aucun contrôle sur la résidence. La liste d’allocations et la liste des emplacements des correctifs seront fournies au pilote en mode utilisateur et au pilote en mode noyau dans les différentes DDIs habituelles, mais toute référence à des allocations qui ne sont pas résidentes entraînera le refus de la soumission et la mise en erreur de l’appareil (perdu). Ce mode de fonctionnement est considéré comme hérité et nous nous attendons à ce que tous les moteurs GPU obtiennent la prise en charge de l’adressage virtuel GPU dans les futures versions matérielles. Il est prévu que ce mode d’opération sera supprimé dans les versions futures de WDDM.
  • Pour les moteurs qui prennent en charge l’adressage virtuel GPU, un nouvel indicateur de création de contexte (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED) est ajouté pour indiquer que le contexte particulier ne nécessite pas de mise à jour corrective. Lorsque cet indicateur est spécifié, aucune liste d’emplacements de correctif n’est allouée et seule une très petite liste d’allocation (16 entrées) est allouée. La liste d’allocations sera utilisée pour effectuer le suivi des références d’écriture aux surfaces primaires et à aucune autre fin. Le planificateur GPU doit savoir quand une mémoire tampon de commande particulière écrit sur une surface primaire afin qu’il puisse synchroniser correctement l’exécution de cette mémoire tampon en ce qui concerne le basculement potentiel sur la surface primaire.

De même, la liste d’allocation est utilisée dans le chemin Actuel du pilote en mode noyau pour transmettre des informations au pilote sur la source et la destination de l’opération Present . Dans ce contexte, la liste d’allocation continuera d’exister pour transmettre des paramètres, mais la liste d’allocation ne sera pas utilisée pour la résidence. Sur les GPU nécessitant une mise à jour corrective, la liste d’allocations présentes contient des informations de pré-correctif, comme elle le fait aujourd’hui, et le paquet Present est corrigé à nouveau avant d’être planifié si l’une des ressources se déplace en mémoire entre le moment où elles sont mises en file d’attente vers le planificateur et le moment où elles sont planifiées pour l’exécution sur le GPU.

Le tableau ci-dessous récapitule quand un pilote WDDM v2 doit s’attendre à recevoir une liste d’emplacements d’allocation et de correctif dans différents DDIs de pilotes en mode utilisateur et en mode noyau.

Moteur GPU Liste d’allocations ? Liste des emplacements des correctifs ?
Aucune prise en charge des adresses virtuelles GPU (exiger la mise à jour corrective, par défaut)

Oui, en taille réelle, mais uniquement à des fins de mise à jour corrective.

Toute référence à une allocation qui n’est pas résidente entraîne une erreur (perte) de l’appareil d’envoi et le rejet de la soumission par le planificateur.		 Oui, en taille réelle.
Prise en charge des adresses virtuelles GPU (jeu d’indicateurs DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED )

Oui, 16 entrées.

Fait référence à la surface primaire, le cas échéant, en cours d’écriture par la mémoire tampon de commande. Utilisé par le planificateur GPU pour la synchronisation avec les lèvres qui se produisent sur le contrôleur d’affichage. La surface principale doit déjà figurer dans la liste des conditions de résidence de l’appareil, sinon la référence sera rejetée.		 No
Prise en charge des adresses virtuelles GPU + planification matérielle Non Non