Freigeben über

Virtueller GPU-Speicher in WDDM 2.0

  • Artikel

Dieser Artikel enthält Details zur verwaltung virtueller GPU-Speicher ab Windows 10 (WDDM 2.0). Es beschreibt, warum WDDM geändert wurde, um die virtuelle GPU-Adressierung zu unterstützen und wie Treiber es verwenden.

Einführung

Vor dem Windows Display Driver Model (WDDM) 2.0 wurde die Gerätetreiberschnittstelle (Device Driver Interface, DDI) so erstellt, dass GPU-Engines voraussichtlich über segmentische physische Adressen auf den Speicher verweisen. Da Segmente für Anwendungen und überlasteten Einsatz freigegeben wurden, wurden Ressourcen über ihre Lebensdauer verschoben und die zugewiesenen physischen Adressen geändert. Für diesen Prozess sind Speicherverweise erforderlich, die in Befehlspuffern über Zuordnungs- und Patchspeicherortlisten nachverfolgt werden sollen. Diese Puffer mussten dann mit dem richtigen physischen Speicherverweis gepatcht werden, bevor sie an ein GPU-Modul übermittelt werden. Dieses Nachverfolgen und Patchen war teuer. Es hat im Wesentlichen ein Planungsmodell auferlegt, bei dem der Videospeicher-Manager (VidMm) jedes Paket prüfen musste, bevor es an ein Modul übermittelt werden konnte.

Im Laufe der Zeit haben sich mehr Hardwareanbieter zu einem hardwarebasierten Planungsmodell bewegt. In diesem Modell wird die Arbeit direkt aus dem Benutzermodus an die GPU übermittelt, und die GPU verwaltet die verschiedenen Arbeitswarteschlangen selbst. Diese Entwicklung machte es notwendig, die Notwendigkeit zu beseitigen, dass VidMm jeden Befehlspuffer vor der Übermittlung an ein GPU-Modul prüfen und patchen muss.

Dazu unterstützt WDDM die virtuelle GPU-Adressierung ab WDDM 2.0. In diesem Modell erhält jeder Prozess einen eindeutigen GPU Virtual Address (GPUVA)-Speicherplatz, in dem jeder GPU-Kontext ausgeführt werden kann. Eine durch einen Prozess erstellte oder geöffnete Zuordnung wird einem eindeutigen GPUVA innerhalb des virtuellen ADRESSraums dieses Prozesses zugewiesen. Diese zugewiesene GPUVA bleibt konstant und eindeutig für die Lebensdauer der Zuordnung. Der Benutzermodusanzeigetreiber (UMD) kann daher über seine virtuelle GPU-Adresse auf Zuordnungen verweisen, ohne sich Gedanken über den zugrunde liegenden physischen Speicher machen zu müssen, der sich durch seine Lebensdauer ändert.

Einzelne Engines einer GPU können im physischen oder virtuellen Modus ausgeführt werden:

  • Im physischen Modus bleibt das Planungsmodell mit WDDM v1.x identisch. Die UMD generiert weiterhin die Zuordnungs- und Patchspeicherortlisten. Diese Zuordnungslisten werden mit einem Befehlspuffer übermittelt und zum Patchen von Befehlspuffern auf tatsächliche physische Adressen vor der Übermittlung an ein Modul verwendet.

  • Im virtuellen Modus verweist ein Modul auf Speicher über virtuelle GPU-Adressen. Die UMD generiert Befehlspuffer direkt aus dem Benutzermodus und verwendet neue Dienste, um diese Befehle an den Kernel zu übermitteln. Die UMD generiert keine Zuordnungs- oder Patchspeicherortlisten, obwohl sie weiterhin für die Verwaltung der Residency von Zuordnungen verantwortlich ist. Weitere Informationen zum Fahrerwohnsitz finden Sie unter Driver Residency in WDDM 2.0.

GPU-Speichermodelle

WDDM v2 unterstützt zwei unterschiedliche Modelle für die virtuelle GPU-Adressierung, GpuMmu und IoMmu. Ein Fahrer muss sich anmelden , um entweder oder beide Modelle zu unterstützen. Ein einzelner GPU-Knoten kann beide Modi gleichzeitig unterstützen.

GpuMmu-Modell

Im GpuMmu-Modell verwaltet VidMm die GPU-Speicherverwaltungseinheit und zugrunde liegende Seitentabellen. VidMm macht auch Dienste für die UMD verfügbar, mit deren Hilfe gpu virtual address mapping to allocations verwaltet werden kann. GpuMmu impliziert, dass die GPU GPU-Seitentabellen für den Zugriff auf Daten verwendet. Die Seitentabellen können auf den Systemspeicher oder den lokalen Gerätespeicher verweisen.

Weitere Informationen finden Sie im GpuMmu-Modell.

IoMmu-Modell

Im IoMmu-Modell teilen die CPU und GPU einen gemeinsamen Adressraum und CPU-Seitentabellen. In diesem Fall kann nur auf den Systemspeicher zugegriffen werden, sodass IoMmu für integrierte GPUs geeignet ist. IoMmu bietet ein einfacheres Programmiermodell, bei dem sowohl die GPU als auch die CPU denselben Zeiger verwenden können, um auf den Arbeitsspeicher zuzugreifen. Es ist nicht erforderlich, einen separaten Satz von Seitentabellen im GPU-Speicher zu verwalten. Das IoMmu-Modell kann jedoch aufgrund des Aufwands der Adressübersetzung und -verwaltung zu einer beeinträchtigten Leistung führen.

Weitere Informationen finden Sie im IoMmu-Modell.