Übersicht über die Residenz

Übersicht

Heute erstellt der Benutzermodustreiber Zuordnungs- und Patchspeicherortlisteninformationen zusammen mit jedem befehlspuffer, den er erstellt. Diese Informationen werden vom Videospeicher-Manager für zwei Zwecke verwendet:

• Die Zuordnungsliste und die Patchspeicherortliste werden verwendet, um Befehlspuffer mit tatsächlichen Segmentadressen zu patchen, bevor sie an eine GPU-Engine (Graphics Processing Unit) übermittelt werden. Durch die Unterstützung virtueller GPU-Adressen im Windows Display Driver Model (WDDM) v2 ist dieses Patchen nicht mehr erforderlich.
• Die Zuordnungsliste und die Patchspeicherortliste werden vom Videospeicher-Manager verwendet, um die Residency der Zuordnung zu steuern. Der Videospeicher-Manager stellt sicher, dass alle Zuordnungen, auf die von einem Befehlspuffer verwiesen wird, als resident festgelegt werden, bevor der Befehlspuffer zur Ausführung für eine bestimmte Engine gesendet wird.

Mit der Einführung des neuen Residenzmodells wird die Residenz in eine explizite Liste auf dem Gerät anstatt in die Pufferliste pro Befehl verschoben. Der Videospeicher-Manager stellt sicher, dass alle Zuordnungen in einer bestimmten Anforderungsliste für die Geräteresidenz resident sind, bevor Kontexte, die zu diesem Gerät gehören, für die Ausführung geplant werden.

Um die Residenz zu verwalten, hat der Benutzermodustreiber Zugriff auf zwei neue Gerätetreiberschnittstellen (DDIs), MakeResident und Evict, und muss einen neuen TrimResidency-Rückruf implementieren. MakeResident fügt einer Anforderungsliste für die Geräteresidenz eine oder mehrere Zuordnungen hinzu. Die Entfernung entfernt eine der weiteren Zuordnungen aus dieser Liste. Der TrimResidency-Rückruf wird vom Videospeicher-Manager aufgerufen, wenn er den Benutzermodustreiber benötigt, um die Residency-Anforderung zu reduzieren.

MakeResident und Evict wurden ebenfalls aktualisiert, um eine interne Verweisanzahl beizubehalten, was bedeutet, dass mehrere Aufrufe von MakeResident eine gleiche Anzahl von Evict-Aufrufen erfordern, um die Zuordnung tatsächlich zu entfernen.

Im Rahmen des neuen Residenzmodells werden die Pufferzuordnung und die Patchspeicherortliste pro Befehl langsam eingestellt. Obwohl diese Listen in einigen Szenarien vorhanden sind, haben sie keine Kontrolle mehr über die Residenz.

Wichtig Die Residenz in WDDM v2 wird ausschließlich durch die Anforderungsliste für die Geräteresidenz gesteuert. Dies gilt für alle Engines der GPU und für jede API.

Schrittweises Auslaufen der Zuordnungs- und Patchspeicherortliste

Die Rolle der Zuordnungs- und Patchpositionsliste wird mit der Einführung des neuen Residenzmodells erheblich reduziert und wird mit der Einführung der hardwareunterstützten Planung vollständig weg.

Unter dem paketbasierten Planungsmodell besteht die Zuordnungsliste weiterhin wie folgt:

• Für Engines, die keine virtuelle GPU-Adressierung unterstützen, sind die Zuordnungsliste und die Patchspeicherortliste weiterhin vorhanden. Sie werden jedoch ausschließlich zu Patchzwecken verwendet und haben keine Kontrolle mehr über die Residenz. Die Zuordnungsliste und die Patchspeicherortliste werden sowohl dem Benutzermodustreiber als auch dem Kernelmodustreiber in den verschiedenen üblichen DDIs bereitgestellt, aber alle Verweise auf Zuordnungen, die nicht resident sind, führen dazu, dass der GPU-Planer die Übermittlung ablehnt und das Gerät fehlerhaft (verloren geht). Dieser Betriebsmodus gilt als legacy, und wir erwarten, dass alle GPU-Engines in zukünftigen Hardwareversionen Unterstützung für die virtuelle GPU-Adressierung erhalten. Es wird erwartet, dass dieser Betriebsmodus in zukünftigen Versionen von WDDM gelöscht wird.
• Für Engines, die die virtuelle GPU-Adressierung unterstützen, wird ein neues Flag für die Kontexterstellung (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED) hinzugefügt, um anzugeben, dass für den jeweiligen Kontext kein Patching erforderlich ist. Wenn dieses Flag angegeben ist, wird keine Patchspeicherortliste zugeordnet, und es wird nur eine sehr kleine Zuordnungsliste (16 Einträge) zugeordnet. Die Zuordnungsliste wird verwendet, um Schreibverweise auf primäre Oberflächen und zu keinem anderen Zweck nachzuverfolgen. Der GPU-Planer muss wissen, wann ein bestimmter Befehlspuffer auf eine primäre Oberfläche schreibt, sodass er die Ausführung dieses Puffers in Bezug auf das möglicherweise auf die primäre Oberfläche auftretendes Flipen ordnungsgemäß synchronisieren kann.

Auf ähnliche Weise wird die Zuordnungsliste im Kernelmodustreiber Present path today verwendet, um Dem Treiber Informationen über die Quelle und das Ziel des Present-Vorgangs zu übergeben. In diesem Kontext wird die Zuordnungsliste weiterhin vorhanden sein, um Parameter zu übergeben, aber die Zuordnungsliste wird nicht für die Residenz verwendet. Auf GPUs, die patchen müssen, enthält die Liste "Aktuelle Zuordnung" Informationen zum Vorpatch, wie es heute der Fall ist, und das Aktuelle Paket wird erneut gepatcht, bevor es geplant wird, wenn eine der Ressourcen im Arbeitsspeicher zwischen der Warteschlange beim Planer und dem Zeitpunkt, zu dem sie für die Ausführung auf der GPU geplant sind, verschoben wird.

In der folgenden Tabelle wird zusammengefasst, wann ein WDDM v2-Treiber eine Zuordnungs- und Patchspeicherortliste in verschiedenen DDIs für Benutzermodustreiber und Kernelmodustreiber erwarten sollte.

GPU-Engine	Zuordnungsliste?	Patchspeicherortliste?
Keine Unterstützung virtueller GPU-Adressen (Patching erforderlich, Standard)	Ja, vollständige Größe, aber nur für Patchzwecke. Jeder Verweis auf die Zuordnung, die nicht resident ist, führt dazu, dass das übermittelnde Gerät fehlerhaft (verloren geht) und die Übermittlung vom Planer abgelehnt wird.	Ja, vollständige Größe.
Unterstützung virtueller GPU-Adressen (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED Flag set)	Ja, 16 Einträge. Verweist ggf. auf die primäre Oberfläche, in die vom Befehlspuffer geschrieben wird. Wird vom GPU-Planer für die Synchronisierung mit Lippen verwendet, die auf dem Anzeigecontroller auftreten. Die primäre Oberfläche muss sich bereits in der Anforderungsliste für die Geräteresidenz befinden, andernfalls wird der Verweis abgelehnt.	No
Unterstützung virtueller GPU-Adressen + Hardwareplanung	No	Nein