NV vertex program - FAQ Frage

[liquid]

Nabend Leute,

lese grade ein wenig in der FAQ im Dev-Bereich von nVidia und sehe da im letzten Abschnitt etwas was mich sehr verwundert hat. Lest am besten selbst:

http://developer.nvidia.com/object/General_FAQ.html

Frage:
Why am I getting z-fighting in my scene? I using multiple passes, but with the exact same vertex data and transformations in each pass.

Antwort:
Make sure you're not using vertex shaders to do transforms in one pass and fixed function transforms in another. These two paths, even given the exact same data, will not generally produce the exact same values, and this can cause z-fighting when rendering multiple passes with an EQUAL depth test. The solution is to stick to one method for all passes over an object, or use an OpenGL extension such as ARB_vertex_program with the ARB_position_invariant option.

Den interessanten Bereich habe ich fett markiert. Frage, warum ist das so? Ich habe schon ein paar Mal in einigen Threads gelesen, dass die GPUs abhängig von der momentanen Last in den Chipbereichen unterschiedliche Ergebnisse ausgeben.
Bis jetzt habe ich das mal so hingenommen, aber jetzt interessiert es mich doch sehr.

cya
liquid

[Kant]

Das ist der Unterschied zwischen der Fixed-Function Pipe und der programmierbaren. Wenn du einen 2-Pass Effekt machst, und bei beiden Passes das Vertex-Programm verwendest bekommst du identische Ergebnisse. Bei 2xFixed ebenfalls, nur mixen gibt wirklich üble Fehler.
Edit : Die Fixed-Function ist ja festverdrahtet, und arbeitet entweder mit einer anderen Genauigkeit, oder kann aus anderen Gründen nicht mit der Transformation im Vertex-Prog imitiert werden.

[Demirug]

Merkwürdig ich dachte dieses Problem sei inzwischen gelöst.

Das es zu unterschiedlichen Ergebnissen kommt dürfte daher kommen das nVidia in den Vertexshadern immer noch ein paar Transitoren zusätzlich verbaut hat um Fixed T&L zu beschleunigen. Wenn also Fixed T&L benutzt wird ist die Positionsberechnung etwas anders und das führt dann zu minimalen Unterschieden.

Das mit der Last ist mir aber neu und habe ich so noch nicht gemerkt.

[ScottManDeath]

mit NV_vertex_program1_1 gibts die OPTION NV_position_invariant, damit wird sichergestellt das die position des vp mit der der FF-Pipe übereinstimmt. du darfst dann nich auf das o[HPOS] register zugreifen, und du hast 4 anweisungen weniger. für mehr details sieh e spec

[liquid]

Original geschrieben von ScottManDeath
mit NV_vertex_program1_1 gibts die OPTION NV_position_invariant, damit wird sichergestellt das die position des vp mit der der FF-Pipe übereinstimmt. du darfst dann nich auf das o[HPOS] register zugreifen, und du hast 4 anweisungen weniger. für mehr details sieh e spec
Jo, steht ja da auch. Aber das beantwortet natürlich nicht meine Frage, warum das denn so ist.

Thx@ Kant und Demirug: Das hört sich schon gut an. Jemand noch weitere Informationen?

cya
liquid

[Demirug]

Original geschrieben von ScottManDeath
mit NV_vertex_program1_1 gibts die OPTION NV_position_invariant, damit wird sichergestellt das die position des vp mit der der FF-Pipe übereinstimmt. du darfst dann nich auf das o[HPOS] register zugreifen, und du hast 4 anweisungen weniger. für mehr details sieh e spec

Ich habe das in letzter Zeit nicht mehr überprüft weil ich nur noch VS benutzte aber könnte es sein das man das bei DX automatisch aktiviert hat?

[Xmas]

Original geschrieben von liquid
Jo, steht ja da auch. Aber das beantwortet natürlich nicht meine Frage, warum das denn so ist.

Thx@ Kant und Demirug: Das hört sich schon gut an. Jemand noch weitere Informationen?

cya
liquid
Der Hinweis von ScottManDeath sagt eigentlich schon alles. Wenn ich das richtig verstanden habe, benutzt die FF-Pipeline zur Transformation vier DPH-Anweisungen (Homogeneous Dot Product) statt vier DP4-Anweisungen (Dot Product mit vier Komponenten)

DPH: a.x * b.x + a.y * b.y + a.z * b.z + b.w
DP4: a.x * b.x + a.y * b.y + a.z * b.z + a.w * b.w

DPH geht also implizit davon aus dass die w-Komponente eines Vektors 1 ist - was in dem Fall, dass man bei den Eckpunkten kein w verwendet auch zutrifft, denn 1 ist hier Defaultwert.

Vier DP4 brauchen 16 Multiplikationen und 12 Additionen, das bedeutet vier Takte. Vier DPH begnügen sich dagegen schon mit 12 Multiplikationen und 12 Additionen, was bei entsprechender Auslegung der Pipeline in 3 Takten zu schaffen ist.