spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

So pauschal kann man einfach nicht sagen wo sich Threading lohnt und wo nicht. Arbeite dich doch einfach mal ein wenig in das Thema Multithreading ein und versuch mal ein paar kleinere Testanwendungen zu schreiben. Mach dich mit den Prinzipien einfach vertraut.

Ich finde das allgemein völlig falsch angegangen. Es mag zwar interessant klingen, verschiedene Aufgaben auf verschiedene Threads zu legen. Aber in der Realität sind die Abhängigkeiten zwischen den Threads ziemlich komplex, was in den meisten Fällen die Parallelisierung mehr oder minder untauglich macht. Und gleichzeitig lohnt sich die Parallelisierung nur, wenn die parallelen Aufgaben ähnliche Arbeitslast haben.

Daher ist das z.B. schonmal Unsinn, den Input zu parallelisieren. Der kostet nur Nanosekunden an Rechenzeit. Paralleler Input kann sich lohnen, wenn die komplette Spiellogik mit einer Kette zeitlich gespreizter Eingabeereignisse klar kommt und das für sie tatsächlich einen Unterschied macht. Die Eingabelatenz senkt man damit aber nicht, und die Auswirkungen auf die Spiellogik dürften so minimal sein, dass man sich das ersparen kann.

Was sich dagegen lohnt zu parallelisieren, ist die grafische Darstellung. Ich habe ja nun schon einige Spiele geschrieben, und bisher war immer die Grafikausgabe mit mindestens 70% die Hauptlast. Da würde ich ansetzen. Die zeitlich vordere Schranke wäre die Spiellogik - solange die den internen Zustand und damit potentiell die grafik-relevanten Parameter (Position, Rotation, Optik) ändert, sollte man nicht losrendern. Die hintere Schranke wäre die GPU, die nunmal (bisher) alle Kommandos nur sequentiell annimmt. Das geht auch nicht anders, da alle 3D-APIs ja zustandsbehaftet sind und damit die Reihenfolge der Änderungen wichtig ist.

Durch DX11 Command Queues oder eine zumeist etwas höher abstrahierte eigene Queue kann man aber mehrere Scene Queries sehr gut parallelisieren und dadurch je nach Verwaltungsaufwand einiges rausholen. Das eigentliche Rendern besteht ja immer aus einem Abklappern der anzuzeigenden Objekte, evtl. Bestimmung der Sichtbarkeit, Zusammenstellung der Zeichenaufträge daraus, evtl. Sortierung der Aufträge, und dann die Ausführung. Die Ausführung muss am Ende sequentiell passieren, aber alles andere kann stressfrei parallel gemacht werden, solange alle Operationen dabei nur lesend auf die Szene zugreifen.

Allgemein würde ich unbedingt nachmessen, wo die Rechenzeit pro Frame denn so hingeht, bevor ich irgendwas parallelisiere.

Schau dir mal das hier an:
http://www.gamasutra.com/features/200609…kkonen_01.shtml

http://www.gamasutra.com/features/20051117/gabb_01.shtml

http://www.geeks3d.com/20100418/game-eng…ming-resources/

Man kann mit events oder anderen techniken die threads synchronisieren.

Mit einer gut durchgeplanten Architektur sollten sich auch Objekte parallel "updaten" lassen.
Schrompf, machst du sowas bei Splatter? Da gibt's ja schon recht viele Gegner gleichzeitig.

Gute Frage, aber ich tu's nicht. Zum Einen, weil auch bei Splatter nach allem Profiling immernoch >70% der Framezeit nur für's Rendern draufgehen. Und zum Anderen, weil ich besonders gegen Ende der Entwicklung eine Menge fieser kleiner Hacks benutzt habe, um bestimmte Effekte zu erzielen. Da greifen sich bestimmte Monster gegenseitig tief in die privaten Taschen und hinterlassen kleine Marker, summieren irgendwas auf oder verschieben/rotieren das Gegenüber. Das alles in kleine autarke Operationen auszulagen, damit die Update-Schleife parallelisiert werden kann, würde einige Wochen Arbeit bedeuten.

Ich werde aber wohl noch ein paralleles Rendering einbauen. Da gehen ja vielleicht zwei Dutzend Passes pro Frame über das Level, die müssten sich mit etwas Schlauheit auch auf mehrere Cores verteilen lassen. Ich werde bei Gelegenheit berichten, ob und was es gebracht hat.