Rasterizer-Auftragsansichten
Rasterizer ordered views (ROVs) ermöglichen dem Pixelshadercode das Markieren von UAV-Bindungen mit einer Deklaration, die die normalen Anforderungen an die Reihenfolge der Grafikpipelineergebnisse für UAVs ändert. Dadurch können OIT-Algorithmen (Order Independent Transparency) funktionieren, die viel bessere Renderingergebnisse liefern, wenn mehrere transparente Objekte in einer Ansicht miteinander in Einklang stehen.
Übersicht
Standardmäßige Grafikpipelines haben möglicherweise Probleme beim ordnungsgemäßen Zusammensetzen mehrerer Texturen, die Transparenz enthalten. Objekte wie Wire Fences, Smoke, Fire,Wiederverwendung und Farbiges Glass verwenden Transparenz, um den gewünschten Effekt zu erzielen. Probleme treten auf, wenn mehrere Texturen, die Transparenz enthalten, miteinander in Einklang stehen (z. B. Feuer vor einem Zäunen vor einem Gebäude mit Brillen). Rasterizer ordered views (ROVs) ermöglichen es den zugrunde liegenden OIT-Algorithmen, Features der Hardware zu verwenden, um zu versuchen, die Transparenzreihenfolge ordnungsgemäß aufzulösen. Transparenz wird vom Pixelshader behandelt.
Rasterizer ordered views (ROVs) ermöglichen dem Pixelshadercode das Markieren von UAV-Bindungen mit einer Deklaration, die die normalen Anforderungen an die Reihenfolge der Grafikpipelineergebnisse für UAVs ändert.
ROVs garantieren die Reihenfolge der UAV-Zugriffe für jedes Paar überlappender Pixel-Shaderaufrufe. In diesem Fall bedeutet "überlappend", dass die Aufrufe von den gleichen Zeichnen-Aufrufen generiert werden und die gleiche Pixelkoordinate verwenden, wenn sie sich im Ausführungsmodus der Pixelfrequenz befinden, und die gleiche Pixel- und Stichprobenkoordinate im Stichprobenhäufigkeitsmodus.
Die Reihenfolge, in der überlappende ROV-Zugriffe von Pixel-Shaderaufrufen ausgeführt werden, ist identisch mit der Reihenfolge, in der die Geometrie übermittelt wird. Dies bedeutet, dass ROV-Schreibvorgänge, die von einem Pixel-Shaderaufruf ausgeführt werden, bei überlappenden Pixelshaderaufrufen verfügbar sein müssen, damit sie von einem nachfolgenden Aufruf gelesen werden können und sich nicht auf Lesevorgänge durch einen vorherigen Aufruf auswirken dürfen. ROV-Lesevorgänge, die von einem Pixel-Shaderaufruf ausgeführt werden, müssen Schreibvorgänge durch einen vorherigen Aufruf und keine Schreibvorgänge durch einen nachfolgenden Aufruf widerspiegeln. Dies ist für UAVs wichtig, da sie explizit aus den Ausgabeinvarianzgarantien weggelassen werden, die normalerweise durch die feste Reihenfolge der Grafikpipelineergebnisse festgelegt werden.
Details zur Implementierung
Rasterizer ordered views (ROVs) werden mit den folgenden neuen HLSL-Objekten (High Level Shader Language) deklariert und sind nur für den Pixelshader verfügbar:
RasterizerOrderedBufferRasterizerOrderedByteAddressBufferRasterizerOrderedStructuredBufferRasterizerOrderedTexture1DRasterizerOrderedTexture1DArrayRasterizerOrderedTexture2DRasterizerOrderedTexture2DArrayRasterizerOrderedTexture3D
Verwenden Sie diese Objekte auf die gleiche Weise wie andere UAV-Objekte (z. RWBuffer B. usw.).
API-Zusammenfassung
ROVs sind ein rein HLSL-Konstrukt, das unterschiedliche Verhaltenssemantik auf UAVs anwendet. Alle APIs, die für UAVs relevant sind, sind auch für ROVs relevant. Beachten Sie, dass die folgende Methode, Strukturen und Hilfsklasse auf den Rasterizer verweisen:
- D3D11 _ RASTERIZER _ DESC2: Struktur, die die Rasterizerbeschreibung aufweist, und notiert die CD3D12 _ RASTERIZER _ DESC2-Hilfsklasse zum Erstellen von Rasterizerbeschreibungen.
- D3D11 _ FEATURE _ DATA _ D3D11 _ OPTIONS2 : Struktur mit dem booleschen
ROVsSupportedWert, der die Unterstützung angibt. - ID3D11Device::CheckFeatureSupport: Methode für den Zugriff auf die unterstützten Features.