Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderingsystems

Transkript

1 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderingsystems Dipl.-Inform. Tim Süß 1 Dipl.-Inform. Timo Wiesemann Dr. rer. nat. Matthias Fischer Heinz Nixdorf Institut, Universität Paderborn Lehrstuhl für Algorithmen und Komplexität Fürstenallee 11, Paderborn {tsuess ava mafi}@uni-paderborn.de Zusammenfassung Typischerweise sind die Knoten eines PC-Clusters nicht mit leistungsfähigen Grafikkarten ausgestattet. Dennoch bieten Cluster-Betreiber einige wenige Rechenknoten an, die mit Highend-Grafikkarten ausgestattet sind, um beispielsweise eine PowerWall zu betreiben. Wenn zwischen diesen unterschiedlichen Knotentypen ein schnelles Netzwerk existiert, kann die Bilderzeugung durch die Knoten mit schwacher Grafikkarte beschleunigt werden. Dabei können die unterschiedlichen Knotentypen unterschiedliche Aufgabe bearbeiten. In einem solchen heterogenen System, müssen die unterschiedlichen entstehenden Lasten auf andere Weise verteilt werden, als in einem System, bei dem alle Knoten gleich ausgestattet sind. Wir präsentieren in dieser Arbeit Lastbalancierungsmechanismen, die in einem parallelen Out-of-Core-Renderingsystem für heterogene PC-Cluster eingesetzt werden. Schlüsselwörter Rendering, Parallel, Lastbalancierung, Out-Of-Core, Netzwerk 1 Diese Arbeit wurde teilweise unterstützt durch das DFG-Projekt DA155/31-1,ME872/11-1, FI1491/1-1 AVIPASIA

2 Seite 40 T. Süß, T. Wiesemann, M. Fischer 1 Einleitung und Motivation Dreidimensionale Modelle werden immer häufiger zur Planung von Maschinen, Städten, Fabriken uvm. eingesetzt. Dabei werden oft CAD-Modelle als einzelne Bausteine verwendet, die eine hohe Komplexität aufweisen, welche jedoch noch von einem einzelnen Computer in Echtzeit gerendert werden können [BSG+02]. Diese Bausteine werden dann zu einer Gesamtszene zusammengefügt. Auf diese Weise kann das Gesamtmodell so groß werden, dass ein einzelner Computer nicht mehr in der Lage ist, die Szene in einer ausreichenden Geschwindigkeit anzuzeigen. Um eine hinreichend gute Navigation innerhalb einer dreidimensionalen Szene zu ermöglichen, sollten nicht weniger als zehn Bilder pro Sekunde berechnet werden können. Ein weiteres Problem ist, dass mit steigender Komplexität auch mehr Speicherplatz benötigt wird, damit keine Daten von langsamen Datenträgern, wie z. B. Festplatten, nachgeladen werden müssen. Durch den Einsatz von Approximationen kann die Komplexität solcher Szenen reduziert werden [AHH08, LWC+02]. Dies hat jedoch den Nachteil, dass die Originalszene verändert wird, da diese reduzierten Versionen von Modellen eine veränderte Oberfläche haben können. Somit können beispielsweise innerhalb der Szene Lücken zwischen einzelnen Objekten entstehen, die im Originalmodell nahtlos aneinander grenzen. Durch den Einsatz von parallelem Rendering können diese hochkomplexen 3D-Modelle in Echtzeit dargestellt werden, ohne deren Komplexität und Aussehen zu verändern. Statt zur Bilderzeugung einen einzelnen Rechner zu verwenden, wird die Gesamtlast der Bildberechnung auf die verschiedenen Computer eines PC-Clusters verteilt. Typischerweise berechnet jeder der Knoten im PC-Cluster ein Teilbild, eine sogenannte Kachel. Anschließend werden die einzelnen Teilbilder zu einem Gesamtbild zusammengefügt [MCE+94]. Dabei ist es wichtig, dass die gesamte Rechenlast gleichmäßig auf die einzelnen Rechenknoten verteilt wird, da die Geschwindigkeit des Gesamtsystems in der Regel vom langsamsten Knoten abhängt. PC-Cluster bieten die Möglichkeit große Szenen zu rendern [SFL+00]. Typischerweise sind PC-Cluster nicht für die effiziente Berechnung von dreidimensionalen Bildern ausgestattet. In der Regel sind keine Grafikkarten mit 3D-Beschleunigung vorhanden. Der Grund hierfür sind oft die Kosten, die durch zusätzliche Hardware entstehen. Dabei sind nicht nur die Anschaffungskosten gemeint, sondern auch die Kosten, die im laufenden Betrieb entstehen. Grafikkarten benötigen viel Energie und zusätzlich entstehende Wärme muss mit leistungsfähigen Klimaanlagen abgeführt werden. Aus diesen Gründen werden selbst vorhandene Grafikkarten selten aktualisiert, da modernere Grafikkarten oft mehr Wärme erzeugen als ältere Fabrikate. Das hat zur Folge, dass viele Möglichkeiten nicht vorhanden sind, die neuere Hardware bietet, wie z. B. aktuelle Shader- Modelle, Erweiterungen oder GPGPU-Schnittstellen. Ein weiterer Grund für seltene Hardware-Aktualisierungen ist, dass sich Grafikkarten negativ auf die Stabilität des Gesamtsystems auswirken können und es somit vermehrt zu Ausfällen von einzelnen Rechenknoten kommen kann.

3 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderers Seite 41 Oft sind Cluster jedoch mit einigen dedizierten Grafikknoten ausgestattet, die über aktuelle 3D-Beschleuniger verfügen. Diese lassen sich mit weniger Aufwand und preiswerter aktualisieren. Mit diesen Teilsystemen können somit alle Möglichkeiten genutzt werden, die aktuelle Grafikkarten bereitstellen. Für den Fall, dass die Gesamtszene so groß ist, dass sie nicht vollständig in den Speicher der Grafikknoten geladen werden kann, können die anderen Knoten des PC- Clusters als Sekundärspeicher eines Out-of-Core-Renderingsystems genutzt werden. Dabei können diese Knoten durch unterstützende Berechnungen zu einer schnelleren Bildererzeugung beitragen. Anstatt alle angeforderten Daten zu senden, können diese Knoten vorselektieren, welche Daten tatsächlich für die Bilderzeugung benötigt werden. Die Last dieser Aufgaben sollte möglichst gleichmäßig auf die einzelnen Knoten verteilt werden. In dieser Arbeit wird ein Algorithmus vorgestellt, mit dem die Verteilung dieser einzelnen Aufgaben schnell berechnet werden kann und der gute Ergebnisse erzielt. 2 Verwandte Arbeiten Das in dieser Arbeit vorgestellte System ist eine Kombination aus einem parallelen Renderer und einem Out-of-Core Renderer. Diese unterschiedlichen Techniken werden in verschiedenen Arbeiten thematisiert und Verfahren dazu vorgestellt. In diesem Abschnitt werden verschiedene Arbeiten zum parallelen Rendering und zum Out-of-Core- Rendering vorgestellt. 2.1 Paralleles Rendering Molnar et al. geben [MCE+94] drei verschiedene Methoden zur parallelen Bilderzeugung an. Diese Methoden unterschieden sich darin, welche Teile der Rendering-Pipeline durchlaufen werden, bevor die geometrischen Primitive umsortiert werden. Bei der Sort-First-Methode werden die geometrischen Primitive in Abhängigkeit ihrer Position auf die verschiedenen Rechner verteilt, bevor sie in die Rendering-Pipeline gesendet werden. Bei Sort-Middle-Methoden werden die Primitive in Abhängigkeit von ihrer Bildschirmposition zwischen der Geometrietransformation und der Rasterung auf die verschiedenen Renderingknoten verteilt. Bei Sort-Last-Methoden werden die Primitive, beziehungsweise die einzelnen gerasterten Pixel, erst nach dem vollständigen Durchlauf der Rendering-Pipeline in einem einzelnen Bild sortiert. Um effizient rendern zu können, muss bei allen drei Methoden die Rechenlast möglichst gleichmäßig auf die einzelnen Renderingknoten verteilt werden. Abraham et al. beschreiben in ihrer Arbeit [ACC+04] wie bei Sort-First-Algorithmen die Kohärenzen zwischen den einzelnen Bildern genutzt werden können, um die Rechenlast der verschiedenen Renderingknoten zu balancieren. Dazu werden die benötigten Rendering- Zeiten der einzelnen Renderingknoten zueinander ins Verhältnis gesetzt.

4 Seite 42 T. Süß, T. Wiesemann, M. Fischer Neben der Balancierung der Rechenlast ist auch mehrfaches Rendern von Objekten ein Problem bei der Sort-First-Methode. Samanta et al. stellen in der Arbeit [SFL+00] Techniken vor, bei denen diese Mehrfachbearbeitung vermieden wird. Die hier vorgestellten Renderingsysteme haben den Nachteil, dass bei ihnen die einzelnen Rechner zur Grafikbearbeitung ausgestattet sein sollten, um eine gute Leistung zu erzielen. Sind einige Knoten mit langsamerer Hardware ausgestattet als die übrigen Rechner, wirkt sich dies negativ auf die Leistung des Gesamtsystems aus. Ein weiterer Nachteil dieser Systeme ist, dass die Datenmenge, die gerendert werden kann, durch die Größe des Arbeitsspeichers begrenzt wird; es sind keine Out-of-Core-Mechanismen vorhanden. 2.2 Out-of-Core Rendering Wenn eine Szene so groß ist, dass sie nicht vollständig in den Grafik- und Hauptspeicher eines Rechners passt, benötigt man ein Out-of-Core-Renderingsystem, um diese Szene vollständig anzuzeigen. Dabei werden Teile der Szene aus einem sekundären Speicher, wie z. B. einer Festplatte, geladen. Durch die Erweiterung des View-Frustums können Objekte im Voraus geladen werden, die wenig später in den Bereich der Kamera geraten können [VM02]. Um schnell auf die Daten im langsamen Speicher zugreifen zu können, werden die Daten beim iwalk-renderer [CKS02] in einem Octree auf der Festplatte gespeichert. Jedes der vorgestellten Systeme verwendet die Festplatte als Speichererweiterung, deren Übertragungsrate im Vergleich zu Hochleistungs-Netzwerken sehr niedrig ist. Zudem werden die Daten ungetestet geladen, auch wenn sie z. B. durch andere Objekte verdeckt sind. Das in dieser Arbeit vorgestellte Renderingverfahren verwendet den Hauptspeicher von anderen Rechnern als sekundären Speicher, anstelle von Festplatten. Diese Rechner sind über ein schnelles Netzwerk verbunden. Dabei können diese Knoten zusätzliche Tests, wie z. B. Occlusion-Culling, durchführen. 3 Paralleler Out-of-Core Sort-First Renderer Die Architektur des parallelen Renderingsystems besteht aus drei Gruppen von Prozessoren (Bild 1 links). Jede Gruppe führt Einzelschritte der parallelen Bildberechnung durch: Auf dem Anzeigeknoten erfolgt die Darstellung des Bildes und die Navigation in der Szene, auf der Gruppe der Renderingknoten werden Teilbilder berechnet und die Gruppe der Datenknoten verwaltet die Szene (Dreiecksdaten) und unterstützt die Renderingknoten mit Verdeckungstests. Aufgrund der unterschiedlichen spezifischen Aufgaben benötigt jede Gruppe unterschiedliche Hardware mit spezifischen Fähigkeiten. Über leistungsfähige Grafikhardware müssen die Renderingknoten verfügen, da diese zeitkritisch die Geometrietransformation und die Rasterung durchführen.

5 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderers Seite 43 A R R RK 4 RK 1 R R RK 2 RK 3 D D D D Skelett des Octrees D D D D D D D D Inhalte der Octreezellen (Dreiecke) D D D D Bild 1: Links: Architektur des Renderingsystems, Anzeigeknoten (AK), Renderingknoten (RK), Datenknoten (DK). Rechts oben: Aufteilung des Bildraums und Zuordnung der Renderingknoten. Rechts unten: Sampletree Organisation und Out-of-Core-Speicherung der virtuellen Szene Die virtuelle Szene wird mit Hilfe eines Sampletrees organisiert (Bild 1, rechts unten). Der Sampletree ist eine Octree-ähnliche, räumliche, randomisierte Datenstruktur zur Approximation großer, aus Dreiecken bestehenden Szenen [KKF+02]. Die Dreiecke sind in den Zellen eines Octrees gespeichert. Der Octree des Sampletrees wird im Preprocessing berechnet und auf der Festplatte gespeichert. Vor dem Walkthrough werden die Zellen des Sampletrees von der Festplatte geladen und redundant (s. u.) auf den Datenknoten gespeichert (Bild 1, links). Die Renderingknoten speichern nur das Skelett des Sampletrees ohne die Geometrie in den Knoten des Octrees. Renderingknoten Vor der Berechnung eines Bildes wird der Bildraum, der Sort-First-Methode entsprechend, in rechtwinklige Kacheln aufgeteilt (Bild 1, rechts oben, Beispiel für vier Renderingknoten). Jeder Renderingknoten berechnet das Teilbild für genau eine Kachel. Dieses Teilbild wird nach dem Rendering an den Anzeigeknoten gesendet und dort mit den Kacheln der anderen Renderingknoten zu einem Bild zusammengefügt und angezeigt. Die virtuelle Szene ist so groß, dass nur das Skelett des Sampletrees vollständig in den Speicher eines Renderingknotens passt. Die Inhalte der Octreezellen sind nur teilweise auf den Renderingknoten vorhanden und werden bei Bedarf aus dem Speicher der Datenknoten nachgeladen. Es wird ein Cachingmechanismus angewandt: Zu Beginn jeder

6 Seite 44 T. Süß, T. Wiesemann, M. Fischer Bildberechnung berechnet der Traversierungsalgorithmus des Sampletrees mit Hilfe des Octree-Skeletts alle Octreezellen, die darzustellen sind. Anschließend ist im Cache der Renderingknoten zu prüfen, ob eine Zelle des Sampletrees neu von den Datenknoten angefordert werden muss. Ist ein Objekt bereits im Cache vorhanden, wird geprüft, ob es weiter benötigt wird; ist es länger nicht genutzt worden, wird es gelöscht. Teile der unsichtbaren Octreezellen, die nahe am Sichtkegel liegen, werden bei den Datenknoten aus dem Netzwerk angefordert. Diese Octreezellen sind auf den Renderingknoten verfügbar, sobald sie in den Sichtkegel der Kamera geraten. Ist nur wenig freier Platz im Primärspeicher, werden diejenigen Octreezellen aus dem Cache der Renderingknoten verdrängt, die seit mehreren Frames nicht mehr gerendert wurden. Falls Octreezellen des Sampletrees nachgeladen werden müssen, erfolgt die Anfrage an den Anzeigeknoten, der alle Anfragen nach der Methode des c-load-collision- Protokolls auf die Datenknoten verteilt. Die Renderingknoten warten jedoch nicht darauf, dass sie alle Octreezellen erhalten. Die Octreezellen, die die Renderingknoten nicht erreichen, sind entweder verdeckt und werden nicht von den Datenknoten verschickt oder sie sind sichtbar und treffen später auf den Renderingknoten ein. Diese Nachzügler werden in der Regel in den nachfolgenden Bildern gerendert. Bei schnellen Kameraschwenks können so Bildfehler entstehen, was in Bild 2 anhand eines Beispiels zu sehen ist. Bild 2: Kameraschwenk mit zwei Renderingknoten. Links: Hinterer Flugzeugteil vor dem Schwenk nach rechts. Rechts: In Teilbildern von den Renderingknoten 1 und 2 sind an der Flugzeughülle Löcher (Hintergrund) zu sehen. Datenknoten Die Datenknoten haben zwei Aufgaben: Sie halten die virtuelle Szene im lokalen Speicher, wobei jeder Datenknoten nur einen Teil der Szene besitzt. Außerdem unterstützen sie die Renderingknoten durch die Berechnung von Verdeckungstests. In vielen Out-of-Core-Renderingsystemen ist die verwaltete Szene auf Festplatten gespeichert. Während des Walkthroughs sind nur Teile davon im Hauptspeicher und werden abhängig von der Position des Benutzers nachgeladen. In unserem System ist die

7 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderers Seite 45 Szene im Hauptspeicher der Datenknoten verteilt gespeichert; der Hauptspeicher der Datenknoten dient damit als sekundärer Speicher für die Renderingknoten. Jede Octreezelle des Sampletrees ist auf konstant vielen Datenknoten gespeichert. Die Octreezellen werden randomisiert vor dem Walkthrough verteilt (s. u.). Während des Walkthroughs erhalten die Datenknoten Anfragen der Renderingknoten nach Octreezellen. Die Datenknoten testen diese Octreezellen auf Sichtbarkeit und schicken nur die sichtbaren Octreezellen an die Renderingknoten. Unsichtbare Objekte werden nicht quittiert. Dazu besitzt jeder Datenknoten von jedem Renderingknoten den Tiefenpuffer. Mit diesem führen die Datenknoten Verdeckungstests für angeforderte Octreezellen durch. Die Werte des Tiefenpuffers können veraltet sein, da sie von zuvor gerenderten Bildern stammen. Damit die Fehler durch die veralteten Tiefenpuffer nicht zu groß werden, senden die Renderingknoten in regelmäßigen Abständen ihre Tiefenpuffer an alle Datenknoten. Anzeigeknoten Auf dem Anzeigeknoten werden die gerenderten Bilder angezeigt und die Kamera vom Benutzer gesteuert. Die Kameraposition und die Orientierung werden an die Renderingund Datenknoten gesendet. Der Anzeigeknoten setzt das fertige Bild aus den Teilbildern zusammen, die von den Renderingknoten berechnet und versendet werden. Dieses Bild wird solange angezeigt, bis ein neues Bild vollständig empfangen und zusammengesetzt ist. Der Anzeigeknoten ist für zwei Lastbalancierungsaufgaben verantwortlich. Er muss zum einen die Last der Renderingknoten und zum anderen die Last der Datenknoten balancieren. Die Lastbalancierung der Renderingknoten erfolgt durch eine Vergrößerung/Verkleinerung der Kacheln (Bild 1, rechts). Nach k Bildern empfängt der Anzeigeknoten die akkumulierten Rendering-Zeiten der letzten k Bilder von den Renderingknoten. Die Rendering-Last auf den einzelnen Renderingknoten wird balanciert, indem diese Zeiten miteinander verglichen und zueinander ins Verhältnis gesetzt werden. Benötigt ein Renderingknoten signifikant mehr/weniger Rendering-Zeit als die anderen Knoten, wird die Kachelgröße des Renderingknotens verkleinert/vergrößert. Die zweite Aufgabe des Anzeigeknotens ist die Verteilung und Balancierung von Anfragen nach Octreezellen an die Datenknoten (s. nachfolgenden Abschnitt). Zusammenfassend ist der Kommunikationsablauf des gesamten Renderingalgorithmus in Bild 3 als Sequenzdiagramm dargestellt.

8 Seite 46 T. Süß, T. Wiesemann, M. Fischer Bild 3: Sequenzdiagramm: Kommunikation für die Render-Schleife Verteilung der Octreezellen auf die Datenknoten und Lastbalancierung Das c-collision-protokoll [Ste96] ermöglicht einen schnellen Zugriff auf Daten, die randomisiert und redundant gespeichert sind. Mit hoher Wahrscheinlichkeit wird ein Datenmodul höchstens mit c Anfragen belastet. Das Protokoll funktioniert wie folgt: Jede Anfrage nach einem Datum wird an alle Datenmodule (Bild 4) gesendet, die eine Kopie des Datums besitzen. Bekommt ein Datenmodul höchstens c Anfragen, beantwortet es alle Anfragen und entfernt diese bei den anderen Datenmodulen. Werden mehr als c Anfragen gestellt, wird keine Anfrage beantwortet. Dies wird rundenweise durchgeführt, bis alle Anfragen beantwortet sind. Kann innerhalb einer Runde keine der noch ausstehenden Anfragen beantwortet werden, wird das c für diese Runde erhöht. Bei dieser Form des Protokolls wird angenommen, dass die Anfragen gleich gewichtet sind. Im einfachen c-collision Protokoll gibt es nur ungewichtete Nachrichten. Eine Erweiterung des Protokolls zum c-load-collision-protokoll [BMS97] bezieht die Gewichte von Anfragen mit in die Verteilung der Anfragen ein. Das Gewicht einer Nachricht wird im Allgemeinen durch die Größe der angefragten Daten bestimmt. Bei einer synchronen Abarbeitung des Protokolls wird die durch c gegebene maximale Belastung der einzelnen Datenmodule typischerweise nicht überschritten, das heißt, wenn alle Anfragen vollständig bearbeitet sind, bevor neue Anfragen gestellt werden. Um die Latenzen zu reduzieren, führen wir die Anfragen der Octreezellen asynchron aus. Das heißt, sobald die neu angefragten Octreezellen bekannt sind, werden die entsprechenden Datenknoten angefragt. Geringere Latenzen haben weniger Bildfehler zur Folge.

9 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderers Seite 47 Bild 4: Das c-collision-protokoll: Ein Auftrag wird an alle Datenmodule, die das gesuchte Datum besitzen, zugewiesen (cyan). Alle Datenmodule, die in einer Runde höchstens c=2 Anfragen haben, beantworten diese (magenta). Um die Last durch Anfragen der Octreezellen gleichmäßig auf die Datenknoten zu verteilen, verwenden wir das c-load-collision-protokoll: Im Preprocessing werden die Octreezellen zufällig und redundant auf den Datenknoten verteilt. Diese Zuweisung bleibt zur Laufzeit bestehen. Bei jedem Bild werden die Datenanfragen von den Renderingknoten zuerst zu dem Anzeigeknoten geschickt. Dieser Knoten sammelt alle Anfragen und berechnet anschließend eine Zuweisung der Anfragen an die Datenknoten nach dem c-load-collision-protokoll. Die Runden des Protokolls werden nicht im Netzwerk ausgeführt, sondern auf dem Anzeigeknoten simuliert. Das verkürzt das Kommunikationsaufkommen und die benötigte Balancierungszeit. Alle zu einem Zeitpunkt vorliegenden Anfragen werden in Phasen eingeteilt. Pro Phase wird eine Verteilung von so vielen Anfragen berechnet, wie es Datenknoten gibt. In jeder Phase werden die Anfragen in mehreren Runden verteilt (Bild 4). Das Gewicht einer Octreezelle entspricht der Anzahl von Dreiecken, die darin gespeichert sind. Dies eignet sich als Gewicht für das c-load-collision Protokoll, da die Dreiecksanzahl sowohl die benötigte Zeit für die Verdeckungstests beeinflusst, als auch eine gute Abschätzung der benötigten Speicherplatzgröße darstellt. Wenn in einer Runde eine Anfrage a von mehreren Datenknoten beantwortet werden kann, muss entschieden werden, welcher Knoten die Anfrage zugewiesen bekommt. Um die Datenknoten möglichst gleichmäßig auszulasten, werden zunächst die Summen der Auftragsgewichte berechnet, die von den verschiedenen Knoten aktuell bearbeitet werden. Die Funktion, mit der die Summe der Gewichte eines Datenknotens d berechnet wird, bezeichnen wir als s(d).

10 Seite 48 T. Süß, T. Wiesemann, M. Fischer Sei D die Menge der Datenknoten, die den Auftrag a bearbeiten können (mit D > 1). Dann ist die Summe der Gesamtgewichte der Knoten, die a bearbeiten können. Die Wahrschein- wird lichkeit, dass ein Datenknoten d i für die Bearbeitung der Anfrage a ausgewählt ist: Pr 1 Da die Summe der Wahrscheinlichkeiten Eins ist, können die Wahrscheinlichkeiten als disjunkte Abschnitte im Null-Eins-Intervall dargestellt werden. Dabei werden die Ab- für einen schnitte nach Größe sortiert. Um zu bestimmen, welcher Knoten den Zuschlag Auftrag erhält, wird eine zufällige Zahl zwischen Null und Eins bestimmt. Diese Zahl liegt in einem der gegebenen Wahrscheinlichkeits-Intervalle und legt somit den Knoten fest, der den Auftrag erhält. Durch diese Art der Verteilung werden Datenknoten mit geringer Belastung bevorzugt. Bild 5: Darstellung des Testpfads durch das 3D-Modell der Boeing Evaluierung Als Testszene wurde das Modell der Boeing 777 verwendet. Dieses Modell ist so groß, dass es nicht vollständig in den Speicher der Renderingknoten unseres Testsystems ge- laden werden kann. Bei unseren Tests wurden vier Renderingknoten und bis zu 32 Dazu können, tenknoten verwendet. Um eine beliebige Anzahl von Datenknoten testen haben wir einen Simulator entwickelt. Dieser Simulator verwendet als Eingabe Anfra- gesequenzen, die aus Durchläufen des Testsystems stammen (Bild 5).

11 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderers Seite 49 In unseren Tests untersuchen wir, wie gleichmäßig das von uns entwickelte c-load- Collision-Protokoll die Last auf die verschiedenen Datenknoten verteilt. Da es sich um ein randomisiertes Protokoll handelt, werden die Experimente mehrfach mit unterschiedlichen Startwerten für den Pseudo-Zufallszahlen-Generator durchgeführt und deren Ergebnisse gemittelt. Für jeden hier vorgestellten Test sind zwei Diagramme gegeben. Es wird an jeder Position des Walkthroughs gemessen, wie viele Dreiecke jeder Datenknoten bearbeiten muss. Das erste Diagramm zeigt auf der x-achse die Positionen des Walkthroughs an und auf der y-achse die Anzahl der Dreiecke, die ein Datenknoten bearbeiten muss. Um die Ergebnisse an den verschiedenen Positionen vergleichen zu können, sind diese Werte normalisiert. Dazu wird die Anzahl der Dreiecke die ein einzelner Datenknoten an einer Position zugewiesen bekommt, in Relation zu der Gesamtanzahl der angefragten Dreiecke an dieser Position gesetzt. Die Datenknoten sind nach der normalisierten, zugewiesenen Dreiecksanzahl sortiert. Die roten eingezeichneten Messwerte in den Diagrammen geben den Median an. Die blauen Messpunkte stellen die 0,1/0,9-Quantile an den einzelnen Positionen dar. Das zweite Diagramm zeigt auf der y-achse ebenfalls die Anzahl der Dreiecke an, die ein Datenknoten bearbeiten muss. Auf der x-achse ist die Anzahl der Anfragen aufgezeichnet. Ein Wert in diesem Diagramm zeigt an, wie viele Dreiecke ein Datenknoten bei einer gegebenen Anzahl von Anfragen bearbeiten muss. Das zweite Diagramm ist angegeben, um die starken Abweichungen bei der Dreiecksbearbeitung im ersten Diagramm zu erklären. Bild 6: Auslastung bei 24 Datenknoten und einer Kopie

12 Seite 50 T. Süß, T. Wiesemann, M. Fischer Bild 7: Auslastung bei 80 Datenknoten und zwei Kopien Bild 8: Auslastung bei 120 Datenknoten und zwei Kopien Bild 9: Auslastung bei 24 Datenknoten und drei Kopien In allen Diagrammen der Bilder 6-8 ist zu erkennen, dass die Abweichung der Auslastung der einzelnen Knoten in der Regel gering ist. Weicht die Auslastung der einzelnen Datenknoten stark voneinander ab, ist die Anzahl der Anfragen niedrig, da wenige Anfragen auf viele Knoten verteilt werden müssen. Je mehr Anfragen es gibt, desto gleichmäßiger ist die Last verteilt. Erhöht man die Anzahl der Datenknoten, sind die Abweichungen vom Median geringer.

13 Gewichtetes c-collision-protokoll zur Balancierung eines parallelen Out-of-Core-Renderers Seite 51 Als nächstes untersuchen wir, wie sich die Redundanz auf die Lastbalancierung auswirkt. Dafür wird die Anzahl von Kopien eines Objektes im Cluster von zwei auf drei erhöht. Die Messungen in den Bildern 6 und 9 zeigen, dass die Last gleichmäßiger verteilt werden kann, wenn die Anzahl der Kopien erhöht wird. Das ist daran zu erkennen, dass die Quantile dichter am Median liegen, wenn die Redundanz höher ist. Insgesamt zeigen die Tests, dass mit dem entwickelten Protokoll eine gute Balancierung erzielt wird, wenn ausreichend viele Anfragen gestellt werden. Dies ist gut an den Positionen in der Szene zu erkennen, an denen wenige Anfragen gestellt werden, da nur wenig Geometrie sichtbar ist; dies ist beim Walkthrough an den Positionen 2250 bis 2800 zu sehen, wo die Boeing verlassen und die Kamera gedreht wird. 5 Resümee und Ausblick In dieser Arbeit haben wir Lastbalancierungsmechanismen für ein paralleles Out-of- Core-Renderingsystem vorgestellt. Das entwickelte Renderingsystem ist so aufgebaut, dass es die verschiedenen Knotentypen eines heterogenen Clusters verwenden kann. Dabei werden die entstehenden Lasten innerhalb des Systems auf unterschiedliche Art und Weise balanciert. Um die entstehende Last der Renderingknoten zu balancieren, werden die Kohärenzen zwischen den einzelnen Bildern ausgenutzt. Zur Balancierung der Last der Datenknoten wird eine Variante des c-load-collision- Protokolls verwendet. Dieses Protokoll erzielt schnell eine gute Lastbalancierung, wenn ausreichend viele Jobs vorhanden sind. Das hier vorgestellte heterogene PC-Cluster-System besteht nur aus zwei verschiedenen Arten von Rechenknoten. Die hier vorgestellte Variante des c-load-collision- Protokolls kann leicht verändert werden, damit es die Last einer größeren Anzahl von verschiedenen Knotentypen balanciert. 6 Literatur [ACC+04] [AHH08] [BMS97] [BSG+02] ABRAHAM, F.; CELES, W.; CERQUEIRA, R.; CAMPOS, J. L.: A Load-Balancing Strategy for Sort-First Distributed Rendering. In: SIBGRAPI 04: Proceedings of the Computer Graphics and Image Processing, XVII Brazilian Symposium. Washington, DC, USA: IEEE Computer Society, 2004, S AKENINE-MÖLLER, T.; HAINES, E.; HOFFMAN, N.: Real-Time Rendering 3rd Edition. Natick, MA, USA : A. K. Peters, Ltd., 2008 BERENBRINK, P.; MEYER AUF DER HEIDE, F.; SCHRÖDER, K.: Allocating weighted jobs in parallel. In: SPAA 97: Proceedings of the ninth annual ACM symposium on Parallel algorithms and architectures. New York, NY, USA: ACM, 1997, S BAXTER, W. V.; SUD, A.; GOVINDARAJU, N. K.; MANOCHA, D.: GigaWalk: interactive walkthrough of complex environments. In: EGRW 02: Proceedings of the 13th Eurographics workshop on Rendering. Aire-la-Ville, Switzerland: Eurographics Association, 2002, S

14 Seite 52 T. Süß, T. Wiesemann, M. Fischer [CKS02] [KKF+02] [LWC+02] [MCE+94] [SFL+00] [Ste96] [VM02] CORRÊA, W. T.; KLOSOWSKI, J. T.; SILVA, C. T.: iwalk: Interactive Out-of-Core Rendering of Large Models KLEIN, J.; KROKOWSKI, J.; FISCHER, M.; WAND, M.; WANKA, R.; MEYER AUF DER HEIDE, F.: The randomized sample tree: a data structure for interactive walkthroughs in externally stored virtual environments. In VRST 02: Proceedings of the ACM symposium on Virtual reality software and technology, pages , New York, NY, USA, ACM. LUEBKE, D.; WATSON, B.; COHEN, J. D.; REDDY, M.; VARSHNEY, A.: Level of Detail for 3D Graphics. New York, NY, USA, Elsevier Science Inc., 2002 MOLNAR, S.; COX, M.; ELLSWORTH, D.; FUCHS, H.: A Sorting Classification of Parallel Rendering. In: IEEE Comput. Graph. Appl. 14 (1994), Nr. 4, S SAMANTA, R.; FUNKHOUSER, T.; LI, K.; SINGH, J. P.: Hybrid sort-first and sort-last parallel rendering with a cluster of PCs. In: HWWS 00: Proceedings of the ACM SIG- GRAPH/EUROGRAPHICS workshop on Graphics hardware. New York, NY, USA: ACM, 2000, S STEMANN, V.: Parallel balanced allocations. In: SPAA 96: Proceedings of the eighth annual ACM symposium on Parallel algorithms and architectures. New York, NY, USA: ACM, 1996, S VARADHAN, G.; MANOCHA, D.: Out-of-core rendering of massive geometric environments. In: VIS 02: Proceedings of the conference on Visualization 02. Washington, DC, USA : IEEE Computer Society, 2002, S Autoren Dipl.-Inform. Tim Süß studierte Informatik an der Universität Paderborn. Seit 2007 ist er wissenschaftlicher Mitarbeiter des Heinz Nixdorf Instituts. Seine Forschungsinteressen liegen im Bereich Computergrafik und verteiltes Echtzeit-Rendering. Dipl.-Inform. Timo Wiesemann studierte Informatik an der Universität Paderborn. Seit 2010 ist er am Heinz Nixdorf Institut angestellt. Seine Forschungsinteressen liegen im Bereich Computergrafik. Dr. rer. nat. Matthias Fischer studierte Informatik an der Universität Paderborn. Seit 1995 ist er am Heinz Nixdorf Institut angestellt und erhielt dort die Promotion für seine Arbeit über verteilte virtuelle Umgebungen. Seine Forschungsinteressen liegen im Bereich Computergrafik, Echtzeit-Rendering Algorithmen und verteiltes Rechnen.