Sinnvolle Aufgabenverteilung für Multicore

[Asmodeus]

Ich möchte in absehbarer Zeit meinen Landschaftsviewer auch von Multicoreumgebungen profitieren lassen. Denn spätestens mit Visual Studio 2005 und OpenMP sollte die Sache ja auch "relativ leicht" realisierbar sein.
Bisher verfügt mein Programm lediglich über einen extra Loader-Thread, um Daten während der Darstellung parallel einlesen zu können. Nun hat sich die Lastverteilung allerdings immer mehr verschoben, so dass dieser extra Thread nicht wirklich viel zu tun hat. Es ist viel eher so, dass pro Pflanzenposition eine Menge Berechnungen notwendig sind und danach einige OpenGL-API Calls folgen, um die entsprechende Pflanze an dieser Position zu zeichnen. Nun sind ja auch mehrere zehntausend OpenGL Calls nicht gerade unerheblich für eine CPU. Meine Frage ist nun, wäre es sinnvoll, die beiden Sachen zu trennen, ein Kern kümmert sich um die ganzen Berechnungen und der andere Kern dann nur um die OpenGL Calls? Oder sollte man besser versuchen, die Anzahl der OpenGL Calls gleichmäßig auf beide Kerne zu verteilen? Ich habe mich bisher mit Multicore Sachen überhaupt noch nicht beschäftigt, stehe also fragend noch etwas im Wald. ;)

Gruss, Carsten.

[Demirug]

Ein OpenGL Context ist eine Statemaschine und damit fällt die Möglichkeit in gleichzeitig von mehr als einem Thread mit Daten zu füttern flach.

Die Berechnungen könnte man forken aber dann müsste man mn noch etwas finden mit dem sich der zweite Kern beschäftigt solange der erste die Daten an OpenGL übergibt.

In Verbindung mit OpenMP muß man berücksichtigen das man damit nur einen begrenzten Ausschnitt aus den möglichkeiten der Multithread programmierung hat. Dafür ist es dann aber auch einfacher in der Handhabung.

Für die Ideale Lastverteilung müsste man mit einem Profiler oder wie auch immer mal messen wie aufwendig die einzelnen Teilaufgaben sind.

[Asmodeus]

Hmm, wäre da nicht folgender Ablauf denkbar:

Um ein Modell in meiner Szene zu plazieren übergebe ich eine Transformationsmatrix gefolgt vom Aufruf zum Zeichnen des Modells. Die Transformationsmatrix enthält Werte für die Skalierung, Rotation und die Translation. Und die Berechnungen dafür werden von der CPU gemacht und sind relativ komplex. Nun könnte man diese Berechnungen ja vielleicht ganz gut auf die 2 Kerne aufteilen, einer berechnet z.B. die Werte für Skalierung und Rotation und der andere für die Translation, beide schreiben ihre Ergebnisse in die Matrix und von einem Kern erfolgt dann die Übergabe der Matrix und der Zeichenaufruf.

EDIT: Und die Frage wäre natürlich noch, ob sich diese Funktionaliät mit OpenMP umsetzen lässt?

Gruss, Carsten.

[micki]

Hmm, wäre da nicht folgender Ablauf denkbar:

Um ein Modell in meiner Szene zu plazieren übergebe ich eine Transformationsmatrix gefolgt vom Aufruf zum Zeichnen des Modells. Die Transformationsmatrix enthält Werte für die Skalierung, Rotation und die Translation. Und die Berechnungen dafür werden von der CPU gemacht und sind relativ komplex. Nun könnte man diese Berechnungen ja vielleicht ganz gut auf die 2 Kerne aufteilen, einer berechnet z.B. die Werte für Skalierung und Rotation und der andere für die Translation, beide schreiben ihre Ergebnisse in die Matrix und von einem Kern erfolgt dann die Übergabe der Matrix und der Zeichenaufruf.

EDIT: Und die Frage wäre natürlich noch, ob sich diese Funktionaliät mit OpenMP umsetzen lässt?

Gruss, Carsten.
das wäre ganz ganz schlecht, der start eines zweiten threads kostet sehr viel (ich glaube intel hat gesagt soviel wie 1000 divisionen, also mehrere khz). es wäre also ziemlich supoptimal das zu machen, zumal aufgrund von cache collisions eventuell das ganze schon deswegen langsammer werden würde.

was eine mögliche aufteileung wäre, wäre wenn du beim durchtransformieren vom scenegraph, einen core die ersten 50% der childnodes des rootnodes abarbeiten lässt und den zweiten core die zweiten 50%. sofern du da alles gut designed hast (von anfang an), könntest du eventuell die möglichen 90% leistungssteigerung bekommen.

MfG
micki

[Asmodeus]

... was eine mögliche aufteileung wäre, wäre wenn du beim durchtransformieren vom scenegraph, einen core die ersten 50% der childnodes des rootnodes abarbeiten lässt und den zweiten core die zweiten 50%. sofern du da alles gut designed hast (von anfang an), könntest du eventuell die möglichen 90% leistungssteigerung bekommen.

MfG
micki

Das Problem dürfte dabei nur sein, dass es dabei sicher möglich ist, dass beide Kerne mal etwa gleich komplexe Nodes abarbeiten, aber in der Regel wird es wohl so sein, dass ein Kern eher unkomplexe Nodes abarbeitet und der andere Kern jede Menge komplexe Nodes zum bearbeiten bekommt. Und somit wäre die Lastverteilung nicht gut ausbalanciert.

Und dann wäre ja noch die Frage, wie man die Ergebnisse wieder zusammenbekommt, denn wenn ich Demirug richtig verstanden habe, können dann ja nicht beide Cores unabhängig voneinander die OpenGL Calls abschicken.

Gruss, Carsten.

[micki]

Das Problem dürfte dabei nur sein, dass es dabei sicher möglich ist, dass beide Kerne mal etwa gleich komplexe Nodes abarbeiten, aber in der Regel wird es wohl so sein, dass ein Kern eher unkomplexe Nodes abarbeitet und der andere Kern jede Menge komplexe Nodes zum bearbeiten bekommt. Und somit wäre die Lastverteilung nicht gut ausbalanciert.

Und dann wäre ja noch die Frage, wie man die Ergebnisse wieder zusammenbekommt, denn wenn ich Demirug richtig verstanden habe, können dann ja nicht beide Cores unabhängig voneinander die OpenGL Calls abschicken.

die loadbalancing der beiden cores mußt du natürlich selber managen, dafür kann man den nodecount der subnodes immer in einer node speichern und vor dem starten der zwei bearbeitungsprocesse (bzw des zweiten threads), die nodes gleichmässig unter der root verteilen. alternativ können die beiden threads sich entgegenkommen, z.b. einer von hinten und vorne durch die childs der root gehen bis sie sich treffen (kann man ja mit nem mutex synchen).

beim durchtransformieren eines scenegraphen gibt man nichts an das api weiter, dementsprechend sehe ich da kein problem. danach kommt ja noch das umsortieren im cullingtree und das cullen... ich sehe das problem also wirklich nicht.

MfG
micki