Hallo,
ich hab mich mal selbst etwas mit dem Thema beschäftigt.
Infos zum Test:
OS: WinXp 32 Bit (unter Win7 hab ich die Demo von Batman AA nicht zum Laufen gebracht,
laut der Kompatibilitätsliste im Luxx läuft das Spiel auch nicht)
Update: unter Win7 läufts jetzt auch. Eventuell lag es an meinen Experimenten mit der DirectCompute-Schnittstelle.
CPU: Core i7-920@4 GHz
Graka: HD 5870@Standardtaktraten
Alle Messdaten habe ich mit Everest erfasst.
Versuche:
PhysX-Effekte
aus mit Framelimiter (ich hab nicht gleich rausgefunden, wie
man den ausschalten kann)
PhysX-Effekte
normal (hier empfiehlt das Spiel bereits eine GTX 260)
PhysX-Effekte
high (hier empfiehlt das Spiel zusätzlich zur GTX 260 eine
weitere Graka, die nur PhysX beschleunigen soll)
PhysX-Effekte
aus ohne Framelimiter
PhysX-Effekte
aus mit
2x2SGSSAA (über den Treiber erzwungen)
Der dargestellte Bereich erstreckt sich über die erste Ingame-Sequenz und
den darauf folgenden Kampf im "Eingangsbereich" vom Arkham Asylum.
Ich habe nicht weiter getestet, da bereits in diesem ersten Kampf mit aktivierten
PhysX-Effekten eigentlich keine spielbaren Fps mehr gegeben sind.
Da außer der Schlägerei nichts passiert, dürfte es halbwegs reproduzierbar sein.
Und nun zu der Ergebnissen:
Mit
normal (ich kürze ab hier ab) ist die Auslastung von Kern1 genauso hoch wie bei
aus mit
deaktiviertem Framelimiter (in dem Diagramm mit
Vsync bezeichnet). Bei
high fällt die Auslastung wieder, was sich aber bei Betrachtung einer der anderen CPU-Kerne erklärt.
Bei Kern2 ist die Auslastung in allen Fällen recht gering, wobei sie mit
normal und
high am geringsten ist. Die höchste Last ergibt sich mit
aus und
deaktivertem Framelimiter gefolgt von
2x2SGSSAA
Die geringste Last erzeugt nun
aus.
normal und
high erzeugen eine etwas höhere Last. So richtig zu tun bekommt dieser Kern aber eigentlich erst bei
aus mit
deaktiviertem Framelimiter. Die mit Abstand höchste Last ergibt sich aber bei
aus mit
2x2SGSSAA.
Mit Kern4 haben wir dann auch die Erklärung gefunden, warum bei
high die Auslastung von
Kern1 wieder sinkt. Anscheinend läuft PhysX nun zum größten Teil auf Kern4. Die Auslastung bewegt sich auf dem gleich hohen Niveau wie bei
Kern3 mit
aus und
2x2SGSSAA.
Normal,
aus mit Framelimiter und
aus ohne Framelimiter liegen in etwa auf dem gleichen Niveau.
Man sieht hier schon, dass sich eine recht ungleichmäßige Lastverteilung bei einer 4-Kern-CPU nicht nur durch das Nutzen von CPU-PhysX ergibt.
Auch die Nutzung von
über den Treiber erzwungenem 2x2SGSSAA hat den gleichen Effekt (hoffentlich kommt jetzt nicht jemand mit einer weiteren Verschwörungstheorie):
Ein Kern ist jeweils fast voll ausgelastet, während die anderen 3 Kerne nur sehr gering ausgelastet sind.
Der im Startpost verlinkte Artikel erweckt zeigt ebenfalls auf, dass die CPU mit aktiviertem PhysX ingesamt weniger stark ausgelastet ist. Einige haben daraus eine künstliche Ausbremsung der CPU geschlussfolgert. Meiner Meinung nach kommt die ingesamt höhere Auslastung bei deaktivierten PhysX Effekten daher, dass die CPU nicht durch PhysX überfordert ist und somit voll für die GPU zur Verfügung steht. Diese kann sich deshalb voll entfalten und belastet dadurch wiederrum die CPU stärker.
Das sieht man auch bei einem Vergleich zwischen
mit und
ohne Framelimiter:
Ohne Framelimiter (Vsync im Diagramm genannt) fällt die CPU-Auslastung nicht nur insgesamt höher aus, die Kerne scheinen mir auch insgesamt gleichmäßiger belastet zu sein.
Obwohl die Auslastung eines einzelnen Kerns mit
high stark steigt, sind die anderen Kerne ähnlich hoch ausgelastet wie bei
aus und aktiviertem Vsync.
Die geringe Auslastung dieser Kerne kommt imho daher, das die Threads, die auf diesen Kernen ausgeführt werden, deutlich schneller abgearbeitet werden können, als die, die auf Kern1 laufen. Ergo müssen die restlichen Kerne öfter auf Kern1 warten und ihre angezeigte Auslastung sinkt.
Schlingel_INVs Ausführungen gingen auch in diese Richtung.
Ich hab mir dann noch für den Bereich zwischen den Messpunkten 40 und 70 (hier dürfte sich das eigentliche Spielgeschehen abgespielt haben) das Ganze zahlenmäßig angeschaut:
Hier sieht man auch recht gut, dass die GPU bei den Effekten auf
normal und
high auf die CPU warten muss.
In diesen Fällen ist die Gesamt-CPU-Auslastung auch um ca. 20 % kleiner als bei der Einstellung
aus ohne Vsync.
Allerdings sieht man auch, wie wenig die CPU zu tun hat, wenn der Framelimiter aktiv ist.
Jetzt sollte man sich fragen, warum nutzt PhysX mehr oder weniger nur einen CPU-Kern?
Es muss imho nicht zwingend böse Absicht seitens Nvidia sein.
Nvidia verkauft GPUs und keine CPU. Da Zeit und Arbeiter Geld kosten, werden sie die Entwicklung verständlicherweise auf den GPU-Teil konzentrieren.
Letztendlich könnte es aber auch mit den Berechnungen an sich zu tun haben.
Aus der Mehrkörperdynamik (dürfte den PhysX-Effekten, die Spiele aktuell so nutzen, recht nahe kommen) und aus der numersichen Simulation im Allgemeinen weiß ich, es gibt nicht den auf jedes Problem optimal anwendbaren Solver. Und da gehts bisher nur um die Mathematik selbst und noch nicht um die Umsetzung in eine Multithreaded Anfwendung.
Wegen der ganzen Problematik hab ich mir zwei UT3-Level angeschaut, die starken Gebrauch von PhysX machen.
Leighthouse (während dieser Anzeige habe ich Wände zerstört):
Tornado (während dieser Anzeige habe ich direkt in den Tornado geblickt,
der dabei große Gegenstände durch die Luft wirbelte)
In Leighthouse scheint Kern4 stärker als die restlichen Kerne ausgelastet zu sein.
Die Kritiker werden sagen: Ja, klar, da haben wir es ja. Nichts anderes als in Batman.
Allerdings zeigt sich in Tornado eine deutlich gleichmäßigere Lastverteilung.
Während Tornado flüssig spielbar ist, ruckelt Leighthouse schon nach den ersten 1-2 zerstörten Wänden.
Das stützt imho meine Annahme, die Lastverteilung hängt auch von der Art der Berechnungen ab.
Keiner kommt hoffentlich auf die Idee, zu sagen, Nvidia würde absichtlich nur ein einzelnes Level ausbremsen.
Nochmal zurück zu der Aussage mit dem Solver. Es kann sogar sein, dass sich in Zukunft eine Situation herausstellt, in der die Wassersimulation in der Physik-Engine X besser umgesetzt (besser kann vieles bedeuten: physikalisch höhere Korrektheit bei gleicher Rechenlast oder niedrigere Rechenlast bei gleicher Korrektheit der Ergebnisse) ist als in der Engine Y. Dafür aber Y wieder Vorteile bei der Simulation der Interaktion von Festkörpern miteinander hat.
Warum die Korrektheit der Ergebnisse eine Rolle spielt? Weil das imho einen Einfluss hat, wie realistisch etwas wirkt. Wenn z.B. in Crysis eine Kiste nicht mehr zur Ruhe kommt und andauernd zappelt, dann kommt das imho von Ungenauigkeiten bei der Berechnung.
Mein Fazit:
Die PhysX-Berechnungen über die CPU könnten sicherlich noch etwas optimiert werden. Das Tornado-Level ist ja z.B. sehr gut spielbar, während dies für das Leightouse-Level oder Batman nicht gilt.
Allerdings sind die PhysX-Level in UT3 eine der ersten Anwendungen, die davon überhaupt Gebrauch machten. Batman AA ist dagegen das aktuellste Spiel und nutzt PhysX sicherlich auch deutlich umfangreicher.
Ob man hier mit einem besser optimierten CPU-Ansatz bei high wirklich auf ein spielbares Level kommen kann, bezweifle ich aktuell.
Allerdings ist keiner dieser Effekte direkt relevant für den Spielablauf. Sie erhöhen "lediglich" den Realitätseindruck des Spieles. Wenn aufgrund einer etwas älteren Graka z.B. die Texturqualität oder die Beleuchtungseffekte auf ein niedrigeres Level gestellt werden müssen, dann betrachtet dies ja auch jeder als etwas völlig normales.
Auch wird die CPU imho nicht künstlich ausgebremst. Die anderen Kerne warten lediglich öfter auf den Kern, der sich um PhysX kümmert.
ciao Tom
