Doom III nVidia "Treiberoptimierungen"

[Coda]

Hm mir is da was sehr seltsames aufgefallen, als ich bischen an der interaction.vfp auf meiner 6800 GT rumgespielt hab (timedemo demo001.demo)

interaction.vfp (orginal): 58fps
interaction.vfp (nur cubemap normalisierungen): 50,9fps
interaction.vfp (nur DP3/RCP/MUL norm.): 53,2fps
interaction.vfp (NV_fragment_program3 + NRM instruction): 53,3fps

Selbst die bei 16bit floats sonst so schnelle NRM instruction ist hier langsamer.
Da ist doch was faul!

[zeckensack]

Cache-Lokalität? ?(

[Coda]

Hm vielleicht, aber warum sollte NRM langsamer sein als ein Cube Map lookup?

[zeckensack]

Hm vielleicht, aber warum sollte NRM langsamer sein als ein Cube Map lookup?Vielleicht blockiert NRM da gerade eine Ausführungseinheit, die noch einen anderen Befehl hätte ausführen können, oder einen Crossbar-Kanal ...

Mir ist noch etwas unklar, was deine Tests jetzt genau machen. Der "Originalzustand" ist doch schon Normalisation mit Arithmetik, oder? Und AFAIK gibt's nur eine einzige (pro Shader). Ich bin da noch nicht richtig drin, da ich das Spiel noch nicht selber habe. Wäre schön, wenn du ein paar mehr Details zu den von dir vermessenen Shadern rausrücken könntest :)

[Coda]

Nein. Der Orginalzustand ist eine Normalisierung mit Arithmetik und eine per Cubemap.

Orginal:

!!ARBfp1.0
OPTION ARB_precision_hint_fastest;

# texture 0 is the cube map
# texture 1 is the per-surface bump map
# texture 2 is the light falloff texture
# texture 3 is the light projection texture
# texture 4 is the per-surface diffuse map
# texture 5 is the per-surface specular map
# texture 6 is the specular lookup table

# env[0] is the diffuse modifier
# env[1] is the specular modifier

TEMP light, color, R1, R2, localNormal, specular;

PARAM subOne = { -1, -1, -1, -1 };
PARAM scaleTwo = { 2, 2, 2, 2 };

# load the specular half angle first, because
# the ATI shader gives a "too many indirections" error
# if this is done right before the texture indirection

#-----------------
#TEX specular, fragment.texcoord[6], texture[0], CUBE;
#MAD specular, specular, scaleTwo, subOne;


# instead of using the normalization cube map, normalize with math
DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
#-----------------


#
# the amount of light contacting the fragment is the
# product of the two light projections and the surface
# bump mapping
#

# perform the diffuse bump mapping

#-----------------
TEX light, fragment.texcoord[0], texture[0], CUBE;
MAD light, light, scaleTwo, subOne;

# instead of using the normalization cube map, normalize with math
#DP3 light, fragment.texcoord[0],fragment.texcoord[0];
#RSQ light, light.x;
#MUL light, light.x, fragment.texcoord[0];
#-----------------

TEX localNormal, fragment.texcoord[1], texture[1], 2D;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;

# modulate by the light projection
TXP R1, fragment.texcoord[3], texture[3], 2D;
MUL light, light, R1;

# modulate by the light falloff
TXP R1, fragment.texcoord[2], texture[2], 2D;
MUL light, light, R1;

#
# the light will be modulated by the diffuse and
# specular surface characteristics
#

# modulate by the diffuse map and constant diffuse factor
TEX R1, fragment.texcoord[4], texture[4], 2D;
MUL color, R1, program.env[0];

# perform the specular bump mapping
DP3 specular, specular, localNormal;

# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;

# modulate by the constant specular factor
MUL R1, R1, program.env[1];

# modulate by the specular map * 2
TEX R2, fragment.texcoord[5], texture[5], 2D;
ADD R2, R2, R2;
MAD color, R1, R2, color;


MUL color, light, color;

# modify by the vertex color

MUL result.color, color, fragment.color;

# this should be better on future hardware, but current drivers make it slower
#MUL result.color.xyz, color, fragment.color;


END


NV_fragment_program2:

!!ARBfp1.0
OPTION ARB_precision_hint_fastest;
OPTION NV_fragment_program2;

# texture 0 is the cube map
# texture 1 is the per-surface bump map
# texture 2 is the light falloff texture
# texture 3 is the light projection texture
# texture 4 is the per-surface diffuse map
# texture 5 is the per-surface specular map
# texture 6 is the specular lookup table

# env[0] is the diffuse modifier
# env[1] is the specular modifier

TEMP light, color, R1, R2, localNormal, specular;

PARAM subOne = { -1, -1, -1, -1 };
PARAM scaleTwo = { 2, 2, 2, 2 };

# load the specular half angle first, because
# the ATI shader gives a "too many indirections" error
# if this is done right before the texture indirection

#-----------------
#TEX specular, fragment.texcoord[6], texture[0], CUBE;
#MAD specular, specular, scaleTwo, subOne;


# instead of using the normalization cube map, normalize with math
#DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
#RSQ specular, specular.x;
#MUL specular, specular.x, fragment.texcoord[6];
NRM specular, fragment.texcoord[6];
#-----------------


#
# the amount of light contacting the fragment is the
# product of the two light projections and the surface
# bump mapping
#

# perform the diffuse bump mapping

#-----------------
#TEX light, fragment.texcoord[0], texture[0], CUBE;
#MAD light, light, scaleTwo, subOne;

# instead of using the normalization cube map, normalize with math
#DP3 light, fragment.texcoord[0],fragment.texcoord[0];
#RSQ light, light.x;
#MUL light, light.x, fragment.texcoord[0];
NRM light, fragment.texcoord[0];
#-----------------

TEX localNormal, fragment.texcoord[1], texture[1], 2D;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;

# modulate by the light projection
TXP R1, fragment.texcoord[3], texture[3], 2D;
MUL light, light, R1;

# modulate by the light falloff
TXP R1, fragment.texcoord[2], texture[2], 2D;
MUL light, light, R1;

#
# the light will be modulated by the diffuse and
# specular surface characteristics
#

# modulate by the diffuse map and constant diffuse factor
TEX R1, fragment.texcoord[4], texture[4], 2D;
MUL color, R1, program.env[0];

# perform the specular bump mapping
DP3 specular, specular, localNormal;

# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;

# modulate by the constant specular factor
MUL R1, R1, program.env[1];

# modulate by the specular map * 2
TEX R2, fragment.texcoord[5], texture[5], 2D;
ADD R2, R2, R2;
MAD color, R1, R2, color;


MUL color, light, color;

# modify by the vertex color

MUL result.color, color, fragment.color;

# this should be better on future hardware, but current drivers make it slower
#MUL result.color.xyz, color, fragment.color;


END


Jetzt ersetz ich mal noch nur das eine DP3/RCP/MUL, wenn's dann auch langsamer ist, dürfte die Sache eigentlich klar sein.

[Coda]

Genau das gleiche. Auch ungefähr 53fps. Das stinkt gewaltig :)

[zeckensack]

"NRM" ist volle Präzision. Versuch's mal mit "NRMH".

[Coda]

Ne, das gibt's gar nicht bei NV_fragment_program2.

Außerdem "OPTION ARB_precision_hint_fastest;"

[nggalai]

Eventuell hebeln deine Änderungen aber auch den "Shader-Optimizer" aus. Man beachte die " ".

93,
-Sascha.rb

[Xmas]

Die Originalversion (mit _pp von Hand gesetzt) ist laut NVidia FX Composer die schnellste (10/19/28 Takte auf NV40/35/30 respektive).
Die eine Cube Map Normalization durch NRM zu ersetzen bringt nichts und kostet einen oder zwei Takte auf NV3x. Beides mit Cube Map zu machen kostet 2 Takte auf NV40.

Was soll eigentlich diese SubOne und ScaleTwo-Verschwendung? Das kann man auch in die X- und Y-Komponente packen. Empfiehlt sich in PS2.0 sogar, weil man keine zwei Const-Register gleichzeitig benutzen darf.

[Coda]

Die eine Cube Map Normalization durch NRM zu ersetzen bringt nichts und kostet einen oder zwei Takte auf NV3x.
Ja, aber nicht auf NV40. Wieso ist es dann gut 5fps langsamer?

Ich hab' ja sogar nur:
DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
mit
NRM specular, fragment.texcoord[6];
ersetzt.

Und das darf IMHO nicht langsamer sein.

[zeckensack]

Ne, das gibt's gar nicht bei NV_fragment_program2.Doch, gibt's. Hab' eben nochmal nachgesehen, und war auch schwer zu finden, aber in einer ziemlich langen Tabelle hier (http://oss.sgi.com/projects/ogl-sample/registry/NV/fragment_program2.txt) steht drin, dass NRM mit Präzisions-Modifikatoren versehen werden darf. Was meinst du, warum meine Antwort so lange gedauert hat? :)
Außerdem "OPTION ARB_precision_hint_fastest;"Evtl beißt sich das auch ... kA.

Btw, NV_texture_expand_normal (http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_expand_normal.txt) anstelle der MAD x,x,2,-1 dürfte auch noch einen kleinen Gewinn bringen. Kannst du leider nicht alleine über den Shader machen, dafür müsstest du schon an den Engine-Code ...

[Coda]

Also ich teste jetzt nochmal mit NRMH, aber da beißt sich IMHO gar nix.

[Gast]

Das hat zwar jetzt nix mit dem Thema zu tun aber es ist mal wieder typisch das auf NVIDIA rumgehackt wird. Wie die Performance-Steigerung im ATI D3 Hotfix Treiber zustande kommt, hat noch niemand wirklich untersucht. Wenn NV einen speziellen D3 Beta Treiber released hätte, wäre das Geschrei wieder groß gewesen.

Ich kann zwar gut verstehen das NV einiges an Vertrauen eingebüsst hat durch so einige Aktionen, aber ATI ist eigentlich kein deut ehrlicher oder sauberer.

Markus

[Coda]

Hä? Rumgehacke? Mich hat's nur gewundert, muss man einem immer gleich das Wort im Mund verdrehen?

Ich wollte nur klarstellen, das der "richtige" Shaderoptimierer wohl noch nicht so weit ist und nVidia da wohl manuell ersetzt...
Solang die Bildqualität nicht leidet isses mir egal.

NRMH ist übrigens genauso schnell (53fps)

[Asmodeus]

Ja, aber nicht auf NV40. Wieso ist es dann gut 5fps langsamer?

Ich hab' ja sogar nur:
DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
mit
NRM specular, fragment.texcoord[6];
ersetzt.

Und das darf IMHO nicht langsamer sein.

Aber war das nicht genau der Sachverhalt, den Nvidia in einem ihrer Performance Tipps mit veröffentlicht hatte, dass NRM eben doch langsamer ist als die andere Methode? Ich schau nochmal nach, eventuell verwechsel ich auch was.

Gruss, Carsten.

[Coda]

Aus nem nVidia PDF:
Use NRM instruction for normalizing vectors,
rather than DP3/RSQ/MUL
Very fast for half-precision data
Sonst hätte die neue Instruction auch nicht wirklich Sinn gemacht.

[Quasar]

Tjo, da haben Demirug und ich gestern auch lange dran rumgerätselt.

Eine (ganz simple) Shaderersetzung scheint's aber nicht unbedingt zu sein...

[Quasar]

Aber war das nicht genau der Sachverhalt, den Nvidia in einem ihrer Performance Tipps mit veröffentlicht hatte, dass NRM eben doch langsamer ist als die andere Methode? Ich schau nochmal nach, eventuell verwechsel ich auch was.

Gruss, Carsten.

In D3D kann der Shadercompiler die drei Anweisungen schon kollabieren (siehe mDolencs Fillrate-Tester).

[Coda]

Ich schätze das es nach dem parsen passiert, d.h. im intermediate code.

[zeckensack]

<...> da beißt sich IMHO gar nix.Ich meinte, dass es sich evtl beisst, dass du 1)den Code mit !!ARBfp1.0 einleitest, 2)eine ARB-Option drin hast, 3)NVIDIA-spezifische Instruktionsformate ("NRMH") nutzt. Vielleicht kommt der Compiler da durcheinander. War auch nur so eine Idee.
*schulterzuck*

XMas Idee war IMO auch nicht übel. Ich packe solche Konstanten (kleine Zweierpotenzen) immer direkt "inline" in den Code, weil ich darauf baue dass die Hardware evtl noch nativ irgendwelche Modifier unterstützt, und der Compiler dann eher erkennt, dass er sowas komplett rausschmeissen kann.

[Asmodeus]

Aus nem nVidia PDF:

Sonst hätte die neue Instruction auch nicht wirklich Sinn gemacht.

Ok, hast recht, hab ich verwechselt. Und aus der leichten Ungenauigkeit von NRM kann ja eigentlich auch kein Geschwindigkeitsverlust resultieren.

Gruss, Carsten.

[Coda]

Selbst wenn ich kein NV_fragment_program2 benütze und 2x Arithmetik oder 2xCube einsetzte darf es nicht einfach um 5fps abfallen.

[Xmas]

XMas Idee war IMO auch nicht übel. Ich packe solche Konstanten (kleine Zweierpotenzen) immer direkt "inline" in den Code, weil ich darauf baue dass die Hardware evtl noch nativ irgendwelche Modifier unterstützt, und der Compiler dann eher erkennt, dass er sowas komplett rausschmeissen kann.
Eben. Da die TMU des NV40 _bx2 kann und arbitrary Swizzle vorhanden ist, ist dieser Teil
TEX localNormal, fragment.texcoord[1], texture[1], 2D;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
im besten Fall nur eine tex_bx2 Instruktion. Später kann man dann localNormal.wyz verwenden.


Ich habs jetzt auch nach langem Rumprobieren nicht geschafft, unter 10 Takte zu kommen. 9 sind allerdings Minimum, drunter gehts wirklich nicht.