Multi-Thread Scene Graphs
-
Hallo Leute!
Keine Ahnung, ob ich mit dieser Frage in nem C++-Forum richtig bin, aber evt. weiss hier jemand darüber bescheid..
Es gibt Scene Graphs (z.B. OpenSG) welche paralleles Rendering ermöglichen. Mich nimmt Wunder, wie das funktioniert. Prinzipiell ist es ja so, dass verschiedene Threads (auf verschiedenen Prozis) je einen gewissen Teil des Bildes rendern. Aber wie funktioniert die Synchronisation?
Kennt jemand einen schnellen Open Scene Graph ausser OpenSG, welcher Multi-Thread fähig ist?mfg,
-
Also das simpelste, was ich mir jetzt vorstellen könnte: Rechner A macht die ersten 50% der Zeilen und Rechner B die anderen. Rechner A ist der "Host" und gibt Rechner B die Daten die zum Rendern nötig sind. Wenn Rechner B fertig ist, schickt er seine Hälfte an Rechner A und der setzt daraus das gesamte Bild zusammen. So was ähnliches ging bei Povray, was hiermit aber wohl nur sehr entfernt zu vergleichen ist.
Bye, TGGC \-/
-
TGGC schrieb:
Also das simpelste, was ich mir jetzt vorstellen könnte: Rechner A macht die ersten 50% der Zeilen und Rechner B die anderen. Rechner A ist der "Host" und gibt Rechner B die Daten die zum Rendern nötig sind. Wenn Rechner B fertig ist, schickt er seine Hälfte an Rechner A und der setzt daraus das gesamte Bild zusammen. So was ähnliches ging bei Povray, was hiermit aber wohl nur sehr entfernt zu vergleichen ist.
Das stell ich mir auch so vor (und wird auch so gemacht: Sort First). Aber wie wird die Synchronisation gehandelt? Wenn es zwei lose gekoppelte Rechner sind, dann ist's noch mal was anderes.
Aber man stelle sich mal vor, es handle sich um einen Rechner mit mehreren GPUs. Wie soll denn das zusammen funktionieren? Mehrere Threads, welche schlussendlich ihren Bereich des Bildschirmspeichers (einer bestimmten GraKa) füllen? Und sobald fertig->Ausgabe?
D.h. ich könnte einfach mehrere GraKas in einem PC stecken, und ab geht die Post?
Kennt Ihr ein Bsp. wo die Multi-Thread-Funktion von OpenSG (oder was ähnlichem) eingesetzt wird?
-
Ich denke das die evtl. so funktionieren könnte, aber von der Geschwindigkeit her nichts bringt. Dann müsstest du deine Daten zweimal über den Bus schicken (was nichts in GraKa RAM passt), die Daten in der eine Karte auslesen (dafür sind "normale" Karten nicht gedacht) und diese zur anderen schicken. Aber eigentlich wird genau das direkt in Hardware gemacht, denn heutig Karten haben ja mehrere Pixelpipelines (oder wie die heissen) die paralell arbeiten.
Bye, TGGC \-/
-
TGGC schrieb:
Ich denke das die evtl. so funktionieren könnte, aber von der Geschwindigkeit her nichts bringt. Dann müsstest du deine Daten zweimal über den Bus schicken (was nichts in GraKa RAM passt), die Daten in der eine Karte auslesen (dafür sind "normale" Karten nicht gedacht) und diese zur anderen schicken. Aber eigentlich wird genau das direkt in Hardware gemacht, denn heutig Karten haben ja mehrere Pixelpipelines (oder wie die heissen) die paralell arbeiten.
Das denk ich eben auch, dass es nix bringen würde. Aber wo liegt denn der Vorteil eines Multi-Threading Scene Graph?
Die Pipes werden ja auch von einem einzelnen Thread alle benutzt, oder? Das regelt die GraKa?
-
Ich kann mir da eigentlich auch nur einen Sinn vorstellen, wenn man in Software rendert und eine Multiprozessormaschine bzw. gleich mehrere Rechner zur Verfügung hat.
Bye, TGGC \-/
-
Ich hab gerade ein News-Arikel über Open Inventor gelesen. So wie ich daraus schliesse brauche ich doch ein Multi-Thread Scene Graph für multi-pipe rendering! Ich dachte bisher, die GraKa regle das "irgendwie" selber.. So gesehen bringt ein Multi Thread Scene Graph doch einen ziemlich grossen Performance-Vorteil.
Hier noch der Aritikel (von http://www.tgs.com/news/Newsletter/Volume2/issue2/spot_multi_thread.htm):Using multiple threads in an application can increase overall performance by making use of multiple processors, or by making better use of a single processor. This also enables use of multiple graphics pipes for high-end systems. Open Inventor support for multiple threads allows graphics developers to design advanced applications with more convenience and performance: convenience for the programmer, convenience for the Open Inventor application user, and performance in terms of graphics display.
Open Inventor support for multiple threads enables scenarios, including the following:
* One or more threads modifying a scene while other threads are rendering the scene graph. For example, an application doing computation (modifying the scene graph) and rendering (displaying the scene graph)
* Reading or writing a scene graph while other threads are working on other scene graphs. This allows the application to simultaneously generate several scene graphs or part of a scene graph.
* Modifying a scene graph in a worker thread. For instance, simplification or spatial optimization.
* Multiple "viewers" (drawing windows) each having a separate rendering thread for each window. This allows graphics processing to be spread over multiple CPUs and/or multiple graphics pipes.
* Multiple threads rendering the same scene graph, useful for multi-pipe rendering. This technology will make it easier to support high performance hardware for the most demanding applications. For instance, applications dedicated to large immersive displays, such as CAVE, Reality Centers or Workbenches, can take advantage of parallelized graphics engines.
-
http://www.c-plusplus.net/forum/viewtopic.php?t=68340
Also normale "Consumerhardware" ist damit jedenfalls nicht gemeint.
Bye, TGGC \-/
