Mémoire virtuelle du GPU dans WDDM 2.0

Cet article fournit des détails sur la gestion de la mémoire virtuelle GPU à partir de Windows 10 (WDDM 2.0). Il décrit pourquoi WDDM 2.0 a été modifié pour prendre en charge l’adressage virtuel GPU et la façon dont les pilotes l’utilisent.

Présentation

Avant WDDM 2.0, l’interface de pilote de périphérique (DDI) a été créée afin que les moteurs GPU soient censés référencer la mémoire via des adresses physiques de segment. À mesure que les segments ont été partagés entre les applications et sur-engagés, les ressources ont été relocalisées tout au long de leur cycle de vie, et leurs adresses physiques attribuées ont changé. Ce processus exige le suivi des références de mémoire à l’intérieur des mémoires tampons de commande par le biais de listes d’emplacements d’allocation et de correctif. Ces mémoires tampons devaient ensuite être corrigées avec la référence de mémoire physique correcte avant la soumission à un moteur GPU. Ce suivi et cette mise à jour corrective étaient coûteux. Il imposait essentiellement un modèle de planification où le gestionnaire de mémoire vidéo (VidMm) devait inspecter chaque paquet avant de pouvoir être soumis à un moteur.

Au fil du temps, d’autres fournisseurs de matériel se sont déplacés vers un modèle de planification basé sur le matériel. Dans ce modèle, le travail est envoyé au GPU directement à partir du mode utilisateur et le GPU gère les différentes files d’attente de travail elle-même. Cette évolution a permis d’éliminer la nécessité pour VidMm d’inspecter et de corriger chaque mémoire tampon de commande avant la soumission à un moteur GPU.

Pour ce faire, WDDM prend en charge l’adressage virtuel GPU à partir de WDDM 2.0. Dans ce modèle, chaque processus reçoit un espace d’adresse virtuelle GPU unique (GPUVA) dans lequel chaque contexte GPU peut s’exécuter. Une allocation créée ou ouverte par un processus se voit attribuer une GPUVA unique au sein de l'espace d'adressage GPU virtuel de ce processus. Cette GPUVA affectée reste constante et unique pour la durée de vie de l’allocation. Le pilote d’affichage en mode utilisateur (UMD) est ainsi en mesure de référencer les allocations via leur adresse virtuelle GPU sans avoir à se soucier du changement de la mémoire physique sous-jacente au cours de sa durée de vie.

Les moteurs individuels d’un GPU peuvent fonctionner en mode physique ou virtuel :

• En mode physique, le modèle de planification reste le même qu’avec WDDM v1.x. L'UMD continue de générer les listes d'emplacements pour l'allocation et les correctifs. Ces listes d’allocation sont envoyées avec une mémoire tampon de commande et sont utilisées pour corriger les tampons de commandes vers des adresses physiques réelles avant de les soumettre à un moteur.

• En mode virtuel, un moteur fait référence à la mémoire via des adresses virtuelles GPU. L’UMD génère des mémoires tampons de commande directement à partir du mode utilisateur et utilise de nouveaux services pour envoyer ces commandes au noyau. L’UMD ne génère pas de listes d’emplacements d’allocation ou de correctifs, bien qu’elle soit toujours responsable de la gestion de la résidence des allocations. Pour plus d’informations sur la résidence des conducteurs, consultez Résidence des pilotes dans WDDM 2.0.

Modèles de mémoire GPU

WDDM v2 prend en charge deux modèles distincts pour l’adressage virtuel GPU, GpuMmu et IoMmu. Un pilote doit choisir de prendre en charge les deux modèles ou l’un ou l’autre. Un seul nœud GPU peut prendre en charge les deux modes simultanément.

Modèle GpuMmu

Dans le modèle GpuMmu, VidMm gère l’unité de gestion de la mémoire GPU et les tables de pages sous-jacentes. VidMm expose également des services à l'UMD qui lui permettent de gérer le mappage des adresses virtuelles de GPU aux allocations. GpuMmu implique que le GPU utilise des tables de pages GPU pour accéder aux données. Les tables de pages peuvent pointer vers la mémoire système ou la mémoire de l’appareil local.

Pour plus d’informations, consultez le modèle GpuMmu.

Modèle IoMmu

Dans le modèle IoMmu, le CPU et le GPU partagent un espace d’adressage commun et les tables de pages de CPU. Seule la mémoire système est accessible dans ce cas. IoMmu convient donc aux GPU intégrés. IoMmu fournit un modèle de programmation plus simple, où le GPU et le processeur peuvent utiliser le même pointeur pour accéder à la mémoire. Il n’est pas nécessaire de gérer un ensemble distinct de tables de pages dans la mémoire accessible par GPU. Cela dit, le modèle IoMmu peut entraîner une dégradation des performances en raison de la surcharge liée à la traduction et à la gestion des adresses.

Pour plus d’informations, consultez le modèle IoMmu.