News Nvidia und die „Power of 3“

[HFkami]

Crysis hat doch mal voll die vielen Physik Fehler, wenn man nen Haus zB zerstört können Bruchteile immer noch wackeln auch wenn die schon amBoden liegen

 

[Realsmasher]

fehler wie der umgang mit kollisionen sind fehler der programmierung

das mag teilweise stimmen, jedoch setzt auch die parallele Berechnung mit einer gpu der Genauigkeit Grenzen auf.

Selbst mit bestmöglicher Programmierung wird es niemals möglich sein parallel und fehlerfrei die Kollision zu berechnen.

Das ergibt sich schon aus der Tatsache, dass die Recheneinheiten einer gpu unabhängig voneinander sind, die Objekte welche kollidieren jedoch nicht.


So kann es vorkommen das haufenweise Objekte die gleiche Position in einem Taktschritt zugewiesen bekommen und dieser Haufen dann aufgelöst werden muss, was nichtmehr möglich ist das sich bereits zig Objekte ineinander befinden.

Bei einer idealen sequentiellen Berechnung kollisieren immer maximal 2 Objekte gleichzeitig, wodurch eine exakte Berechnung möglich ist.


Ob das letztendlich so umgesetzt wird ist jedoch eine andere Frage.

 

[Lübke]

So kann es vorkommen das haufenweise Objekte die gleiche Position in einem Taktschritt zugewiesen bekommen und dieser Haufen dann aufgelöst werden muss, was nichtmehr möglich ist das sich bereits zig Objekte ineinander befinden.

wenn die berechnung korrekt durchgeführt wird, können nicht mehrere objekte gleichzeitig den gleichen raum einnehmen. wenn sie sich aufeinander zubewegen, dann kommt es zu einer erneuten kollision und jedes objekt prallt je nach geschwindigkeit, richtung und einschlagwinkel ab. das führt dann mit anderen objekten wieder zu folgekollisionen usw usf...

und was die hardware-seitigen vor- und nachteile angeht: hier sehe ich derzeit vorteile bei ati, die leider nicht mit physx arbeiten. ihre 5-d shader erlauben doppelte präzision, was sich auf einem g200 nur schwer (wenn überhaupt) realisieren lässt. aber auch hier wird die zukunft weitere verbesserungen bringen. eine cpu kann keine komplexen multi-kollisionen berechnen, jedenfalls nicht in echtzeit, da sie die kollisionen nacheinander abgearbeite werden müssen und folgekollisionen bei noch nicht berechneten objekten nicht berücksitigt werden können. da sind der cpu einfach physikalisch grenzen gesetzt.

 

[r4yn3]

Wie kommst du darauf das die HD Karten DoublePrecision Shader haben? Das haben doch nur die GT200 Karten, wurde ja nicht umsonst häufig damit geworben.

 

[Realsmasher]

wenn die berechnung korrekt durchgeführt wird, können nicht mehrere objekte gleichzeitig den gleichen raum einnehmen

Keine Ahnung wie du auf diese Idee kommst.


wenn du 100 objekte parallel bewegst, dann bewegst du sie auch nur und zwar ohne kollision, die wird erst im Schritt danach ermittelt.

Selbst wenn man die Kollision berechnen würde, dann müssten die Ergebnisse an alle anderen "Kerne" propagiert werden, da diese immer noch mit den alten werten rechnen. Folglich müssten diese danach die Berechnung von neuem beginnen und voila, wir sind wieder bei sequentieller Berechnung.


Wenn du eine möglichkeit findest framebasierte Kollisionen zu parallelisieren, dann kannst du ziemlich viel Geld verdienen

Vermutlich schaffst du es dann nicht nur zu beweisen das P=NC sondern auch das P=NP und du bist um 1 Mio $ reicher : http://de.wikipedia.org/wiki/Millennium-Probleme
(obwohl alle Welt davon ausgeht das dies nicht gilt, aber bitte....)

 

[Lübke]

Wenn du eine möglichkeit findest framebasierte Kollisionen zu parallelisieren,

wer sagt denn was von framebasiert? Oô
dir ist schon klar, dass physx die flugbahnen berechnet und nichts mit der grafischen umsetzung zu tun hat?
physx = physikberechnung
physx != grafische darstellung
die physik gibt nur die richtung der objekte vor, die objekte selbst werden aber ganz wo anders erstellt.

 

[Realsmasher]

spiele sind nunmal framebasiert.

es macht keinen Sinn eine kontinuirliche Berechnung laufen zu lassen wenn der benutzer eh nur zu den stichzeiten etwas davon sieht, das würde nunmal den Berechnungsaufwand enorm vergrößern.

dir ist schon klar, dass physx die flugbahnen berechnet und nichts mit der grafischen umsetzung zu tun hat?

Das ist vollkommener Kokolores.

Zu dem zeitpunkt an dem die Grafikkarte das Bild rendert muss diese auch wissen wo die Objekte sich befinden, ergo müssen die Positionen deterministisch bestimmt sein.


Selbst wenn du eine kontinuirliche Berechnung hättest, was unsinnig wäre, dann müsstest du zum Renderzeitpunkt genaue Werte liefern können und zwar für alle Objekte.


Demzufolge hat physx extrem viel mit der grafischen Umsetzung zu tun, es bestimmt nämlich zu sehr großen Teilen die Position auf dem Bildschirm.

 

[Lübke]

Demzufolge hat physx extrem viel mit der grafischen Umsetzung zu tun, es bestimmt nämlich zu sehr großen Teilen die Position auf dem Bildschirm.

sie bestimmt NUR die position. und an dieser position wird das betreffende objekt dann gerendert.
dir grafikkarte weis auch nicht, wohin sich die spieler als nächstes bewegen werden und kann es trotzdem zeitnah darstellen. das ist das gleiche in grün.

 

[Realsmasher]

dir grafikkarte weis auch nicht, wohin sich die spieler als nächstes bewegen werden und kann es trotzdem zeitnah darstellen. das ist das gleiche in grün.

das ist mitnichten das Gleiche, sondern vielmehr ein erschwerender Fall.

Damit zeigt sich nämlich das nicht nur die physik welche ggf in der gpu berechnet wird auf die Speicherzelle mit der Objektposition zugreift, sondern auch noch die Eingabe.

Bei einer sequentiellen Beabrietung stellt dies gar kein Problem dar, da die beiden Funktionen nacheinander ausgeführt werden.
Bei der parallelen Verarbeitung jedoch veralten die Informationen, werden aber dennoch verwendet.

Es wäre also problemlos möglich ein Spielerobjekt zu bewegen, parallel zu der Bewegung eines anderes Objektes welches von der gpu bearbeitet wird und beide landen auf der gleichen Position.

Fraglich ist auch hier wieder was sich durchsetzt : die Bewegung über die Eingabe oder die Kollision auf der gpu ? Egal wie rum man es macht, entsteht auf diese Art und Weise ein Fehler da der andere Einfluss ignoriert wird.

Oder man beachtet den anderen Einfluss, dann arbeitet man jedoch wieder sequentiell.



Ich meine wir können hier noch lange diskutieren, jedoch sollte die Tatsache das nach mehreren jahren parallel-physx kein halbwegs brauchbares Ergebnis erreicht wurde schon für sich sprechen.

Der Vergleich mit den ersten 3D Karten ist dabei auch völlig unpassend, da diese mit anerkannt parallelisierbaren Problemen arbeiten.

Und damit ist nichtmal NC(logarithmisch) gemeint, sondern 100%iger Speedup durch mehr Kerne.

 

[mightymartin]

PhysX ist einfach nur daneben. Die Effekte in Sacred 2 z.B. sind einfach nur übertrieben und nervig. Und die anderen 12 Spiele... eh, wayne?!

Und CF oder SLI haben meiner Meinung nach noch nie eine Existenzberechtigung gehabt. Wieviele Leute gibt es wirklich, die SLI effektiv und sinnvoll nutzen? Und mit effektiv und sinnvoll meine ich nicht den Verbund von 2 Mittelklasse-Karten, denn genau das ist sinnlos und ineffizient. Wer hat wirklich einen Monitor mit einer 2560er Auflösung und braucht 2 GPUs? 0,001%? Und dafür wird son Wirbel um CF/SLi gemacht?

SLI/CF dient nicht dazu, enorm Große Auflösungen zu fahren, da dort der VRAM nicht für ausreicht. Eher die Qualität und Geschwindigkeit(Frames) gehen hoch.
Ich selbst habe eine GTx295 und vorher eine GTX260² ... sind welten zwischen :-)


Zu der PHYXangelegenheit .... PX ist ein super vorreiter, der zeigt wie überholt Grafikkarten mitlerweile sind. bei dne neuen 12kern CPU werden schon 2 einzelne 6kerner verbunden um 12Kerne arbeiten zu lassen. soetwas wirdes sicherlich bald in Form von CPU/GPU geben, sobald man eine Lösung für VRAM und Shadereinheiten gefunden hat... ab daan.... Tschüß Grafikkarte, Hallo teure CPU.

 

[Konti]

spiele sind nunmal framebasiert.

es macht keinen Sinn eine kontinuirliche Berechnung laufen zu lassen wenn der benutzer eh nur zu den stichzeiten etwas davon sieht, das würde nunmal den Berechnungsaufwand enorm vergrößern.

Gerade eine Frame-basierte Physik-Berechnung macht überhaupt keinen Sinn. Der Spielfluss muss unabhängig von den angezeigten FPS sein. Der Spielfluss muss flüssig sein.

Ich meine wir können hier noch lange diskutieren, jedoch sollte die Tatsache das nach mehreren jahren parallel-physx kein halbwegs brauchbares Ergebnis erreicht wurde schon für sich sprechen.

Du ziehst recht vorschnell Schlüsse.
Es ist etwas nicht unmöglich, nur weil es bisher noch nicht erreicht wurde. Die Physik in Games steckt noch in den Kinderschuhen und GPU-PhysX erst recht.
Davon abgesehen kenne ich kein einziges Game mit CPU-Physik, welches sonderlich viel besser wäre.
Nimm Crysis, HL2 oder was auch immer ... in allen gibt es Physik-Fehler am laufenden Band.
Es ist einfach noch nicht gut genug programmiert. Und klar wird's mit hoher Parallelisierung schwieriger aber mitnichten unmöglich. Wahrscheinlich muss man eine kleine Latenz für's Buffering einräumen .. dann würde das Ganze etwas unkritischer machen.

 

[Realsmasher]

100%ige Genaugkeit ist unmöglich, das ergibt schon rein theoretisch.

Dadurch das mehrere Objekte gleichzeitig bewegt werden können diese aufgrund des Informationsmangels über die neue Position in den jeweils anderen Recheneinheiten nicht mehr exakt kollidieren.

Würde man also auf einer cpu exakt rechnen, dann könnte eine gpu unmöglich an diese Leistung herankommen wenn sie auch exakt rechnen soll.

Und das ist kein "vielleicht klappt das später mal", das ergibt sich schon aus dem Ablauf an sich.(P-Vollständiges Problem)

Das einzige was funktioniert, ist eine Annäherung zu erreichen die nicht extrem viel schlechter ist als die exakte Lösung.

Davon abgesehen kenne ich kein einziges Game mit CPU-Physik, welches sonderlich viel besser wäre.

Wüsste gerne mal was deine Vergleichswerte hier sind.

Wenn ich mir Crysis oder Oblivion ansehe ist das durchaus akzeptabel.

Bei Cellfactor z.b. ist es jedoch ein einziges rumgezappel.

Die meisten anderen physx titel bieten ja erst garkeine Kollision.

Gerade eine Frame-basierte Physik-Berechnung macht überhaupt keinen Sinn. Der Spielfluss muss unabhängig von den angezeigten FPS sein

Was hat das Eine mit dem Anderen zu tun ?

Diskrete Werte müssen doch nicht zwangsläufig den gleichen Abstand haben.

Eine timermultiplizierte Bewegungsgeschwindigkeit löst das Problem mit einem Schlag, dafür tut man sich das doch nicht eine kontinuirliche Bewegungsfunktion an....

Ganz davon abgesehen das die ganzen Eingangsgrößen ohnehin nur in diskreten zeitschritten vorliegen.

Eine Tastatur z.b. sendet nunmal nur x mal pro Sekunde ein Signal und meldet nicht : "taste y wurde für z sekunden gedrückt"

 

[Lübke]

es ist für das spiel egal, ob ein spieler willkürlich mit objekten interagiert oder ob objekte physikgesteuert miteinander interagieren. das hat mit der grafischen umsetzung nichts zu tun. die nötige vorlaufzeit ist die gleiche bzw bei der physik eher geringer, weil die flugbahnen im vorraus berechnet werden können. wie das dann anschließend in frames umgesetzt wird, ist eine völlig banale sache und unabhängig von der berechnung.

Wenn ich mir Crysis oder Oblivion ansehe ist das durchaus akzeptabel.

also ist physik auf einmal doch ok? Oô oder meinst du, weil das auf der cpu berechnet wurde wäre das was anderes?

 

[Realsmasher]

weil die flugbahnen im vorraus berechnet werden können

wie das dann anschließend in frames umgesetzt wird, ist eine völlig banale sache und unabhängig von der berechnung

Bei solchen Aussagen geht mir fast der Hut hoch.

Anstatt hier wieder einen ellenlangen Text zu schreiben lasse ich es einfach. Du hast scheinbar noch nie auf dem Gebiet gearbeitet und stellst dir das alles völlig verquer vor.


Ich empfehle dir mal ein simples Programm zu schreiben und deinen Ansatz von vorberechneten Flugbahnen und frameunabhängiger Berechnung zu implementieren.

Spätestens wenn du bei Synchronisierung scheiterst und die Performance zudem hundsmiserabel ist wirst du das sein lassen.

oder meinst du, weil das auf der cpu berechnet wurde wäre das was anderes?

Klar ist es etwas anderes.

Auf einer cpu kann man nach jeder einzelnen bewegung auf kollision prüfen, das geht parallel nunmal nicht.

 

[Lübke]

auf den ersten teil gehe ich jetzt nicht mehr ein, da du den programmablauf und die optische ausgabe an den monitor immer in einen topf wirfst.
nur so viel dazu: glaubst du nicht, dass intel und nvidia beim kauf von havok bzw agaia nicht bedacht haben, ob es sich um ein realisierbares vorhaben handelt? so ganz dumm können die ja nicht sein, sonst wären sie wohl kaum so groß geworden.

Klar ist es etwas anderes.

Auf einer cpu kann man nach jeder einzelnen bewegung auf kollision prüfen, das geht parallel nunmal nicht.

sowas hab ich erwartet.
auf einer cpu kann man das, richtig. und zwar maximal für 4 objekte gleichzeitig (bei einem quadcore), bei einer grafikkarte kann man das ganze aber für hunderte objekte gleichzeitig. das ist der springende punkt. es ist wie gesagt, völlig egal, ob es mit havok, agaia oder direct physics berechnet wird, das ergebnis ist das gleiche. der unterschied ist hier, ob man es auf einer cpu mit wenigen kernen nacheinander berechnet, oder auf einer gpu viele objekte gleichzeitig um zeit zu sparen. das ist alles. und das ist der grund, warum eine gpu mit mehr objekten umgehen kann als eine cpu: sie hat mehr ausführungseinheiten zur verfügung.

Ich empfehle dir mal ein simples Programm zu schreiben und deinen Ansatz von vorberechneten Flugbahnen und frameunabhängiger Berechnung zu implementieren.

ich weis nicht, wies in deinen programmen aussieht, aber in meinen quellcodes kommen genau 0 frames vor. ich sage dem programm, was dargestellt werden soll, aber nicht wieviele fps es zu haben hat geschweige denn, welches pixel in welchem frame wo zu plazieren ist.
hier ein schönes beispiel zur veranschaulichung was ich meine:
https://www.computerbase.de/2009-04/video-cuda-berechnet-ki-von-1.024-flugzeugen/
es ist wie gesagt noch alles in den anfängen, aber die entwicklung von physik (und ich spreche von physik ganz allgemein und nicht speziell agaia oder sonst was) wird meiner meinung nach mit den jahren immer weiter voranschreiten und in 10 jahren so selbstverständlich sein wie direct x und open gl und vermutlich werden die spiele dann nicht mehr ohne laufen und auch was mit physikberechnungen gemacht wird, wird bei weitem über diese ersten gehversuche, wo sich das ganze vor allem auf effektphysik beschrenkt weit hinaus gehen. davon bin ich überzeugt.

 

[Realsmasher]

glaubst du nicht, dass intel und nvidia beim kauf von havok bzw agaia nicht bedacht haben, ob es sich um ein realisierbares vorhaben handelt?

klar ist es realisierbar ein bischen Effekthascherei damit zu betreiben.

Ob glaubwürdige Physik, welche Kollisionen beinhaltet, damit realisierbar ist muss sich zeigen.

Das exakte Physik damit möglich ist muss jedoch nicht gezeigt werden, denn das ist per Definition schon unmöglich.

auf einer cpu kann man das, richtig. und zwar maximal für 4 objekte gleichzeitig

nö, exakt geht nur für 1 Objekt gleichzeitig, auch auf einem quadcore.

ich weis nicht, wies in deinen programmen aussieht, aber in meinen quellcodes kommen genau 0 frames vor

in meinen programmen skalier die bewegungsgeschwindigkeit mit dem abstand zum letzten frame.

Eine kontinuirliche bewegung, welche man an einem bestimmten Zeitpunkt abgreift ist viel zu aufwändig um im großen Maßstab eingesetzt zu werden.

hier ein schönes beispiel zur veranschaulichung was ich meine:

das zeigt höchstens das du immernoch nicht kapiert hast um was es geht....

kommst hier mit einem Beispiel von KI wo es um Physik und Kollisionen geht.


Warum fängst nicht gleich mit Wetterberechnung an. Hurra dort können wir ein paar Millionen Kerne nehmen, na dann geht das wohl auch bei jedem anderen Problem

 

[Lübke]

hm stimmt, das physik video war was mit explosion und umherfliegenden teilen, die flugzeuge sollen ja gar nicht kollidieren xD
sry mein fehler^^ hab nur auf die schnelle n video mit der flugbahnberechnung von 1024 teilen gesucht...

ok vergessen wir das video, ich schätze du weist was ich meinte? war nicht aus nem spiel sondern son vorzeigevideo von nvidia damals, was mit physik auf ner gpu möglich ist (bzw damals schon war).

Eine kontinuirliche bewegung, welche man an einem bestimmten Zeitpunkt abgreift ist viel zu aufwändig um im großen Maßstab eingesetzt zu werden.

ich glaub an dieser stelle reden wir die ganze zeit aneinander vorbei. ich meine, dass die physik die flugbahnen inklusive kollisionsbedingter abweichungen berechnet und die grafik das ganze dann in einer realistischen zeit wiedergibt. das ist keine 1:1 übertragung der positioen, das spiel weis schon millisekunden vorher, wies weitergeht und gibt die flugbahn grafisch in einer realistischen geschwindigkeit aus. problematisch wäre es, wenn die gpu zu langsam wäre, die flugbahnen vorher zu berechnen. dann würde das spiel ruckeln, weil auf informationen gewartet werden muss.

 

[Realsmasher]

ok vergessen wir das video, ich schätze du weist was ich meinte? war nicht aus nem spiel sondern son vorzeigevideo von nvidia damals

tut mir leid, das kenne ich nicht, aber es würde mich interessieren wie echt das aussieht und vor allem ob die Objekte ineinander clippen.

wenn du es findest, dann verlink es bitte mal.

 

[Lübke]

mir ist noch ein anderes "neutrales" (da weder agaia noch havok noch direct physics genutzt) beispiel für "echte" physik eingefallen: die autoindustrie lässt schon seit langem crashtests aus quadrokarten berechnen. ich denke das ist ein guter beleg, dass eine gpu in dieser hinsicht der cpu vorraus ist, denn die betreffenden karten kosten ca 7.000,- €/stück, dafür bekommt man auch jede beliebige cpu

 

[Realsmasher]

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


Ich nehm ein ganz simples Beispiel : Billard

t1 : kugel 1 rollt
t2 : kugel 1 stößt an kugel 2
t3 : kugel 2 rollt los
t4 : kugel 2 stößt an kugel 3
t5 : kugel 3 rollt los
t6 : kugel 3 stößt an nichts

das sind 6 Schritte für diese Berechnung, das Ergebnis wurde sequentiell ermittelt und ist exakt.


Wer diesen Ablauf parallelisieren kann, also das er weniger als 6 Zeitschritte benötigt, ist ein Genie.


Wer bei dem Versuch scheitert kann sich jedoch überlegen das dieser Ablauf typisch ist bei der Nutzung von hunderten von Objekten auf engem Raum.

Insbesondere steigt die Quote von solchen Ereignissen EXTREM stark, je mehr Objekte sich in einem Raum befinden (siehe auch : Geburtstagsparadoxon).

Deswegen wird die sequentielle Leistung immer wichtiger, je mehr Objekte man verwendet.

Das klingt absurd, weil die Logik einem sagt das mehr Objekte ja von mehr Recheneinheiten berechnet werden können.

Der wahre Flaschenhals liegt aber an dem Punkt der nicht parallel betrieben werden kann da hier die Leistung stagniert.