c.p.d.
2007-01-18, 01:56:00
Man liest in letzter Zeit häuffig, dass moderne Spiele auf MultiCore optimiert seien, wobei diese Spiele dann auch auf MultiCore Systemen etwas schneller laufen als auf SingleCore Systemen.
Obwohl mir gängige Threading-Konzepte durchaus bekannt sind, will mir nicht so ganz in den Kopf wie zukünftige Spiele-Engines mehrere Prozessoren sinnvoll nutzen wollen.
Im Zusammenhang mit neuen DualCore CPUs wurde viel darüber gesprochen, dass man die AI, Physik und 3D Berechnungen (und was sonst noch so anfallen könnte) in eigene Threads packen will. Und hier fange schon meine Verständnisprobleme an. Wie will man die AI und Physik parallel berechnen lassen, wenn doch die physikalischen Auswirkungen auf die Spielwelt stark von den Resultaten der AI Berechnungen abhängig sind. Auch die 3d Berechnugnen sind von AI/Physik/etc abhängig. Von parallelen Berechnungen also keine Spur. Aber irgendwie muss es ja funktionieren (sonst würden Engine-Entwickler nicht so auf MultiCore abfahren :). Sehe ich das Ganze zu fest Schwarz/Weiss?. Sind gewisse Teile der AI/Physik/3D Berechnungen sowieso voneinander unabhängig? Oder lassen sich Unabhängigkeiten zur Laufzeit mit vernünftigem Rechenaufwand bestimmen?
Des Weiteren ist mir nicht ganz klar, wie die Spiele Industrie mit der vortschreitenden CPU Entwicklung mithalten will. Angenommen wir haben 8 physikalische CPUs und 8 Engine Module, die wir auf Threads und somit CPUs verteilen können. In meinem Schönwetterszenario sind die Berechnungen der 8 Module weitgehend voneinander unabhängig. Wir hätten also (mal von gewissen Auslastungsproblemen abgesehen) unsere Berechnungen schön verteilt.
Nun wird aber die Anzahl der CPUs auf 16 verdoppelt. 16 sinvolle und unabhängige Engine Module lassen sich beim besten Willen nicht aus dem Hut zaubern und die einzelnen Module selbst lassen sich nicht weiter parallelisieren. Und schon sind wir wieder in einer Sackgassen angelangt.
Da sich gewisse Berechnungen vermutlich nur schwer (oder überhaupt nicht) parallelisieren lassen (3D auf CPU Seite?), diese möglicherweise aber sehr rechenintensiv sind, bekommen wir zu den generellen Paralleliserungs-Problemen auch noch Auslanstungsprobleme.
Was nützen 16 CPUs, wenn die 3D Berechnungen (nur ein Beispiel), im Verhältnis zu den restlichen Berechnungen, locker 5 CPUs auslasten könnten, dies aber technisch nicht realisierbar ist? Gibt es da gewisse Ansätze in Richtung micro Ops (so alla RISC). Oder sind die verschiedenen Berechnungen dafür zu unterschiedlich? Oder ist der Verwaltungsaufwand dafür zu gross?
Nun viele Fragen. Vielleicht kann mir ja jemand die einte oder andere Frage beantworten.
Obwohl mir gängige Threading-Konzepte durchaus bekannt sind, will mir nicht so ganz in den Kopf wie zukünftige Spiele-Engines mehrere Prozessoren sinnvoll nutzen wollen.
Im Zusammenhang mit neuen DualCore CPUs wurde viel darüber gesprochen, dass man die AI, Physik und 3D Berechnungen (und was sonst noch so anfallen könnte) in eigene Threads packen will. Und hier fange schon meine Verständnisprobleme an. Wie will man die AI und Physik parallel berechnen lassen, wenn doch die physikalischen Auswirkungen auf die Spielwelt stark von den Resultaten der AI Berechnungen abhängig sind. Auch die 3d Berechnugnen sind von AI/Physik/etc abhängig. Von parallelen Berechnungen also keine Spur. Aber irgendwie muss es ja funktionieren (sonst würden Engine-Entwickler nicht so auf MultiCore abfahren :). Sehe ich das Ganze zu fest Schwarz/Weiss?. Sind gewisse Teile der AI/Physik/3D Berechnungen sowieso voneinander unabhängig? Oder lassen sich Unabhängigkeiten zur Laufzeit mit vernünftigem Rechenaufwand bestimmen?
Des Weiteren ist mir nicht ganz klar, wie die Spiele Industrie mit der vortschreitenden CPU Entwicklung mithalten will. Angenommen wir haben 8 physikalische CPUs und 8 Engine Module, die wir auf Threads und somit CPUs verteilen können. In meinem Schönwetterszenario sind die Berechnungen der 8 Module weitgehend voneinander unabhängig. Wir hätten also (mal von gewissen Auslastungsproblemen abgesehen) unsere Berechnungen schön verteilt.
Nun wird aber die Anzahl der CPUs auf 16 verdoppelt. 16 sinvolle und unabhängige Engine Module lassen sich beim besten Willen nicht aus dem Hut zaubern und die einzelnen Module selbst lassen sich nicht weiter parallelisieren. Und schon sind wir wieder in einer Sackgassen angelangt.
Da sich gewisse Berechnungen vermutlich nur schwer (oder überhaupt nicht) parallelisieren lassen (3D auf CPU Seite?), diese möglicherweise aber sehr rechenintensiv sind, bekommen wir zu den generellen Paralleliserungs-Problemen auch noch Auslanstungsprobleme.
Was nützen 16 CPUs, wenn die 3D Berechnungen (nur ein Beispiel), im Verhältnis zu den restlichen Berechnungen, locker 5 CPUs auslasten könnten, dies aber technisch nicht realisierbar ist? Gibt es da gewisse Ansätze in Richtung micro Ops (so alla RISC). Oder sind die verschiedenen Berechnungen dafür zu unterschiedlich? Oder ist der Verwaltungsaufwand dafür zu gross?
Nun viele Fragen. Vielleicht kann mir ja jemand die einte oder andere Frage beantworten.