Freigeben über

Features, die in früheren WDDM 2.X-Versionen hinzugefügt wurden

  • Artikel

Auf dieser Seite werden die Features von Anzeige- und Grafiktreibern beschrieben, die in früheren Versionen von WDDM 2.X für Windows 10 hinzugefügt wurden. Informationen zum Anzeigen von Features, die für die neueste WDDM 2.X-Version hinzugefügt wurden, finden Sie unter Neuigkeiten für Windows 10-Anzeige- und Grafiktreiber.

WDDM 2.6

Super nasse Freihandeingabe

Super-Wet Ink ist ein Feature, das sich um das Rendern des Frontpuffers dreht. IHV-Treiber können die Erstellung von "anzeigefähigen" Texturen von Formaten oder Modi unterstützen, die von der Hardware nicht unterstützt werden. Sie können dies tun, indem sie die von der App angeforderte Textur zusammen mit einer "Schatten"-Textur mit einem Format/Layout angibt, das angezeigt werden kann, und dann zwischen den beiden gleichzeitig kopieren. Dieser "Schatten" ist möglicherweise nicht unbedingt eine Textur in der normalen Art, wie wir es denken, sondern kann nur Komprimierungsdaten sein. Darüber hinaus ist es möglicherweise nicht erforderlich, aber stattdessen eine Optimierung zu sein.

Die Laufzeit wird sich entwickeln, um diese Aspekte der anzeigefähigen Oberflächen zu verstehen:

  • Gibt an, ob ein Schatten für die Anzeige auf einer bestimmten VidPnSource/-Ebene vorhanden sein muss.

  • Ob es für einen Schatten optimaler ist.

  • Wann inhalte von der Anwendungsoberfläche auf die Schattenoberfläche übertragen werden sollen. Die Laufzeit wird explizit für diesen Vorgang verwendet, im Gegensatz dazu, dass sie innerhalb von Present implizit ist.

  • Anfordern des Festlegens eines Modus oder dynamisches Kippen zwischen der ursprünglichen und schattenoberfläche.

Scanout kann kurz nach einem VBlank beginnen, vertikal von oben nach unten des Bilds scannt und kurz vor dem nächsten VBlank abgeschlossen. Dies ist nicht immer der Fall, abhängig vom Zeitpunkt der Pixeluhr und dem Layout der Daten in der Textur; insbesondere, wenn tatsächlich Komprimierung verfügbar ist.

Neue DDIs wurden hinzugefügt, um Transformationen zu trennen und zu verstehen, die vor dem Scanout auftreten, um (wenn möglich) das Rendern von Frontpuffern zu ermöglichen. Siehe D3DWDDM2_6DDI_SCANOUT_FLAGS und PFND3DWDDM2_6DDI_PREPARE_SCANOUT_TRANSFORMATION.

Variable Rate Schattierung

Eine variable Schattierung oder grobe Pixelschattierung ist ein Mechanismus, mit dem die Zuordnung von Renderingleistung/Leistung bei unterschiedlichen Geschwindigkeiten über gerenderte Bilder hinweg ermöglicht wird.

Im vorherigen Modell, um MSAA (Multi-Sample Antialiasing) zu verwenden, um geometrische Aliase zu reduzieren:

  • Der Betrag, um den geometrischen Aliasing reduziert werden soll, muss bei der Zuordnung des Ziels vorab bekannt sein.
  • Der Betrag, um den geometrische Aliasing reduziert werden kann, nachdem das Ziel zugewiesen wurde, nicht mehr geändert werden.

In WDDM 2.6 erweitert das neue Modell MSAA in die entgegengesetzte, grobe Pixelrichtung , indem ein neues Konzept der groben Schattierung hinzugefügt wird. Hier kann eine Schattierung mit einer Häufigkeit, die grober als ein Pixel ist, ausgeführt werden. Eine Gruppe von Pixeln kann als einzelne Einheit schattiert werden, und das Ergebnis wird dann an alle Beispiele in der Gruppe übertragen.

Mit einer groben Schattierungs-API können Apps die Anzahl der Pixel angeben, die zu einer schattierten Gruppe gehören. Die grobe Pixelgröße kann nach der Zuordnung des Renderziels variieren. Unterschiedliche Teile des Bildschirms oder unterschiedliche Zeichendurchläufe können also unterschiedliche Kursschattierungsraten aufweisen.

Eine Mehrstufige Implementierung ist mit zwei benutzerdefinierten Kapitälchen verfügbar. Für Tiers 1 und 2 ist grobe Schattierung sowohl für Single-Sample-Ressourcen als auch für MSAA-Ressourcen verfügbar. Bei MSAA-Ressourcen kann die Schattierung pro Grobpixel oder pro Probe wie gewohnt ausgeführt werden. Bei MSAA-Ressourcen der Ebene 1 und 2 können grobe Samplings jedoch nicht verwendet werden, um eine Häufigkeit zwischen Pixel und Stichprobe zu schattieren.

Ebene 1:

  • Die Schattierungsrate kann nur pro Draw-Basis angegeben werden; nichts genaueres als das

  • Die Schattierungsrate gilt einheitlich für das, was unabhängig davon gezeichnet wird, wo sie sich innerhalb des Renderziels befindet.

Ebene 2:

  • Die Schattierungsrate kann wie in Stufe 1 pro Draw-Basis angegeben werden. Sie kann auch durch eine Kombination aus Gezeichnet-Basis und von:

    • Semantik aus dem provozierende Scheitelpunkt und
    • Ein Screenspace-Bild

  • Schattierungsraten aus den drei Quellen werden mit einer Reihe von Kombinationskombinationen kombiniert.

  • Die Kachelgröße des Bildschirmraumbilds beträgt 16 x 16 oder kleiner. Die von der App angeforderte Schattierungsrate wird garantiert genau geliefert (für die Genauigkeit von zeitlichen und anderen Wiederaufbaufiltern)

  • SV_ShadingRate PS-Eingabe wird unterstützt. Die provozende Vertexrate, auch hier als Grundtyprate bezeichnet, ist nur gültig, wenn ein Viewport verwendet wird und SV_ViewportIndex nicht geschrieben wird.

  • Die provozierende Vertexrate, auch als Grundtyprate bezeichnet, kann mit mehr als einem Viewport verwendet werden, wenn die Obergrenze "SupportsPerVertexShadingRateWithMultipleViewports" als "true" markiert ist. Darüber hinaus kann sie in diesem Fall verwendet werden, wenn SV_ViewportIndex geschrieben wird.

Siehe PFND3D12DDI_RS_SET_SHADING_RATE_0062 und D3D12DDI_SHADING_RATE_0062.

Sammeln von Diagnoseinformationen

Durch das Sammeln von Diagnoseinformationen kann das Betriebssystem private Daten von Treibern für Grafikkarten sammeln, die sowohl aus Rendering- als auch Anzeigefunktionen bestehen. Dieses neue Feature ist eine Anforderung in WDDM 2.6.

Der neue DDI sollte es dem Betriebssystem ermöglichen, jederzeit Informationen zu sammeln, die ein Treiber geladen wird. Derzeit verwendet das Betriebssystem die DxgkDdiCollectDebugInfo-Funktion, die vom Miniport implementiert wird, um private Daten des Treibers für TDR-Fälle (Timeouterkennung und -wiederherstellung) abzufragen. Der neue DDI wird aus verschiedenen Gründen verwendet, um Daten zu sammeln. Das Betriebssystem ruft diesen DDI auf, wenn eine Diagnose benötigt wird, um eine Art von Informationen bereitzustellen, die angefordert werden. Der Treiber sollte alle privaten Informationen sammeln, die wichtig sind, um das Problem zu untersuchen und an das Betriebssystem zu übermitteln. DxgkDdiCollectDebugInfo wird schließlich veraltet und durch DxgkDdiCollectDiagnosticInfo ersetzt.

Siehe DXGKDDI_COLLECTDIAGNOSTICINFO.

Hintergrundverarbeitung

Die Hintergrundverarbeitung ermöglicht es Benutzermodustreibern, das gewünschte Threadingverhalten auszudrücken, und die Laufzeit zum Steuern/Überwachen. Benutzermodustreiber würden Hintergrundthreads drehen und die Threads so niedrig wie möglich zuweisen, und verlassen sich auf den NT-Scheduler, um sicherzustellen, dass diese Threads die Threads für kritische Pfade, im Allgemeinen mit Erfolg, nicht stören.

MIT APIs können Apps anpassen, welche Menge an Hintergrundverarbeitung für ihre Workloads geeignet ist und wann diese Arbeit ausgeführt werden soll.

Siehe PFND3D12DDI_QUEUEPROCESSINGWORK_CB_0062.

Treiber hot update

Das Hot Update des Treibers reduziert die Serverausfallzeiten so weit wie möglich, wenn eine Betriebssystemkomponente aktualisiert werden muss.

Der Hot Patch des Treibers wird verwendet, um einen Sicherheitspatch auf den Kernelmodustreiber anzuwenden. In diesem Fall wird der Treiber aufgefordert, den Adapterspeicher zu speichern, der Adapter wird beendet, der Treiber wird entladen, neuer Treiber geladen und der Adapter wird erneut gestartet.

SieheDXGKDDI_SAVEMEMORYFORHOTUPDATE und DXGKDDI_RESTOREMEMORYFORHOTUPDATE.

WDDM 2.5

Nachverfolgte Workloads

Nachverfolgte Workloads sind ein experimentelles Feature, das mehr Kontrolle über den Kompromiss zwischen schnellerer Prozessorausführung im Vergleich zum geringeren Stromverbrauch bietet und erst nach weiterer Ankündigung verfügbar ist. Die Implementierung wurde aus Windows 10, Version 2003, entfernt; und veraltet von früheren Betriebssystemversionen als Teil eines Sicherheitspatches.

Inhaltliche Änderungen

Thema Datum Beschreibung
EDID Extension (VSDB) für HMDs und Spezialisierte Displays 03.12.2018 Spezifikation für Displayhersteller
DirectX Graphics Kernel Subsystem (Dxgkrnl.sys) 12/04/2018 Kernelmodusschnittstellen, die vom Windows-Betriebssystem über das Microsoft DirectX-Grafik-Kernelsubsystem (Dxgkrnl.sys) implementiert werden.
WDDM 2.1-Features 01/10/2019 Beschreibt neue und aktualisierte Features für WDDM 2.1

Raytracing

Neue Direct3D DDI wurden parallel zu den Direct3D-APIs erstellt, um hardwarebeschleunigte Raytracing zu unterstützen. Beispiel-DDIs:

Weitere Informationen zum Raytracing finden Sie unter:

Synchronisierung anzeigen

Das Betriebssystem sucht nach Funktionen für die Anzeigesynchronisierung, wenn die Anzeige vom Treiber für das Betriebssystem verfügbar gemacht wird, also bevor die Anzeige aktiviert wird. Für untergeordnete TypeIntegratedDisplay-Geräte wird dies über einen Aufruf von DxgkDdiQueryAdapterInfo mit Type DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 während der Adapterinitialisierung gemeldet. Für untergeordnete TypeVideoOutput-Geräte, die ab WDDM 2.5 unterstützt werden, werden die Funktionen als Teil der Hot Plug-Verarbeitung über DxgkDdiUpdateMonitorLinkInfo gemeldet, sodass sich die Funktionen basierend auf dem Ziel- oder angeschlossenen Monitor ändern können.

Das Betriebssystem gibt die Anzeigesynchronisierung im DxgkDdiSetTimingsFromVidPn-Aufruf im Eingabefeld in der DXGK_SET_TIMING_PATH_INFO-Struktur pro Pfad an.

WDDM 2.1

WDDM 2.1 ermöglicht neue Szenarien und bietet erhebliche Verbesserungen in den Bereichen Leistung, Zuverlässigkeit, Upgraderesilienz, Diagnoseverbesserungen und zukünftige Systementwicklungen für das Windows-Grafikuntersystem. Das WDDM 2.0-Treibermodell ist eine Voraussetzung für D3D12. WDDM 2.0 und DirectX12 sind nur unter Windows 10 und höher verfügbar.

Nachfolgend finden Sie eine Liste der Featurezufügungen und Updates für WDDM 2.1.

  • Verbesserte Grafikleistung durch Reduzierung des Mehraufwands für die Speicherverwaltung und effizientere Nutzung knapper Grafikspeicher. Die Verbesserungen der Grafikleistung sind:

    • Anbieten und Freigeben von Ressourcen – Bieten und freigeben Sie Verbesserungen, um den Speicherbedarf von Anwendungen zu reduzieren, die im Hintergrundmodus ausgeführt werden.
    • Unterstützung für die 2MB-Codierung von Seitentabelleneingaben – In WDDM 2.1 ist die PTE-Codierung (Large Page Table Entry) in VRAM aktiviert. Diese Änderung erhöht die Leistung auf Systemen, die sie unterstützen.
    • Unterstützung für 64 KB Arbeitsspeicherseiten – Virtuelle Speicherzuweisungen mit einer Granularität von 64 KB werden auch in WDDM 2.1 unterstützt. Diese Änderung profitiert insbesondere von APUs und SoCs, indem der Mehraufwand für den Zugriff auf virtuelle Speicherseiten reduziert wird.

  • Hardwarebasierte Verbesserungen geschützter Inhalte mit vorhandener Batchverarbeitung (PlayReady 3.0)

  • Treiberspeicherinstallation für Grafiktreiber, um die Ausfallsicherheit des Treiberupgrades zu verbessern.

  • DXIL, eine neue Shaderkonformersprache

  • D3D12-Leistungs- und Optimierungsverbesserungen

  • Verbesserte Diagnoseoptionen für Entwickler

Weitere Informationen finden Sie unter WDDM 2.1-Features.

WDDM 2.0

WDDM 2.0 enthält Speicherverwaltungsupdates.

VIRTUELLER GPU-Speicher

  • Der gesamte physische Speicher wird in virtuelle Segmente abstrahiert, die vom GPU-Speicher-Manager (Graphics Processing Unit) verwaltet werden können.
  • Jeder Prozess erhält einen eigenen virtuellen GPU-Adressraum.
  • Die Unterstützung für Swizzling-Bereiche wurde entfernt.

Weitere Informationen finden Sie im virtuellen GPU-Speicher in WDDM 2.0.

Driver Residency

  • Der Videospeicher-Manager stellt sicher, dass die Zuordnungen im Arbeitsspeicher vorhanden sind, bevor Befehlspuffer an den Treiber übermittelt werden. Um diese Funktionalität zu vereinfachen, wurden Benutzermodustreibertreiberschnittstellen (DDIs) hinzugefügt (MakeResident, TrimResidency, Evict).
  • Die Zuordnungs- und Patchspeicherortliste wird auslaufen, da sie im WDDM 2.0-Modell nicht erforderlich ist.
  • Benutzermodustreiber sind jetzt für die Behandlung der Zuordnungsnachverfolgung verantwortlich. Es wurden mehrere DDIs hinzugefügt, um dies zu aktivieren.
  • Treiber erhalten Speicherbudgets und werden erwartet, dass sie sich unter Dem Speicherdruck anpassen. Auf diese Weise können universelle Windows-Treiber auf anwendungsübergreifenden Plattformen funktionieren.
  • DDIs wurden für die Prozesssynchronisierung und die Kontextüberwachung hinzugefügt.

Weitere Informationen finden Sie unter Driver Residency in WDDM 2.0.