• VS2.0 gilt als Basismodell, welches minimal benötigt wird, um als DirectX 9.0 VPU zu gelten.
• VS2.0 Extended ist eigentlich kein neues Modell, es ist lediglich eine Erweiterung des 2.0'er Modells, welches variabel durch CAP-Bits (Bitfelder, welche je nach Fähigkeiten der Hardware gesetzt. werden) zwischen dem VS2.0 und dem VS3.0 Modell liegt.
• VS3.0 ist als High-End Modell gedacht um zukünftiger Hardware (und Herstellern) ein Basismodell für ihre VPU's zu bieten, es könnte in DirectX 10.0 als Basismodell dienen.
• Daneben gibt es noch die Modelle VS 2_sw und VS 3_sw, welche nur von der CPU ausgeführt werden können und für Entwickler gedacht sind.
  

Gibt die Vertex Shader Version an. Aus der Version 2_0 wird 2_x, falls eines oder mehrere der folgenden CAP-Bits gesetzt bzw. die Werte vom 2_0 Standard abweichen:

D3DVS20CAPS_PREDICATION
DynamicFlowControlDepth
NumTemps
StaticFlowControlDepth

Gibt an, wie lang ein Vertex Shader Programm sein darf. Durch Schleifen und Sub-Routinen kann ein VS-Programm deutlich länger werden, als die max. 256 Instruktionen in einem Block. Manche Befehle benötigen mehrere Instruktionen, weshalb man Instruktion und Befehl nicht gleichsetzen darf.

Der Vertex Shader arbeitet seit Version 1.0 mit 32 Bit Fließkomma-Genauigkeit.

Statische Flußsteuerung ist rech einfach erklärt:

vs_2_0
defb b3, TRUE

if b3
// wenn b3 TRUE ist, dann gehe hier hin

else
// sonst mache hier weiter

endif

Jedoch sind hier keine komplexen Vergleich im IF-Block möglich, lediglich die "Constant Boolean " Register, welche pro Register nur die Werte 0 oder 1 haben können, dürfen nach dem IF stehen. Weitere Befehle sind z.B. loop, call, rep. Ich habe also bei der statischen Flußsteuerung lediglich die "Constant Boolean " Register mit denen ich Vergleiche anstellen kann. Dies ist für komplexe Aufgaben sehr hinderlich, da man nur über Umwege (wenn überhaupt) kompliziertere Vergleichen hinbekomme.

Dynamische Flußsteuerung ist viel leistungsfähiger als ihr statische Vertreter.

vs_2_x

if_lt r3.x, r4.y
// wenn r3.x kleiner ist als r4.y, dann gehe hier hin

else
// sonst mache hier weiter

endif

Hier habe ich wesentlich mehr Möglichkeiten z.B. den IF-Block zu beginnen (_gt "größer", _lt "kleiner", _ge "größer / gleich", _le "kleiner / gleich", _eq "gleich", _ne "ungleich"), ich bin nicht an boolsche Register gebunden. Ebenso hilft die dyn. Flußsteuerung bei Schleifen, welche ich durch feinere Vergleichsmöglichkeiten z.B. "break_lt r3.x, r4.y" - bricht aus momentaner Schleife aus, wenn r3.x < r4.y - beenden kann. Eine if_p0 Anweisung ist ebenfalls möglich, wobei p0 das Predicationsregister ist.

Predication ist eine feine Sache. Im Grunde etwas ähnliches wie eine Flußsteuerung, jedoch ohne Sprünge (zumindest aus der Sicht des Programmierers). Erstmal benötigen wir eine neue Art von Register, das "Predicate Register". Im VS3.0 Modell gibt es davon 1 Stück, p0. Das Register ist ein 4D Vektor mit den 4 Komponenten xyzw, aber jede Komponente (also x, y, z, w) ist ein boolsches Register, kann also nur 0(false) oder 1(true) enthalten.

vs_3_0

setp_le p0, r0, r2.z


bedeuted folgendes:
IF (r0.x <= r2.z) THEN p0.x = true ELSE false
IF (r0.y <= r2.z) THEN p0.x = true ELSE false
IF (r0.z <= r2.z) THEN p0.x = true ELSE false
IF (r0.w <= r2.z) THEN p0.x:= true ELSE false

Andere Vergleiche sind auch möglich. So jetzt haben wir unser p0 Register gesetzt. Was machen wir nun damit?
Wir können nun p0 dazu verwenden, bestimmte Befehle auszuführen, falls das Predicate Register für die entsprechende Komponente eine 1 enthält.

p0.x=true
p0.y=false
p0.z=false
p0.w=true

(p0) add r4, r5, r6


Ohne (p0) würde das VS-Programm folgendes tun:
r4.x = r5.x + r6.x
r4.y = r5.y + r6.y
r4.z = r5.z + r6.z
r4.w = r5.w + r6.w

Mit dem (p0) Befehl jedoch, rechnet er:
IF (p0.x = true) THEN  r4.x = r5.x + r6.x
IF (p0.y = true) THEN  r4.y = r5.y + r6.y
IF (p0.z = true) THEN  r4.z = r5.z + r6.z
IF (p0.w = true) THEN r4.w = r5.w + r6.w

Es würden sich also r4.y und r4.z nicht verändern, da p0.y und p0.z nicht "true" enthalten.

Mittel "Texture Lookup" können Texturedaten(4 Stück) im Vertex Shader geladen werden. Somit könnte man z.B. ein eigenes Displacement Mapping realisieren oder andere Effekte.

SetSamplerState(D3DVERTEXTEXTURESAMPLER[0...3], ...);
SetTexture(D3DVERTEXTEXTURESAMPLER[0...3], ...);

vs_3_0
dcl_2d s0 // 2D Texture
...
mov rSrcTexcoord .w, MipMap-Level
texld rDest, rSrcTexcoord, s0

Bei den bisherigen Vertex Shadern (<3.0) und der festen T&L Einheit wird der Vertex Shader einmal pro Vertex ausgeführt. Die "Input Register" wurden bei jedem Aufruf mit neuen Vertexdaten von einem Vertex Stream versorgt. Mit einer Änderung der Frequenz kann man nun z.B. erreichen, dass ein bestimmter Teil der "Input Register" mit einer niedrigeren Frequenz neue Daten bekommen. Stellt man die Frequenz z.B. auf 2, dann bekommen die "Input Register" (welche dem Stream zugeorndet sind) lediglich bei jedem zweiten verarbeitetem Eckpuntk neue Daten.

"Input Register" müssen zu Begin des Vertex Shader Programms deklariert werden. Es wird ihre Verwendung sowie die Zuordnung festgelegt. Im Vertex Shader Programm kann nur lesend auf die "Input Register" zugegriffen werden.

vs_1_1
dcl_position0 v0
dcl_normal0 v3
dcl_texcoord0 v6

"Temp Register" sind Allzweckregister. Auf sie kann man lesend und schreibend einwirken.

vs_1_1
mov r0.x, v0.x

"Constant Register" gibt es seit dem Vertex Shader 2.0 drei Typen. Einmal den Typ "float", welchen es bereits in den Vorgängerversionen 1.0 und 1.1 gab, sowie "integer" und "boolean". Die "float" Version wird für allgemeine Berechnungen genutzt. Die "integer" und "boolean" hingegen für statische/dynamische Flußsteuerung und als Schleifenzähler.

"Address Register" werden zur Adressierung verwendet. Es können lediglich die "Constant Float Register" indirekt adressiert werden. Hier ein kurzes Beispiel:

vs_1_1
mov r0.x, c[a0.x + n].x // indirekt
mov r0.x, c[n].x // direkt

Das "Loop Counter Register" wird automatisch um 1 erhöht, wenn der Vertex Shader in einen "loop" Block eintritt.

Das "Predicate Register" wird, wie im obigen Beispiel zu sehen war, zur bedingungsabhängigen Ausführung von Befehlen verwendet.

Mit Hilfe des "Sampler Register" können Texturedaten im Vertex Shader verwendet werden. Sie Beispiel weiter oben.

Ohne die "Output Register" würden die fertigen Eckpunkte niemals aus dem Vertex Shader heraus kommen. Beim VS3.0 gibt es nur noch 12 o# Register. Hier ein kurzes (unvollständiges) Beispiel:

// Defenition eines Eckpunktes
struct CUSTOMVERTEX_POS_NORM_COLOR1_TEX1
{
    float       x, y, z;        // Koordinaten    (4 Byte *3)
    float       nx, ny, nz;     // Normalen       (4 Byte *3)
    DWORD       color1;         // diffuse Farbe    (4 Byte *1)
    float       tu1, tv1;       // Texturekoordinaten (4 Byte *2)
};

// Eine Vertex Shader Deklaration, welche die Verbindung zwischen "Input Registern" und Vertexdaten ist
D3DVERTEXELEMENT9 decl[] =
{
    { 0, 0,  D3DDECLTYPE_FLOAT3,   D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
    //v0 enthält unsere Koordinaten, Rückgabe in oPos
   
    { 4, 12, D3DDECLTYPE_FLOAT3,   D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL,   0 },
    //v4 enthält unsere Normalen, sie befinden sich 12 Bytes (4 Bytes * 3 Komponenten) vom Anfang des Streams entfernt,
    //kein Rückgabe

    { 7, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_DIFFUSE,  0 },
    //v7 enthält unsere diffuse Farbe, 24 Bytes (4 Bytes * 6 Komponenten) vom Anfang des Streams entfernt
    //Rückgabe in oD0

    { 8, 28, D3DDECLTYPE_FLOAT2,   D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_TEXCOORD, 0 },
    //v8 enthält unsere Texturekoordinaten, 28 Bytes (4 Bytes * 7 Komponenten) vom Anfang des Streams entfernt
    //Rückgabe in oT0

    D3DDECL_END()
};

// die Vertex Shader Konstante c[0] wird gefüllt
float constants[4] = {0, 0.5f, 1.0f, 2.0f};
m_pd3dDevice->SetVertexShaderConstantF( 0, (float*)&constants, 1 );

// die Vertex Shader Konstante c[4] wird gefüllt
D3DXMATRIX mat;
D3DXMatrixMultiply( &mat, &m_matView, &m_matProj );
D3DXMatrixTranspose( &mat, &mat );
m_pd3dDevice->SetVertexShaderConstantF( 4, (float*)&mat, 4 );

// die Vertex Shader Konstante c[8] wird gefüllt
float color[4] = {1,1,1,1};
m_pd3dDevice->SetVertexShaderConstantF( 8, (float*)&color, 1 );

// die Vertex Shader Konstante c[12] wird gefüllt
float lightDir[4] = {-1,0,1,0};
m_pd3dDevice->SetVertexShaderConstantF( 12, (float*)&lightDir, 1 );


// Vertex Shader
// v0  Eckpunktkoordinaten
// v4  Normalen
// v7  diffuse Farbe
// v8  Texturekoordinaten
// c4  Matrix für die persp. Transformation
// c12 Richtung des Lichtes

vs_1_1                       // Version

dcl_position0 v0             // Eckpunktkoordinaten v0 zuweisen
dcl_color     v7              // Farbwerte v7 zuweisen
dcl_normal0   v4              // Normalen v4 zuweisen
dcl_texcoord  v8                          // Texturekoordinaten v8 zuweisen

m4x4 oPos,    v0,    c4      // transformiere Eckpunkte(v0) mit Hilfe der Matrix(c4) durch den Befehl "m4x4", schreiben in oPos
dp3  r0     , v4   , c12     // Lichtberechnung Normale(v4) *(Skalarprodukt) Lichtvektor(c12), schreiben in r0

mul  oD0    , r0.x , v7      // Vertexfarbe berechnen Farbe * Lichtintensität, schreiben in oD0
                            
mov  oT0.xy , v8             // kopiere Texturekoordinaten (.xy weil es nur 2 Koordinaten(U,V) sind)

So, ich hoffe der Zusammenhang zwischen der Vertex Shader Deklaration und den "Output Registern" ist ein wenig verständlich geworden.

Hiermit wird der absolute Wert eines Registers gebildet.

add rDest, rSrc0, rSrc1_abs

Hiermit wird der Inhalt des Quellregisters negiert.

add rDest, - rSrc0 , rSrc1

Saturate begrenzt das Resultat einer Berechnung auf den Wertebereich [0, 1]. Somit gibt es keine Überläufe.

add_sat rDest, rSrc0 , rSrc1

Mit Replicate/Source Swizzle kann man bestimmen, welche Quellregisterkomponenten in ein Zielregister geschrieben werden.

add rDest, rSrc0 , rSrc1.xxyy    // addiert zu den xy Komponenten von rSrc0 jeweils nur x von rSrc1
                                // und zu den zw Komponenten von rSrc0 jeweils nur y von rSrc1

Arbitrary Swizzle bezeichnet die Möglichkeit, dass die Komponenten (x, y, z, w) beliebig vertauscht werden können.

add rDest, rSrc0, rSrc1.yxzw      // vertauscht x und y beim addieren

Eine "Write Mask" dient dazu, festzulegen, welche Zielregisterkomponenten von einer Operation verändert werden dürfen, jedoch muss die Reihenfolge erhalten bleiben.

add rDest.xw, rSrc0            // nur die x und w Komponenten werden durch den Befehl verändert

Zum Setup gehören Befehle, welche die Version des verwendeten Vertex Shaders festlegen, sowie die Zuordnung zwischen den Input Registern und deren Funktion.

vs_1_1                // legt Version 1_1 des VS fest
dcl_position0 v0       // erklärt das v0 Register zum Register mit den Normalen eines Eckpunktes            

Hier werden einfache mathematische Operationen zur Verfügung gestellt.

mul  oD0, r0.x, v7    // r0.x wird mit v7(skalarer Wert) multipliziert und das Resultat in oD0(diffuse Farbe) geschrieben

Hier werden komplexere mathematische Operationen zur Verfügung gestellt. Man könnte diese auch umgehen und selbst per arithmetischer Operationen nachbilden.

dp3  r0, v4, c12      // rechnet einfach:
                      // r0.w = (v4.x * c12.x) + (v4.y * c12.y) + (v4.z * c12.z);
                      // r0.x = r0.y =  r0.z = r0.w;

Hier werden alle Befehle der statischen und dynamischen Flußsteuerung zusammengefasst. Diese gibt es erst seit VS2.0. Die dyn. Flußsteuerung wird erst mittels der Extended Version des VS2.0 verfügbar sein.

vs_2_x

if_lt r3.x, r4.y
// wenn r3.x kleiner ist als r4.y, dann gehe hier hin

else
// sonst mache hier weiter

endif