Auswirkungen von SM3 auf Computerspiele. Wann und Wie

[Demirug]

Da sich diese Diskussion ja inzwischen wieder über alle möglichen Threads verteilt machen wir hier mal einen Sammelthread für diese Diskussion auf.

[q@e]

OK, dann hier nochmal:

Original geschrieben von Mr. Lolman
Häng dich bloss nicht an den längeren Shadern auf. Die UE3 Denmo hatte bloss 50-200 Instructionen/Shader und trotzdem hats stellenweise geruckelt.


Und jetzt stell' dir mal ganz schlimme Shader vor, die ans Instruktions-Limit von 512 auf der X800 herangehen - wie muss das erst ruckeln?

[aths]

Mich interessiert eher die Leistung der kleinen NV40-Ableger. Wenn diese so bescheiden ist, wie damals bei der 5200 (und leider auch bei der 5600), wird das natürlich nichts mit vernünftiger Verbreitung von 3.0.

[Ailuros]

Original geschrieben von aths
Mich interessiert eher die Leistung der kleinen NV40-Ableger. Wenn diese so bescheiden ist, wie damals bei der 5200 (und leider auch bei der 5600), wird das natürlich nichts mit vernünftiger Verbreitung von 3.0.


Uhhmmm....vorzeitiges und leicht gewagtes ja....:-(

[Crushinator]

Original geschrieben von q@e
(...) Und jetzt stell' dir mal ganz schlimme Shader vor, die ans Instruktions-Limit von 512 auf der X800 herangehen - wie muss das erst ruckeln? Mit eigenen Augen gesehen, wenn auch (aus Gamer Sicht) nicht repräsentativ, würde ich nicht mehr von FPS sprechen, sondern SPF. :D

[Demirug]

Original geschrieben von Crushinator
Mit eigenen Augen gesehen, wenn auch (aus Gamer Sicht) nicht repräsentativ, würde ich nicht mehr von FPS sprechen, sondern SPF. :D

Hängt im wesentlichen vom Overdraw ab. Ohne Overdraw sollte man noch im FPS bereich liegen.

[aths]

Original geschrieben von Crushinator
Mit eigenen Augen gesehen, wenn auch (aus Gamer Sicht) nicht repräsentativ, würde ich nicht mehr von FPS sprechen, sondern SPF. :D Wie lange würde der NV40 für 512 Anweisungen brauchen, wenn jedes Pixel damit geshadet wird?

Annahmen:

- 400 MHz
- Effektiv 2 Instruktionen pro Takt (was leicht pessimistisch ist)
- 16 Pipes (Annahme: immer volle Quads, was leicht optimistisch ist.)

Wären 25 Megapixel pro Sekunde. Bei 1024x768 gut 30 fps.

edit: Ach ja, Early-Z-Pass vorausgesetzt, sowie dass jener keine Performance kostet (was er aber tut.)

[Crushinator]

Ihr habt Beide mit Sicherheit recht, deshalb schrieb ich, daß es nicht ganz repräsentativ sei, weil z.B. der NV40 in dem besonderen Falle ca. doppelt soviele Sekunden für ein Frame braucht.

/edit: Tippfehl0r

[Ailuros]

Original geschrieben von Demirug
Hängt im wesentlichen vom Overdraw ab. Ohne Overdraw sollte man noch im FPS bereich liegen.

Sind die Overdraw-Resultate von synthetischen Applikationen (wie z.b. GL_XTREME) nicht ein bisschen optimistisch im Vergleich zu wahrem throughput auf R420? (ja das ist schon wieder leicht OT).

[Ailuros]

edit: Ach ja, Early-Z-Pass vorausgesetzt, sowie dass jener keine Performance kostet (was er aber tut.)

Nicht nur lange Shader, sondern wenn man auch nicht front to back sortieren kann. Haarspalterei, aber ein langer Shader muss nicht unbedingt nicht front to back sortierbar sein.

[q@e]

Original geschrieben von Crushinator
Mit eigenen Augen gesehen, wenn auch (aus Gamer Sicht) nicht repräsentativ, würde ich nicht mehr von FPS sprechen, sondern SPF. :D

Und nun stelle dir, auch wenn du nicht Mr.Lolman bist, einen Chip vor, der nach ein bsw. 15 Instruktionen erkennt, daß er einen großen Branch überspringen kann und erst bei Instruktion 314 weitermachen muss oder gar das Pixel komplett verwerfen kann.

[Gast]

Original geschrieben von aths
Mich interessiert eher die Leistung der kleinen NV40-Ableger. Wenn diese so bescheiden ist, wie damals bei der 5200 (und leider auch bei der 5600), wird das natürlich nichts mit vernünftiger Verbreitung von 3.0.

Nein aths, es zaehlt hier nur die Feature-Liste und nicht die Leistung. Frag mal Demirug, der wird dir das bestaetigen.

[Crushinator]

Original geschrieben von q@e
Und nun stelle dir, auch wenn du nicht Mr.Lolman bist, einen Chip vor, der nach ein bsw. 15 Instruktionen erkennt, daß er einen großen Branch überspringen kann und erst bei Instruktion 314 weitermachen muss oder gar das Pixel komplett verwerfen kann. Wenn er für's Erkennen und das Überspringen selbst nicht länger oder eben so lang bräuchte als für's Ausführen der Instruktionen, wäre der Chip in der Tat sehr interessant.

[Coda]

sUnd nun stelle dir, auch wenn du nicht Mr.Lolman bist, einen Chip vor, der nach ein bsw. 15 Instruktionen erkennt, daß er einen großen Branch überspringen kann und erst bei Instruktion 314 weitermachen muss oder gar das Pixel komplett verwerfen kann.
Das kann aber auch schon CineFX 1.0, ich frage mich warum jetzt die Diskussion darüber so aufflammt.

[TheCounter]

Um gleich mal das Beispiel Farcry vorwegzunehmen, der Shadermod wird so wie es aussieht (zu unrecht!) nur auf PS3.0 Karten laufen, was ich nicht verstehe da jede PS2.0 Karte die gleichen Effekte darstellen kann, was ja schon durch die Community bewießen wurde. Da zahlt Nvidia wohl kräftig ;)

Und wer sagt durch PS3.0 gibts bessere Bildqualität, der muss auch sagen das es durch 3dc bessere Bildqualität gibt.

[Ailuros]

Und wer sagt durch PS3.0 gibts bessere Bildqualität, der muss auch sagen das es durch 3dc bessere Bildqualität gibt.

Schlechter Vergleich; 3dc ist eigentlich nur eine Variante von DXT5 quasi und kann leicht in einem refresh chip implementiert werden; hingegen fuer SM3.0 braucht man radikale Architektur-Aenderungen.

Was und wie alles moeglich ist mit SM3.0 werden wir wohl dann schon in der Zukunft sehen und natuerlich auch nach dem Erscheinen von R500. Bis dahin kann man sich gerne dem hier nach richten:

http://users.otenet.gr/~ailuros/SM3.jpg

Braucht man bestimmte Erlaeuterungen dafuer?

[Gast]

Original geschrieben von Crushinator
Wenn er für's Erkennen und das Überspringen selbst nicht länger oder eben so lang bräuchte als für's Ausführen der Instruktionen, wäre der Chip in der Tat sehr interessant.

Was heisst hier waere?
Glaubst du allen Ernstes, ein Branch taete laenger dauern als 300 Instruktionen zu ueberspringen??

[Crushinator]

Was ich glaube ist doch nicht wirklich wichtig, lieber ow. Denn wir sind a) im Sepkulationsforum und b) könnte doch jemand anderer aus meinem wäre bei Bedarf ein ist machen, wenn er die Zeit, die Mitteln dazu und das Interesse daran hat. :)

[Ailuros]

Original geschrieben von Crushinator
Was ich glaube ist doch nicht wirklich wichtig, lieber ow. Denn wir sind a) im Sepkulationsforum und b) könnte doch jemand anderer aus meinem wäre bei Bedarf ein ist machen, wenn er die Zeit, die Mitteln dazu und das Interesse daran hat. :)

Das wird aber dann ein nicht nur schwer machbarer sondern auch ein sehr verkorkster Fall wenn moeglich. Optimal wuerde es auf keiner Architektur laufen IMHO.

[Benedikt]

Original geschrieben von Gast
Was heisst hier waere?
Glaubst du allen Ernstes, ein Branch taete laenger dauern als 300 Instruktionen zu ueberspringen??

Wie viel (greifbaren) Performance-Hit kann man denn Branching zuordnen?
Zahlt es sich jetzt aus, dies zu verwenden, oder ist es wirklich performancemäßig so katastrophal schlecht, dass die Shader eh' wieder in einem Stück abgearbeitet werden?

Mich würde jetzt einfach mal nur interessieren, ob das Feature in der jetzt verfügbaren Hardwaregeneration nützlich ist, oder eben ein reines Technologie-Feature ist.

MFG,

B. W.

[aths]

Original geschrieben von Gast
Was heisst hier waere?
Glaubst du allen Ernstes, ein Branch taete laenger dauern als 300 Instruktionen zu ueberspringen?? Eine volle Branch Control Structure kostet minimal 6, meistens 8 Takte. Kleiner Nachteil: Wenn von 4096 Pixeln nur ein einziges den anderen Branch braucht, führt NV40 für alle diese Pixel beide Zweige aus. (So sieht es zumindest aus, nach dem was ich weiß. Vielleicht sind es auch nur 1024 Pixel, vielleicht ist es eine Zahl dazwischen.)

[Gast]

Original geschrieben von aths
Eine volle Branch Control Structure kostet minimal 6, meistens 8 Takte. Kleiner Nachteil: Wenn von 4096 Pixeln nur ein einziges den anderen Branch braucht, führt NV40 für alle diese Pixel beide Zweige aus. (So sieht es zumindest aus, nach dem was ich weiß. Vielleicht sind es auch nur 1024 Pixel, vielleicht ist es eine Zahl dazwischen.)

Na und?
Duerfte immer noch wesentlich schneller sein als ein R420, der ebenfalls beide Zweige komplett fuer alle Pixel berechnen muss und erst danach entscheidet, welche Ergebnisse davon er denn braucht.

[Gast]

Original geschrieben von TheCounter
Um gleich mal das Beispiel Farcry vorwegzunehmen, der Shadermod wird so wie es aussieht (zu unrecht!) nur auf PS3.0 Karten laufen, was ich nicht verstehe da jede PS2.0 Karte die gleichen Effekte darstellen kann, was ja schon durch die Community bewießen wurde. Da zahlt Nvidia wohl kräftig ;)

Und wer sagt durch PS3.0 gibts bessere Bildqualität, der muss auch sagen das es durch 3dc bessere Bildqualität gibt.

Da habe ich aber auch schon anderes von gehört, nämlich das die Effekte auch für die anderen Karten verfügbar sein werden. Aber gut, lassen wir uns überraschen, wenn der Patch raus ist :)

[aths]

Original geschrieben von Gast
Na und?
Duerfte immer noch wesentlich schneller sein als ein R420, der ebenfalls beide Zweige komplett fuer alle Pixel berechnen muss und erst danach entscheidet, welche Ergebnisse davon er denn braucht. So eine Entscheidung kostet afaik 1 Takt, (vielleicht 2.) Das einfachste Branching auf NV40 ist nicht für unter 4 Takte zu kriegen. Bei kurzen Zweigen ist das auf dem NV40 also langsamer, als CMP zu nutzen. Sofern große Flächen (mehrere tausend Pixel) den gleichen Zweig benutzen, kann der NV40 Performancevorteile gewinnen.

[Demirug]

Original geschrieben von Gast
Da habe ich aber auch schon anderes von gehört, nämlich das die Effekte auch für die anderen Karten verfügbar sein werden. Aber gut, lassen wir uns überraschen, wenn der Patch raus ist :)

Die erste Frage wird dann IMHO sein ob es überhaupt auf irgendeiner Karte was von den Effekten zu sehen geben wird.

Vielleicht bin ich aber auch nur zynisch. Aber seit der angeblichen NV40/SM 3.0 unterstützung mit Patch 1.1 bin ich vorsichtig geworden. Das was ich in den letzten Tage sehen musste hat meine Meinung zu Far Cry/Cry Tek auch nicht unbedingt verbessert.

[zeckensack]

Original geschrieben von aths
So eine Entscheidung kostet afaik 1 Takt, (vielleicht 2.)Tendenziell weniger :)
CMP ist eine "ganz normale" ALU-Instruktion, die ebenso parallelisierbar ist wie ADD. Wenn du einer Architektur zusprichst, bis zu 4 ALU-Ops pro Takt (pro "Pipe") auszuführen, dann gilt das auch für CMP.

... wobei praktisch noch -- in beiden Fällen -- die Limitationen der einzelnen ALUs zu berücksichtigen sind. Nicht jede ALU kann MUL ausführen <=> nicht jede ALU kann CMP ausführen.

[xL|Sonic]

In irgendeinem Forum gibts nen thread, wo nur far cry screenshots gepostet wurden und darunter warren auch einige mit dem nv40 und dx 9.0c und da hat man die offset-mapping effekte schon gesehen, weiss nur leider nicht mehr wo das war :(

[deekey777]

Original geschrieben von seahawk
Wobei es eigentlich auch keine Leistung ist 3.0 zu unterstützen. Wenn die Shader in HLSL vorliegen ist das eine sehr geringfügige Aufgabe, da die HAuptarbeit der Compiler übernimmt. Deswegen halte ich die Liste der kommenden 3.0 Spiele auch für sehr glaubwürdig.
Ob sich diese Versionen, dann deutlich oder auch nur sichtbar von der 2.0 Version unterscheidet, dass wird eine Frage sein.

Wenn z.B. der NV treiber per Recomplier in der LAge wäre bestimme 2.0 Funktionen in 3.0 umzuwandeln, dann könnte sie auch in nicht 3.0 Spielen einen Vorteil erzielen. Vielleicht tut der neue Treiber das auch schon.

Ob es eine grosse Leistung ist, SM 3.0 in HL2 einzubauen oder nicht, ist egal - VALVe wird auf jeden Fall auf R520 warten (müssen).

[TheCounter]

Original geschrieben von Valmar
In irgendeinem Forum gibts nen thread, wo nur far cry screenshots gepostet wurden und darunter warren auch einige mit dem nv40 und dx 9.0c und da hat man die offset-mapping effekte schon gesehen, weiss nur leider nicht mehr wo das war :(

Wenn du willst mach ich dir Screenshots davon (Offset-Mapping), und zwar mit meiner Radeon 9800np, geht wunderbar und ohne irgendwelche Probleme.

@Demirug

Was hast du denn in den letzten Tagen so gesehen?

[seahawk]

Original geschrieben von deekey777
Ob es eine grosse Leistung ist, SM 3.0 in HL2 einzubauen oder nicht, ist egal - VALVe wird auf jeden Fall auf R520 warten (müssen).

Dann macht sich Valve und ATI imho endgültig lächerlich.

[ow]

Original geschrieben von aths
So eine Entscheidung kostet afaik 1 Takt, (vielleicht 2.) Das einfachste Branching auf NV40 ist nicht für unter 4 Takte zu kriegen. Bei kurzen Zweigen ist das auf dem NV40 also langsamer, als CMP zu nutzen. Sofern große Flächen (mehrere tausend Pixel) den gleichen Zweig benutzen, kann der NV40 Performancevorteile gewinnen.


Man sollte entsprechende Techniken immer nur dort einsetzen wo sie was nutzen.
Ich habe keine Zweifel daran, dass sich 3.0 Shader schreiben lassen, die dem NV40 gar nicht schmecken und wo man mit 2.0/2.x besser bedient ist.

[Demirug]

Original geschrieben von TheCounter
@Demirug

Was hast du denn in den letzten Tagen so gesehen?

Verstösse gegen Optimierungsregeln (sowohl von ATI wie auch nVidia) am laufenden Band. Details würde hier aber zu weit führen weil Offtopic.

[TheCounter]

Original geschrieben von Demirug
Verstösse gegen Optimierungsregeln (sowohl von ATI wie auch nVidia) am laufenden Band. Details würde hier aber zu weit führen weil Offtopic.

Könntest du nen neuen Thread bezüglich dieses Themas aufmachen oder mir das ganze mal per PM schicken (Die Details)? Würde mich sehr interessieren.

Okay genug OT ;)

[deekey777]

Original geschrieben von seahawk
Dann macht sich Valve und ATI imho endgültig lächerlich.

Jein. HL2 wird mit hoher Wahrscheinlichkeit etwas mehr "SM 3.0" haben als Far Cry und die restlichen Alibi-SM3.0-Spiele - da wird eine R520/NV50 bzw. deren Leistung vorausgesetzt.
Wozu braucht man heute SM 3.0, wenn es die heutige SM 3.0 HW überfordern würde?

[Demirug]

Original geschrieben von deekey777
Jein. HL2 wird mit hoher Wahrscheinlichkeit etwas mehr "SM 3.0" haben als Far Cry und die restlichen Alibi-SM3.0-Spiele - da wird eine R520/NV50 bzw. deren Leistung vorausgesetzt.
Wozu braucht man heute SM 3.0, wenn es die heutige SM 3.0 HW überfordern würde?

Aufgrund desen was von HL2 bekannt ist würde ich mal primär das statische Branching als gutes Mittel sehen. Im Moment (SM2) mahct man das ja über die CPU und so werden aus einem HLSL-PS ganz schnell 2048 Shader.

Im Vertexshader könnte unter umständen noch das dynamische Branching für die unterschiedlichen Lichtquellen interesant sein.

[LovesuckZ]

Original geschrieben von deekey777
Wozu braucht man heute SM 3.0, wenn es die heutige SM 3.0 HW überfordern würde?

Und wieso sollte das in Zukunft nicht so sein?
Agesehen davon, dass ich gern wissen moechte, wie du darauf kommst.

[deekey777]

Original geschrieben von LovesuckZ
Und wieso sollte das in Zukunft nicht so sein?
Agesehen davon, dass ich gern wissen moechte, wie du darauf kommst.

Glaskugel...

[seahawk]

Original geschrieben von deekey777
Jein. HL2 wird mit hoher Wahrscheinlichkeit etwas mehr "SM 3.0" haben als Far Cry und die restlichen Alibi-SM3.0-Spiele - da wird eine R520/NV50 bzw. deren Leistung vorausgesetzt.
Wozu braucht man heute SM 3.0, wenn es die heutige SM 3.0 HW überfordern würde?

So wie ich bis jetzt die Hl2 Engine verstehe, nutzt sie die CPU um zu entscheiden welcher Shader genutzt wird, bzw. rechnet erst alls und verwirft dann den Überschuss. Da könnte static Branching schon helfen.

Allerdings bin ich noch nicht weit mit dem Verständnis der HL2 Engine - liege also möglicherweise falsch.

[Winter[Raven]]

Original geschrieben von deekey777
Glaskugel...

Welch ein schönes Posting ... dieser strotzt gerade so vor "SINN".:balla:

//Edit:

@ Mods ... ja genauso wie meiner aber nunja :)

[Demirug]

Original geschrieben von seahawk
So wie ich bis jetzt die Hl2 Engine verstehe, nutzt sie die CPU um zu entscheiden welcher Shader genutzt wird, bzw. rechnet erst alls und verwirft dann den Überschuss. Da könnte static Branching schon helfen.

Allerdings bin ich noch nicht weit mit dem Verständnis der HL2 Engine - liege also möglicherweise falsch.

Die CPU wählt aufgrund von jeweils einigen Flags (können auch ein paar mehr sein) den passenden Shader. Da es für jede Flagkombination einen Shader gibt kommen auch die vielen hundert Schader zusammen.

Wie schon erkannt ein gutes Einsatzgebiet für static Branching.

[ShadowXX]

Original geschrieben von deekey777
Jein. HL2 wird mit hoher Wahrscheinlichkeit etwas mehr "SM 3.0" haben als Far Cry und die restlichen Alibi-SM3.0-Spiele - da wird eine R520/NV50 bzw. deren Leistung vorausgesetzt.
Wozu braucht man heute SM 3.0, wenn es die heutige SM 3.0 HW überfordern würde?

Gott sei Dank hat so niemand argumentiert, als es damals bei ATi / nV darum ging ob man denn SM2.0 einbaut...

Dann hätten wir nämlich heute noch PS1.3...

Es ist doch völlig normal, das neue Features erst mal brach liegen...

Am Anfang des r3x0 gabs bis auf 2 oder 3 Techdemos auch nix für ATIs SM2.0...hat auch nicht wirklich jemanden gestört.
Der r3x0 wurde zum grössten Teil wegen seines sehr guten AAs und auch wegen seines AF-Speeds gekauft...weniger weil er SM2.0 hatte (zumindest am Anfang seiner Laufbahn)

Der nv40 hat genaug PS.2x Speed und als Bonus noch SM3.0.

Wenn es zu seinen Lebzeiten nicht gebraucht wird..dann eben nicht..falls doch...schön für die nv40 Besitzer.

Es wird wirklich so getan, als wenn SM3.0 was schlechtes sei und die Performance der gesamten nv40 in Grund und Boden zieht..

Wie aths schon öfter erwähnte bestehen die neuen Features des nv40 aus mehr als nur PS3.0...(bzw. SM3.0, der VS3.0 wird ja gerne übergangen).

[Jesus]

Original geschrieben von q@e
OK, dann hier nochmal:



Und jetzt stell' dir mal ganz schlimme Shader vor, die ans Instruktions-Limit von 512 auf der X800 herangehen - wie muss das erst ruckeln?

gar nicht da die im F Buffer gecacht werden können :) theroretisch.

[q@e]

Original geschrieben von Jesus
gar nicht da die im F Buffer gecacht werden können :) theroretisch.

Nein, Jesus.

An das Limit herankommen heißt nicht, es zu überschreiten.

[deekey777]

Original geschrieben von ShadowXX
Es ist doch völlig normal, das neue Features erst mal brach liegen...

Der nv40 hat genaug PS.2x Speed und als Bonus noch SM3.0.


Genau das meine ich, nur bringt dieser Bonus relativ wenig, wenn echte SM 3.0 Spiele kommen, bis dahin ist die NV40 die Grafikkarte überhaupt. Zum Zeitpunkt, wenn "echte" SM 3.0 Spiele kommen, wird die NV40 die Basis für diese Spiele darstellen.


Original geschrieben von ShadowXX
Wenn es zu seinen Lebzeiten nicht gebraucht wird..dann eben nicht..falls doch...schön für die nv40 Besitzer.

Schlecht für R420(+ Refresh)-Besitzer -> blanker Neid ;(
Und das wird bestimmt in den nächsten Monaten eintreten; die Möglichkeit, diese Spielereien auch für die R420er umzusetzen, spielt hier keine Rolle. Wie ich schon in einem der x Threads sagte: Man braucht in ein Spiel nur etwas einzubauen, was die R420 nicht kann, das würde schon ausreichen.

Original geschrieben von ShadowXX
Es wird wirklich so getan, als wenn SM3.0 was schlechtes sei und die Performance der gesamten nv40 in Grund und Boden zieht...

Es ist auch falsch SM 3.0 als ganzes nur auf NV40 zu übertragen, ohne im Hinterkopf den Gedanken zu haben, dass auch die NV50/R520 auch SM 3.0 haben werden - nur mit sehr hoher Wahrscheinlichkeit viel schneller.

[Jesus]

im übrigen ist 512 ein theoretisches Limit , da wohl kaum ein shader 512 gleiche ( z.b. ALU ) anweisungen benutzen wird und der R420 ja bekanntlich die magischen 1536 "gleichzeitig" berechnen kann.

Für nen normalen shader mit 512 befehlen wird das also etwa die 3fache ausführungsgeschwindigkeit bedeuten da er ALU , FPU und textures absolut parallel berechnen kann. ( vorrausgesetzt alle kommen gleich oft vor :) )

[Jesus]

vorrausgesetzt das ganze wird von nem anständigen precomiler passend vorsortiert , aber da tut sich ja im moment noch einiges in den Cats ( Stichwort 4.7 beta :) ) aber genug des OTs ...

[q@e]

Original geschrieben von Jesus
im übrigen ist 512 ein theoretisches Limit , da wohl kaum ein shader 512 gleiche ( z.b. ALU ) anweisungen benutzen wird und der R420 ja bekanntlich die magischen 1536 "gleichzeitig" berechnen kann.

Für nen normalen shader mit 512 befehlen wird das also etwa die 3fache ausführungsgeschwindigkeit bedeuten da er ALU , FPU und textures absolut parallel berechnen kann. ( vorrausgesetzt alle kommen gleich oft vor :) )

Nein, Jesus.

ATi rechnet nur ihre INstruktionen als 3+1 Vector und Textur aus.
Das Limit bleibt weiterhin bei 512 Instruktionsslots für einen DX9-Shader.

Außerdem hat das absolut gar nichts mit meiner Aussage von weiter oben zu tun.

[Jesus]

Original geschrieben von q@e
Nein, Jesus.

ATi rechnet nur ihre INstruktionen als 3+1 Vector und Textur aus.
Das Limit bleibt weiterhin bei 512 Instruktionsslots für einen DX9-Shader.


0h je...

das hab ich auch gar nicht bestritten !:chainsaw:

[LovesuckZ]

Original geschrieben von Jesus
im übrigen ist 512 ein theoretisches Limit , da wohl kaum ein shader 512 gleiche ( z.b. ALU ) anweisungen benutzen wird und der R420 ja bekanntlich die magischen 1536 "gleichzeitig" berechnen kann.

Unter SM2.x gibt es ein Anweisunglimit von 512. Dabei ist egal, ob die Anweisung mathematischer und texturischer Natur sind oder gemischt..

Für nen normalen shader mit 512 befehlen wird das also etwa die 3fache ausführungsgeschwindigkeit bedeuten da er ALU , FPU und textures absolut parallel berechnen kann. ( vorrausgesetzt alle kommen gleich oft vor :) )

Trotzdem muss der r420 512 Anweisungen durchlaufen lassen. Das er dabei bei mathematischen Anweisungen schneller ist, liegt an den erweiterten Einheiten.

[aths]

Original geschrieben von Jesus
gar nicht da die im F Buffer gecacht werden können :) theroretisch. Kann das in DirectX genutzt werden, um das Maximum an 512 Instruktionen zu überschreiten? Soweit ich informiert bin, ist das nicht der Fall.

[aths]

Original geschrieben von deekey777
Wozu braucht man heute SM 3.0, wenn es die heutige SM 3.0 HW überfordern würde? Man muss ja nicht jedes 3.0-Feature sofort benutzen.

[aths]

Original geschrieben von Jesus
im übrigen ist 512 ein theoretisches Limit , da wohl kaum ein shader 512 gleiche ( z.b. ALU ) anweisungen benutzen wird und der R420 ja bekanntlich die magischen 1536 "gleichzeitig" berechnen kann. Nein.

Der R420 kann nur bestimmte Befehle in einen Takt bündeln. Er kann, sofern man MAD-Befehle (bis maximal 3 Komponenten), SFUs und TEX-Ops jeweils gleich häufig vorkommen, theoretisch jeweils 512 solcher Instruktionen ausführen. Praktisch kann er das aus mehreren Gründen nicht. Einer davon ist, dass MAD-Operationen am häufigsten sind. Der zweite ist, dass DirectX das SM 2.x auf 512 Instruktionen begrenzt. Ich wüsste nicht, dass in 9.0c das 2.x-Maximum (und damit 3.0-Minimum) angehoben wurde.

Original geschrieben von Jesus
Für nen normalen shader mit 512 befehlen wird das also etwa die 3fache ausführungsgeschwindigkeit bedeuten da er ALU , FPU und textures absolut parallel berechnen kann. ( vorrausgesetzt alle kommen gleich oft vor :) ) Wenn du konstruierten Fälle nimmst, kann eine NV40-Pipe 4 (oder sogar 5, das versuche ich noch herauszukriegen) Instruktionen gleichzeitig ausführen.

[aths]

Original geschrieben von Tigerchen
[COLOR="#000088"]
Mal ne Frage aths. In der aktuellen PCGH ist auf Seite 138/139 so einiges aufgeführt was lange Shader bzw. Shader mit Sprüngen als nicht ganz unproblematisch erscheinen läßt. Hast du die Zeitung zur Hand? Nein.
Original geschrieben von Tigerchen
Was hälst du davon?Im Artikel an dem ich gerade arbeite, wird die Vermutung geäußert, dass NV40 mit großen Quad-Batches arbeitet, was solches Branching ineffizient macht.
Original geschrieben von Tigerchen
Schaun wir mal ob die "herkömmliche" Technik nicht doch ausreicht. Immerhin verdaut diese Art von Technik bisher alles was man ihr vorsetzt klaglos. Je nach Natur des Effekts kann SM 3.0-Branching sogar auf dem NV40 der Performance gut tun. So weit ich das weiß, wird auch 2.0 (mindestens) mit R420-Geschwindigkeit ausgeführt. Zusätzlich gibt es die ganzen "alten" CineFX-Instruktionen, die manchmal zwei R420-Instruktionen ersetzen können, wodurch Shader kürzer (und schneller) werden. Dann kommt noch hinzu, dass (allerdings selten eingesetzte) Instruktionen wie SINCOS auf R420 8 Takte kostet, auf NV40 2 oder 3. Afaik ist auch arithmetisches Wurzelziehen schneller (das braucht man schon öfters, z. B. bei 3Dc.)

[Mr. Lolman]

Dann dürfte ja noch so einiges an Potential im NV40 schlummern. Bin gespannt ob es diesmal besser genutzt werden kann, als beim NV35...

[aths]

R420 (R300) hat auch seine Vorteile:

- Die Mini-ALU kann Co-Issued betrieben werden (im 3:1-Split.) NV40 hat sowas nicht, das mit der "Mini-ALU" (bzw. Mini-FPU) ist anders gelöst.

- Die einzelnen Units sind bei der Radeon weniger voneinander abhängig als beim NV40, wodurch Leertakte entfallen können in denen gewisse Units einfach nur Daten weitergeben müssen.

- Die Lösung, Shader in Passes zu zerlegen, erlaubt vergleichsweise kostengünstig eine Hardware, die mit der Nutzung vieler Temp-Register keine Probleme hat.

[Gast]

Original geschrieben von aths
Nein.
Im Artikel an dem ich gerade arbeite, wird die Vermutung geäußert, dass NV40 mit großen Quad-Batches arbeitet, was solches Branching ineffizient macht.
Je nach Natur des Effekts kann SM 3.0-Branching sogar auf dem NV40 der Performance gut tun. So weit ich das weiß, wird auch 2.0 (mindestens) mit R420-Geschwindigkeit ausgeführt. Zusätzlich gibt es die ganzen "alten" CineFX-Instruktionen, die manchmal zwei R420-Instruktionen ersetzen können, wodurch Shader kürzer (und schneller) werden. Dann kommt noch hinzu, dass (allerdings selten eingesetzte) Instruktionen wie SINCOS auf R420 8 Takte kostet, auf NV40 2 oder 3. Afaik ist auch arithmetisches Wurzelziehen schneller (das braucht man schon öfters, z. B. bei 3Dc.)

Bei bedingten Sprüngen muß nV40 auch bis zu 10 Takten Däumchen drehen. Meinst du man kann die Leistung an einzelnen Worst-Case Szenarien festmachen? Du kannst nicht einzelne besonders schlecht arbeitende Befehle des R420 den besonders gut Arbeitenden des nV40 gegenüberstellen. Ich denke es ist wichtiger was so im Durchschnitt an Zeit verloren geht bei langen/verzweigten Shadern.

Nun ja. Hoffen wir mal daß der Far Cry Shader 3.0 Patch bald kommt. Den wird bestimmt einer auseinandernehmen um zu erfahren wie lang und verzweigt die Shader wirklich sind. Und vor allem wie flott der nV40 damit ist. Da bin ich wirklich drauf gespannt. Und das ist ja meine eigentliche Frage. Dann sehen wir ob die Power wirklich reicht für SM 3.0.:)

[q@e]

Original geschrieben von Gast
[COLOR="#000088"]
Ich denke es ist wichtiger was so im Durchschnitt an Zeit verloren geht bei langen/verzweigten Shadern.
Absolut. Wenn ich jetzt einen langen Shader habe (meinetwegen das PS2.0 Limit von 96 Instruktionen), den ein Chip, der keine conditional Branches kennt, von vorn bis hinten durchrechnen muss, dann können das durchaus auch mal mehr als 96 Takte sein. Wenn ein Chip allerdings nun durch einen Sprung bsw. eine komplexe Lichtberechnung erkennen kann und die, sagen wir, 20 Instruktionen dafür direkt überspringt - dafür aber eine 10-Takt Penalty hinnehmen muss, dann kommt am Ende noch ein recht guter Deal heraus.

Nun bleibt allerdings die Frage, wie lang solche "überspringbaren" Sequenzen im Schnitt ausfallen ( a) in Instruktionen und b) in Takten) und wie granular ein Shader hier ausgeführt werden kann.

Pro Pipeline wird das sicherlich nicht gehen - evtl. aber pro Quad?

[Demirug]

Original geschrieben von Gast

Bei bedingten Sprüngen muß nV40 auch bis zu 10 Takten Däumchen drehen. Meinst du man kann die Leistung an einzelnen Worst-Case Szenarien festmachen? Du kannst nicht einzelne besonders schlecht arbeitende Befehle des R420 den besonders gut Arbeitenden des nV40 gegenüberstellen. Ich denke es ist wichtiger was so im Durchschnitt an Zeit verloren geht bei langen/verzweigten Shadern.

Nun ja. Hoffen wir mal daß der Far Cry Shader 3.0 Patch bald kommt. Den wird bestimmt einer auseinandernehmen um zu erfahren wie lang und verzweigt die Shader wirklich sind. Und vor allem wie flott der nV40 damit ist. Da bin ich wirklich drauf gespannt. Und das ist ja meine eigentliche Frage. Dann sehen wir ob die Power wirklich reicht für SM 3.0.:)


Bleibt abzuwarten ob Farcry überhaupt dynamische Branches in den Pixelshader nutzen wird. So richtig glaube ich da nicht daran.

[aths]

Original geschrieben von Gast
[COLOR="#000088"]
Bei bedingten Sprüngen muß nV40 auch bis zu 10 Takten Däumchen drehen. Meinst du man kann die Leistung an einzelnen Worst-Case Szenarien festmachen? Du kannst nicht einzelne besonders schlecht arbeitende Befehle des R420 den besonders gut Arbeitenden des nV40 gegenüberstellen. Ich denke es ist wichtiger was so im Durchschnitt an Zeit verloren geht bei langen/verzweigten Shadern. Das hängt beim NV40 immer "davon ab". Was die Befehle angeht, so denke ich dass gerade in "Real-World"-Situationen NV40 insgesamt deutlich im Vorteil ist.

Original geschrieben von Gast
Nun ja. Hoffen wir mal daß der Far Cry Shader 3.0 Patch bald kommt. Den wird bestimmt einer auseinandernehmen um zu erfahren wie lang und verzweigt die Shader wirklich sind. Und vor allem wie flott der nV40 damit ist. Da bin ich wirklich drauf gespannt. Und das ist ja meine eigentliche Frage. Dann sehen wir ob die Power wirklich reicht für SM 3.0.:)SM 3.0 bietet ggü. 2.0 mehr als Branching, SM3 auf dem NV40 sinnvoll einzusetzen heißt nicht, wie blöd zu branchen. Es würde beim Duell NV40 vs. R420 reichen, wenn CineFX richtig ausgenutzt würde, um effizienter als die NV-Konkurrenz zu sein.

[aths]

Original geschrieben von q@e
Absolut. Wenn ich jetzt einen langen Shader habe (meinetwegen das PS2.0 Limit von 96 Instruktionen), den ein Chip, der keine conditional Branches kennt, von vorn bis hinten durchrechnen muss, dann können das durchaus auch mal mehr als 96 Takte sein. Wenn ein Chip allerdings nun durch einen Sprung bsw. eine komplexe Lichtberechnung erkennen kann und die, sagen wir, 20 Instruktionen dafür direkt überspringt - dafür aber eine 10-Takt Penalty hinnehmen muss, dann kommt am Ende noch ein recht guter Deal heraus.Kaum. In 10 Takte sollte NV40 mindestens 20 Instruktionen gestopft bekommen.

Original geschrieben von q@e
Pro Pipeline wird das sicherlich nicht gehen - evtl. aber pro Quad? Pro Quad-Batch.

[q@e]

Original geschrieben von aths
Kaum. In 10 Takte sollte NV40 mindestens 20 Instruktionen gestopft bekommen.

Pro Quad-Batch.

Nagut, ein plus-minus-Null Geschäft. Verdopple halt die Instruktionen. ;)

Was heisst "Pro Quad-Batch"?

[aths]

Original geschrieben von q@e
Nagut, ein plus-minus-Null Geschäft. Verdopple halt die Instruktionen. ;)Insgesamt sogar ein Minusgeschäft.
Original geschrieben von q@e
Was heisst "Pro Quad-Batch"? Pro Batch von Quads :naughty: Für mehrere Quads wird gemeinsam entschieden, welche Branches abgearbeitet werden. Sofern ein Quad beide Zweige braucht (bzw. den anderen Zweig), gehen alle Quads des Batches mehrfach durch die Pipe. Wenn ich das richtig verstanden habe ist ein Batch so groß, wie viele Quads gleichzeitig in der Pipe sind. Die Pipeline dürfte mindestens 256 Stages haben.

[deekey777]

Original geschrieben von aths
Man muss ja nicht jedes 3.0-Feature sofort benutzen.

Langweilig...

[Jesus]

Tim Sweeney ( UE 3.0 ):

For mainstream games shipping this year and trying to take advantage of a broad range of hardware, the problem of scaling from 8-bit-per-component fixed function to 32-bit-per-component programmable shaders sounds quite tough. I'm happy to not be trying to solve that problem.

[q@e]

Was möchtest du uns damit sagen, Jesus?

[tb]

Original geschrieben von aths
So eine Entscheidung kostet afaik 1 Takt, (vielleicht 2.) Das einfachste Branching auf NV40 ist nicht für unter 4 Takte zu kriegen. Bei kurzen Zweigen ist das auf dem NV40 also langsamer, als CMP zu nutzen. Sofern große Flächen (mehrere tausend Pixel) den gleichen Zweig benutzen, kann der NV40 Performancevorteile gewinnen.

Momentan bestehen beim Pixel Shader 3.0 dyn. flow control noch ein paar Einschränkungen (HW seitig, nicht API seitig)

Aus der ATi Folie (D3DTutorial_ShaderModels.pdf)
Hence, nothing that requires a derivative of a computed value may exist inside of dynamic flow control
- This includes most texture fetches, dsx()and dsy()
texldl and texldd work since you have to compute the LOD or derivatives outside of the dynamic flow control

Von Microsoft:
This behavior is very much by design. Both the gradient instructions and
the tex*D() cause the hardware to compute differences based on the values
computed by a (usually) 2x2 grid of pixels. When using dynamic flow
control, some of the pixels in the 2x2 grid may take divergent code
execution paths, which means that the differences cannot be computed. Note
that this is an algorithm/hardware issue, not a software/API issue.

Somit dürfte der momentane Gewinn nur bei intensiven Berechnungen liegen, welche ohne dsx / dsy und jegliche tex Befehle auskommen.

Hier mal 2 Testshader(es wird zwischen geraden und ungeraden Pixeln in X-Richtung unterschieden), welche ich mittels - MDolenc's Fillrate Tester ausprobiert habe:

Display adapter: NVIDIA GeForce 6800 GT (400/550)
Driver version: 6.14.10.6190
Display mode: 1600x1200 A8R8G8B8 85Hz
Z-Buffer format: D24S8

PS 2.0 - Longer - 35.098045M pixels/sec (ca. 400 Befehle, dyn. flow control)

ps_3_0
dcl vPos.xy
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.0, 0.5, 1.0 //blue
def c3, 0.125, 1.0, 0.0164, 0.0

mul r0.x, vPos.x, c3.x // r0.x = xpos / 16.0
frc r1.x, r0.x
if_ne r1.x, c3.z
add r0, c1, r1.x // just to make r1.x needed
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
else
add r0, c2, r1.x // just to make r1.x needed
endif
mov oC0, r0


PS 2.0 PP - Longer - 36.648529M pixels/sec (ca. 400 Befehle, kein. flow control)

ps_3_0
dcl vPos.xy
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.0, 0.5, 1.0 //blue
def c3, 0.125, 1.0, 0.0164, 0.0

mul r0.x, vPos.x, c3.x // r0.x = xpos / 16.0
frc r1.x, r0.x
//if_ne r1.x, c3.z
add r0, c1, r1.x // just to make r1.x needed
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
mul r0, r0, c1.x
add r0, r0, c3.z
//else
//add r0, c2, r1.x // just to make r1.x needed
//endif
mov oC0, r0


PS 2.0 - Longer 4 Registers - 658.437073M pixels/sec (dyn. flow control)



ps_3_0
dcl vPos.xy
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.0, 0.5, 1.0 //blue
def c3, 0.5, 1.0, 0.0, 0.0

mul r0.x, vPos.x, c3.x // r0.x = xpos / 16.0
frc r1.x, r0.x
if_ne r1.x, c3.z
add r0, c1, r1.x // just to make r1.x needed
else
add r0, c2, r1.x // just to make r1.x needed
endif
mov oC0, r0



PS 2.0 PP - Longer 4 Registers - 3131.991699M pixels/sec (kein. flow control)


ps_3_0
dcl vPos.xy
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.0, 0.5, 1.0 //blue
def c3, 0.5, 1.0, 0.0, 0.0

mul r0.x, vPos.x, c3.x // r0.x = xpos / 16.0
frc r1.x, r0.x
//if_ne r1.x, c3.z
add r0, c1, r1.x // just to make r1.x needed
//else
//add r0, c2, r1.x // just to make r1.x needed
//endif
mov oC0, r0



Thomas

[zeckensack]

Thomas :massa:

Damit dürfte ja klar sein, wieviel dynamisches Flow control (mit aktuellen Treibern ...) bringt: minus garnichts ;(

Ist diese Interpretation korrekt?

edit: kannst du evtl äquivalente Shader, die mittels CMP "branchen" vermessen?

[tb]

Original geschrieben von zeckensack
Thomas :massa:

Damit dürfte ja klar sein, wieviel dynamisches Flow control (mit aktuellen Treibern ...) bringt: minus garnichts ;(

Ist diese Interpretation korrekt?

Würd ich soweit bestätigen, zumindest im Pixel Shader, allerdings hab ich keine Ahnung, wie weit die Treiber im Bezug auf dyn. Flow Control im Pixel Shader sind...

P.S. Noch ne Fehler bei der C3 Konstante gefunden, die muss überall def c3, 0.5, 1.0, 0.0164, 0.0 lauten, ändert aber nichts am Gesamtbild.

Thomas

[Gast]

Original geschrieben von tb
When using dynamic flow control, some of the pixels in the 2x2 grid may take divergent code execution paths, which means that the differences cannot be computed. Note
that this is an algorithm/hardware issue, not a software/API issue.
Unabhängig vom flow control: Bei 1 Pixel Polygonen oder Randpixeln gibt es i.d.R auch keine 4 gültigen Werte. Die Begründung ist unlogisch oder zumindest unvollständig.

Original geschrieben von tb
Hier mal 2 Testshader(es wird zwischen geraden und ungeraden Pixeln in X-Richtung unterschieden)
Unterschiedliche if-then-else Pfade innerhalb eines Quads bringen dem NV40 keine Performancevorteile. Was also beweist der Test?

[Demirug]

Thomas, nichts für ungut aber ist der Test so nicht etwas unsinng?

equal und not equal sind ja von sich aus schon sehr unsicher. Refrast kommt bei deinem Beispiel mit dem geänderten C3 Wert gar nicht mehr in den Else-Zweig.

Aber selbst wenn das bei der echten NV40 Hardware anders ist zeigt der Test nur das der NV40 wenn innerhalb eines Quads beide Zweige gebraucht werden auch beide für den gesamten Quad ausgeführt werden müssen. Das wusste wir aber schon.

Falls du die Möglichkeit hast wäre es interesant zu wissen was passiert wenn der NV40 die Möglichkeit hat für eine grössere Fläche den aufwendigen Rechenteil zu überspringen.

[tb]

Ups, hast recht, der kommt nie in den else teil. hier die berichtigte version:

alle 128 pixel führt er den langen code aus:

ps_3_0
dcl vPos.xy
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.125, 0.5, 1.0 //blue
def c3, 0.0078125, 1.0, 0.0, 0.1

mul r0.x, vPos.x, c3.x // r0.x = xpos / 128.0
frc r1.x, r0.x
if_eq r1.x, c3.z
add r0, c2, r1.x // just to make r1.x needed
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
else
mov r0, c1
endif
mov oC0, r0

51.568298M pixels/sec

jeden pixel führt er den langen code aus:

ps_3_0
dcl vPos.xy
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.125, 0.5, 1.0 //blue
def c3, 0.0078125, 1.0, 0.0, 0.1

mul r0.x, vPos.x, c3.x // r0.x = xpos / 128.0
frc r1.x, r0.x
// if_eq r1.x, c3.z
add r0, c2, r1.x // just to make r1.x needed
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
// else
// mov r0, c1
// endif
mov oC0, r0

26.195530M pixels/sec

Thomas

[LovesuckZ]

tb,
koenntest du mal einen r420 durch den test jagen?
Digit-life.com aeußerte sich mal, dass die Architektur mit laengeren Shadern deutliche Probleme bekommen koennte.

[Jesus]

öpö

also gut ist das jetzt nicht oder ? die verzweigung zu einem einzigen befehl bringt nur die doppelte peformance im vgl. zu 400 befehlen ?

[tb]

Original geschrieben von LovesuckZ
tb,
koenntest du mal einen r420 durch den test jagen?
Digit-life.com aeußerte sich mal, dass die Architektur mit laengeren Shadern deutliche Probleme bekommen koennte.

Hab leider keinen, ist leider auch ein 3.0'er shader welcher das vpos register verwendet, dat gibts under 2.x noch nicht, aber wenn interesse besteht kann man(oder ich) ja einfach ein stück aus den 400 befehlen rauskopieren und ne 2.x shader basteln...

Thomas

[Winter[Raven]]

Original geschrieben von tb
Hab leider keinen, ist leider auch ein 3.0'er shader welcher das vpos register verwendet, dat gibts under 2.x noch nicht, aber wenn interesse besteht kann man(oder ich) ja einfach ein stück aus den 400 befehlen rauskopieren und ne 2.x shader basteln...

Thomas

wir wären dir dankbar :) wenn du das machen könntest x-D

[tb]

Original geschrieben von Jesus
öpö

also gut ist das jetzt nicht oder ? die verzweigung zu einem einzigen befehl bringt nur die doppelte peformance im vgl. zu 400 befehlen ?

Es könnte schlimmer sein ;)
Was meinst Du, was bei kürzeren Shadern passiert?
Man sieht halt recht deutlich, dass eine VPU keine CPU ist, zumindest noch nicht....

Thomas

[LovesuckZ]

Original geschrieben von tb
[...] aber wenn interesse besteht kann man(oder ich) ja einfach ein stück aus den 400 befehlen rauskopieren und ne 2.x shader basteln...


Das waere nett.
Eventuell einen Shader mit ca. 300+ Anweisungen? :)

[Demirug]

Original geschrieben von Jesus
öpö

also gut ist das jetzt nicht oder ? die verzweigung zu einem einzigen befehl bringt nur die doppelte peformance im vgl. zu 400 befehlen ?

Es zeigt in erster Näherung das dynamische Branchen beim NV40 überhaupt funktioniert. Bei allen anderen bisher aufgetauchten Ergebniessen hatte man den Eindruck das er sowieso beide Pfade ausführt.

@tb:
Wenn es nicht zu viel arbeit macht wären das ganze noch mit etwa 200/100/50/10 Anweisungen interesant. Ein Spilt in der Bildschirmmitte könnte auch zusätzliche Erkenntnisse bringen. Also ich meine sowas


def c5, 512.0, 0.0, 0.0, 0.0
if_lt vPos.x, c5.x

oder

def c5, 384.0, 0.0, 0.0, 0.0
if_lt vPos.y, c5.x


PS: Mein Shaderbenchmark (http://demirug.bei.t-online.de/DX9/SSM.zip) programm unterstützt inzwischen auch 3.0 Pixelshader. Braucht allerding .Net und MDX ist dafür aber sehr flexible.

[Jesus]

Original geschrieben von tb
Es könnte schlimmer sein ;)
Was meinst Du, was bei kürzeren Shadern passiert?


0.0 bis -x.y ? ;)

[tb]

Original geschrieben von Winter[Raven]
wir wären dir dankbar :) wenn du das machen könntest x-D

macht nix sinnvolles, geht aber:

ps_2_x
dcl v0
def c1, 0.5, 0.0, 0.0, 1.0 //red
def c2, 0.0, 0.125, 0.5, 1.0 //blue
def c3, 0.0078125, 1.0, 0.0, 0.1
mul r0.x, v0.x, c3.x
frc r1.x, r0.x
add r0, c2, r1.x
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mul r0, r0, c2.y
add r0, r0, c3.w
mov oC0, r0


PS 2.0 - Simple - 36.451702M pixels/sec

Thomas

[tb]

Original geschrieben von Jesus
0.0 bis -x.y ? ;)

Volltreffer!

Thomas

[Jesus]

;D

[tb]

Original geschrieben von Demirug
Es zeigt in erster Näherung das dynamische Branchen beim NV40 überhaupt funktioniert. Bei allen anderen bisher aufgetauchten Ergebniessen hatte man den Eindruck das er sowieso beide Pfade ausführt.

@tb:
Wenn es nicht zu viel arbeit macht wären das ganze noch mit etwa 200/100/50/10 Anweisungen interesant. Ein Spilt in der Bildschirmmitte könnte auch zusätzliche Erkenntnisse bringen. Also ich meine sowas


def c5, 512.0, 0.0, 0.0, 0.0
if_lt vPos.x, c5.x

oder

def c5, 384.0, 0.0, 0.0, 0.0
if_lt vPos.y, c5.x


PS: Mein Shaderbenchmark (http://demirug.bei.t-online.de/DX9/SSM.zip) programm unterstützt inzwischen auch 3.0 Pixelshader. Braucht allerding .Net und MDX ist dafür aber sehr flexible.

Poste ich nachher mal, muss erstmal kurz ins Bett...
P.S. Dein Benchmark schmiert bei mir ab, mit ner "file not found exception" - könnte an der managed runtime liegen, ich hab die dx9.0c beta 3 drauf, dein Benchmark braucht aber sicher die dx9.0b version - die saug ich denne mal...

[Gast]

Original geschrieben von tb
alle 128 pixel führt er den langen code aus:
51.568298M pixels/sec

jeden pixel führt er den langen code aus:
26.195530M pixels/sec

Original geschrieben von tb
macht nix sinnvolles, geht aber:
36.451702M pixels/sec

Im Worst-Case verliert man mit sinnlosem Branching als rund 30% Performance und in einem sinnvolleren Fall kann man durch Verzicht auf Branching ebenfalls rund 30% Performance verschenken?

Sind deine Shader rechnerisch gleichwertig?

[Jesus]

das zweite ist auf nem r420 wenn ich nicht irre...

also das hier 36.451702M pixels/sec

ich denke bei etwas realistischeren shaderlängen (100 ) wird man durchs branching eher verlieren als gewinnen.

[q@e]

Wenn man jeden Shader krampfhaft branchen will, sicherlich. Genauso, wie für jeden Shader sinnlos 2.0-fp zu benutzen.

Allerdings kannst du mit längeren Shadern bsw. mehrere Lichtquellen (je nach Situation evtl. sogar alle) zu einem Shader zusammenfassen und wenn für eine bestimmte Fläche recht schnell ausgeschlossen werden kann, daß sie im Licht liegt, überspringst du eben sämtliche Instruktionen, die die Beleuchtung betreffen (oder rechnest nur ein paar Pixel Specular - je nach Bedarf halt).

[LovesuckZ]

Original geschrieben von Jesus
das zweite ist auf nem r420 wenn ich nicht irre...

NV40. tb habe keinen r420, wie er oben schreibt.

ich denke bei etwas realistischeren shaderlängen (100 ) wird man durchs branching eher verlieren als gewinnen.

Nur beim NV40, zukuenftige Hardware sollte wohl solche Faelle besser bewerkstelligen.
Koennte jemand mit Mcdonaldfillratetester und einem R420 den PX2.x Shader mal ausfuehren?

[q@e]

Original geschrieben von Jesus
das zweite ist auf nem r420 wenn ich nicht irre...

also das hier 36.451702M pixels/sec


denke nicht:

Original geschrieben von tb
Hab leider keinen, [...bezogen auf R420]

[Demirug]

Original geschrieben von tb
Poste ich nachher mal, muss erstmal kurz ins Bett...
P.S. Dein Benchmark schmiert bei mir ab, mit ner "file not found exception" - könnte an der managed runtime liegen, ich hab die dx9.0c beta 3 drauf, dein Benchmark braucht aber sicher die dx9.0b version - die saug ich denne mal...

Der läuft auch mit DX9.0c Beta3. Habe ich ja selbst auch auf dem Rechner.

[Jesus]

Original geschrieben von q@e
denke nicht:

stimmt, aber heisst das dann derselbe shader wird als 2.0 shader schneller abgearbeitet als der 3.0er ?

[aths]

Original geschrieben von q@e
(oder rechnest nur ein paar Pixel Specular - je nach Bedarf halt). So wie ich das verstanden habe, würde er dann für mindestens 1000, eher für 4000 Pixel den specularen Anteil noch berechnen (wenn auch nicht nutzen.) Ich hoffe, dass ich in dieser Sache auf dem falschen Dampfer bin – sonst :freak:

[q@e]

Natürlich - denn du hast für jeden Pixel das Branching-Penalty, ohne das das ein Branch übersprungen werden kann und somit keine Chance besteht, das Branching-Penalty irgendwo wieder einzusparen.
Wie gesagt - worst case.

Branching ist ja kein Selbstzweck, sondern soll eben nicht benötigte Anweisungen überspringen.

[aths]

Original geschrieben von q@e
Branching ist ja kein Selbstzweck, sondern soll eben nicht benötigte Anweisungen überspringen. Aus logischer Sicht wird das auch gemacht. Physikalisch rechnet er in den meisten Fällen beide Zweige durch, so dass man Performancemäßig nichts sparen dürfte. Nicht mal Early-Out bringt Performance, so weit ich das weiß.

[tb]

die 2.x version macht nix sinnvolles, geht aber und ist ein wenig schneller als die 3.0er version (wird wohl am treiber liegen).

@Demirug

Additional information: Datei- oder Assemblyname 'Microsoft.DirectX.Direct3D' oder eine Abhänigkeit davon wurde nicht gefunden.

Ne Idee? Die 9.0b MDX brachte nix :(

dyn. flow control:

10 befehle alle 128 pixel
554.531250M pixels/sec

50 befehle alle 128 pixel
255.539764M pixels/sec

100 befehle alle 128 pixel
157.135132M pixels/sec

200 befehle alle 128 pixel
95.918098M pixels/sec

400 befehle alle 128 pixel
44.076843M pixels/sec


ohne flow control:

10 befehle pro pixel
1045.339844M pixels/sec

50 befehle pro pixel
220.687057M pixels/sec

100 befehle pro pixel
108.408989M pixels/sec

200 befehle pro pixel
60.458839M pixels/sec

400 befehle pro pixel
26.192341M pixels/sec


Thomas

[q@e]

Selbst bei 50 Befehlen pro Pixel schon ein "Gewinn"?

[tb]

Original geschrieben von q@e
Selbst bei 50 Befehlen pro Pixel schon ein "Gewinn"?

Naja Du musst das Verhältnis sehen, ohne Branching macht er die 50 Befehle pro Pixel, mit Branching nur all 128 - im Falle einer CPU sollte das Resultat da bei Branching wesentlich höher(~128 mal schneller) sein....

Thomas

[seahawk]

Also kann man nicht firekt von einer Schwäche reden. Bei den 3.0 typisch langen Shadern bringt die Funktion was.

Bei kurzen Shadern lohnt sich der Aufwand nicht.

Oder sehe ich das falsch?

[LovesuckZ]

Original geschrieben von seahawk
Bei kurzen Shadern lohnt sich der Aufwand nicht.
Oder sehe ich das falsch?

Ja, weil die "Strafe" durch Branching nicht "verdeckt" werden kann.

[Demirug]

Original geschrieben von tb
Naja Du musst das Verhältnis sehen, ohne Branching macht er die 50 Befehle pro Pixel, mit Branching nur all 128 - im Falle einer CPU sollte das Resultat da bei Branching wesentlich höher(~128 mal schneller) sein....

Thomas

Deswegen ja mein Vorschlag mit dem Bildschirm teilen. Eine einzelne Líne alle 128 Pixel ist sicherlich nicht sehr praxsisorintiert.

[Demirug]

Original geschrieben von tb
@Demirug

Additional information: Datei- oder Assemblyname 'Microsoft.DirectX.Direct3D' oder eine Abhänigkeit davon wurde nicht gefunden.

Ne Idee? Die 9.0b MDX brachte nix :(

Mhm, sind die MDX Dlls im Global Assembly Cache eingetragen?

[Gast]

Original geschrieben von tb
Naja Du musst das Verhältnis sehen, ohne Branching macht er die 50 Befehle pro Pixel, mit Branching nur all 128 - im Falle einer CPU sollte das Resultat da bei Branching wesentlich höher(~128 mal schneller) sein....

Thomas

Ja schon, solange du bei der CPU nicht auch die SIMD-Einheiten nimmst, oder?

Außerdem kursierten hier ja Horrorgeschichten bezgl. des Branching... so furchtbar scheint es ja nicht zu sein. Daß es kein Allheilsbringer ist, ist mir allerdings auch klar.

[q@e]

^^ /me

[tb]

Jap, die dx9.0b und die dx9.0c beta 3 - die SDK Demos laufen auch...


Deswegen ja mein Vorschlag mit dem Bildschirm teilen. Eine einzelne Líne alle 128 Pixel ist sicherlich nicht sehr praxsisorintiert.


Ich versteh nicht genau, was Du möchtest bzw. mir sagen willst. Der Shader wird doch nicht praxisrelevanter, wenn ich den Bildschirm teile!? Es ist doch nur ein reiner Testshader ohne jeglichen Bezug zur Realität bzw. zu irgendeiner praktischen Anwendung.

Thomas

[tb]

Original geschrieben von Gast
Ja schon, solange du bei der CPU nicht auch die SIMD-Einheiten nimmst, oder?

Außerdem kursierten hier ja Horrorgeschichten bezgl. des Branching... so furchtbar scheint es ja nicht zu sein. Daß es kein Allheilsbringer ist, ist mir allerdings auch klar.

Gibt es innerhalb einer SIMD (single instruction multiple data) Einheit dyn. flow control? Die bisherigen SSE/SSE2/3DNOW Befehlssätze sind doch nur recht einfache Befehle ohne internes Branching!?

http://www.hayestechnologies.com/de/techsimd.htm#SSE2

Thomas

[zeckensack]

Original geschrieben von tb
Gibt es innerhalb einer SIMD (single instruction multiple data) Einheit dyn. flow control? Die bisherigen SSE/SSE2/3DNOW Befehlssätze sind doch nur recht einfache Befehle ohne internes Branching!?

http://www.hayestechnologies.com/de/techsimd.htm#SSE2

Thomas Nein. SSE und 3DNow haben Vektor-Äquivalente zu SGE/SLT, etc, und CMP (letzteres über AND/NAND). "Echtes" branching kann aber nur die "Integer"-Einheit. Das Zurückfüttern von Flusskontrollinformationen von den Vektorregistern in die Integer-Einheit ist ein nicht zu unterschätzendes Problem.
Beispiel (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=993203#post993203)

edit:
comisd (bzw bei SSE1 comiss) transferieren Vergleichsergebnisse zwischen zwei Skalaren direkt in die x86-flags, womit stinknormal Jcc möglich wird. Ist aber auch teuer ...

[TheCounter]

http://www.nvnews.net/images/news/200407/farcry_sm30.png
http://www.nvnews.net/articles/chrisray_iq/comparison/farcrygraph1.jpg

Hui, na wenn das wirklich soviel bringt :)

http://www.nvnews.net/vbulletin/showthread.php?p=356712

[Demirug]

Original geschrieben von TheCounter
Hui, na wenn das wirklich soviel bringt :)

http://www.nvnews.net/vbulletin/showthread.php?p=356712

Leider kann man diesen Gewinn jetzt nicht nur SM3 zuschreiben. Da kommt auch noch ein gutes Stück "Wir könnte eigentlich die Möglichkeiten von DX9 auch mal zum optimieren und nicht für schönere Effekte benutzen" hinzu.

Der SM2 Pfad ist im wesentlichen ein SM1 Pfad mit schöneren Effekten. Erst beim SM3 Pfad nutzt man Dinge wie Passreduktion mal etwas mehr aus.

Der Gewinn durch Instancing beim Grünzeug. von dem aber keiner weiss wie gross dieser nun aleine ist. kann man SM3 zuschreiben.

[TheCounter]

Original geschrieben von Demirug
Der Gewinn durch Instancing beim Grünzeug. von dem aber keiner weiss wie gross dieser nun aleine ist. kann man SM3 zuschreiben.

Anandtech hat dazu noch geschrieben:

The main point that the performance numbers make is not that SM3.0 has a speed advantage over SM2.0 (as even the opposite may be true), but that single pass per-pixel lighting models can significantly reduce the impact of adding an ever increasing number of lights to a scene.

[Demirug]

Original geschrieben von TheCounter
Anandtech hat dazu noch geschrieben:

The main point that the performance numbers make is not that SM3.0 has a speed advantage over SM2.0 (as even the opposite may be true), but that single pass per-pixel lighting models can significantly reduce the impact of adding an ever increasing number of lights to a scene.

Das passt aber besser zu diesem Teil meines Posts:

Der SM2 Pfad ist im wesentlichen ein SM1 Pfad mit schöneren Effekten. Erst beim SM3 Pfad nutzt man Dinge wie Passreduktion mal etwas mehr aus.

Instancing bringt wirklich was aber da ein Frame aber ebene nicht nur aus Grünzeug besteht kann es nur diesen kleinen Teil etwas beschleuningen und das auch nur wenn man am CPU limit ist.

[deekey777]

One of the main features of pixel shader 3.0 is that is supports dynamic branching (also called data dependent branching), something that nVidia of course makes a big deal about. This demo however shows a way to implement dynamic branching without pixel shader 3.0, using basic graphics functionality such as alpha testing and stencil testing. Not only is it doable, but also gives every bit of the performance of real dynamic branching.
One scenario where dynamic branching comes in handy is when you have range-limited lights. Whenever a fragment is outside the range of the light, you can skip all the lighting math and just return zero immediately. With pixel shader 3.0 you'd simply implement this with an if-statement. Without pixel shader 3.0, you just move this check to another shader. This shader returns a truth value to alpha. The alpha test then kills all unlit fragments. Surviving fragments will write 1 to stencil. In the next pass you simply draw lighting as usual. The stencil test will remove any fragments that aren't tagged as lit. If the hardware performs the stencil test prior to shading you will save a lot of shading power. In fact, the shading workload is reduced to the same level of pixel shader 3.0, or in some cases even slightly below since the alpha test can do a compare that otherwise would have to be performed in the shader.
The result is that early-out speeds things up considerably. In this demo the speed-up is generally in the range of two to four times as fast than without early-out. And with more complex lighting, the gain would have been even larger.


Quelle (http://esprit.campus.luth.se/~humus/3D/index.php)

Diese Demo lief auf meiner 9800 Pro.

[Demirug]

Original geschrieben von deekey777
Quelle (http://esprit.campus.luth.se/~humus/3D/index.php)

Diese Demo lief auf meiner 9800 Pro.

Der gute humus gehört ja jetzt auch zu ATI aber ich habe ein ganz anderes Problem mit dieser Demo.

Mit aktiviertem "Dynamic Branching" ist auf meiner 5900 langsamer als wenn man es ausschaltet. Ist das auf deiner R9800 anders?

Zudem hätte ich auch noch gerne die SM3 Lösung dazu gesehen. Die fehlt aber in der Demo. Aber das lässt sich ja lösen.

[LovesuckZ]

Original geschrieben von Demirug
Mit aktiviertem "Dynamic Branching" ist auf meiner 5900 langsamer als wenn man es ausschaltet. Ist das auf deiner R9800 anders?


Nicht ganz.
Es ist nur 2-3fach schneller...

[deekey777]

Original geschrieben von Demirug
Der gute humus gehört ja jetzt auch zu ATI aber ich habe ein ganz anderes Problem mit dieser Demo.

Mit aktiviertem "Dynamic Branching" ist auf meiner 5900 langsamer als wenn man es ausschaltet. Ist das auf deiner R9800 anders?

...

Wenn ich DB deaktiviere, fällt die Framerate von ~114-125 Frames auf konstant 40 Frames (Vollbild).

[Demirug]

ATI kann also den Stenciltest vor dem Shading machen. Das war abergrund der Beschreibung fast zu erwarten.

[Gast]

wie schaltet man in dieser Demo irgendwas ein oder aus??

[deekey777]

Original geschrieben von Gast
wie schaltet man in dieser Demo irgendwas ein oder aus??

Drücke auf F1 und wünsch dir was.


Zurück zum Spekulieren:
Wenn ich mir einige Postings anschaue (auch in einem anderen Fred), komme ich zu diesem Ergebnis:
Far Cry' SM 3.0 Path ist eigentlich in etwa das, was schon der SM 2.0 Path für die DX9-Grafikkarten á la R300&NV3x vom Anfang an sein sollte.

[LovesuckZ]

Original geschrieben von deekey777
Zurück zum Spekulieren:
Wenn ich mir einige Postings anschaue (auch in einem anderen Fred), komme ich zu diesem Ergebnis:
Far Cry' SM 3.0 Path ist eigentlich in etwa das, was schon der SM 2.0 Path für die DX9-Grafikkarten á la R300&NV3x vom Anfang an sein sollte.

Nein, da die Limitierung vom SM2.0 (nicht x!) nicht unerheblich sind.
Imo sollten PS2.x fuer die Shader vollkommen ausreichen.
Beim VS2.0/x sieht es dagegen schon anders aus, da sie nicht ueber GI verfuegen.

[deekey777]

Mißverständnis:
Demirugs Posting war der Anstoss:

"Kein Wunder wenn man auch endlich mal langsam anfängt DX9 Chips so zu benutzten wie man es tun sollte. Allerdings eben nur DX9 Chips die SM3 können. Das Potenial ist aber IMHO noch nicht ausgeschöpft. Ich meine damit bei allen DX9 Chips."

Ich meinte nur die Wirkung des Patches 1.2(+DX9.0c)&SM 3.0 Pfad auf einer NV40, was ehrlich gesagt zu keiner Leistungssteigerung führt, sondern zeigt, wie FC eigentlich laufen soll.

Nachtrag: Kriegt die R420 eigentlich jetzt auch ihren eigenen Renderpfad, oder wird sie auf den Pfad der 2 Jahre alten R300 setzen müssen? ;D

[Demirug]

OK, jetzt muss ich das ganze wohl doch etwas genauer darlegen.

Ich habe Far Cry dahingehend ja schon öfter kritisiert das dort ineffektiv mit der Leistung einer Grafikkarte umgegangen wird. Das liegt unter anderem daran das für einen Pixel oft viele Schichten übereinader gelegt werden. Erschwerden kommt dabei hinzu das zur Berechnung der einzelnen Schichten oft mehrfach die gleichen Texturen an der gleichen Stelle ausgelesen werden.

Der 1.2 Patch fasst nun beim SM3 Pfad zumindestens bis zu 4 Lichtquellen zusammen. Dadurch können bestimmte Dinge auf bis zu einem viertel reduziert werden. Allerdings bekommen die Objekte immer noch mehr als eine Schicht. Das müsste aber in den meisten Fällen nicht sein.

Die Frage ist jetzt natürlich warum das ganze nur beim SM3 Pfad und nicht auch beim SM2 Pfad. SM2 ist in dieser Beziehung komplizierter. Aufgrund der Limits bekommt man nicht immer (eher so gut wie nie) 4 Lichtquellen in einen Pass. Bei 3 sieht es schon besser aus und 2 sollten eigentlich immer machbar sein. Ein Lichtquellenzusammenfassen bei SM2 hätte also bedeutet das man Zusatzlogik braucht die entscheidet wie viele Passes man für die benötige Kombination von Lichtquellen braucht. Da die Shader ja dynamisch aus Scripten gebaut werden ist das Problem mit der Anzahl Passes nicht ganz trivial.

Was nun einen R420 Pfad (2.b) angeht so ist es nicht ganz trivial zu sagen ob man dort immer 4 Lichtquellen in einen Pass bekommt. Von der Programmlänge ist das kein problem. Es könnten allerding die Interpolatoren ausgehen. Davon haben 3.0 Shader 2 mehr. Wenn es allerdings nur das Problem mit der Shaderlänge gibt dann könnte man auch für den R420 einen entsprechenden Pfad bauen der bis zu 4 Lichtquellen in einem Pass rendert. Allerdings muss man sich dann auch Fragen warum sowas nicht für den NV3X und 2.A gemacht wurde.

In Summe kann man also sagen das der Patch 1.2 beim NV40 ein wenig mehr von der möglichen Leistung zeigt bei allen anderen DX9 Karten allerdings weiterhin auf Leistung hoft um die ineffizienz auszugleichen.

PS: Die 4 Lichtquellen aus der Demo von Humus passen nicht zusammen in einen 2.0 Shader. Das gibt eine Anweisung zu viel. Ich habe die Demo nämlich gerade um einen "One Pass for All Lights" Modus erweitert.

[LovesuckZ]

Original geschrieben von Demirug
PS: Die 4 Lichtquellen aus der Demo von Humus passen nicht zusammen in einen 2.0 Shader. Das gibt eine Anweisung zu viel. Ich habe die Demo nämlich gerade um einen "One Pass for All Lights" Modus erweitert.

Koenntest du auch einen "real dynamic branching" Modus hinzufuegen?

[Jesus]

rofl

wozu soll das den gut sein ?

[Demirug]

Original geschrieben von LovesuckZ
Koenntest du auch einen "real dynamic branching" Modus hinzufuegen?

Im Prinzip ja. Allerdings mangelt es mir derzeit noch an einer Karte um zu Testen ob ich dabei keinen Mist baue und dann das Ergebniss auf dem Bildschirm nicht stimmt.

Ich versuche jetzt erstmal da noch irgendwie eine Anweisung einzusparen.

[deekey777]

Das würde also heissen, das die Crytek GmbH endlich ihr Hirn eingeschaltet hat und mit dem Patch 1.2 - zumindest bei der NV40+SM 3.0 - die Hardware halbwegs effektiv ausreizt wird (siehe Unterschied zw. SM 2.0 und SM 3.0 auf einer NV40), was aber bei SM 2.0 nicht mehr gilt.

PS: Habt ihr in der DB Demo auch diese zwei weisse Punkte?

http://www.ystart.net/upload/20040702/1088803680.jpg

(Das Bild habe ich mit der "Druck"-Taste gemacht, da die integrierte Screenshotfunktion diese zwei weissen Punkte nicht erfasste.)

[tombman]

Also was ich bisher gesehen habe (und überhaupt zu verstehen im Stande war), bringt derzeit der 3.0 patch nicht gerade sehr viel... kann bestenfalls den Rückstand zu ATI aufholen...

hab jetzt auch schon einige far cry 1.2 + sm3.0 reviews gelesen und dabei sah ich auch welche, wo die x800xt pe besonders bei zuschalten von AA/AF immer noch schneller war.

Naja, in ein paar Tagen werd ichs eh selbst wissen ;)

[TheCounter]

Original geschrieben von tombman
Naja, in ein paar Tagen werd ichs eh selbst wissen ;)

Am Montag wird kein Patch kommen ;)

Ubisoft wollte vorher noch ne Ankündigung machen, und du glaubst doch nicht wirklich das die am selben Tag noch den Patch releasen. IMHO ist das nur weitere hinhaltetaktik, und das rausgeben des Patches an "Reviewer" ist ne schöne Werbung, vor allem für NVIDIA und den N40. Die Leute die das Teil wirklich brauchen (Wegen den Bugfixes) müssen wieder ewig warten...

@deekey777

Nein, solche weißen Punkte hab ich bei mir nicht bemerkt.

[tombman]

Original geschrieben von TheCounter
Am Montag wird kein Patch kommen ;)



ICH habs eh ned eilig ;)

und für mich sind reviewer eh :@#$!%: :down:

UPDATE: Anandtech hat bereits zugegeben, daß AA nicht an war bei Nvidia.

Jetzt hat er die scores ausgebessert und ATI liegt wieder vorne :D:D
(nicht vergessen, die 6800 UE existiert nicht)
http://images.anandtech.com/graphs/farcry%20sm3%20benches_07010410708/2845.png

[Ailuros]

Ein kurzer Kommentar was FarCry generell und den SM3.0 path betrifft:

Es tut mir leid wenn ich die Begeisterung von vielen was das Spiel betrifft nicht teilen kann. Gut es hat fortschrittlicheres AI und sieht auch schoen aus, aber sonst kann ich generell die uebermaessig erscheinende Leistungsanforderung bei bestem Willen wirklich nicht verstehen.

Fuer mich haben hier die Entwickler grandios verpatzt und dabei ist es mir schnuppe welcher IHV mit was und wo gerade wirbt. Wieso noch bessere Bildqualitaet und zur gleichen Zeit bessere und balanciertere Leistung moeglich ist, werden wohl nur alternative zukuenftige Spiele beweisen koennen.

Was jetzt den zeitigen SM3.0 path im 1.2 patch betrifft, so sieht es eben nur nach Leistungssteigerungen fuer NV40 momentan aus durch "pass reduction". Ebenso sieht es so aus als ob die Leistungssteigerungen in den maps wo die NVIDIA demos laufen auch tatsaechlich real sind und man dieses auch in Echtzeit verfolgen kann.

Was man hier aber dem einfachem Verbraucher nicht sagt, ist dass in der breiten Mehrzahl von demos fuer FarCry (und auch wohl in diesen 4 von NVIDIA) kein einziger Schuss abgefeuert wird. Was ich hiermit meine ist dass der einfache Verbraucher die tollen 60-80 fps scores sieht und fast vom Hocker faellt. Dass er aber trotz allem zumindest 1.0GB host ram und einen =/> 3.0GHz auch noch haben sollte, wird ihm nicht so leicht erklaert und selbst dann sieht die Echtzeit-Leistung auch nicht genauso toll aus wie die diversen Benchmarks zeigen, ueberhaupt wenn eine gesunde Anzahl von Gegnern auf einen losballern.

Cliff notes: ein 8. Weltwunder ist FC fuer mich garantiert nicht. Nun ja man kann eben damit schoene "Gegner-lose" Screenshots mit normal erscheinenden Leistungsnummern aufnehmen und damit protzen, aber viel mehr sehe ich in dem Ding nicht. Von "re-playability" angesehen sagt mir der Titel unbedingt auch nichts.

[xL|Sonic]

D.h. also, dass wenn Crytek FC auch auf den R420 optimieren würde, dass sich dieser Performancegewinn vom nv40 gegenüber dem R420 durch den neuen Patch auch wieder egalisieren könnte?
Das wird aber wohl nie passieren, da nvidia anscheinend Crytek gut bezahlt...

[Al-CAlifAX]

Original geschrieben von Valmar
D.h. also, dass wenn Crytek FC auch auf den R420 optimieren würde, dass sich dieser Performancegewinn vom nv40 durch den neuen Patch auch wieder egalisieren könnte?
Das wird aber wohl nie passieren, da nvidia anscheinend Crytek gut bezahlt...


So wie Valve von Ati *fg*

Sorry konnte ich mir jetzt nicht verkneifen. ;)

[xL|Sonic]

Naja HL2 ist noch nicht raus, von daher kannst du bis jetzt schlecht rückschlüsse auf das fertige Spiel und die Performance ziehen.

[Gast]

Original geschrieben von Valmar

Das wird aber wohl nie passieren, da nvidia anscheinend Crytek gut bezahlt...

Nein, NVidia zahlt da nichts.

[Ailuros]

Original geschrieben von Valmar
D.h. also, dass wenn Crytek FC auch auf den R420 optimieren würde, dass sich dieser Performancegewinn vom nv40 durch den neuen Patch auch wieder egalisieren könnte?
Das wird aber wohl nie passieren, da nvidia anscheinend Crytek gut bezahlt...

Nein. Jegliche Anpassung im Spiel wird und wurde an die bis jetzt bekannten Faehigkeiten von SM3.0 komplianter HW von CryTek angepasst. Und nein das betrifft nicht ausschliesslich NV40.

Kurz gefasst: waere das Spiel nicht so schlecht entwickelt worden von Anfang an, gaebe es heute weniger Grund fuer jegliche Leistungs-Optimierungen.

Zum Rest, ganz unten stehen die Technologie-Partner von CryTek:

http://www.crytek.com/news/index.php?lang=deu&x=17&y=17

***edit:

genauer:

http://www.crytek.com/inside_crytek/index.php?s=partners

[xL|Sonic]

Wenn dem so nicht wäre, warum entwickelt Crytek dann den neuen Patch so einseitig, was die Grafikkarten angeht.
Ich meine Crytek schiesst sich doch so selbst in den Fuß, wenn man nur nvidia bevorzugt behandelt und man auf ATI Karten schlechtere Performance bekommt, obwohl da mehr drin ist. Das vergrault doch nur die Käufer und würde wohl keiner machen, wenn er da nicht irgendwie Geld für bekommen würde.

[xL|Sonic]

Original geschrieben von Ailuros
Nein. Jegliche Anpassung im Spiel wird und wurde an die bis jetzt bekannten Faehigkeiten von SM3.0 komplianter HW von CryTek angepasst. Und nein das betrifft nicht ausschliesslich NV40.

Kurz gefasst: waere das Spiel nicht so schlecht entwickelt worden von Anfang an, gaebe es heute weniger Grund fuer jegliche Leistungs-Optimierungen.


Nur warum bekommt dann nur der nv40 einen Performanceschub, wenn laut demirug viele der neuen Optimierungen (zumindest zum Teil)auch auf dem R420 machbar wären.

[Ailuros]

Original geschrieben von Valmar
Wenn dem so nicht wäre, warum entwickelt Crytek dann den neuen Patch so einseitig, was die Grafikkarten angeht.
Ich meine Crytek schiesst sich doch so selbst in den Fuß, wenn man nur nvidia bevorzugt behandelt und man auf ATI Karten schlechtere Performance bekommt, obwohl da mehr drin ist. Das vergrault doch nur die Käufer und würde wohl keiner machen, wenn er da nicht irgendwie Geld für bekommen würde.

a) Leistung fuer NV40 wird nur in manchen Stellen leicht besser und dann im Durchschnitt nicht mit mehr als 20%.

b) Ist NV40 wirklich generell schneller in FarCry als R420?

c) Eigentlich ob patch oder nicht patch die reale Leistung ist in den meisten Faellen bis jetzt viel zu optimistisch dargestellt. Normalerweise muesste man das ganze Spiel nochmal von Anfang entwickeln, um nutzlosen Bloedsinn loszuwerden.

d) ISVs versuchen stets so viel wie moeglich verfuegbare Features von diversen IHVs auszunutzen. Muss CroTeam von ATI "bezahlt" werden um 3dc in ihrer kommenden engine einzusetzen? Wenn sie dann noch irgendwelche "pass reduction SM3.0 paths" fuer NV4x benutzen sollten, dann "verdienen" sie nach der Logik oben, gleich doppelt so viel *seufz*

Uebrigens falls es Dir noch nicht aufgefallen ist, NVIDIA ist sowieso in den 4 (eigenen) demos meistens schneller als ATI mit dem SM2.0 path:

http://www.anandtech.com/video/showdoc.html?i=2102&p=7
http://www.anandtech.com/video/showdoc.html?i=2102&p=8
http://www.anandtech.com/video/showdoc.html?i=2102&p=9
http://www.anandtech.com/video/showdoc.html?i=2102&p=10

[Ailuros]

Original geschrieben von Valmar
Nur warum bekommt dann nur der nv40 einen Performanceschub, wenn laut demirug viele der neuen Optimierungen (zumindest zum Teil)auch auf dem R420 machbar wären.

Link?

[Gast]

Original geschrieben von Demirug
Der gute humus gehört ja jetzt auch zu ATI aber ich habe ein ganz anderes Problem mit dieser Demo.

Mit aktiviertem "Dynamic Branching" ist auf meiner 5900 langsamer als wenn man es ausschaltet. Ist das auf deiner R9800 anders?

Zudem hätte ich auch noch gerne die SM3 Lösung dazu gesehen. Die fehlt aber in der Demo. Aber das lässt sich ja lösen.


Abhilfe:


Found what was hurting NV cards :

changing
dev->SetRenderState(D3DRS_STENCILPASS, D3DSTENCILOP_ZERO);
to
dev->SetRenderState(D3DRS_STENCILPASS, D3DSTENCILOP_KEEP);

(Early Stencil kill doesn't work if your still writing to stencil??)


OK revised figures using FRAPS

1280x960
FALSE: 51
TRUE: 121 ish
DB PS2 (cmp) 54
DB PS3 (if then else) 65 ish


Link: http://www.beyond3d.com/forum/viewtopic.php?t=13716&postdays=0&postorder=asc&start=220&sid=00404410f20b1862fd561b19d1dee639

[Demirug]

Original geschrieben von Valmar
Nur warum bekommt dann nur der nv40 einen Performanceschub, wenn laut demirug viele der neuen Optimierungen (zumindest zum Teil)auch auf dem R420 machbar wären.

Meine Aussage war wohl etwas missverständlich.

Es gibt nur zwei neue Optimierungen

- Instancing. Das ist ein feature das das nur mit SM3 funktioniert.

- Zusammenfassen von bis zu 4 Lichtquellen in einem Pass. Bei SM3 funktioniert das immer. Bei SM2 gibt es Kombinationen von Licht und Materialtypen bei denen man 4 Lichtquellen nicht in die Limits reinbekommt. Crytek hätte sich also hier noch was überlegen müssen was die Anzahl der benötigen Passes für jede mögliche Kombination ermittelt. Das wäre im Vergleich zum "Allways go" beim SM3 natürlich ein zusätzlicher Aufwand gewesen.

Ich meinte daher mit "vielen" die Anzahl der Kombinationen bei denen auch bei einer SM2 Karte weniger Passes als jetzt notwendig wären. Wobei das besonders für die NV3X sowie den R420 gilt weil soweit ich das überblicken kann meist das Limit von 64 Rechenanweisungen das Problem ist.

[Gast]

Ach ja,

die Methode von Humus ist hier doppelt so schnell wie dynBranching (DB) auf dem NV40 ( 121 <-> 65 ).

Das ganze scheint sich also für alle Karten zu lohnen.

[Demirug]

@Gast, danke für die Info. Ich denke aber da muss dann noch ein Stencilclear rein. Mal mit meinem NV35 testen ob es da auch was bringt.

Update: Hat scheinbar keine Auswirkung. Alle Lichtquellen in einem Pass sind etwas doppelte so schnell wie jede Lichtquelle einzelen. Ein PS3 Shader mit allen Lichtquellen in einem Pass und Branching wäre vielleicht noch interesant.

[deekey777]

Original geschrieben von Valmar
D.h. also, dass wenn Crytek FC auch auf den R420 optimieren würde, dass sich dieser Performancegewinn vom nv40 gegenüber dem R420 durch den neuen Patch auch wieder egalisieren könnte?
Das wird aber wohl nie passieren, da nvidia anscheinend Crytek gut bezahlt...

Es gab auch Gerüchte, dass sich der Patch 1.2 nur deswegen verzögere, weil Crytek zusätzliche R420 Optimierungen einbauen will. Diese scheinen aber in diesem Patch (noch) nicht gegeben zu sein, vielleicht aber erst mit dem Patch 1.3 kommt ein verbesserter SM 2.0 Path in Hinblick auf die Möglichkeiten der NV3x bzw. R420.

[robbitop]

@Demirug

wie siehts denn mit dem NV3x aus, wäre da die Reduktion der 4 Lichtquellen auf einen Pass IMMER möglich?

[Demirug]

Original geschrieben von robbitop
@Demirug

wie siehts denn mit dem NV3x aus, wäre da die Reduktion der 4 Lichtquellen auf einen Pass IMMER möglich?

Bei der Vielzahl der Kombinationen kann man das natürlich mit 100% Sicherheit sagen wenn man nicht jede denkbare Kombination kennt.

Wenn man die Resourcennutzung (Interpolatoren) auf die gleiche Art betreibt wie beim SM3 Pfad gibt es allerdings auf jeden Fall Fälle bei denen man mehr Interpolatoren braucht als der NV3X hat.

Da die Interpolatoren aber nicht immer volständig genutzt werden könnte man das ganze durch Zusammenlegung gangbar machen.

Bevor jetzt noch die Frage nach dem R420 kommt. Auch dort würde das funktionieren allerdings ist das Zusammenlegen dort komplizierter weil dem Chip die Fähigkeit des freien Swizzle fehlt

[Gast]

Demirug,

kann man also sagen, dass 3.0 Shader für Entwickler eine wesentliche Vereinfachung des Codes bringen und daher vermutlich sehr schnell weit verbreitet eingesetzt wird?

[Demirug]

Original geschrieben von Gast
Demirug,

kann man also sagen, dass 3.0 Shader für Entwickler eine wesentliche Vereinfachung des Codes bringen und daher vermutlich sehr schnell weit verbreitet eingesetzt wird?

Wenn man in HLSL programmiert sind die Unterschiede nicht so gross das ich von einer wesentlichen Vereinfachung sprechen würde. Die SM3 Profile können in Grenzfällen eben noch Shader compilieren bei denen die SM2 Profile es nicht mehr schaffen. Das ist aber der einzige Punkt auf dieser Seite.

Wenn es nun um die Frage geht ob man eine neue Technologie einsetzten will/kann so kommt es immer darauf an von welcher Seite man kommt.

Hat man bereits einen Effekt und möchte man die neue technologie nutzen um diesen schneller oder schöner als bei der bisherigen Variante zu rendern oder hat man noch gar nichts?

Den ersten Fall haben wir ja gerade bei Farcry erlebt wobei hier schon die neuste Technologie benutzt wurde obwohl die schon lange vorhandene nicht voll ausgenutzt wurde.

Im zweiten Fall muss man sich natürlich Frage welche Technologiestufen man alles unterstützen möchte/muss. Auf der einen Seite will man ja einen möglichst grossen Markt und auf der anderen Seite aber natürlich auch der "Konkurrenz" vorraus sein. Hier muss man abwägen. Im Gegensatz zu früher sind die Kosten für den Einsatz neuster Technologien aufgrund der veränderten Umstände heute aber kleiner als bei den letzten Sprüngen.

- Fixed Funktion -> Shader : Engine musste erst auf DX8 geändert werden und die Editoren um eine möglichkeit Shader zu nutzen erweiter werden.

- Shader 1.1 -> Shader 1.4 : Inkompatibler Syntax und lange zeit nur ein Produkt mit Unterstützung.

- Shader 1.4 -> Shader 2.0 : Engineanpassung (aber einfacher als von 7 nach 8) und einfügen von HLSL Unterstüzung bzw wieder ein neuer Syntax.

- Shader 2.0 -> Shader 3.0 : Sowohl an der Engine wie auch an den Editoren sind keine Veränderungen erforderlich. Allerdings derzeit nur ein Produkt verfügbar und das zweite angekündigte ist im Spielebreich eher uninteresant.

Es wird also jedes Studio für sich eine entscheidung treffen müssen wie es die neue Technologien nutzen will. Ich würde mich aber aufgrund der einfacheit der SM3 benutzung nicht wundern wenn wir eine Menge angeblicher SM3 Titel zu sehen bekommen.

[Ailuros]

Original geschrieben von Gast
Demirug,

kann man also sagen, dass 3.0 Shader für Entwickler eine wesentliche Vereinfachung des Codes bringen und daher vermutlich sehr schnell weit verbreitet eingesetzt wird?

Erlaube eine persoenliche Schaetzung (und ja ich weiss dass die Frage an einen Entwickler gerichtet wurde und nicht an einen Laien):

Fuer Leistungs-Optimierungen in der Mehrzahl vielleicht schon. Falls sich aber die "FarCry-Story" wiederholen sollte dann kann es sein dass es am Ende nur dafuer kompensiert ATI's PS2.x Leistung zu erreichen oder stellenweise sogar zu uebertreffen. Viel was fortschrittlichere Effekte mit SM3.0 betrifft erwarte ich ehrlich gesagt dieses Jahr wohl nicht mehr; ausser CroTeam hat ein paar Ueberraschungen in der Pipeline, die mir nicht bewusst sind.

[Demirug]

Original geschrieben von Ailuros
Viel was fortschrittlichere Effekte mit SM3.0 betrifft erwarte ich ehrlich gesagt dieses Jahr wohl nicht mehr; ausser CroTeam hat ein paar Ueberraschungen in der Pipeline, die mir nicht bewusst sind.

Keiner ausser den beteiligten Entwicklern oder jemand der genau nachgeschaut hat wird dir sagen können ob ein Effekt nun mit SM2 oder SM3 erreicht wurde. Nur an einem Screenshot oder selbst einem bewegten Bild wird man sich nicht festlegen können. Oder wie soll man am Bild erkennen ob ein Partikelsyste jetzt durch die CPU und SM2 oder vollständig mit der GPU und SM3 berrechnet wurde.

Ich schrieb schon in einem anderen Thread das man sich von SM3 keine neuen Effekte erwarten sollte sondern nur die Möglichkeit Dinge jetzt in Echtzeit zu tun die vorher so nicht möglich waren.

[aths]

Original geschrieben von Demirug
Ich schrieb schon in einem anderen Thread das man sich von SM3 keine neuen Effekte erwarten sollte sondern nur die Möglichkeit Dinge jetzt in Echtzeit zu tun die vorher so nicht möglich waren. ... das würde ich schon als "neuen Effekte" bezeichnen. "Neue Effekte" ansich gibts kaum, da fast alles schon hergeleitet wurde, wie man im Kino sieht, kann man dem Fotorealismus schon sehr nahe kommen. Mit "neuen Effekten" meint man im Kontext "neue Effekte in brauchbarer Performance, und anständiger Quantität" – Echtzeitrendering wird immer Kompromisse machen: Offset-Mapping statt Displacement Mapping, weil man somit mehr Oberflächen verbessern kann, etc. pp. Image-based MDR-lighting im größeren Stil ist wohl erst ab NV40 in Echtzeitperformance zu schaffen, insofern würde ich das als neuen Effekt bezeichnen.

[Gast]

Original geschrieben von Demirug
@Gast, danke für die Info. Ich denke aber da muss dann noch ein Stencilclear rein. Mal mit meinem NV35 testen ob es da auch was bringt.


Stimmt:


Oops! missed a bit out - wasn't clearing the stencil buffer between passes.
Demo now runs :


1280x960
FALSE: 51
TRUE: 185 ish <- better
DB PS2 (cmp) 54
DB PS3 (if then else) 65 ish

I'll work on combining the individual light passes into a single SM2/3 pass and see how that works out...


und von jemand anderem :


the optimization can also be applied to NV3x/NV40 now, just change "dev->SetRenderState(D3DRS_STENCILPASS, D3DSTENCILOP_ZERO);" to "dev->SetRenderState(D3DRS_STENCILPASS, D3DSTENCILOP_KEEP);" and clear the stencil buffer after drawLighting call.

got 80FPS with optimization off and 230-250FPS with optimization on