News Nvidia und die „Power of 3“

[Lübke]

Die Frage ist aber auch dort wieder was das Ergebnis leisten muss. Exakt wird es nicht sein.

oh glaub mir, in der automobilindustrie bei der entwicklung von karosserien muss schon sehr exakt sein, sonst könnten die unter umständen ne ganze serie wieder einstampfen, weil die sicherheit nicht gewährleistet ist. was so eine rückrufaktion kosten würde, wage ich nicht mal abzuschätzen.

in deinem beispiel ist ja immer nur ein einziges objekt in bewegung. das ist wohl nicht geeignet um den sinn oder unsinn von parallelen berechnungen aufzuzeigen oder? wenn aber andere kugeln in der rollbahn der sich bewegenden kugel befinden, müssen diese zeitgleich mitberechet werden, damit der lauf exakt bleibt.
konstruiere mal ein beispiel mit mehreren sich bewegenden kugeln. dann wirst du sehn, dass du den verlauf von einer kugel nicht ohne den verlauf der anderen kugeln berechnen kannst, weil du sonst nicht weis, wann und wie dieser beeinflusst wird. du musst immer alle variablen kennen.

die cpu muss die berechnungen nacheinander anstellen und dann nachträglich die kollisionen bereinigen und wieder neu rechnen, die gpu kann alle bahnen zeitgleich berechnen und kennt daher von vornherein alle variablen. das spart zeit.

beispiel: beim billard sind alle kugeln in bewegung. kugel 1 rollt ohne hindernis, kugel 2 rollt ohne hindernis, kugel 3... kugel 11 kollidiert mit kugel 7. jetz rollt kugel 7 in die bahn von kugel 2 (bisher ohne kollision) und kollidiert. das hat zur folge, dass diese kugel 4 aus ihrer ursprünglich berechneten bahn wirft. alle berechnungen bis kugel 11 sind damit wieder hinfällig.

 

[Realsmasher]

die gpu kann alle bahnen zeitgleich berechnen

wovon aber im je nachdem ziemliche viele wieder verworfen werden müssen.

Und im Gegensatz zur Berechnung auf einem Prozessorkern ist das deutlich aufwändiger aufgrund der langen Kommunikationswege zwischen den Recheneinheiten.


Letztendlich wird man zu einem Punkt kommen an dem man entweder auf eine nachträgliche Bereinigung verzichten muss (so wie das bei cellfactor z.b. sehr schön zu sehen ist) oder aber einen Performanceeinbruch hinnehmen muss, da die sequentielle Leistung nicht ausreicht für die einzelnen sich ergebenen Situationen.


Warum ausgerechnet sie Autoindustrie diese Technik einsetzt ist mir dennoch schleierhaft. Bei einem zusammenhängenden Modell gibt es doch viel bessere Möglichkeiten das zu verwalten.

Eine schöne Gitter-Struktur, z.b. auf einem fgpa, kann da wunder wirken -> eine Erregung an einer Recheneinheit wird an die Nachbarn mit einem Faktor multipliziert weitergegeben.

Das würde eine aktuelle gpu um Längen schlagen in Sachen Performance und wäre zudem noch genauer, da in sich sequentiell gerechnet wird nur über viele Takte.

Scheint dann wohl eher eine Kostenfrage zu sein...

 

[Lübke]

wovon aber im je nachdem ziemliche viele wieder verworfen werden müssen.

warum sollte man auch nur eine berechnung verwerfen müssen? wie gesagt, bei der gpu-lösung sind alle variablen zeitgleich bekannt. da kann man den gesamten ablauf für sämtliche objekte kontinuierlich berechnen, da jede kollision und jede richtungsänderung unmittelbar für die berechnung sämtlicher objekte verfügbar ist.

 

[Realsmasher]

Dann sag mir doch wie du das Beispiel auf der vorigen Seite parallelisierst.

Es gibt nunmal Abläufe die nicht parallelisierbar sind und die kann man vorher nicht erkennen.

da kann man den gesamten ablauf für sämtliche objekte kontinuierlich berechnen

schon wieder dieses kontinuierlich...

Mich würde mmal brennend interessieren welche kontinuierliche Funktion du berechnen willst(Grad der Funktion, etc), im Hinterkopf dabei natürlich die Geschwindigkeit der Berechnung.

Entweder du verwechselst die Begriffe oder du schätzt den Mehraufwand völlig falsch ein.

 

[Lübke]

Dann sag mir doch wie du das Beispiel auf der vorigen Seite parallelisierst.

meinst du dein beispiel, wo sich immer nur ein objekt bewegt? wie willst du eins paralellisieren? Oô eine anzahl kleiner 1 gibts ja wohl nicht. hast du meinen post dazu gar nicht gelesen?

Mich würde mmal brennend interessieren welche kontinuierliche Funktion du berechnen willst(Grad der Funktion, etc), im Hinterkopf dabei natürlich die Geschwindigkeit der Berechnung.

Entweder du verwechselst die Begriffe oder du schätzt den Mehraufwand völlig falsch ein.

damit ist gemeint, dass die berechnung nur bis zur ersten kollision berechnet wird und dann mit den geänderten werten (richtung, geschwindigkeit, etc) weitergerechnet wird bis zur nächsten kollision und dann wieder mit den neuen werten bis zur nächsten usw usf. kennst du einen simpleren und effektiveren weg?

 

[Realsmasher]

meinst du dein beispiel, wo sich immer nur ein objekt bewegt? wie willst du eins paralellisieren?

warum eins ? es sind sind 3, könnten aber auch 100 sein.

Die Sache ist das Kollisionen praktisch immer mit genau einem anderem Objekt erfolgen.

Ob du nebenher 100 anderen bewegen kannst ist irrevelant, der längste Berechnungsweg bestimmt die Performance.

dass die berechnung nur bis zur ersten kollision berechnet wird und dann mit den geänderten werten (richtung, geschwindigkeit, etc) weitergerechnet wird bis zur nächsten kollision und dann wieder mit den neuen werten bis zur nächsten

Die Sache ist dies auf einer gpu nicht funktioniert, weil dazu viel zu viele Werte zu jeweils allen anderen Recheneinheiten propagiert werden müssten (broadcast).

Auf einer gpu gibt es schlichtweg keine interne Struktur welche dies in annehmbarer Zeit ermöglicht.

Selbst bei einem extra entworfen chip dürfte es äußerst schwierig werden, wenn nicht gar unmöglich, zig oder gar hunderte Recheneinheiten mit geringem Delay zu vernetzen.

Du hast demnach keine Möglichkeit im Ganzen immer mit aktuellen Werten zu rechnen ab einem bestimmten Parallelitätsgrad.

 

[Konti]

schon wieder dieses kontinuierlich...

Kontinuierlich ist im Computer (bzw. der digitalen Welt generell) ohnehin nichts.

Allerdings tut man bei gewissen Dingen gut daran, die Auflösung hoch zu halten, da es sonst "Aliasing" gibt. Fraglich, ob man den Begriff hier überhaupt verwenden kann, aber das Problem besteht.
Je höher die (hier zeitliche) Auflösung einer Physik-Berechnung ist, desto weniger (Clipping-)Fehler gibt es.

Klar kann man auch bei geringerer Auflösung solche Fehler verhindern, indem man Zwischenschritte da einführt, wo es nötig ist, oder auf andere weise "trickst". Aber je mehr zwischen zwei regulären Schritten passiert, desto komplizierter wird es. Und ich denke genau hier muss man noch feilen ... bei CPU-Physik sowie GPU-Physik, denn zumindest die Techniken, die heutzutage in Spielen implementiert sind (egal ob von GPU oder CPU berechnet) weisen noch recht viele Fehler auf.

Ich nehme an, es ist hier ähnlich wie beim digitalen Audio-Processing. Um Aliasing zu verhindern kann man entweder die Auflösung in's unermessliche hochschrauben (was dann allerdings sehr viel Performance kostet), oder man findet andere Tricks und Wege um so etwas zu verhindern. Nur scheint das eben nicht einfach zu sein und einiges an Ingenieursarbeit zu fordern.

Die Physik-Berechnung jedoch an die ausgegebenen FPS zu koppeln macht wirklich überhaupt keinen Sinn.



Und sagmal Realsmasher:
Hast du denn schonmal irgendetwas in der Richtung gemacht, oder wieso bist du so überzeugt davon, daß eine GPU total ungeeignet für sowas ist, wobei jedoch alle namhaften Größen das Gegenteil behaupten?

 

[Lübke]

Die Sache ist das Kollisionen praktisch immer mit genau einem anderem Objekt erfolgen.

das ist definitv nicht so. stoß beim billard an und du hast 16 objekte, die im ersten moment mit 1-3 anderen objekten zeitgleich kollidieren.

in deinem beispiel liegt der fokus immer nur auf einer kugel die sich grade bewegt. im moment der kollision ist dann die nächste kugel im fokus. ergo: ein aktives objekt. ansonsten musst du auch die bahn der anderen beiden kugeln weiterberechnen. dann kannst du aber alle drei kugeln parallel berechnen, sprich auch die bahn von kugel 1 wenn kugel 2 schon rollt und ebenso kugel 3 (ob sie überhaupt die kugel 2 kreuzt und kollidiert). was ist daran so schwer zu verstehen?
in deinem beispiel ist der weitere verlauf von kugel 1 unbekannt und auch der von kugel 2.

ersetzt "kontinuierlich" durch "sukzessive" wenn ihr schwierigkeiten mit dem begriff habt. passt vllt auch besser. aber ich habs ja auch schon erläutert.

 

[Realsmasher]

@ Lübke : wie auch immer du es beschreibst, es bleibt dabei das du die angegebenen 6 Schritte brauchst.

Du kannst vielleicht noch viel drumherum rechnen während der gleichen zeit, aber unter diesen 6 Schritten geht es nicht und hier ist der Flaschenhals.

Hast du denn schonmal irgendetwas in der Richtung gemacht, oder wieso bist du so überzeugt davon, daß eine GPU total ungeeignet für sowas ist

Ich entwerfe parallele Schaltungen (echt parallel, mit direkter Vernetzung, nicht derart verkrüppelte Kommunikation) und denke schon das ich einigermaßen ein Gefühl dafür habe.

Insbesondere wenn man mehrere hundert elementare Operationen parallel ausführt ist es von essentieller Bedeutung zu wissen ob etwas überhaupt mit der gegebenen Struktur möglich ist oder ob man sich nur über Umwege(z.b. Approximation) behelfen kann.

Gpus sind nunmal für unabhängige Abläufe erfunden worden und nicht für die wirkliche Zusammenarbeit der einzelnen Recheneinheiten.

Das man sie mit Einschränkungen dazu missbrauchen kann ist richtig, das heißt aber auch das man mit diesen Einschränkungen leben muss.

Diese Einschränkung ist nunmal das a nicht weiß was b macht und das muss man akzeptieren wenn man diese Struktur nutzt.

 

[Lübke]

Du kannst vielleicht noch viel drumherum rechnen während der gleichen zeit, aber unter diesen 6 Schritten geht es nicht und hier ist der Flaschenhals.

ich glaube, du verstehst nicht ganz was ich sagen will. klar kann man bei deinem beispiel, wo es immer nur eine option gibt und auch nur ein objekt im fokus steht auch nur eine berechnug gleichzeitig durchführen. dein beispiel bedarf aber auch gar keiner physik, sowas würde man eh skripten, denn es gibt bei deinem beispiel gar keine variablen.

nimm einfach mein beispiel mit mehr als einem sich bewegenden objekt. von hand lässt sich da gar nix mehr berechnen, da jedes objekt einfluss auf jedes andere nehmen kann und so eine einzelberechnung erst dann gültigkeit hat, wenn alle anderen berechnungen ebenfalls durchgeführt wurden und es dabei zu keiner kollision gekommen ist. andernfalls musst du ab dem zeitpunkt der kollison alle berechnungen wieder über den haufen werfen und mit den neuen parametern neu rechnen. der rechenaufwand wäre enorm und ziemlich ineffizient.
aber wir drehen uns im kreis. ich diskutiere eigentlich immer ganz gern mit dir, aber hier reden wir die ganze zeit iwie aneinander vorbei und ich weis nicht, wie ich dir begreiflich machen soll, was ich meine.

 

[Realsmasher]

geht mir genauso...

Ich will eigentlich nur deutlich machen, das es Abläufe gibt die mehr Berechnungszeit bedürfen als die der Nachbarn.

Wenn du 10 Objekte mal parallel berechnest, dann werden nicht alle 10 Recheneinheiten die gleiche Zeit benötigen, weil sich an bestimmten Positionen mehr Kettenreaktrionen ergeben als an anderen Positionen.

Und diese Ketten sind es, welche zusammen mit der lausigen Kommunikationsfähig der einzelnen Recheneinheiten in GPUs die Performance bestimmten, weil sie sich nicht durch mehr Recheneinheiten beschleunigen lassen.


Der einzige Weg darum ist es sie zu ignorieren.

 

[Lübke]

klar, die geschwindigkeit passt sich (zwangsläufig) bei paralleler berechnung natürlich an die jeweils langsamste berechnung an, aber wenn du jede berechnung nacheinander anstellst, dann hast du nicht nur die dauer der langsamsten berechnung sondern die summer der dauer aller berechnungen die sonst parallel verlaufen würden, richtig?

 

[Realsmasher]

durchaus korrekt, aber nicht relevant.

Eine gpu ist schon an sich sequenziell wesentlich langsamer und durch die ewig dauernde Kommunikation wird das weiter verringert.

Letzteres entfällt bei einem einzelnen cpu Kern fast völlig aufgrund der lokal vorliegenden Daten.


Ich würde die sequentielle Leistung einer cpu derzeit wenigstens beim 5-fachen ansetzen, je mehr Objekte berechnet werden, umso höher der Komm-Aufwand und umso mehr bricht die GPU ein.

Aber lassen wir mal den Faktor 5.

Nun ist die Frage : wieviel % der Berechnung sind rein sequentiell zu erledigen ?

Wenn wir großzügig sind und der gpu unendlich viele Recheneinheiten geben, dann dürfte maximal 20% sequentieller Anteil dabei sein damit die gpu überhaupt noch so schnell ist wie die cpu.

Da fragt sich doch ob das realistisch ist.


Insbesondere aber zeigt sich folgendes : mehr Recheneinheiten als wir heute haben bringen keinen relevanten Vorteil mehr.


Und das Fazit bleibt wieder das gleiche : Die Performance wird rein von dem seq. Anteil bestimmt, so wie das bei allen Problemen mit relevant großen seq. Anteil ist.



Und diesem Problem sind die Ageia, Nvidia und Timeline(als Beispiel) durchaus bewusst.

Die hundmiserable gpu-physx-Kollision, in Cellfactor etwa, rührt nicht aus einer Unfähigkeit heraus, sondern aus dem Mangel an sequentieller Leistung die dafür nötig wäre.


Viel lieber inszeniert man aufwändig konstruierte Partikeleffekte oder ähnliches, was WIRKLICH von der zugrunde liegenden Architektur profitiert.


Und dem stimme ich zu. Dafür ist eine gpu geeignet, dafür sollte man sie benutzen.

Aber man sollte nicht den Pferdekarren hinters Schwein spannen nur weil man meint das alles mit 4 Beinen geeignet ist als Zugtier.

 

[Lübke]

ich denke, dass der anteil deutlich höher liegt. nicht vergessen, wir reden hier ja von den splittern einer explosion beispielsweise. bisher ist nur eine gpu (oder ppu) im stande, 1024 objekte gleichzeitig zu berechnen. mit einer cpu ist das meines wissens noch nicht gelungen. die physikberechnung ist ja ein prozess für sich. was den spielablauf und die grafische darstellung anbelangt, was dann auf dem chip noch so berechnet wird, bleibt ja davon unberührt. da gehen nur die vorberechneten flugbahnen hin.

ich bin der meinung dass eine cpu bei wenigen objekten noch im vorteil ist, aber je mehr objekte gleichzeitig zu berechnen sind, des so mehr verschiebt sich der vorteil zu gunsten der gpu. interessant hierbei wäre für mich, wo die kritische menge liegen würde beim vergleich q9550 zu gtx260 (um nicht ganz ins highend abzuschweifen) und ob ich mit meiner vermutung richtig liege, dass gpu-physik auf einer ati hd4k aufgrund ihrer 5d-shader gegenüber der gtx2 mit ihren 1d-shadern vorteile hätte. denn imho bekommt man kaum eine gleichmäßigere auslastung aller 5-teilshader hin als bei dieser berechnung.

 

[Realsmasher]

bisher ist nur eine gpu (oder ppu) im stande, 1024 objekte gleichzeitig zu berechnen

Warum sollte das nur mit einer gpu funktionieren ?

Die Frage ob das geht entscheidet sich genau wie bei einer gpu nur aus der Tatsache wie lang die Ereignisketten sind.


1024 Objekte kann man sogar recht problemlos auf einer cpu kollidieren lassen.
Wenn es zu keiner kollision kommt sind das gerade mal ~1mio Fälle die zu prüfen sind.
Bei sagen wir 20 Takten pro Fallprüfung (hoch gegriffen) macht das 20 Mio Instruktionen und damit nichtmal 1% der verfügbaren Leistung eines aktuellen cpu-kerns aus, ganz zu schweigen von Superskalarität.

Problematisch wird die Situation hier, genau wie auch der gpu, erst dann wenn es zu kollisionen kommt und Folgeberechnungen notwendig werden.


Und für DIESE Situationen braucht man die sequenzielle Leistung.


Ob in unkritischen Phasen 10% oder 1% Last anliegt ist irrelevant, außer man möchte auf Leistungsverbrauch optimieren.

Fraglich ist wie in kritischen Situationen damit umgegangen wird.


Hier gebe ich dir recht, da reicht wohl keine aktuelle cpu. eine gpu aber erst nicht, die sind in den Fällen ja noch langsamer.

 

[Lübke]

dieser link ist ganz informativ in bezug auf gpu-physik wie ich finde:
http://de.wikipedia.org/wiki/Physikbeschleuniger

Der große Vorteil von GPUs gegenüber CPUs ist die hohe erreichbare Parallelisierbarkeit der Berechnungen. Zwar wurde in den vergangenen Jahren durch Architekturoptimierung und Befehlssatzerweiterung wie SSE im Bereich der Hauptprozessoren viel getan – die Leistungsfähigkeit moderner GPUs erreichen diese bei weitem nicht.

Weiterhin beinhaltet die Architektur einer GPU bereits vorsortierende und somit durchsatzschonende Elemente (z. B. Z-Buffer), die bei der Reduzierung des erforderlichen Aufwandes helfen. Eben diese Elemente werden bei ähnlich strukturierten Berechnungen wieder verwendet (z. B. Kollisionserkennung).

 

[Realsmasher]

Das zweite Zitat zeigt was ich meinte : es werden Puffer benutzt und Puffer sind per Definition schon veraltet (die aktuellen werte stehen in den Recheneinheiten)

Damit lässt sich nur das bewerkstelligen was ich schon ganz weit vorne erwähnt habe : alle Recheneinheiten arbeiten jeweils mit den Werten des vorherigen Taktes, Kettenreaktionen während eines Taktes entfallen.


das erste Zitat hat nie jemand angezweifelt. klar hat eine gpu mehr parallele Leistung, aber hier handelt es sich um ein sequenzielle limitierendes Problem.


Viel interessanter als der Wiki-text ist übrigens das paper von ati welches dort verlinkt wurde.

Auf Seite 5 sieht man exakt das : nach der Kollision kommt keine erneute Prüfung. Man berechnet diese für mehrere Objekte gleichzeitig und hofft einfach das es zu keiner Kettenreaktion kommt.

Und genau diese Art Kollision ist sehr sinnvoll für eine gpu, denn auch nur eine erneute Prüfung würde hier die laufzeit sofort verdoppelt (ganz im gegensatz zu einer cpu)


Deshalb ist es schon richtig das man das so macht und bei vielen Dingen (typische grafische Schmankerl wie Partikeleffekte) ist das auch völlig ausreichend.


Der versuch jedoch das für sämtliche Kollisionen, insbesondere spielentscheidende zu verwenden wird jedoch fehlschlagen und ist auch schon fehlgeschlagen.

 

[Lübke]

lies den zweiten abschnitt bitte nochmal. er beinhaltet nicht die ergebnisse, sondern den rechenweg. gleiche berechnungen werden vorsortiert um rechenaufwand einzusparen.

Eben diese Elemente werden bei ähnlich strukturierten Berechnungen wieder verwendet

Auf Seite 5 sieht man exakt das : nach der Kollision kommt keine erneute Prüfung. Man berechnet diese für mehrere Objekte gleichzeitig und hofft einfach das es zu keiner Kettenreaktion kommt.

das kann ich aus dem text so nicht nachvollziehen. ich hoffe du stützt deine aussage jetzt nich auf das beispielbildchen Oô das ist nur eine vereinfachte darstellung zur veranschaulichung, das ist dir bewusst, oder?

 

[Realsmasher]

doch ich beziehe mich auf die Bilder.

Es gibt keinen Pfeil von Ebene 3 zu 1 und es wird auch nirgendswo erwähnt das danach noch etwas käme.


Ein weiterer Knackpunkt ist, das mehrere GPUs verwendet werden können (zumindest bei dem Ati Modell).
Hier wäre die Kommunikation und Synchronität nun wirklich vollständig im Eimer.

 

[Konti]

Mein Gott ... da wird dann halt ein bisschen gepuffert und ein bisschen Latenz dazu gepackt. Das merkt kein Mensch, wenn z.B. ein Gebäude erst 10ms später einstürtzt.