Diskussion zu: Was bringt ein Pixelshader 3.0 Chip heute?

[Leonidas]

Link (http://www.3dcenter.org/artikel/2004/03-31_a.php)


Thx @ Demirug.




/Update 1.4. 20:42
Schreibfehler gefixt.

[mapel110]

hm, jetzt kommts drauf an, wie gut Nvidia es schafft, sowas im Treiber umzusetzen.

auf das neue 3dmark-theater kann man sich wohl auch wieder freuen. =)

btw Directx7-effekte schön und gut, aber warum sollte man dort noch Füllrate einsparen? bei diesen alten games rocken doch schon die aktuellen Karten. :grübel:

für die kleinen karten kann das wohl interessant sein, die zwar ps3.0 bieten werden, aber wohl weit weniger Füllrate und Bandbreite haben werden.

[x-dragon]

Danke für den Artikel :up:, endlich mal was konkreteres was das nun für Auswirkungen haben könnte.

Auf jeden Fall kann man sich dann wohl in Zukunft auf noch größere Treiber einstellen, damit bei bestimmten Spielen/Benchmarks auch wirklich alle möglichen Optimierungen ausgenutzt werden.
Original geschrieben von mapel110
...
für die kleinen karten kann das wohl interessant sein, die zwar ps3.0 bieten werden, aber wohl weit weniger Füllrate und Bandbreite haben werden. Das ist doch auch schon mal eine nette Sache für Nvidia, das ihre Lowcost-Produkte vielleicht sogar wirklich für Spiele nutzbar sind (zumindest für die "ältere"-Generation).

[Black-Scorpion]

Aufgrund der vielen verwendeten Texturwerte

Da fehlt ein n

'edit' Ist auf Seite 2.

[BodyLove]

Eins vorab auf Seite 2:
...Texturwerte ist dieser Shader natürlich hoffnungsloss durch die Füllrate limitiert. Die Verwendung...


Interessant. Ich dachte es wäre nur den Spieleentwickler möglich PS3.0 einzusetzen. Das dies auch via Treiber möglich sei, ist mir neu. Demzufolge kann man davon ausgehen, dass NV die Performence für Spiele, je "neuer" die Treiber werden, immer besser wird. Nur auf die Frage "wieviel besser" bleibst du uns eine Antwort schuldig Demirug. 1 - 5% Leistungszuwachst? 5 - 20%? Was ist realistisch?

edit: Klar, sehr gute Arbeit! Danke.

[Lightning]

Original geschrieben von BodyLove
Interessant. Ich dachte es wäre nur den Spieleentwickler möglich PS3.0 einzusetzen. Das dies auch via Treiber möglich sei, ist mir neu. Demzufolge kann man davon ausgehen, dass NV die Performence für Spiele, je "neuer" die Treiber werden, immer besser wird. Nur auf die Frage "wieviel besser" bleibst du uns eine Antwort schuldig Demirug. 1 - 5% Leistungszuwachst? 5 - 20%? Was ist realistisch?

edit: Klar, sehr gute Arbeit! Danke.

Dazu steht doch was am Ende des Artikels:

"Abschließend soll hier noch einmal ausdrücklich darauf hingewiesen werden, dass alle angesprochenen Optimierungen theoretischer Natur sind. Welche davon mit messbarem Erfolg von einem Pixelshader 3.0 Grafikchip und den dazugehörigen Treibern wirklich realisiert werden können, müssen wir schlicht abwarten."


Der Artikel ist auf jeden Fall gut gelungen. Sehr informativ :)

[BodyLove]

Tja, auch dies hatte ich gelesen.:) Nur hätte ich mir eine kleine Spekulation gewünscht. Im Artikel wäre hierfür kein Platz, aber im Forum möglicherweise.;)

[Sk_Antilles]

Fragt sich nur, ob der Aufwand Sinn hat, denn:

1) Sind das in der Regel schon ältere Spiele, die eh keiner mehr neu kauft und
2) Werden die NextGen Karten so viel Power bieten, dass der Unterschied garnicht zu merken ist. Eventuell würde es sich für die Low-End Karten von der Performance her lohnen - aber vom Treiberaufwand...?

Imho wie schon im Artikel abschließend erwähnt alles nur von theoretischer Natur.

Sk_Antilles

[Demirug]

Original geschrieben von Sk_Antilles
Fragt sich nur, ob der Aufwand Sinn hat, denn:

1) Sind das in der Regel schon ältere Spiele, die eh keiner mehr neu kauft und
2) Werden die NextGen Karten so viel Power bieten, dass der Unterschied garnicht zu merken ist. Eventuell würde es sich für die Low-End Karten von der Performance her lohnen - aber vom Treiberaufwand...?

Imho wie schon im Artikel abschließend erwähnt alles nur von theoretischer Natur.

Sk_Antilles

1. Ich würde Farcry (Texkill) und UT2004 (0*X = 0) nicht unbedingt als ältere Spiele ansehen. Zudem lassen sich die Verfahren auch auf Spiele anwenden die jetzt erst noch erscheinen und bei dennen es nVidia nicht geschaft hat die Entwickler von den PS 3.0 Vorzügen zu überzeugen.

2. Man wird auch die NextGen Karten an den Anschlag bringen wenn man die Settings nur entsprechend aufwendig wählt. Und wie du schon schreibst profitieren ja auch die "kleineren Karten" davon was man wieder als Verkaufsargument ausschlachten kann.

Natürlich es is derzeit noch von theoretischer Natur weil es die Karten ja noch nicht gibt um die Umsetzung zu überprüfen.

[Gast]

Original geschrieben von Demirug
1. Ich würde Farcry (Texkill) und UT2004 (0*X = 0) nicht unbedingt als ältere Spiele ansehen. Zudem lassen sich die Verfahren auch auf Spiele anwenden die jetzt erst noch erscheinen und bei dennen es nVidia nicht geschaft hat die Entwickler von den PS 3.0 Vorzügen zu überzeugen.

2. Man wird auch die NextGen Karten an den Anschlag bringen wenn man die Settings nur entsprechend aufwendig wählt. Und wie du schon schreibst profitieren ja auch die "kleineren Karten" davon was man wieder als Verkaufsargument ausschlachten kann.

Natürlich es is derzeit noch von theoretischer Natur weil es die Karten ja noch nicht gibt um die Umsetzung zu überprüfen.

Das ist eine wunderbare Story !

PS3.0 ist NICHT durch den Treiber alleine realisierbar, weiterhin bedeutdet PS3.0 nur einen vereinfachten Weg der
der Berechnungen im Spiel.

Brisant finde ich nur das der Grund für PS3.0 Support bei NV40 das alte Lied bedeutet, FP16 und FP32, d.h, nv hat es nicht geschafft die Performance-Lücke hinsichtlich FP16-Berechnungen die auf PS2.0 zurückgreifen zu schliessen.

Da der R420 auf volle FP16 und PS2.0 Leistung zurückgreifen kann erwarte ich trotz PS3.0 Support bei Farcry und UT2004 von NV40 einen klaren Vorteil für den R420.

[Quasar]

Wie kommst du darauf?

[ow]

.

[zeckensack]

Demirug,
hat NVIDIA nicht bei irgendeiner GDC-Präsentation gesagt, dass das Branching auf NV40 die üblichen SIMD-Schwächen hat? Ging ~ so:
"Performance depends on split of fragments between branch targets"
*linkleiderverlegthat*
*ganzsicherkeinenaprilscherzmach*

edit:
Hier (http://download.nvidia.com/developer/presentations/GDC_2004/gdc_2004_OpenGL_NV_exts.pdf) (PDF), Seite 23.
_______
Fragment Program Branching
Performance
Static branching is fast
– But still may not be worth it for short branches (less than ~5 instructions)
– Can use conditional execution instead
Divergent (data-dependent) branching is more expensive
– Depends on which pixels take which branches

[Demirug]

Original geschrieben von zeckensack
Demirug,
hat NVIDIA nicht bei irgendeiner GDC-Präsentation gesagt, dass das Branching auf NV40 die üblichen SIMD-Schwächen hat? Ging ~ so:
"Performance depends on split of fragments between branch targets"
*linkleiderverlegthat*
*ganzsicherkeinenaprilscherzmach*

edit:
Hier (http://download.nvidia.com/developer/presentations/GDC_2004/gdc_2004_OpenGL_NV_exts.pdf) (PDF), Seite 23.
_______
Fragment Program Branching
Performance
Static branching is fast
– But still may not be worth it for short branches (less than ~5 instructions)
– Can use conditional execution instead
Divergent (data-dependent) branching is more expensive
– Depends on which pixels take which branches

Natürlich. Bei nebeneinander liegenden Pixel ist aber mit einer gewissen Wahrscheinlichkeit damit zu rechnen das sie den gleichen Weg nehmen und damit eine Beschleunigung erfahren.

[Gaestle]

Super Artikel! :up:

Eine Anmerkung zum Artikel:
IMHO wird in der Grafik nicht (zumindest nicht direkt) angezeigt, wie hoch die EINSPARUNG ist.
Ich würde die Grafik so beschreiben, dass angezeigt wird, wieviel (ANTEIL) der "ursprünglich" anfallenenden Arbeit noch zu tun ist, wenn bei dem Verhältnis X:Y Z% der "ursprünglich" zu zeichnenden Pixel gespart/weggefiltert werden.
Also es geht darum, dass derjenige Anteil angezeigt wird, der noch übrig bleibt. Angezeigt wird quasi die Invertierung der Einsparung (und somit der übrig bleibende Arbeitsanteil), denn die Einsparung ist die Differenz des Graphen zum obersten Ende der Y-Achse (vertikal).
Alles IMHO natürlich.

Zur Diskussion:
Natürlich bringt das auch im Low-End-Sektor was, eigentlich zunächst nur dort. Die nächsten Spiele werden sicherlich durch die High-End-HW super darzustellen sein, mit allen Effekten etc.; alleine wegen der RAW-Power der Dinger. Interessant wird's doch aber, wenn im (meistverkauften) Low-End-Bereich z.B. UT2004 noch richtig gut spielbar läuft, so dass Low-End damit auf einmal (besser als jetzt) zum zocken taugt (und damit besser verkauft wird)...

[zeckensack]

Original geschrieben von Demirug
Natürlich. Bei nebeneinander liegenden Pixel ist aber mit einer gewissen Wahrscheinlichkeit damit zu rechnen das sie den gleichen Weg nehmen und damit eine Beschleunigung erfahren. 'türlich. Dort steht nun aber mehr oder weniger im Klartext, dass statisches Branching mindestens 5 Takte kostet und dynamisches Branching "more expensive" ist.
Und zwar steht da ganz generell "more expensive", und eben nicht mit zB der Einschränkung "wenn verschiedene Wege gegangen werden".

Das ist mir viel zu vorsichtig formuliert. NVIDIA würde es IMO klipp und klar so sagen, wenn es so wäre. Es wäre in ihrem Interesse.

[Demirug]

Original geschrieben von zeckensack
'türlich. Dort steht nun aber mehr oder weniger im Klartext, dass statisches Branching mindestens 5 Takte kostet und dynamisches Branching "more expensive" ist.
Und zwar steht da ganz generell "more expensive", und eben nicht mit zB der Einschränkung "wenn verschiedene Wege gegangen werden".

Das ist mir viel zu vorsichtig formuliert. NVIDIA würde es IMO klipp und klar so sagen, wenn es so wäre. Es wäre in ihrem Interesse.

Wo steht da was von Takten? Da steht was von 5 Anweisungen. 1 Anweisung != 1 Takt.

[Demirug]

Original geschrieben von zeckensack
'türlich. Dort steht nun aber mehr oder weniger im Klartext, dass statisches Branching mindestens 5 Takte kostet und dynamisches Branching "more expensive" ist.
Und zwar steht da ganz generell "more expensive", und eben nicht mit zB der Einschränkung "wenn verschiedene Wege gegangen werden".

Das ist mir viel zu vorsichtig formuliert. NVIDIA würde es IMO klipp und klar so sagen, wenn es so wäre. Es wäre in ihrem Interesse.

Wo steht da was von Takten? Da steht was von 5 Anweisungen. 1 Anweisung != 1 Takt.

Ungenauigkeiten bin ich von den IHVs gewöhnt wenn es um Leistungsverhalten geht. Die Daten bekommt man in der Regel immer erst 6-12 Monate zu spät.

[ram]

Original geschrieben von zeckensack
'türlich. Dort steht nun aber mehr oder weniger im Klartext, dass statisches Branching mindestens 5 Takte kostet und dynamisches Branching "more expensive" ist.
Und zwar steht da ganz generell "more expensive", und eben nicht mit zB der Einschränkung "wenn verschiedene Wege gegangen werden".

Das ist mir viel zu vorsichtig formuliert. NVIDIA würde es IMO klipp und klar so sagen, wenn es so wäre. Es wäre in ihrem Interesse.

In einer anderen GDC-Präsentation meinte NVDA noch, dass Fragment Program branches generell teuer seien und auch "not cheap in near future" sein werden.

[Demirug]

Original geschrieben von ram
In einer anderen GDC-Präsentation meinte NVDA noch, dass Fragment Program branches generell teuer seien und auch "not cheap in near future" sein werden.

Den Spruch habe ich AFAIR so nur bei ATI gesehen.

[ram]

Original geschrieben von Demirug
Den Spruch habe ich AFAIR so nur bei ATI gesehen.

Ich bin 100% sicher dass es eine NVDA doc war.

[zeckensack]

Original geschrieben von Demirug
Wo steht da was von Takten? Da steht was von 5 Anweisungen. 1 Anweisung != 1 Takt.Ja, da hast du natürlich auch wieder recht.
Wieviele Anweisungen pro Takt gestartet werden können, kann und will ich (noch) nicht wissen.

Ich bin davon ausgegangen, dass es eine Instruktion pro Takt (pro Fragment) ist, was natürlich spekulativ war.
Ungenauigkeiten bin ich von den IHVs gewöhnt wenn es um Leistungsverhalten geht. Die Daten bekommt man in der Regel immer erst 6-12 Monate zu spät.Ungenauigkeiten gibt's AFAICS immer nur da, wo es Details zu verheimlichen gilt. Parhelia: "it is fast".

Eine positive Produkteigenschaft, noch dazu wenn es eine ist, die die Konkurrenz nicht bieten kann, wird man dagegen immer so früh wie möglich herausposaunen. Eben wie in diesem Falle das Branching. Das verlinkte PDF ist dahingehend sehr freizügig und detailliert. Das einzige was fehlt, ist eine klare Performanceangabe.
*schulterzuck*

[Demirug]

Original geschrieben von ram
Ich bin 100% sicher dass es eine NVDA doc war.

Habe es gefunden. Ist im GPGPU Dokument auf Seite 26.

Ist aber wie Zeckensack schon sagt auch nicht näher spezifiziert wie "teuer" es nun genau ist. Es wird aber wohl bald Tests dazu geben.

[Demirug]

Original geschrieben von zeckensack
Ja, da hast du natürlich auch wieder recht.
Wieviele Anweisungen pro Takt gestartet werden können, kann und will ich (noch) nicht wissen.

Ich bin davon ausgegangen, dass es eine Instruktion pro Takt (pro Fragment) ist, was natürlich spekulativ war.

Hoch spekulativ. Wenn man bedenkt das der R300 ja auf 3 Anweisungen pro Takt ausgelegt ist und unter bestimmten Umständen ja noch mehr kann.

[loewe]

Ich weiß auch nicht wie teuer was ist und wird bei Shader 3 Hardware, aber mal die folgende Überlegung:

Wenn kein IF Bedingung THEN Anweisung1 ELSE Anweisung2 dann muss zwar immer alles berechnet werden, aber es kann auf das IF verzichtet werden.
Wenn IF jetzt 1 Takt kostet aber 5 Takte sparen kann lohnt es erst bei mehr als 20% möglicher Einsparung.

Bsp.:

100 Takte Verlust durch IF

20*5 Takte=100 Takte Einsparung bei 20%

50*5 Takte=250 Takte Einsparung bei 50% hier lohnt der Aufwand wirklich!


Es ist auf jeden Fall sehr gut zu überlegen wann der Aufwand für solche Konstruktionen lohnt.
Diese Überlegung basiert (leider) nicht auf meiner eigenen Idee. :)

[Demirug]

Original geschrieben von loewe
Ich weiß auch nicht wie teuer was ist und wird bei Shader 3 Hardware, aber mal die folgende Überlegung:

Wenn kein IF Bedingung THEN Anweisung1 ELSE Anweisung2 dann muss zwar immer alles berechnet werden, aber es kann auf das IF verzichtet werden.
Wenn IF jetzt 1 Takt kostet aber 5 Takte sparen kann lohnt es erst bei mehr als 20% möglicher Einsparung.

Bsp.:

100 Takte Verlust durch IF

20*5 Takte=100 Takte Einsparung bei 20%

50*5 Takte=250 Takte Einsparung bei 50% hier lohnt der Aufwand wirklich!


Es ist auf jeden Fall sehr gut zu überlegen wann der Aufwand für solche Konstruktionen lohnt.
Diese Überlegung basiert (leider) nicht auf meiner eigenen Idee. :)

Die Sache enthält IMHO einen Denkfehler. Wenn man immer beide Möglichkeiten berechnet braucht man nachdem beide Berechnungen abgeschlossen sind noch einen MUX der dynamisch das richtige der beiden Ergebnisse auswählt. Werden in den beiden zweigen mehr als ein Ergebniss erzeugt braucht man mehr als einen MUX. Letzen Endes ersetzt man das IF also nur durch einen MUX.

[loewe]

Original geschrieben von Demirug
Die Sache enthält IMHO einen Denkfehler. Wenn man immer beide Möglichkeiten berechnet braucht man nachdem beide Berechnungen abgeschlossen sind noch einen MUX der dynamisch das richtige der beiden Ergebnisse auswählt. Werden in den beiden zweigen mehr als ein Ergebniss erzeugt braucht man mehr als einen MUX. Letzen Endes ersetzt man das IF also nur durch einen MUX.

Da hast du natürlich recht, wenn es sich um eine echte Alternative handelt, also entweder nur Anweisung1 oder Anweisung2 ausgeführt werden darf.

Ist es aber nicht oft so, dass Anweisung2 eine nicht unbedingt notwendige Anweisung1 einfach überschreibt?
Also eher ein Konstrukt wie:

IF Bedingung THEN Anweisung1;
Anweisung2;

In dem Fall könnte ich unter der Bedingung Anweisung1 zwar sparen, sollte mir aber überlegen ob der Preis dafür nicht zu hoch ist.

Es bleibt auf jeden Fall trickreich. Die Leute die sich mit solcher Hardware beschäftigen warnen auf jeden Fall vor zu großen Erwartungen bezüglich der dynamischen Verzweigungen. ;)

[Demirug]

Original geschrieben von loewe
Da hast du natürlich recht, wenn es sich um eine echte Alternative handelt, also entweder nur Anweisung1 oder Anweisung2 ausgeführt werden darf.

Ist es aber nicht oft so, dass Anweisung2 eine nicht unbedingt notwendige Anweisung1 einfach überschreibt?
Also eher ein Konstrukt wie:

IF Bedingung THEN Anweisung1;
Anweisung2;

In dem Fall könnte ich unter der Bedingung Anweisung1 zwar sparen, sollte mir aber überlegen ob der Preis dafür nicht zu hoch ist.

Anweisung1 würde aber in diesem Fall aber auch Register verändern und diese Änderungen dürfte ja nicht durchgeführt werden wenn die "Bedingung" nicht erfüllt ist. Also letzten Endes doch wieder ein Mux der zwischen dem Wert vor der Durchführung von Anweisung1 und nach der Durchführung von Anweisung1 wählt.

Es bleibt auf jeden Fall trickreich. Die Leute die sich mit solcher Hardware beschäftigen warnen auf jeden Fall vor zu großen Erwartungen bezüglich der dynamischen Verzweigungen. ;)

Natürlich ist es Trickreich. Im wesentlichen ist es aber nur der SIMD Aufbau der Pixelprozessoren der Probleme macht sowie der Einsatz von VLIW. VLIW hat nun mal den Nachteil das bei Brachnes mit kurzen Zweigen bestimmte Teileinheiten der Pipeline einfach keine Arbeit zugewiessen bekommen können. nVidia gibt an dieser Stelle ja auch Predications den Vorzug. Sinnvollerweise sollte der Treiber das aber selbst entscheiden. IMHO hat nVidia nicht umsonst von "Breit und Kurz" gesprochen.

Ansonsten muss man sich bei Aussagen bezüglich der möglichen Performance zum Branching bei GPUs IMHO derzeit auch die mögliche Motivation der Quelle mit in Betracht ziehen.