ATI - Open Physics noch 2010?

Nun, der Artikel deckt sehr schön die reine PR-Vermarktung von PhysX seitens Nvidia auf. PhysX auf einer GPU ist murks und nur gepusht von NV, leider.
Mit einer einfachen Threading- und SSE-Optimierung für CPUs, würde ein x86-Prozessor PhysX wahrscheinlich ca. 960-1920 mal schneller ausführen, als ein Singlethreaded-basierter Code, auf einer GPU .
Selbst ein winziger Intel Atom würde 100x schneller als ein Singlethreaded PhysX-Code sein. Wenn man dann noch die Vektorisierung wegnimmt, sinkt die GPU-Performance noch weiter ins Bodenlose.

Den Rest bitte selber lesen,...

MfG,
Explosiv

der artikel bzw. das fazit ist murks. singlethread auf der gpu wird gegen multithread auf einer modernen cpu verglichen, das da die gpu verliert, hätte ich dir auch vorher sagen können. gpu sind mittlerweile auf extremes multithreading ausgelegt und daraus beziehen die ihre rechenpower, dagegen haben aktuelle cpus keine chance. ausser wenn man dummfug macht und massiv parallelisierbares wie physikberechnungen auf singelthread beschränkt.
 
Ich find es ist der richtige Weg in die Zukunft, endlich einen einheitlichen Standart zu etablieren!!
Weiter so AMD!!!!
 
In der von mir verlinkten Original-Quelle wirst Du das auch nicht finden, sry :P.
Beide Artikel sind mit einander verknüpft, wusste ned mehr, wo ich was gelesen hatte :ugly:.
Hier
, ich reiche gerne nach, aber erschlage mich nicht immer gleich :D:



MfG,
Explosiv


by Charlie Demerjian
:ugly::ugly::ugly::ugly:


On a modern 4 core CPU, you would get 4x speed increase from SSE, and a 4x increase from threading. Math says that would get you a 16x increase in speed,
Den 4x-Boost hält sogar die Originalquelle für unereichbar. ;) Wie gesagt sind 1x bis 2x wahrscheinlich, also wie ich bereits zuvor sagte die 8x Leistung bei Quadcores und nicht, wie Charlie so schön rausposaunt, die 16x Leistung.

As Real World Tech pointed out, the Ageia PhysX chip used 32 bit math, and the now Nvidia PhysX programs likely do as well. The code runs on G80 based GPUs, and they did not have DP FP capabilities.
Alle GPUs ab der GTX200 sind 64bit tauglich (außer die umbenannten GF9er :ugly:). Da Nvidia mit Sicherheit jede Möglichkeit zur Optimierung auf GPUs wahrnimmt, wird PhysX also vermutlich auf den entsprechenden GPUs auch mit 64bit laufen.

With the simple threading and SSE optimizations above, the CPU would run it 960-1920x faster than single threaded GPU code. Even a lowly Atom CPU would probably be 100x faster than single threaded GPU PhysX code. If you take away vectorization as well, the GPU performance drops yet farther.
Es ist kein Geheimnis, dass ein einzelner GPU-Shader-Prozessor einem CPU-Kern nicht das Wasser reichen kann, aber die Masse macht es halt. Man braucht sich ja nur mal einen Via C7 mit 200 Kernen Vorstellen. Der würde bei entsprechendem Code jeden Intel EE-CPU in der Luft zerpflücken wie eine alte lederige Weihnachtsgans, aber ein einzelner Kern ist nach wie vor kriechend langsam.
Dieser Vergleich, den Charlie anbringt, unterstreicht imo eigentlich nur seine Anti-Nvidia-Haltung. ;)
Nebenbei bemerkt verdoppelt sich sowohl bei AMD als auch Nvidia mit jeder Generation im Schnitt die Zahl der Shader-Prozessoren. Das heißt, dass sich die GPGPU-Leistung theoretisch JEDES JAHR verdoppelt. Und wie lang hat der Schritt von 2 auf 4 (echte) CPU-Kerne gedauert? 4 Jahre? ;) Und der Schritt auf 8 Kerne? Nochmal 3 Jahre und dabei gibt es Octacores bisher nur für Server.
Die C2Q von Intel würde ich ehr mit einem SLI-Gespann vergleichen als mit einzelnen GPUs, daher finden sie in meinem "Zeitstrahl" keine Berücksichtigung.
 
Zuletzt bearbeitet:
der artikel bzw. das fazit ist murks. singlethread auf der gpu wird gegen multithread auf einer modernen cpu verglichen, das da die gpu verliert, hätte ich dir auch vorher sagen können. gpu sind mittlerweile auf extremes multithreading ausgelegt und daraus beziehen die ihre rechenpower, dagegen haben aktuelle cpus keine chance. ausser wenn man dummfug macht und massiv parallelisierbares wie physikberechnungen auf singelthread beschränkt.

Nein, das ist er nicht. Es wird auch nicht "singlethread auf der gpu [...] gegen multithread auf einer modernen cpu verglichen", sondern es wurd Single-Threaded auf der CPU mit Multi-Threaded auf der CPU verglichen.

Man vertut sich da schnell -- "PhysX Multithreaded" ist nämlich schlecht für (nvidia-)Grafikkarten -- die werden dabei nämlich langsamer -- während die CPU schneller wird, wenn PhysX multithreaded läuft. Multi-Threaded ist auch nicht alles. Gucken Sie mal:
http://physxinfo.com/news/wp-content/uploads/2010/03/fluidmark_graph.jpg

Das hat sich da niemand aus den Fingern gesogen -- Fluidmark bei PhysX-Info zeigt das recht schön, schauen Sie es sich mal an -- das ist wirklich erstaunlich (ich habe damals erstmal geschluckt bis ich das so akzeptieren konnte wie Sie in den Kommentaren sehen können):

New PhysX FluidMark 1.2: First Tests | PhysXInfo.com - PhysX News

Die parallele Abarbeitung in den Shaderprozessoren der Graphikkarte hat nämlich nichts mit mehreren parallelen Threads zu tun wie sich (nicht nur) dort schön zeigt.

Und es stimmt, daß gerade die SSE-Befehle sich dazu eignen, mehrere Operationen parallel im Prozessor abzuarbeiten (das eine S steht für SIMD, Single Instruction -- Multiple Data), die sonst mehrere Takzyklen und Pipelines des Prozessors verbrauchen würden, so daß auch dort akut zu Lasten des Prozessors gecoded ist -- niemand würde Befehle aus dem SSE-Satz aus Versehen nicht benutzen, das ist wie eine Mutter mit der Rohrzange statt der Ratsche zu öffnen.

cu
Thomas

Edit: Äh, den Artikel lese ich übrigens jetzt erst, die hier im Forum teilweise vermittelten Inhalte wollte ich bestätigen, der Artikel ist so auf den ersten Blick, , äh, nun ja, wie sag' ich's, tja, breiten wir den Mantel des Schweigens darüber.
 
Zuletzt bearbeitet:
Nein, das ist er nicht. Es wird auch nicht "singlethread auf der gpu [...] gegen multithread auf einer modernen cpu verglichen", sondern es wurd Single-Threaded auf der CPU mit Multi-Threaded auf der CPU verglichen.

Artikel schrieb:
With the simple threading and SSE optimizations above, the CPU would run it 960-1920x faster than single threaded GPU code.

muss ich die entscheidenden details noch rot markieren?
 
muss ich die entscheidenden details noch rot markieren?

Sie haben es nicht verstanden, was Sie gelesen haben, nicht? GPU-PhysX ist immer erst einmal Single-Threaded -- nur mit Workarounds kriegt man das PhysX-SDK offensichtlich dazu, mittels mehrerer Threads zu arbeiten. Die parallele Abarbeitung in den SPs hat nichts mit einer Programmierung in mehreren Threads zu tun, das sind unterschiedliche Ebenen.

Zum Artikel gab es bereits vor Ihrer Antwort oben einen Edit meinerseits.

Und auch hier noch ein Edit: Der Absatz ist doch ohnehin eine reine Hypothese, der da zitiert wird -- wenn man den Code für GPU so schlecht programmieren würde wie der für CPU programmiert ist und dafür den CPU-Code optimieren, nichts anderes wird da angeführt -- ich nenne sowas einen Blödsinnsvergleich.

:ugly::ugly::ugly::ugly:


Den 4x-Boost hält sogar die Originalquelle für unereichbar. ;) Wie gesagt sind 1x bis 2x wahrscheinlich, also wie ich bereits zuvor sagte die 8x Leistung bei Quadcores und nicht, wie Charlie so schön rausposaunt, die 16x Leistung.

Einen Boost von 75 auf 500 Punkte im Fluid-Mark alleine durch Multithreading und Steigerung der Emitter-Anzahl würde ich schon als Faktor 7 bezeichnen wollen.
http://physxinfo.com/news/wp-content/uploads/2010/03/fluidmark_graph.jpg

Und da sind keinerlei SSE-Optimierungen im Einsatz.

cu
Thomas
 
Zuletzt bearbeitet:
Einen Boost von 75 auf 500 Punkte im Fluid-Mark alleine durch Multithreading und Steigerung der Emitter-Anzahl würde ich schon als Faktor 7 bezeichnen wollen.
http://physxinfo.com/news/wp-content/uploads/2010/03/fluidmark_graph.jpg

Und da sind keinerlei SSE-Optimierungen im Einsatz.

cu
Thomas

Zu beachten:

While SPH fluid simulation is running on CPU with “Multi-core PhysX” set to off, load is destributed through several cores (probably due to internal Windows threads management), but in sum that’s 26% – full one core.
Windows hat von sich aus den einen Thread auf vier Kerne verteilt. Man müssste den Test wiederholen, indem man im Taskmanager dem Prozess nur einen einzelnen Kern zuweist. Sonst ist das Ergebnis nicht so recht verwertbar aus meiner Sicht.


Edit: Ich habs mal mit meinem Quad getestet. Es macht doch KEINEN Unterschied, ob ich dem Prozess alle 4 oder nur 1 Kern zuweise bei Single Thread. Allerdings habe ich beim Multi Thread Test gerade mal die dreifache Punktezahl. (104 vs 306)

PS: Seit wann siezt man sich eigentlich hier im Forum?
 
Zuletzt bearbeitet:
Zu beachten:

Windows hat von sich aus den einen Thread auf vier Kerne verteilt. Man müssste den Test wiederholen, indem man im Taskmanager dem Prozess nur einen einzelnen Kern zuweist. Sonst ist das Ergebnis nicht so recht verwertbar aus meiner Sicht.

Nein, was soll das bringen -- das ist irrelevant, das Verhalten des Core-Hopping ist ja wohlbekannt. Es ist und bleibt ein einzelner Thread.

Edit: Gerade den Edit gesehen -- genau das meine ich, ja:

Edit: Ich habs mal mit meinem Quad getestet. Es macht doch KEINEN Unterschied, ob ich dem Prozess alle 4 oder nur 1 Kern zuweise bei Single Thread. Allerdings habe ich beim Multi Thread Test gerade mal die dreifache Punktezahl. (104 vs 306)
Haben Sie denn auch mit mehreren Emittern gearbeitet oder nur MultiCore-PhysX on? Davon ab ist 3x immerhin schon 3x -- ohne jede SSE-Magie.
 
Nein, was soll das bringen -- das ist irrelevant, das Verhalten des Core-Hopping ist ja wohlbekannt. Es ist und bleibt ein einzelner Thread.

Edit: Gerade den Edit gesehen -- genau das meine ich, ja:

Haben Sie denn auch mit mehreren Emittern gearbeitet oder nur MultiCore-PhysX on? Davon ab ist 3x immerhin schon 3x -- ohne jede SSE-Magie.


Ja ich habe eben erst gesehen, dass man beliebig viele Emitter einstellen kann.
Bei 10 Emittern sieht das Ergebnis so aus:

Multi Thread: 511
Single Thread: 144

511/144 = ~3.5


31 Emitter:

Multi Thread: 423
Single Thread: 167


Ich wiederhole den Test ein letztes mal mit einer minimalen Auflösung, da bei 31 Emittern die GPU-Temp anstieg, was evtl auf eine GPU-Limitierung schließen lässt.

Edit: Hier der letzte Test bei einer Auflösung von 640x480, 15000 Particel Count:
Multi Thread: 441
Single Thread: 170

441/170 = ~ 2.6
 
Zuletzt bearbeitet:
Sie haben es nicht verstanden, was Sie gelesen haben, nicht? GPU-PhysX ist immer erst einmal Single-Threaded -- nur mit Workarounds kriegt man das PhysX-SDK offensichtlich dazu, mittels mehrerer Threads zu arbeiten. Die parallele Abarbeitung in den SPs hat nichts mit einer Programmierung in mehreren Threads zu tun, das sind unterschiedliche Ebenen.

ich versteh das schon noch eingermassen, nur bei dir bei ich mir da nicht so sicher. die frage, mit wieviel threads physx arbeitet, liegt bei den devs. dass physx auch mit multithreads arbeiten kann, steht ja wohl ausser frage. und auf der gpu arbeitet physx von sich aus mit multithreads, alles andere wäre schwachsinnig. und genau deswegen ist der erwähnte speedup-faktor von 9xx bis sagenhaften 19xx mal schneller einfach nur dummes gequatsche.
 
[...] und genau deswegen ist der erwähnte speedup-faktor von 9xx bis sagenhaften 19xx mal schneller einfach nur dummes gequatsche.

Nein, das hatte ich oben schon erklärt -- der ist nicht dummes Gequatsche, der ist Blödsinn wiel er eine hypothetische Situation konstruiert.

IOW: Es gibt PhysX, es gibt Multithreading, es gibt SSE -- was es aber nicht gibt, ist beschnittenes GPU-PhysX, das aber setzt der Artikel hypothetisch vorraus. Diese Annahme ist aber nichts wert. Das ist ein sinnloser Schwanzlängenvergleich zwischen einem SP und einer CPU.
 
Zuletzt bearbeitet:
Ich habe mit dem Benchmark nun mit 10 Emittern bei 15000 Partikeln @ 640x480 meine 9600 GT getestet:

Multi Thread 321
Single Thread 326

Seltsam ist außerdem, dass ich die Emitterzahl maximal auf 11 setzen kann. Wenn ich sie auf 12 oder mehr setze, werden keine Partikel mehr dargestellt.

Das Programm scheint also noch einige Macken zu haben.
 
Eben, deswegen ist das Argument mit der Schule nicht immer wirklich treffend.:ugly:
warum nicht? wenn man in der Schule mehr gelernt hätte, könnte man besser Englisch? Mit den Noten hat das trotzdem noch nichts zu tun...
Ich find es ist der richtige Weg in die Zukunft, endlich einen einheitlichen Standart zu etablieren!!
Weiter so AMD!!!!
wenn du es schon rot schreibst, dann wenigstens richtig: das Wort Standart gib es nicht!!! Man schreibt es mit d, warum ist das so schwierig?
Ist klar, dass sich so ein einheitlicher Standard nicht durchsetzt, wenns die Leute nicht mal richtig schreiben können :ugly:
 
Das hatte ich geschrieben.
http://extreme.pcgameshardware.de/user-news/107844-ati-open-physics-noch-2010-a-4.html#post1984390
Ich beschäftige mich schon eine ganze weile mit PhysX ,was man in mein Thread erkennen kann. In vielen Benchmarks, erkennt man wie gut PhysX von nVidia ist, ganz abgesehen von der Kompatibilität. Bei AMD ist lt. Internet eine DX11-graka Pflicht, was bei nVidia nicht so ist , denn da reiche eine billige 8600gt oder 9500gt aus. Das Spektrum an Grafikkarten was PhysX kann ist bei nVidia besser gestaltet als bei ATI, was bei mir keine gute Zustimmung findet.
 
Das hatte ich geschrieben.
http://extreme.pcgameshardware.de/user-news/107844-ati-open-physics-noch-2010-a-4.html#post1984390
Ich beschäftige mich schon eine ganze weile mit PhysX ,was man in mein Thread erkennen kann. In vielen Benchmarks, erkennt man wie gut PhysX von nVidia ist, ganz abgesehen von der Kompatibilität. Bei AMD ist lt. Internet eine DX11-graka Pflicht, was bei nVidia nicht so ist , denn da reiche eine billige 8600gt oder 9500gt aus. Das Spektrum an Grafikkarten was PhysX kann ist bei nVidia besser gestaltet als bei ATI, was bei mir keine gute Zustimmung findet.
aber in ein paar Jahren völlig unwichtig ist: bei Nvidia sinds halt alle DX10 und später Karten, bei AMD halt alle DX11. Da der letztere Standard sowieso für viele JETZT schon der wichtigere ist (bzw den besseren Start hat, obwohl der Start der HARDWARE nicht so reibungslos verläuft, angesichts der immer noch nicht wirklich gut verfügbaren Radeons und Geforces). Und da der Physikkampf nicht schnell sondern allmählich entschieden wird, ist es eigentlich nicht wichtig ob ATI das erst aber DX11 Generation unterstützt oder nicht. Liegt wohl an OpenCL/Compute Shader
 
Das hatte ich geschrieben.
http://extreme.pcgameshardware.de/user-news/107844-ati-open-physics-noch-2010-a-4.html#post1984390
Ich beschäftige mich schon eine ganze weile mit PhysX ,was man in mein Thread erkennen kann. In vielen Benchmarks, erkennt man wie gut PhysX von nVidia ist, ganz abgesehen von der Kompatibilität. Bei AMD ist lt. Internet eine DX11-graka Pflicht, was bei nVidia nicht so ist , denn da reiche eine billige 8600gt oder 9500gt aus. Das Spektrum an Grafikkarten was PhysX kann ist bei nVidia besser gestaltet als bei ATI, was bei mir keine gute Zustimmung findet.


Bei ATI kommt aber bald schon die zweite DX11 Generation, das heißt, es sind die selben Vorraussetzungen wie bei nVidia.
 
Zurück