WDDM 2.1 – Features

Artikel
10/07/2024

Dieser Artikel enthält Details zu Features und Verbesserungen im Windows Display Driver Model (WDDM) Version 2.1, die ab der Windows 10 Anniversary Edition (Windows 10, Version 1607) verfügbar ist.

WDDM 2.1 selbst ist optional. Wenn es implementiert ist, handelt es sich um eine Sammlung obligatorischer und optionaler Treiberfunktionen. Ein Treiber, der eine dieser WDDM 2.1-Funktionen unterstützt, muss alle obligatorischen Funktionen unterstützen. Windows Hardware Lab Kit (HLK)-Tests können die Unterstützung überprüfen, Dxgkrnl prüft jedoch auf Konsistenz in den Funktionen und DDIs.

Tabelle der WDDM 2.1-Anforderungen

Funktion	Anwendbarkeit
Verbesserungen bei Angebot und Rückforderung	Obligatorisch.
Videospeicherverwaltung	Optional
Verbesserungen bei der Zuverlässigkeit von HW-geschützten Inhalten	Ausgewählte Hardware
Anwendungsunterstützung mit Windows GameDVR	Obligatorisch.
Indirekte Anzeige	Ausgewählte Hardware
Treiberspeicher und parallele Installation	Obligatorisch.
DirectX-Speicheroberflächenfreigabe für Kamera-/Aufnahmeszenarien	Obligatorisch.

WDDM 2.1 unterstützt die folgenden D3D-Versionen: D3D9, D3D10, D3D10.1, D3D11, D3D11.x, D3D12

Verbesserungen bei Angebot und Rückforderung

Die Rückruffunktion PFND3DDDI_RECLAIMALLOCATIONS3CB wurde hinzugefügt, um den Speicherbedarf von Anwendungen zu verringern, die im Hintergrundmodus ausgeführt werden. Diese Schnittstelle ermöglicht Anwendungen, Ressourcen anzubieten, die für die vollständige Deaktivierung im Hintergrund akzeptabel sind. Daher kann der Process Lifetime Manager mehr Arbeitsspeicher aus Hintergrundanwendungen freigeben, die DirectX verwenden, was zu weniger Beendigungen der Hintergrundanwendung führt, wenn der Arbeitsspeicher stark belastet ist.

Weitere DDI-Änderungen:

Weitere Informationen zum Anbieten und Freigeben von Ressourcen finden Sie unter Änderungen bei Angebot und Rückforderungen.

Anwendungsunterstützung mit Windows GameDVR

Windows 10 Anniversary Edition enthält die verbesserte Möglichkeit, die Windows Game Bar und GameDVR mit Vollbildspielen zu verwenden.

WDDM 2.1-Treiber sind erforderlich, um ein Leistungsfeature namens Present Batching zu unterstützen, das Multithreading-Unterstützung für Flip-Modell-Swapchains hinzufügt. Dieses wesentliche Feature stellt sicher, dass Vollbildspiele mit Game Bar auf dem gleichen Leistungsniveau wie in früheren Versionen von Windows ausgeführt werden.

Die folgenden DDIs wurden hinzugefügt, um dieses Feature zu aktivieren:

Indirekte Anzeige

In WDDM 2.1 ermöglicht die indirekte Anzeige, dass per USB angeschlossene Displays die gleichen Benutzeroberflächen wie alle anderen Monitore nutzen. Darüber hinaus ist ein indirekter Anzeigetreiber (IDD) ein Benutzermodustreiber, der einfacher zu entwickeln ist als ein Kernelmodustreiber, was zu einer erhöhten Gesamtsystemzuverlässigkeit beiträgt.

In WDDM 2.1 sind die folgenden USB-Anzeigefeatures/-umgebungen aktiviert:

Wenn ein USB-Display mit einer Windows-Plattform verbunden ist oder Betriebssysteme aktualisiert werden, werden die korrekten Treiber von Windows Update heruntergeladen und installiert.
Wenn Monitore mit USB-Display-Hardware verbunden werden, wird die korrekte Monitortopologie, -auflösung und -DPI erkannt und eingerichtet.
Benutzer können die Monitorauflösung und -skalierung auf dem Monitor ändern.
Benutzer können USB-Displays trennen und erneut anschließen, ohne dass unerwartete Nebeneffekte auftreten.
Die Monitortopologie wird beim Trennen und erneuten Verbinden mit demselben Monitor beibehalten.
USB-Displays funktionieren ordnungsgemäß in verschiedenen Betriebszuständen, einschließlich Standbymodus und Ruhezustand.

Weitere Informationen zur indirekten Anzeige finden Sie unter Treibermodelle für indirekte Anzeige – Übersicht.

Treiberspeicher und parallele Installation von Treibern

WDDM 2.1 führt die Installation von Grafiktreibern über den Treiberspeicher ein. Dieser Mechanismus zum Installieren von Grafiktreibern verbessert die Resilienz von Treiberupdates von Windows Update. Er beseitigt fehlende Übereinstimmungen von Treiberdateiversionen, die zu Systeminstabilitäten und vom Benutzer zu initiierenden Neustarts führen. Jedes nachfolgende Treiberupdate wird direkt vom eindeutigen Speicherort im Treiberspeicher (d. h. System32\DriverStore\FileRepository\[…]) aus ausgeführt, wodurch Überschreibungen und Nichtübereinstimmungen von Treibern vermieden werden.

Die Featureimplementierung des Treiberspeichers erfordert Änderungen an der INF-Datei des Grafiktreibers, um sicherzustellen, dass die Treiberdateien in das eindeutige Treiberrepository kopiert werden. Die INF-Änderungen werden unter INF-Anforderungen ausführlicher erläutert.

DXIL

WDDM 2.1 führt den Übergang des GPU-Shader-Compilerstapels von DirectX Byte Code (DXBC) zu DirectX Intermediate Language (DXIL) ein, einem neueren Format zum Übertragen von Shaderanweisungen an die GPU. Der Übergang zu DXIL bietet Entwicklern die folgenden Vorteile:

Programmierbarkeit. Die Einfachheit der Entwicklung wird verbessert und die Komplexität des Shadererstellungsprozesses für Entwickler reduziert, indem Unterschiede zwischen GPU-Programmiersyntax und CPU-Sprachen minimiert werden, mit denen Entwickler vertraut sind.
Compiler mit höherer Leistung:
- Runtime Shader Performance ist aktiviert, um höhere Leistung zu ermöglichen.
- DXIL bietet eine Reihe intrinsischer Funktionen, die das Weitergeben von Daten über die Spuren der SIMD-Prozessoren in GPUs ermöglicht.
Workflowflexibilität – DXIL ermöglicht Entwicklern die Kontrolle über ihre eigenen benutzerdefinierten Tools und Optimierungsdurchläufe sowie die Möglichkeit zu wählen, welche Kompilierungsschritte zur Buildzeit gegenüber der Laufzeit angewendet werden.
Erweiterte Sprachfeatures – Eine weiterentwickelte Sprache bietet wichtige Features, die Unterschiede zwischen GPU-Code und CPU-Code beseitigen und die Lernkurve für GPU-Programmierer optimieren.

Mit diesen Features, die Vorteile für Entwickler bieten, erhalten Endbenutzer die Vorteile besserer Leistung neuer oder aktualisierter Spiele, auch wenn sie auf vorhandener Hardware ausgeführt werden.

In WDDM 2.1 wurde eine Frameserver-Komponente eingeführt, um ein Kamera- oder Aufnahmegerät für mehrere Prozesse gleichzeitig freizugeben. Erfasste Frames können an einem Ort gespeichert werden, von dem aus mehrere Anwendungen lesen können, sodass die Bilddaten nicht mehrmals zwischen Prozessen und Co-Prozessen kopiert werden müssen. Dieses Feature ermöglicht die effizientere Verwaltung erfasster Bilder über mehrere Prozesse hinweg sowie Energieeinsparungen, Bandbreitenreduzierung und Latenzreduzierung für WDDM 2.1-kompatible Hardware und Treiber. Das Endergebnis sind Leistungsgewinne für Anwendungen und Benutzer.

Der Frameserver weist ein erfasstes Bild als prozessübergreifend gemeinsam nutzbaren Speicher zu und gibt diesen Speicher für Prozesse frei, die Zugriff anfordern. Da der Frameserver die Textur an mehrere Clientprozesse sendet, muss die Textur gleichzeitiges Lesen unterstützen. Derzeit werden NV12-Texturen für diesen Zweck unterstützt.

Pipelinestatusobjekt (PSO)-Zwischenspeicherung und Bibliothek

Das Pipelinestatusobjekt (PSO) ist eine Schnittstelle, die die Anweisungen und Ressourcen der Grafikpipeline (auch als „Zustand“ bezeichnet) als einheitliches Objekt repräsentiert, um den Konflikt zwischen D3D und Treiberdekompositionen des Zustands zu reduzieren. Das Ausführen graphisch anspruchsvoller Anwendungen und Spiele erfordert die Erstellung einer großen Anzahl von PSOs. PSO wurde in D3D12 eingeführt.

WDDM 2.1-PSO-Bibliothek und -Zwischenspeicherung ermöglichen Gaminganwendungen, ein PSO auf physischen Speichermedien zu speichern, nachdem sie während der ersten Ausführung erstellt wurden. Mit dieser Funktion kann die D3D-Laufzeit die vordefinierten PSOs aus der Bibliothek in zukünftigen Instanzen abrufen, wodurch die PSO-Extraktionszeit reduziert wird. Wenn Sie beispielsweise ein Spiel nach der ersten Ausführung oder nach dem Neustart des PCs ausführen, werden Inhalte aus der physischen Bibliothek als gespeicherte PSOs geladen.

Pipelinestart-GPU-Zeitstempel

In WDDM 2.1 wurde die Funktion zum Abrufen der Zeitstempel des Starts von Grafikereignissen in der GPU-Pipeline eingeführt. Dieses Feature, das mit dem Pipelineend-Zeitstempeln verwendet wird, ermöglicht Entwicklern die klare und fein abgestimmte Visualisierung von Parallelisierung, Pipelining und Timing der Aktivitäten ihrer Anwendung, die auf der GPU auftreten. Entwickler können ihren Code weiter optimieren und Ineffizienzen und andere Leistungsprobleme untersuchen, wenn sie die Ausführungszeit jedes Ereignisses kennen.

Dieses Feature trägt dazu bei, das Erfassen von GPU-Leistungsdaten in Echtzeit mit geringem Aufwand zu ermöglichen und gleichzeitig genügend Informationen bereitzustellen, um Workloads auf GPUs zu visualisieren und zu messen. Das Ziel besteht darin, ausreichend Informationen bereitzustellen, um die genaue Reihenfolge und Dauer von Vorgängen zu rekonstruieren, die von der GPU ausgeführt wurden. Mit diesen Informationen können Tools Parallelität und Pipelining mit einer Engine visualisieren, GPU-Workloads messen und potenzielle Synchronisierungsprobleme identifizieren.

Anzeigen von GPU-Microcode

WDDM 2.1 ermöglicht Entwicklern die weitere Optimierung ihrer Shader durch die Anzeige von GPU-Microcode. Entwickler programmieren die Grafikpipeline, indem Shader in High-Level Shader Language (HLSL) erstellt werden, die dann in eine Zwischensprache für den GPU-Treiber kompiliert werden. Der Treiber führt zusätzliche Kompilierungen und Optimierungen durch, um diesen Code in GPU-spezifische Anweisungen zu konvertieren, die für die Entwickler intransparent blieben. Mit diesem Feature wird Entwicklern lesbarer GPU-spezifischer Code präsentiert, um den Umfang ihrer Shaderoptimierung und -geschwindigkeit zu evaluieren.

Mit diesem Feature kann der Benutzermodustreiber (User-Mode Driver, UMD) zu jeder programmierbaren Phase der Grafikpipeline (Shader) Kommentare und Informationen zu Aktionen zur Verwendung oder zum Missbrauch dieser Shader zurückgeben. Der GPU-spezifische Microcode wird zerlegt und zusammen mit den UMD-Kommentaren in lesbarem Zeichenfolgenformat dargestellt. Entwickler können ihre HLSL-Codezuordnung zu lesbarem GPU-Code nebeneinander anzeigen und so ihren Code dynamisch ändern und die Ergebnisse der Compileroptimierung auf der GPU-Codeseite anzeigen.

Ermitteln der WDDM-Version

WDDM 2.1-Caps

Treiber melden WDDM 2.1-Unterstützung über DXGK_DRIVERCAPS::WDDMVersion mit der Versionskonstante:

DXGK_WDDMVERSION::DXGKDDI_WDDMv2_1 = 0x2100

Dxgkrnl verwendet die WDDMVersion-Cap nicht als Möglichkeit, um zu bestimmen, welche Features unterstützt werden. Diese Aufgabe bleibt bei anderen Caps oder DDI-Anwesenheitsinformationen. Wenn der Treiber jedoch WDDM 2.1-Unterstützung über die WDDMVersion-Cap meldet, validiert Dxgkrnl, ob die von WDDM 2.1 benötigten Caps oder DDIs vorhanden sind und den Adapter nicht erstellen können, wenn dies nicht der Fall ist. Inkonsistente Caps führen dazu, dass keine Adapter oder Segmente erstellt werden.

Hinweis

Vorhandene oder neuere Anwendungen müssen nicht das Treibermodell abfragen, um alle Features der Windows 10 Anniversary Edition zu nutzen, die durch Plattformverbesserungen wie die hier beschriebenen aktiviert werden. Alle Funktionsänderungen müssen über die jeweilige Laufzeit angezeigt werden.

Die folgende Konstante wurde hinzugefügt, um KMT_DRIVERVERSION_WDDM_2_1 zu entsprechen:

typedef enum _DXGIDRIVERMODELVERSION
{
    DXGIDMVERSION_1_0            = 1000,
    DXGIDMVERSION_1_1_PRERELEASE = 1102,
    DXGIDMVERSION_1_1            = 1105, 
    DXGIDMVERSION_1_2            = 1200,
    DXGIDMVERSION_1_3            = 1300,
    DXGIDMVERSION_2_0            = 2000,
    DXGIDMVERSION_2_1            = 2100,

} DXGIDRIVERMODELVERSION;

DDI-Schnittstellenversionen im Kernelmodustreiber (KMD) sind die folgenden:

#define DXGKDDI_INTERFACE_VERSION_VISTA      0x1052
#define DXGKDDI_INTERFACE_VERSION_VISTA_SP1  0x1053
#define DXGKDDI_INTERFACE_VERSION_WIN7       0x2005
#define DXGKDDI_INTERFACE_VERSION_WIN8       0x300E
#define DXGKDDI_INTERFACE_VERSION_WDDM1_3    0x4002
#define DXGKDDI_INTERFACE_VERSION_WDDM1_3_PATH_INDEPENDENT_ROTATION  0x4003
#define DXGKDDI_INTERFACE_VERSION_WDDM2_0    0x5023
#define DXGKDDI_INTERFACE_VERSION_WDDM2_1    0x6002

Grafik-INF-Anforderungen

WDDM 2.1-Grafiktreiber weisen unterschiedliche INF-Anforderungen im Vergleich zu den WDDM 2.0- oder früheren Treibern auf:

WDDM 2.1 muss über eine identische Featurebewertung zum WDDM 2.0-Grafiktreiber (D1) verfügen.
WDDM 2.1-Grafiktreiber müssen einen anderen OS INF-Installationsabschnitt verwenden.
Der WDDM 2.1-Grafiktreiber INF ändert sich für die Installation des Treiberspeichers.

Weitere Informationen finden Sie unter INF-Dateiabschnitte und Anweisungen.

Sowohl 32-Bit- als auch 64-Bit-Treiberdateien verbleiben im Treiberspeicher und werden aus dem Treiberspeicher geladen. Die Umleitung des WoW64-Dateisystems gilt nicht für den Treiberspeicher. IHVs können Unterordner mithilfe der standardmäßigen INF-Syntax angeben, um z. B. einen WoW64-Ordner unter dem eindeutigen Treiberspeicherordner bei Bedarf zu erstellen.

Das folgende Beispiel zeigt, wie sich eine INF-Unterstützung vom Treiberspeicher vom vorherigen Verhalten unterscheidet.

WINDOWS 10 ANNIVERSARY EDITION APPROACH: RUNNING DRIVERS FROM THE DRIVER STORE
[DestinationDirs]
KMDCopyFiles = 13
UMDCopyFiles = 13
UMDWoW64CopyFiles = 13

[DDInstall]
CopyFiles=KMDCopyFiles
CopyFiles=UMDCopyFiles
CopyFiles=UMDWoW64CopyFile

[KMDCopyFiles]
myKMD.sys

[UMDCopyFiles]
myUMD64.dll
myOpenCL64.dll
myOpenGL64.dll

[UMDWow64CopyFiles]
myUMD32.dll
myOpenCL32.dll
myOpenGL32.dll

[DDInstall.Services]
AddService = serviceName, 0x00000002, serviceName_Service_Inst

[serviceName_Service_Inst]
ServiceBinary = %13%\serviceName.sys

[regAdd]
HKR,,UserModeDriverName,%REG_MULTI_SZ%,%13%\myUMD64.dll, %13%\myUMD64.dll, %13%\myUMD64.dll, %13%\myUMD64.dll
HKR,,UserModeDriverNameWoW,%REG_MULTI_SZ%, %13%\myUMD32.dll, %13%\myUMD32.dll, %13%\myUMD32.dll, %13%\myUMD32.dll
HKLM,"Software\Khronos\OpenCL\Vendors",%13%\myOpenCL64.dll,%REG_DWORD%,0x00000000
HKLM,"Software\Wow6432Node\Khronos\OpenCL\Vendors",%13%\ myOpenCL32.dll,%REG_DWORD%,0x00000000
HKR,,OpenGLDriverName,%REG_MULTI_SZ%,%13%\myOpenGL64.dll
HKR,,OpenGLDriverNameWoW,%REG_MULTI_SZ%,%13%\myOpenGL32.dll

Um einen Unterordner anzugeben, können Treiber die Syntax verwenden, die im folgenden Beispiel gezeigt wird:

...
[DestinationDirs]
...
UMDWoW64CopyFiles = 13,WoW64
...
[regAdd]
...
HRK,, UserModeDriverNameWoW,%REG_MULTI_SZ%, %13%\WoW64\myUMD.dll, %13%\WoW64\myUMD.dll, %13%\

The manufacturer install section decoration for Windows 10 Anniversary edition WDDM 2.1 drivers is as follows: 
...
[Manufacturer]
%Grfx_Manf% =  IHVGfx, NTamd64.10.0…14310
...
[IHVGfx.NTamd64.10.0…14310]
; HW ID list
[list of HW IDs]

Treiberversionsverwaltung

Die Treiber-DLL- und SYS-Dateien für einen Grafikadapter oder Chipsatz müssen eine ordnungsgemäß formatierte Dateiversion haben.

Die Treiberinformationsdatei (.inf), der Kernelmodustreiber (.sys) und die Dateiversionsinformationen des Benutzermodus (.dll) müssen übereinstimmen. Darüber hinaus müssen Versionsinformationen für alle im Abschnitt [SignatureAttributes] der .inf-Datei als PETrust-Binärdateien mit der .inf übereinstimmen. Es wird empfohlen, dass Dateiversionsinformationen für zusätzliche Binärdateien in einem Treiberpaket mit der .inf übereinstimmen.

Um mit den jeweiligen Dateiversionsanforderungen für ältere Betriebssysteme konsistent zu sein, muss die Dateiversionsformatierung einem AA.BB.CCCCC.DDDDD-Muster entsprechen, wobei Folgendes gilt:

AA gibt die Treibermodellversion des Geräts mit der größten Kapazität an, das in der .inf aufgeführt ist
BB (für WDDM 1.2-Treiber und höher) gibt die höchste verfügbare D3D-Featureebene des in der .inf aufgeführten Geräts mit der höchsten Kapazität an
BB (für WDDM 1.1-Treiber und niedriger) gibt die höchste verfügbare DDI-Version an, die von dem in der .inf aufgeführten Gerät mit der höchsten Kapazität unterstützt wird
CCCCC ist eine Zahl mit bis zu fünf Ziffern von 0 bis 65535, die vom Anbieter ausgewählt wird
DDDDD ist eine Zahl mit bis zu fünf Ziffern von 0 bis 65535, die vom Anbieter ausgewählt wird

Werte für das AA-Feld:

Treibermodell	AA-Wert
WDDM v2.1	21
WDDM v2.0	20
WDDM v1.3	10
WDDM v1.2	9
WDDM v1.1	8
WDDM v1.0	7
XDDM	6

Werte für das BB-Feld (WDDM 1.2 und höher):

DirectX-Featureebene	BB-Wert
12_x	21
12_1	20
12_0	19
11_1	18
11_0	17
10_1	16
10_0	15
9_3	14
9_2	14
9_1	14

Werte für das BB-Feld (WDDM 1.1 und früher):

DDI-Version	BB-Wert
D3D11-DDI auf Featureebene 11_0	17
D3D11-DDI auf Featureebene 10	16
D3D10-DDI	15
D3D9 DDI	14

Beispiele

Hinweis

Für die Felder CCCCC oder DDDDD muss 123 nicht als 00123 (d. h. mit Nullen aufgefüllt) dargestellt werden. In früheren Versionen des Windows-Betriebssystems hatten die beiden letzten Felder vier Ziffern, d. h. CCCC.DDDD. Daher weisen die Beispiele für Treiberversionen vor Windows 10 und WDDM 2.0 nur vier Ziffern auf.

Windows Vista WDDM 1.0:
- D3D9 DDI-Treiber können 7.14.0000.0000 bis 7.14.9999.9999 verwenden
- D3D10 DDI-Treiber können 7.15.0000.0000 bis 7.15.9999.9999 verwenden
Windows 7 WDDM 1.1:
- D3D9 DDI-Treiber können 8.14.0000.0000 bis 8.14.9999.9999 verwenden
- D3D10 DDI-Treiber können 8.15.0000.0000 bis 8.15.9999.9999 verwenden
- D3D11 DDI mit FL_10_0-Treibern kann 8.16.0000.0000 bis 8.16.9999.9999 verwenden
- D3D11 DDI mit FL_11_0-Treibern kann 8.17.0000.0000 bis 8.17.9999.9999 verwenden
Windows 8 WDDM 1.2:
- FL_10_0 HW kann 9.15.0000.0000 bis 9.15.9999.9999 verwenden
- FL_10_1 HW kann 9.16.0000.0000 bis 9.16.9999.9999 verwenden
- FL_11_0 HW kann 9.17.0000.0000 bis 9.17.9999.9999 verwenden
- FL_11_1 HW kann 9.18.0000.0000 bis 9.18.9999.9999 verwenden
Windows 8.1 WDDM 1.3:
- FL_10_0 HW kann 10.15.0000.0000 bis 10.15.9999.9999 verwenden
- FL_10_1 HW kann 10.16.0000.0000 bis 10.16.9999.9999 verwenden
- FL_11_0 HW kann 10.17.0000.0000 bis 10.17.9999.9999 verwenden
- FL_11_1 HW kann 10.18.0000.0000 bis 10.18.9999.9999 verwenden
Windows 10 WDDM 2.0:
- FL_11_1 HW kann 20.18.0000.0000 bis 20.18.65535.65535 verwenden
- FL_12_0 HW kann 20.19.0000.0000 bis 20.19.65535.65535 verwenden
- FL_12_1 HW kann 20.20.0000.0000 bis 20.20.65535.65535 verwenden
Windows 10 WDDM 2.1:
- FL_11_1 HW kann 20.18.0000.0000 bis 21.18.65535.65535 verwenden
- FL_12_0 HW kann 20.19.0000.0000 bis 21.19.65535.65535 verwenden
- FL_12_1 HW kann 20.20.0000.0000 bis 21.20.65535.65535 verwenden

Durchsetzung

Ein obligatorischer Test in der HLK-Zertifizierungswiedergabeliste für Windows 10-Builds ab 10586 erzwingt die in diesem Artikel angegebenen Regeln. Der Test ist für ältere Betriebssystemversionen optional. Für Windows 10-Builds ab 10586 wurde die WDDM-Version auf 2.1 aktualisiert. Dies kann auch so verstanden werden, dass die obligatorische Anforderung nur für Treiber gilt, die für WDDM 2.1 oder höher erstellt werden.

Freigeben über

WDDM 2.1 – Features

Tabelle der WDDM 2.1-Anforderungen

Verbesserungen bei Angebot und Rückforderung

Anwendungsunterstützung mit Windows GameDVR

Indirekte Anzeige

Treiberspeicher und parallele Installation von Treibern

DXIL

Pipelinestatusobjekt (PSO)-Zwischenspeicherung und Bibliothek

Pipelinestart-GPU-Zeitstempel

Anzeigen von GPU-Microcode

Ermitteln der WDDM-Version

WDDM 2.1-Caps

Grafik-INF-Anforderungen

Treiberversionsverwaltung

Beispiele

Durchsetzung

Feedback

Zusätzliche Ressourcen

Freigeben über

WDDM 2.1 – Features

Tabelle der WDDM 2.1-Anforderungen

Verbesserungen bei Angebot und Rückforderung

Anwendungsunterstützung mit Windows GameDVR

Indirekte Anzeige

Treiberspeicher und parallele Installation von Treibern

DXIL

DirectX-Speicheroberflächenfreigabe für Kamera-/Aufnahmeszenarien

Pipelinestatusobjekt (PSO)-Zwischenspeicherung und Bibliothek

Pipelinestart-GPU-Zeitstempel

Anzeigen von GPU-Microcode

Ermitteln der WDDM-Version

WDDM 2.1-Caps

Grafik-INF-Anforderungen

Treiberversionsverwaltung

Beispiele

Durchsetzung

Feedback

Zusätzliche Ressourcen