Partager via

Mémoire virtuelle GPU dans WDDM 2.0

  • Article

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 a été modifié pour prendre en charge l’adressage virtuel GPU et la façon dont les pilotes l’utilisent.

Introduction

Avant le modèle de pilote d’affichage Windows (WDDM) 2.0, l’interface de pilote de périphérique (DDI) a été créée de telle sorte que les moteurs GPU étaient censés référencer la mémoire par le biais d’adresses physiques de segment. À mesure que les segments ont été partagés entre les applications et sur-validés, les ressources ont été déplacées pendant leur durée de vie et leurs adresses physiques affecté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 reçoit une appliance gpu unique au sein de l’espace d’adressage virtuel GPU 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 à vous soucier de la mémoire physique sous-jacente qui change par le biais 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 d’allocation et de correctif. 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 les services à l’UMD qui lui permettent de gérer le mappage d’adresses virtuelles 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, l’UC et le GPU partagent un espace d’adressage commun et des tables de pages processeur. 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.