Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Details zur verwaltung virtueller GPU-Speicher ab Windows 10 (WDDM 2.0). Es beschreibt, warum WDDM 2.0 geändert wurde, um die virtuelle GPU-Adressierung zu unterstützen und wie Treiber es verwenden.
Einleitung
Vor 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 zwischen Anwendungen geteilt und überbeansprucht wurden, wurden Ressourcen über ihre Lebensdauer verlagert, wodurch sich ihre zugewiesenen physischen Adressen änderten. Für diesen Prozess müssen Speicherverweise in Befehlspuffern über Zuordnungs- und Patch-Standortlisten nachverfolgt werden. 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. Ein Planungsmodell wurde im Wesentlichen auferlegt, bei dem der Videomemory-Manager (VidMm) jedes Paket prüfen musste, bevor es an eine Engine ü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 Allokation, die von einem Prozess erstellt oder geöffnet wird, erhält eine eindeutige GPU-Virtual-Address innerhalb des GPU-virtuellen Adressraums dieses Prozesses. Diese zugewiesene GPUVA bleibt konstant und eindeutig für die Dauer der Zuweisung. 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 Patch-Speicherortlisten. Diese Zuordnungslisten werden mit einem Befehls-Buffer übermittelt und zum Patchen von Befehls-Buffer auf tatsächliche physische Adressen vor ihrer Übermittlung an eine Engine 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 Listen für Zuordnungen oder Patch-Positionen, obwohl sie weiterhin für die Verwaltung der Zuordnungsspeicher 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 die GPU-Zuordnung virtueller Adressen zu Zuweisungen 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 sowohl die CPU als auch die 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.