Freigeben über


Direct3D 12-Renderdurchgänge

Das Render-Pass-Feature von Direct3D 12 wird in Windows 10, Version 1809 (WDDM 2.5) eingeführt. Es erweitert das allgemeine Konzept der Renderdurchläufe, indem es eine strukturiertere Methode für Anwendungen einführt, um Datenabhängigkeiten und Ausgabeziele für eine Reihe von Renderingvorgängen zu deklarieren, wodurch eine effizientere GPU-Verarbeitung ermöglicht wird.

In diesem Artikel werden die Ziele der Renderpass-Funktion beschrieben und die wichtigsten DDI-Ergänzungen und Änderungen aufgeführt, die sie unterstützen. Weitere Informationen finden Sie in der D3D12-Spezifikation für Renderdurchgänge. Informationen zur Anwendungsebene finden Sie unter Direct3D 12-Renderdurchgänge.

Ziele

D3D12-Renderdurchgänge sind zum Erreichen folgender Ziele konzipiert:

  • Ermöglichen Sie Anwendungen, unnötige Lade- und Speicheroperationen von Ressourcen zwischen On-Chip-Speicher und Hauptspeicher zu vermeiden.

    D3D12-Renderdurchgänge bieten Anwendungen eine zentrale Stelle, um ihre Abhängigkeiten für eine Reihe von Renderingvorgängen anzugeben. Diese Datenabhängigkeiten ermöglichen es den Treibern, die Daten zur Bindungs- und Barrierezeit zu prüfen und Anweisungen zu geben, um Ressourcenladungen und -speichern in und aus dem Hauptspeicher zu minimieren.

    Durch die Reduzierung unnötiger Ressourcenlasten/Speicher wird insbesondere das Rendern auf TBDR-Architekturen (kachelbasiertes verzögertes Rendering) optimiert.

  • Zulassen, dass TBDR-Architekturen (kachelbasiertes verzögertes Rendering) opportunistisch Ressourcen im Chip-Cache über Renderdurchläufe hinweg beibehalten (auch in separaten Befehlslisten)

    • Fall A: Lesen/Schreiben von Pixeln „1:1”

      Ein häufiges Renderingmuster besteht darin, dass eine Anwendung zunächst in die Zielansicht (Render Target View, RTV) A rendert, und danach zu einem späteren Zeitpunkt während des Renderns in RTV B die Textur von dieser Ressource als Shaderressourcenansicht (Shader Resource View, SRV) A nutzt. In Fällen, in denen die Schreibvorgänge in RTV B von SRV A im „1:1“-Verhältnis gelesen werden (Pixel, die genau an der gleichen Position in SRV A abgebildet sind), können einige Architekturen den aktuellen Binningdurchgang während der Schreibvorgänge in RTV B fortsetzen. Diese Architekturen vermeiden daher eine Speicherflutung, da die SRV A-Lesevorgänge lediglich eine Abhängigkeit von der aktuellen Kachel haben.

      Ein Designziel besteht darin, diese beiden Durchgänge ohne einen dazwischenliegenden Flush in den Hauptspeicher zusammenzuführen.

    • Fall B: Schreibt in die gleichen Renderziele in mehreren Befehlslisten

      Ein weiteres gängiges Renderingmuster ist es, dass die Anwendung in denselben Renderzielen in mehreren Befehlslisten seriell gerendert wird, auch wenn die Renderingbefehle parallel generiert werden. Mit D3D12-Renderdurchgängen können Treiber ein Leeren des Hauptspeichers an Befehlslistengrenzen vermeiden, wenn die Anwendung weiß, dass sie das Rendern für dieselben Renderziele in der unmittelbar folgenden Befehlsliste fortsetzen wird.

      Ein Designziel besteht darin, diese beiden Durchläufe so zu kombinieren, dass ein dazwischen liegender Leerlauf in den Hauptspeicher vermieden wird.

  • Zulassen, dass die Renderdurchgangs-APIs für Treiber verwendet werden, die diese nicht nutzen

    Mit dem Design können die APIs für Treiber aufgerufen werden, die das Feature nicht nutzen. Solange die Anwendung auf einer ausreichend neuen Runtime ausgeführt wird, können Renderdurchgänge auf allen Geräten verwendet werden. Apps können einen Pfad schreiben.

    Geräte, denen dies egal ist, erhalten eine Runtimeübersetzung des Features zu Nicht-Renderdurchgängen. Geräte, die dieses Feature nutzen möchten, können dies tun.

  • Zulassen, dass UMD einen optimalen Renderingpfad ohne hohe CPU-Strafe auswählen kann

    Dieses Feature sollte mit den Zielen für den niedrigen CPU-Overhead von D3D12 übereinstimmen und so konzipiert werden, dass die CPU-Auslastung für allgemeine Renderingworkloads nicht erheblich beeinträchtigt wird (nicht mehr als ~20%).

  • Zulassen, dass ISVs die ordnungsgemäße Verwendung des Features auch bei Treibern überprüfen, die nicht notwendigerweise Verhaltensänderungen basierend auf der Featureverwendung vornehmen

    Die Debugebene sollte in der Lage sein, die falsche Verwendung des Features zu identifizieren, auch wenn sie auf einem nicht unterstützten Treiber ausgeführt wird. (Beispielsweise wie die DX11-Debug-Schicht eine Ressource als Reaktion auf einen Verwerfen-Aufruf auf eine zufällige Farbe zurücksetzt).

Treiberschnittstellenupdates der Renderdurchgänge

In diesem Abschnitt werden die wichtigsten D3D12-Schnittstellenupdates beschrieben, die zur Unterstützung der Funktion für erweiterte Renderdurchläufe vorgenommen wurden.

Ressourcenzugriffsdeklaration

Die D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053-Enumeration wird hinzugefügt. Er gibt den Anfangszugriffstyp einer Ressource in einem Renderdurchlauf an. Die folgenden erweiterten-Renderdurchgangswerte werden hinzugefügt:

  • D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER
  • D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV
  • D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV

Ebenso wird die D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053-Enumeration hinzugefügt. Er gibt den Endzugriffstyp einer Ressource in einem Renderdurchlauf an. Die folgenden erweiterten-Renderdurchgangswerte werden hinzugefügt:

  • D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER
  • D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV
  • D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV

Zur pfnBeginRenderPass-Zeit empfängt der Treiber alle Ressourcen, die als RTVs/DSVs (Datenquellenansicht) innerhalb dieses Renderdurchgangs dienen. Der Benutzer deklariert diese Ressourcen und gibt die Merkmale des Typs "Anfangs-/Endzugriff" an. Die Anfangs- und Endwerte müssen für alle Ressourcen bereitgestellt werden.

Beginnender Zugriffstyp Übereinstimmender Endzugriffstyp
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_DISCARD D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_DISCARD
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_PRESERVE D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_PRESERVE
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_CLEAR D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_RESOLVE
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0053_NO_ACCESS D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0053_NO_ACCESS
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_RENDER
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_SRV
D3D12DDI_RENDER_PASS_BEGINNING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV D3D12DDI_RENDER_PASS_ENDING_ACCESS_TYPE_0101_PRESERVE_LOCAL_UAV

WHLK-Tests

Direct3D 11on12 ersetzt OMSetRenderTargets-Aufrufe durch B„eginRenderPass/EndRenderPass”, um die allgemeine Rendering-Funktionalität mit Renderdurchgängen zu testen.

Die HLK testet andere spezifische Funktionen, darunter:

  • Eine BEGINNING-Bereinigung mit keinem Rendering im Renderdurchgang und ein PRESERVE am Ende führt zu einer Bereinigung für verschiedene Ressourcenformate und -typen (und RT-Anzahlen).

  • Eine BEGINNING-Bereinigung mit Rendering im Renderdurchgang und ein PRESERVE am Ende führen zu einer Bereinigung (mit korrekter Reihenfolge der Zeichnungen nach der Bereinigung) für verschiedene Ressourcenformate und -typen (und RT-Anzahlen).

  • Ein BEGINNING-Verwerfen, das Misch- oder Tiefenoperationen verwendet und Abhängigkeiten von bestehenden Inhalten aufweist, führt nicht zu einem GPU-Stillstand (nicht definierte Rendering-Werte sind akzeptabel).

  • Eine ENDING-Auflösung löst Ressourcen in verschiedenen Konfigurationen ordnungsgemäß auf (einschließlich der Verwendung der neuen MIN/MAX-Funktionen für Tiefen-/Schablone, die in ResolveSubresourceRegion hinzugefügt wurden).

  • Die Verwendung von SUSPEND/RESUME führt zu keinem Renderingunterschied (im Vergleich zu ENDING_PRESERVE/BEGINNING_PRESERVE) für verschiedene Ressourcenformate und -typen.

  • Für einen BEGINNING/ENDING preserve/preserve_local, bleiben die Werte im Renderziel auch außerhalb des Renderdurchgangs erhalten, wenn beim Renderdurchgang keine Arbeit ausgeführt wird.