Common-Shader Core
Im Shadermodell 4 implementieren alle Shaderphasen die gleiche Basisfunktionalität mithilfe eines Common-Shader-Kerns. Darüber hinaus bietet jede der drei Shaderphasen (Vertex, Geometrie und Pixel) funktionen, die für jede Phase eindeutig sind, z. B. die Möglichkeit, neue Grundtypen aus der Geometrie-Shaderphase zu generieren oder ein bestimmtes Pixel in der Pixelshaderphase zu verwerfen. Das folgende Diagramm zeigt, wie Daten durch eine Shaderphase fließen, und die Beziehung des Common-Shader-Kerns zu Shaderspeicherressourcen.
- Eingabedaten: Ein Vertex-Shader empfängt seine Eingaben von der Eingabeassemierphase. geometry- und Pixelshader erhalten ihre Eingaben aus der vorherigen Shaderphase. Zusätzliche Eingaben umfassen Systemwertsemantik, die von der ersten Einheit in der Pipeline verwendet werden kann, für die sie anwendbar sind.
- Ausgabedaten: Shader generieren Ausgabeergebnisse, die an die nachfolgende Phase in der Pipeline übergeben werden. Bei einem Geometrie-Shader kann die Datenmenge eines einzelnen Aufrufs variieren. Einige Ausgaben werden vom Common-Shader-Kern interpretiert (z. B. Vertexposition und Renderzielarrayindex), andere sind so konzipiert, dass sie von einer Anwendung interpretiert werden.
- Shadercode: Shader können aus dem Arbeitsspeicher lesen, arithmetische Vektor-Gleitkomma- und Ganzzahloperationen oder Flusssteuerungsvorgänge ausführen. Es gibt keine Beschränkung für die Anzahl von Anweisungen, die in einem Shader implementiert werden können.
- Sampler: Sampler definieren, wie Texturen abtast und gefiltert werden. Bis zu 16 Sampler können gleichzeitig an einen Shader gebunden werden.
- Texturen: Texturen können mithilfe von Samplern gefiltert oder auf texelbasierter Basis direkt mit der intrinsischen Load-Funktion gelesen werden.
- Puffer: Puffer werden nie gefiltert, können aber auf Elementbasis direkt mit der systeminternen Load-Funktion aus dem Arbeitsspeicher gelesen werden. Bis zu 128 Textur- und Pufferressourcen (kombiniert) können gleichzeitig an einen Shader gebunden werden.
- Konstantenpuffer: Konstantenpuffer sind für Shadervariablen optimiert. Bis zu 16 Konstantenpuffer können gleichzeitig an eine Shaderphase gebunden werden. Sie sind für häufigere Aktualisierungen von der CPU konzipiert. daher verfügen sie über zusätzliche Größen-, Layout- und Zugriffsbeschränkungen.
Unterschiede zwischen Direct3D 9 und Direct3D 10:
- In Direct3D 9 verfügte jede Shadereinheit über eine einzelne, kleine Konstantenregisterdatei zum Speichern aller konstanten Shadervariablen. Die Aufnahme aller Shader mit diesem begrenzten konstanten Platz erforderte häufiges Recycling von Konstanten durch die CPU.
- In Direct3D 10 werden Konstanten in unveränderlichen Puffern im Arbeitsspeicher gespeichert und wie jede andere Ressource verwaltet. Es gibt keine Beschränkung für die Anzahl von Konstantenpuffern, die eine Anwendung erstellen kann. Durch das Organisieren von Konstanten in Puffern nach Updatehäufigkeit und Nutzung kann die zum Aktualisieren von Konstanten erforderliche Bandbreite für alle Shader erheblich reduziert werden.
Ganzzahlige und bitweise Unterstützung
Der allgemeine Shaderkern bietet einen vollständigen Satz von IEEE-konformen 32-Bit-Ganzzahl- und bitweisen Vorgängen. Diese Vorgänge ermöglichen eine neue Klasse von Algorithmen in Grafikhardwarebeispielen, z. B. Komprimierungs- und Verpackungstechniken, FFTs und Die Steuerung des Bitfeld-Programmflusses.
Die Datentypen int und uint in Direct3D 10 HLSL werden 32-Bit-Ganzzahlen in der Hardware zugeordnet.
| Unterschiede zwischen Direct3D 9 und Direct3D 10: In Direct3D 9 wurden Streameingaben, die in HLSL als ganze Zahl markiert sind, als Gleitkomma interpretiert. In Direct3D 10 werden Streameingaben, die als ganzzahlig markiert sind, als 32-Bit-Ganzzahl interpretiert. Darüber hinaus sind boolesche Werte jetzt alle Bits festgelegt oder alle Bits nicht festgelegt. In bool konvertierte Daten werden als true interpretiert, wenn der Wert nicht gleich 0,0f ist (positive und negative Null dürfen false sein) und andernfalls false. |
Bitweise Operatoren
Der allgemeine Shaderkern unterstützt die folgenden bitweisen Operatoren:
| Operator | Funktion |
|---|---|
| ~ | Logisches NOT |
| << | Linke Umschalttaste |
| >> | Rechtsverschiebung |
| & | Logisches UND |
| | | Logisches ODER. |
| ^ | Logischer Xor |
| <<= | Linke Verschiebung gleich |
| >>= | Rechtsverschiebung gleich |
| &= | Und gleich |
| |= | Oder gleich |
| ^= | Xor Gleich |
Bitweise Operatoren sind so definiert, dass sie nur für die Datentypen int und uint verwendet werden. Der Versuch, bitweise Operatoren für float - oder struct-Datentypen zu verwenden, führt zu einem Fehler. Bitweise Operatoren haben die gleiche Rangfolge wie C in Bezug auf andere Operatoren.
Binäre Umwandlungen
Bei der Umwandlung zwischen einer ganzen Zahl und einem Gleitkommatyp wird der numerische Wert gemäß C-Abschneideregeln konvertiert. Das Umwandeln eines Werts aus einem Float in ein int und zurück in einen Float ist eine verlustbehaftete Konvertierung, die von der Genauigkeit des Zieldatentyps abhängt. Hier sind einige der Konvertierungsfunktionen: asfloat (DirectX HLSL),asint (DirectX HLSL), asuint (DirectX HLSL).
Binäre Umwandlungen können auch mit systeminternen HLSL-Funktionen ausgeführt werden. Diese führen dazu, dass der Compiler die Bitdarstellung einer Zahl in den Zieldatentyp uminterpretiert.