Diplomarbeit Interaktives Raytracing Auf Hochleistungsrechnern

TECHNISCHE UNIVERSITÄT DRESDEN

FAKULTÄT INFORMATIK INSTITUTFÜR SOFTWARE- UND MULTIMEDIATECHNIK PROFESSURFÜR COMPUTERGRAPHIKUND VISUALISIERUNG PROF.DR.STEFAN GUMHOLD

Diplomarbeit

zur Erlangung des akademischen Grades Diplom-Informatiker

Interaktives Raytracing auf Hochleistungsrechnern

Daniel Grafe (Geboren am 16. August 1980 in Ostercappeln)

Betreuer: Prof. Dr. Stefan Gumhold, Dr. Matthias Müller

Dresden, 11. November 2007 Aufgabenstellung

Das Raytracing Verfahren erlaubt es, realistisch beleuchtete Szenen darzustellen. Dabei können harte und weiche Schatten, spiegelnde Reflektionen und Brechung an transparenten Oberflächen wiederge- geben werden. Außerdem lönnen beliebige Reflektionseigenschaften definiert werden. Das Raytracing- Verfahren eignet sich ausgesprochen gut für eine parallele Berechnung. In der Diplomarbeit soll ein paralleler Raytracer entwickelt und in eine interaktive Anwendung integriert werden. Im Einzelnen sind folgende Teilaufgaben zu lösen:

• Literaturrecherche über bestehende Parallelisierungen des Raytracing Verfahrens

• Entwicklung eines neuen oder Modiﬁkation eines existierenden Raytracing Ansatzes für das parallele Berechnen von Bildern. Es sollen Szenengraphen mit den üblichen Grundprimitiven, Trans- formationsknoten, Materialeigenschaften und Lichtquellen unterstützt werden.

• Erstellung oder Import von Beispielszenen mit unterschiedlichen Kompexitätsmerkmalen

• Entwicklung einer Applikation, die das Durchwandern einer Szene vor der Powerwall des Lehr- stuhls CGV mit stereoskopischer Projektion erlaubt. Für die interaktive Bildgenerierung soll der parallelisierten Raytracingansatz verwendet werden.

• Optimierung des Datenverkehrs zwischen Hochleistungsrechner und Darstellungsrechner.

• Untersuchung von Vorhersagestrategien für die Verminderung von Latenzzeiten.

• Analyse und Bewertung des implementierten Ansatzes Selbstständigkeitserklärung

Hiermit erkläre ich, dass ich die von mir am heutigen Tag dem Prüfungsausschuss der Fakultät Informa- tik eingereichte Diplomarbeit zum Thema:

Interaktives Raytracing auf Hochleistungsrechnern vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel be- nutzt sowie Zitate kenntlich gemacht habe.

Dresden, den 11. November 2007

Daniel Grafe 1

Inhaltsverzeichnis

1 Einleitung 3 1.1 Motivation und Zielsetzung ...... 3 1.2 Gliederung ...... 3

2 Bisherige Arbeiten und Schwerpunkte 5 2.1 Ausdrücklich interaktiv ...... 5 2.2 Nicht ausdrücklich interaktiv ...... 6 2.3 Zusammenfassung ...... 8

3 Eingesetzte Hardware und Bedingungen 9 3.1 Die Powerwall ...... 9 3.2 Rechentechnik und Kommunikation ...... 9 3.2.1 SGI Altix 4700 ...... 10 3.2.2 Linux Networx PC-Farm Deimos ...... 10 3.2.3 Kommunikation auf dem Großrechner ...... 11 3.2.4 Kommunikation zwischen Großrechner und Anzeige ...... 11 3.3 Der Anzeigerechner ...... 12

4 Das Bilderzeugungsverfahren “Ray Tracing” 13 4.1 Überblick über das Verfahren ...... 13 4.2 Abschätzung des Berechnungsaufwandes ...... 14 4.3 Parallelisierungsansatz ...... 15

5 Entwurf 16

6 Implementierung als Bibliothek 18 6.1 Repräsentation der Szene und Realisierung der Rekursion ...... 18 6.2 Schnittberechnungen ...... 19 6.2.1 Quadrics ...... 19 2

6.2.2 Dreicksschnitt ...... 22 6.2.3 Schnitt mit Dreicksnetzen ...... 24 6.2.4 Boxschnitt ...... 25 6.3 Kameras ...... 26 6.3.1 Perspektivische Kamera ...... 26 6.3.2 Stereoskopische Kamera ...... 27 6.4 Lichtquellen ...... 28 6.4.1 Point Light ...... 29 6.4.2 Spot Light ...... 29 6.4.3 Sharp Spot Light ...... 29 6.4.4 Area Light ...... 30 6.5 Beleuchtung ...... 30 6.5.1 Lokale Beleuchtung ...... 30 6.5.2 Reﬂexion und Transmission ...... 32 6.6 Hüllvolumen ...... 35 6.7 Zusammenfassung und Bewertung ...... 37

7 Parallelisierung auf den Rechnern des ZIH 43 7.1 Entwicklung auf dem CPU-Set “Neptun” der Altix ...... 44 7.2 Vergleichsmessungen auf der Altix und der PC-Farm ...... 51 7.2.1 Messung auf der Altix ...... 52 7.2.2 Messung auf der PC-Farm “Deimos” ...... 55 7.3 Zusammenfassung und Bewertung ...... 58

8 Darstellung auf der Powerwall 59 8.1 Bildausgabe mit OpenGL ...... 59 8.2 Nutzerinteraktion ...... 60 8.3 Bandbreite und Latenz ...... 60 8.4 Szenenorganisation ...... 61 8.5 Messung und Bewertung des Gesamtsystems ...... 62

9 Zusammenfassung und Bewertung 67

Literaturverzeichnis 70

A Screenshots 75 1. EINLEITUNG 3

1 Einleitung

1.1 Motivation und Zielsetzung

Das Bilderzeugungsverfahren “Ray Tracing” steht im Allgemeinen für hochqualitative, realistisch wir- kende Einzelbilder. Dieser Eindruck wird durch die Möglichkeiten des Verfahrens erreicht, Szenen realistisch zu beleuchten und optische Effekte wie Brechung und Reflexion zu modellieren. Die Simulation von Schatten verleiht den Szenen einen erhöhten Eindruck von Tiefe und Räumlichkeit. Einen Eindruck von den Möglichkeiten des Verfahrens kann man beispielsweise bei der “Internet Ray Tracing Compe- tition” [irt] bekommen, wo monatlich die optisch eindrucksvollsten, mit Ray Tracing erzeugten Bilder ausgezeichnet wurden. Die Darstellungsqualität der Bilder wird allerdings durch einen großen Berech- nungsaufwand erkauft. Die Berechnungszeiten der einzelnen Bilder können je nach Komplexität im Be- reich von Stunden bis Tagen liegen, und Szenen mit solch einem Realismus eignen sich somit nicht für interaktive Anwendungen. Das Verfahren lässt sich aufgrund seiner Berechnungsart allerdings sehr gut parallelisieren. Im April 2007, und somit kurz vor Beginn dieser Diplomarbeit, wurde am Zentrum für Informationsdienste und Hochleistungsrechnen ein neuer Hochleistungsrechnerkomplex eingeweiht, welcher für einen parallelisierten Ray Tracer genutzt werden konnte. Dieser Ray Tracer war im Rahmen der Diplomarbeit als bilderzeugende Komponente eines interaktiven Systems zu entwickeln. Am Lehrstuhl für Computergrafik und Visualisierung wird die Powerwall betrieben, eine großflächi- ge Projektionsleinwand, welche mittels Stereoskopischer Projektion die Wiedergabe von Bildern mit Tiefeneindruck erlaubt. Auf diesem System sollen die auf dem Hochleistungsrechner erzeugten Bilder angezeigt werden, wodurch sich aufgrund der räumlichen Trennung beider Komponenten das Problem eines effizienten Datentransports ergibt. Insgesamt war eine Anwendung zu entwickeln, die mit der Rechenleistung des Hochleistungsrechners ausreichend viele Bilder erzeugt, so dass eine interaktive Durchwanderung von Szenen möglich wurde und mit Tiefeneindruck an der Powerwall angezeigt wird.

1.2 Gliederung

Im folgenden Kapitel soll einleitend ein Überblick über bestehende Parallelisierungsansätze des Ray Traycings und deren Ergebnisse gegeben werden. Ohne bisher auf das Bilderzeugungsverfahren einge- gangen zu sein, sollen zunächst die unterschiedlichen Anwendungungen des Bilderzeugungsverfahren, die unterschiedlichen Plattformen und somit auch unterschiedlichen Ansätze vorgestellt werden. Ab- schließend wird die gemeinsame Grundidee alle Ansätze zusammengefasst, welche auch in dieser Arbeit angewendet wurde. Danach wird einzelnd auf die eingesetzte Hardware für Berechnung, Transfer und Darstellung einge- 1. EINLEITUNG 4 gangen, welche für eine interaktive Anwendung kombiniert werden musste. Hier sollen Kenndaten und Eigenschaften vorgestellt werden, die für diese Arbeit relevant waren. Darauffolgend wird das Ray Tracing als Bilderzeugungsverfahren theoretisch vorgestellt und sein ho- her Berechnungsaufwand sowie der allen Implementationen zugrundeliegende Parallelisierungsansatz motiviert. Im Entwurf wird der Implementierungsansatz des Gesamtsystems beleuchtet und die noch groben, aber richtungsweisenden Designentscheidungen erläutert. Im nächsten Kapitel wird konkret beschrieben, wie Ray Tracing implementiert wurde. Dabei als Kern- komponente eine noch völlig unparallelisierte Bibliothek entwickelt und die Theorie und Designent- scheidungen vorgestellt. Abschließend soll in diesem Kapitel die Bibliothek völlig unabhängig von einer Parallelisierung bewertet werden. Die Parallelisierung wird dann ebenfalls isoliert betrachtet. In diesem Kapitel werden die Designent- scheidungen bezüglich des Servers, die Implementierung auf dem Hochleistungsrechner sowie die daraus resultierenden Entscheidungen für Netzwerk und Kompression vorgestellt. Leistungsbewertungen und Messungen der Serverkomponente werden ebenfalls in diesem Kapitel diskutiert. Die Darstellungskomponente als Client soll anschließend thematisiert werden. Hier wird es darum gehen, wie der Client Daten vom Server entgegennimmt und auf der Powerwall anzeigt. Der Client lädt außerdem die Szenen und realisiert die Nutzerinteraktion. Anhand zweier unterschiedlicher Testszenen wird der Darstellungsprozess eines Bildes betrachtet und bewertet. Abschließend folgt eine Bewertung aller Komponenten in Kombination und eine Zusammenfassung der gesammelten Erfahrungen. Erweiterungsmöglichkeiten und weitere Ansätze sollen als Ausblick vorgestellt werden. 2. BISHERIGE ARBEITEN UND SCHWERPUNKTE 5

2 Bisherige Arbeiten und Schwerpunkte

In diesem Kapitel sollen Arbeiten vorgestellt werden, aus denen Erkenntnisse für diese Diplomarbeit gewonnen werden konnten. Die grobe Einteilung in interaktive und nicht ineraktive Anwendungen grenzt die Arbeiten lediglich voneinander ab, Interaktivität war bei der Betrachtung nicht der einzige Aspekt. Es werden sowohl Arbeiten auf Systemen mit gemeinsamen, als auch verteiltem Speicher vorgestellt. Hinsichtlich der Parallelisierung werden neben Arbeiten auf Hochleistungsrechnern auch sehr spezielle Arbeiten betrachtet, welche das parallele Potential von Ray Tracing untersuchen und demonstrieren.

2.1 Ausdrücklich interaktiv

Die ersten interaktive Ergebnisse eines Ray Tracers wurden auf einer Origin 2000 erziehlt [PMS+99]. Auf bis zu 120 Prozessoren und auf einem gemeinsamen Speicher wurden unterschiedliche Anwen- dungsfälle von realistischer Beleuchtung bis Visualisierung großer Datenmengen implementiert. Die Ausgabe erfolgte auf ein an die Origin 2000 angeschlossenes Ausgabegerät. Der gemeinsame Speicher machte es möglich, die gesamte Szene ohne Unterteilung oder Mehrfachhaltung für alle Prozessoren zur Verfügung zu stellen. Damit reduzierte sich der Synchronisations- und Kommunikationsaufwand auf ein Synchronisierung der Lastverteilung. Der Grundgedanke der Parallelisierung ist das Verteilen von Bildpunkten als einzelne Arbeitsaufträge. Diese Aufgabe übernahm ein Master-Thread, welcher eine Warteschlange füllte. Eine Anzahl von arbeitenden Threads entahm aus dieser Warteschlange Aufträ- ge und schrieb sie direkt in den für alle Threads schreibbaren Frame Buffer. Da mit der Vergabe von Bildpunkten auch die Position im Frame Buffer bekannt war, bedurfte der parallele Schreibzugriff auf den Frame Buffer keiner Synchronisation mehr. Erreicht wurde somit ein fast idealer Speedup bis zur maximalen Prozessoranzahl des Systems, die Anzahl der berechneten Bilder schwankte je nach Szene zwischen 1-20fps. Am gleich Institut wurden große Datensätze von Isoﬂächen mittels Ray Tracing dargestellt [PSL+98]. Parallelisiert wurde der Ansatz auf einer SGI Reality Monster mit gemeinsamen Speicher. Die einzelnen Prozessoren verfolgten dabei unabhängig voneinander Strahlen in die Szene. Es werden ausdrücklich die Vorteile von gemeinsamen Speicher erwähnt, da jeder Prozessor unabhängig von den anderen jeden Teil des Datensatzes erreichen kann. Ein sehr pragmatischer und von der Zielrichtung festgelegter Ansatz wurde mit der Spezialisierung auf Dreiecke verfolgt [WSBW01, Wal04, WS01, WBS]. Als Grundlage dient ein Echzeit-Raytracer, welcher mit starker Optimierung auf die Intel-Architektur einen sehr efﬁzienten Dreiecksschnit realisiert. Dabei werden die SIMD-Fähigkeiten der SSE-Erweiterung zur gleichzeitigen Berechnung von mehreren Daten mit einer Instruktion genutzt und die gesamte Datenorganisation und Datenausrichtung auf das Lay- out der eingesetzten CPU ausgerichtet. Als Resultat entstand ein Raytracer, der zwar nur Dreiecke auf Intel-Architekturen berechnen kann, dieses aber in zum Zeitpunkt dieser Diplomarbeit ungeschlagener Geschwindigkeit. Der Focus der Arbeit ist somit eindeutig auf die Visualisierung großer, triangulierter 2. BISHERIGE ARBEITEN UND SCHWERPUNKTE 6

Modelle gesetzt. Der Ray Tracer wurde mittels eines entwickelten Parallelisierungsframeworks auf han- delsüblichen Desktop-PCs parallelisiert, welche mit einem üblichen Ethernet-Netzwerk zu einem Cluster verbunden wurden. Auch hier kam wieder ein Master-Slave-Ansatz zum Tragen, welcher rechteckige Be- reiche von Bildpunkten als Aufträge an die rechnenden Knoten vergibt. Durch weiter Entwicklung des Echtzeitraytracers und performanterer Hardware wurde mit diesem Ansatz eine interaktive Anwendung auf einem einzelnen PC möglich [Die], welche ein extrem großes CAD-Modell visualisieren konnte. Das gleiche Modell wurde in [SBB+06] auf einer SGI Prism mit gemeinsamen Speicher visualisiert. Ziel war hierbei weniger die Parallelisierung, als viel mehr eine Applikation zu entwickeln, die einer realen Nutzung bei der Wartung von Flugzeugen entspricht. Ebenfalls auf einem Cluster von handelsüblichen PCs wurde in [DPH+03] ein interaktiver Ray Tracer zum Visualisieren von Isoﬂächen mit großen Datenvolumen entwickelt. Dabei liegen die Daten verteilt über die gesamten Knoten und in einem Master-Slave-Ansatz werden dynamisch rechteckige Gruppen von Bildpunkten vom Master an die Arbeiter zur Bearbeitung vergeben. Mit einer eindeutigen Ausrichtung auf die Spielentwicklung wurde zum Zeitpunkt dieser Diplomarbeit ein sehr aktueller Echtzeit-Raytracer entwickelt [Bik07]. Als Zielplattform wurden handelsübliche PCs gewählt, so dass eine Parallelisierung sich auf Threading über mehrere Cores beschränkt. Durch eine starke Optimierung auf diese Plattform und den Anwendungsfall, sowie durch die Anwendung von aktuellen Forschungsergebnissen wurde ein performanter Ray Tracer für Dreiecke entwickelt. Eigene Forschungsergebnisse werden nicht vorgestellt, jedoch werden Quelltexte angeboten [arab] und die pra- xisnahe Entwicklung wird sehr detailliert vorgestellt [int, araa].

2.2 Nicht ausdrücklich interaktiv

Auf einem Großrechner mit verteiltem Speicher wurde ein Raytracer parallelisiert, indem ein gemeinsamer Speicher simuliert wurde [BP90]. Dabei wurden bei Bedarf über Nachrichten Seiten ausgetauscht, so dass der gesamte Speicher auf allen Knoten erreichbar war. Dieses Vorgehen erzeugt selbstverständ- lich einen gewissen Overhead, es wurde allerdings mit diesem Ansatz vermieden, dass die gesamte Szene auf jedem Knoten für die Berechnung vorliegen muss. Bechrieben wird außerdem der Kompromiss, dass die Daten zwar gleichmäßig verteilt und somit den Speicher optimal ausnutzend liegen können, aber damit nicht jedem Knoten sofort zur Verfügung stehen. Relevant für diese Diplomarbeit ist jedoch der Ansatz der Lastverteilung und der Kompromiss beim Scheduling. Dadurch, dass nicht alle Bildpunkte die gleiche Zeit zur Berechnung benötigen, wäre ein statischer Ansatz mit gleicher Anzahl an Bildpunk- ten für jeden Knoten eine ineffiziente Lastverteilung. Der dynamische Ansatz sieht vor, Bildpunkte über die Zeit auf freie Knoten zu verteilen, die effizienteste Lastverteilung wäre eine Verteilung von einzelnen Bildpunkten. Dieses steigert jedoch den Kommunikationsaufwand. Als Kompromiss wurden Blöcke von Bildpunkten verteilt. Zu den gleichen Ergebnissen kommt auch [CM93]. Mittels Ray Tracing wurde ein Volume Renderer auf einer AP1000-Maschine mit verteiltem Speicher realisiert. In einem Master-Slave-Ansatz werden einzelne Bildpunkte als Arbeitsaufträge an die rechnenden Knoten geschickt. Auch in diesem Ansatz wird ein gemeinsamer Speicher simuliert, indem nicht vorhandene Daten über Nachrichten angefordert und nachgeladen werden. Das Problem der Szenenorganisation auf Systemen mit verteiltem Speicher wird in [Lef93] zusammen- 2. BISHERIGE ARBEITEN UND SCHWERPUNKTE 7 gefasst. Es werden die drei Ansätze diskutiert: Erstens die gesamte Szene zu kopieren und somit den Speicher ineffizient auszunutzen. Zweitens die Szene aufzuteilen und kommunikationsintensiv bei Be- darf Daten anzufordern und zu verschicken. Und drittens eine geometrische Aufteilung der Datenbank, bei der die Szene in Regionen mit den einzelnen Objekten aufgeteilt wird, und diese Regionen verteilt werden. Wenn ein Strahl bei diesem Ansatz ein Region verlässt, wird er der zuständigen Region als Berechnungsauftrag zugestellt. In der vorgestellten Arbeit wird der geometrische Ansatz gewählt und Algorithmen zur dynamischen Lastverteilung vorgestellt. Da auch Sekundärstrahlen in fremde Regionen eintreten können, werden Strahlen unabhängig von der Rekursionstiefe verteilt. Ebenfalls auf Cluster von PCs setzt die Arbeit von [NG97]. Bei einem Master-Slave-Ansatz werden Bild- punkte dynamisch an die Arbeiter verteilt, wodurch eine Lastverteilung erreicht wird. Forschungsgegen- stand ist in dieser Arbeit die Parallelisierung eines progressiven Ray Tracers, der Parallelisierungsansatz ist aber identisch zu anderen Arbeiten auf Clustern. In dieser Arbeit ist der ungleiche Berechnungs- aufwand pro Bildpunkt anschaulich visualisiert worden und dementsprechend wurde ein dynamischer Ansatz zur Lastverteilung implementiert. Die Ausrichtung beim Kilauea-Renderer [Kat03] geht in Richtung hochqualitativer Bilder. Monte Car- lo Ray Tracing wird dabei zum Erzeugen von realistisch beleuchteten Szenen verwendet, eine Paral- lelisierung reduziert die hohen Berechnungszeiten durschschnittlich auf insgesamt ca. 10 Minuten. Im Vordergrund stand somit nicht ein interaktiver Betrieb, sondern das Ermöglichen von aufwändigen Be- rechnungen. Verwendet wurde dabei ein Cluster aus gewöhnlichen PCs mit jeweils privatem Speicher. Die Szene liegt aufgeteilt über den gesamten, verteilten Speicher. Bei der Berechnung werden die zu berechnenden Strahlen an die einzelnen Knoten geschickt, welche die Schnittberechnungen ausführen. Die Ergebnisse werden zurückgesendet und unter allen Schnitten wird der am nächsten liegende Schnitt bestimmt und übernommen. Bei der “Ray Engine” [CHH02] sieht der Ansatz vor, Schnitte von Strahlen mit Dreiecken von der GPU auf der Grafikkarte berechnen zu lassen. Diese Aufgabe kann die GPU effizient lösen, allerdings wird die CPU weiterhin zum Berechnen und Traversieren von Hierarchien benötigt, da Rekursion aufgrund des fehlenden Stacks auf der GPU nur schwer umzusetzen ist. Die Kommunikation über den AGP-Bus war in dieser Arbeit der Bottleneck. Parallelisiert wurde die Schnittberechnung nebenläufig zu der Arbeit der CPU, Gegenstand der Parallelisierung waren Strahlen. Der Ansatz in [PBMH02] geht noch einen Schritt weiter, implementiert wurde ein vollständig auf der Grafikkarte laufender Raytracer. Die Teilaufgaben des Ray Tracing (Strahlerzeugung, Traversierung der Beschleunigungsstruktur, Schnittberechnung und Farbwertberechnung) wurden als einzelne, unabhängi- ge Kerne mittels Fragment Programs implementiert. Das Prinzip beruht auf der Beobachtung, dass die einzelnen Kerne auf voneinander völlig unabhängig zu berechnenden Strahlen arbeiten können. Als Beispiel für eine Anpassung auf spezielle Architekturen kann die Optimierung für Cell-Prozessor gelten [BWSF06]. Dieser Prozessor besteht aus mehreren parallelen Recheneinheiten, welche ebenfalls bei dem in der Arbeit vorgestellten Ansatz mit der Berechnung einzelner Bildpunkte betraut werden. Aufgrund der parallelen Eigenschaften des Ray Tracings werden so Kommunikation und der Austausch von Teilergebnissen vermieden. Auch bei der Lastverteilung wird der schon mehrfach beschriebende Ansatz verwendet, dynamisch Bildpunkte zuzuteilen. Das Potential einer Parallelisierung des “Ray Tracing”-Verfahrens wird in [Pur02] sehr deutlich. Grund- lage ist der “Smart Memories Chip”, ein rekonfigurierbares System von Speicher-, Berechnungs- und 2. BISHERIGE ARBEITEN UND SCHWERPUNKTE 8

Kommunikationskomponenten. Der eigentliche Zweck dieses Designs war, mit diesem Chip andere Architekturen simulieren zu können. Für die verwirklichte Parallelisierung von Ray Tracing war aber vielmehr die ausgeprägte Parallelität des Chips interessant. Ein Chip besteht aus insgesamt 64 Berech- nungsknoten, welche über ein schnelles Verbindungsnetzwerk miteinander verkoppelt sind. Jeder Be- rechnungsknoten verfügt über 128KB Speicher und hat mit einer RISC-Architektur ungefähr die Rechen- leistung eines in der Origin 2000 verwendeten R10000-Prozessors. Ähnlich wie bei dem oben erwähn- ten Ansatz auf der GPU werden nur Dreicke als Primitive unterstützt und die einzelnen Arbeitsschritte eines Ray Tracers in einzelne Programme aufgeteilt, welche als Threads auf den hochparallelen Berech- nungsknoten ausgeführt werden. Es werden zunächst Strahlen erstellt, welche dann von Arbeitschritt zu Arbeitsschritt zwischen den einzelnen Threads ausgetauscht werden.

2.3 Zusammenfassung

Die vorgestellten Ansätze lassen sich grob in drei Gruppen einteilen: Demonstrationen und Studien der parallelen Eigenschaften des “Ray Tracing”-Algorithmus, zweitens sehr pragmatische, interaktive Vi- sualisierungsansätze und drittens Parallelisierungen, die die Bewältigung des großen Berechnungsauf- wandes für realistisch beleuchtete und photorealistische Szenen ohne Interaktivität garantieren sollen. Ansätze, die auf spezielle Hardware wie der GPU oder den erwähnten Smart Memories Chips zuge- schnitten sind, sind zwar technisch interessant und verdeutlichen die Parallelisierungsmöglichkeiten von Ray Tracing. Sie haben aber bisher keine praktische Relevanz erlangt. Renderfarmen wie der Kilauea-Renderer setzen noch immer auf die ursprüngliche Anwendung von Ray Tracing, um photorealistische Bilder zu erzeugen. Interaktion ist dabei nicht entscheidend, die Paralleli- sierung zielt einzig und allein darauf ab, die Berechnungszeiten zu verkürzen. Für interaktive Anwendungen werden zunehmend pragmatische Entscheidungen getroffen. Visualisie- rungen von großen Datensätzen stehen dabei im Vordergrund und nicht der Photorealismus. Das Dreieck als oftmals einizges, unterstütztes Primitiv zielt eindeutig auf die Darstellung von großen CAD-Daten ab. Sehr hardwarenahe, auf bestimmte Architekturen zugeschnittene Optimierungen kennzeichnen diese Anwendungen. Unabhängig von der Ausrichtung und rein von der Parallelisierungsseite betrachtet, können zwei Er- kenntnisse aus den vorgestellten Arbeiten gewonnen werden: Eine Lastbalancierung durch eine dynamische Verteilung von Bildpunkten bzw. Primärstrahlen ermöglicht bei performanter Hardware einen fast idealen Speedup. Außerdem kann der Kommunikationssaufwand deutlich reduziert werden, wenn auf ein System mit gemeinsamen Speicher zurückgegriffen werden kann. In diesem Fall fällt keine zusätzliche Verzögerung für Kommunikation und Datenaustausch zwischen getrennten Knoten an. Aufgrund der parallelen Eigenschaften des Algorithmus entfällt auch der ansonsten notwendige Synchronisationsbedarf bei Zugriffen auf Szenendaten im gemeinsamen Speicher. Die im Algorithmus begründete, natürliche Abgrenzung von Daten erlaubt außerdem, eine einzige Kopie der Szenendaten zu halten, auf die alle Threads zugreifen können, inefﬁziente Kopieroperationen oder Mehrfachhaltungen werden vermieden. 3. EINGESETZTE HARDWARE UND BEDINGUNGEN 9

3 Eingesetzte Hardware und Bedingungen

3.1 Die Powerwall

Abbildung 3.1: Schematische Darstellung der Powerwall

Der Lehrstuhl für Computergraphik und Visualisierung verfügt mit der “Powerwall” über eine groß- flächige Projektionsleinwand, welche die stereoskopische 3D-Darstellung von Szenen erlaubt. Der 3D- Eindruck entsteht dabei, indem jedem Auge getrennt je ein Halbbild angeboten wird. Diese Halbbilder müssen zuvor für jedes Auge getrennt generiert werden, wobei die leicht unterschiedlichen Perspektiven der Augen bei der Berechnung beachtet werden müssen. Diese zwei Halbbilder werden getrennt über zwei Projektoren über einen Umlenkspiegel auf die Rückseite der Projektionsfläche geworfen, auf der die Bilder sich überlagern. Die Auftrennung der Bilder für die Augen erfolgt passiv durch Polarisations- filter. Das Licht wird durch vor die Projektoren angebrachte Polarisationsfilter unterschiedlich polarisiert, diese Polarisation wird auf der Oberfläche der Leinwand erhalten. Polarisationsbrillen trennen die beiden sich überlagernden Bilder wieder auf, bei korrekt berechneten Bildern entsteht ein räumlicher Eindruck. Die starre Projektionswand mit einer 120 Zoll Bilddiagonalen (272 cm x 204 cm) wird dabei durch zwei Projektoren (Christie DS+26) bestrahlt, die Maximale Auflösung beträgt SXGA+ (1400 x 1050), was einem Seitenverhältnis von 4:3 entspricht. Justiert werden die beiden Strahler in einer vom Lehrstuhl selbst entworfenen Halterung, die Projektion auf die Leinwand erfolgt indirekt über einen Umlenkspiegel mit den Dimensionen 120 cm x 150 cm und einem Reflexionsgrad von 98%.

3.2 Rechentechnik und Kommunikation

Im April 2007 wurde im Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) ein seit 2005 geplanter und gebauter Hochleistungsrechnerkomplex eingeweiht. Das System besteht aus zwei Kom- ponenten, einem Hochleistungsrechner und einer PC-Farm. Auf beiden Komponenten wurde Rechenzeit 3. EINGESETZTE HARDWARE UND BEDINGUNGEN 10 beantragt, um Erfahrungen auf den unterschiedlichen Architekturen zu sammeln.

3.2.1 SGI Altix 4700

Als Komponente mit gemeinsamen Speicher wurde die Altix installiert. Sie vereint 2048 dual core Intel Itanium 2 CPUs (1.6GHz, “Montecito”), welche in CPU-Sets organisiert sind. Dabei ist das Neptun-Set als Testumgebung gedacht, auf der sich alle Nutzer die verfügbaren CPUs teilen, allerdings fällt auch keine Wartezeit eines Batch-Betriebes an und es wird keine CPU-Zeit berechnet. Diese Testumgebung wurde hauptsächlich in dieser Diplomarbeit verwenet.

CPU-Set Anzahl Prozessoren Speicher pro Prozessor Mars 384 2GB Jupiter 512 4GB Saturn 512 4GB Uranus 512 4GB Neptun 128 2GB

Der Speicher ist physikalisch verteilt, logisch aber wie ein gemeinsamer Speicher nutzbar. Die Hard- ware stellt die Cache-Kohärenz sicher und stellt den gesamten Speicher über ein schnelles NumaLink4- Netzwerk zur Verfügung. Der Speicherzugriff kann je nach Distanz der Daten im Netzwerk allerdings unterschiedliche Latenzen verursachen (Cache Coherent Non-Uniform Memory Access).

3.2.2 Linux Networx PC-Farm Deimos

Der auf dual core AMD Opteron CPUs (2.6GHz) basierende, heterogene PC-Cluster verfügt über 1292 CPUs, welche in Knoten organisiert sind. Die einzelnen Knoten besitzen nur lokal ansprechbaren Spei- cher. Über zwei seperate Inﬁniband-Netzwerke miteinander verbunden, beschränkt sich die Kommuni- kation auf Nachrichtenaustausch. Pro Core stehen jedem Knoten, mit Ausnahme von 24 umfangreicher ausgerüsteten Knoten, 2GB Speicher zur Verfügung wobei die Knoten in unterschiedlicher Anzahl mit Prozessoren bestückt sind:

Prozessoren pro Knoten Anzahl Knoten Knoten Phase1 Knoten Phase2 Speicher pro Knoten 1 384 128 256 4GB 2 230 102 128 8GB 4 88 24 64 16GB 4 24 - 24 32GB

Das System wurde in zwei Phasen geliefert, die schrittweise Erweiterung des Clusters schlägt sich auch in der in Abbildung 3.2 gezeigten Vernetzung für die MPI-Kommunikation der Knoten nieder [dei]. Die Knoten der ersten Phase konnten allesamt über einen 288-Port Voltaire ISR 9288 IB-Switch miteinander verbunden werden. Dieser Switch bindet jeden Knoten mit 4x Inﬁniband (10Gbps) an und verspricht theoretische Latenzzeiten zwischen je zwei Ports von unter 420ns. Die Knoten der zweiten Phase wurden an zwei weitere Switches gleichen Fabrikats angebunden, über die Inﬁniband-Vernetzung der Switche untereinander entsteht das Gesamtsystem. Dieses Netzwerk zwischen den Switches steht einem einzelnen MPI-Programm selbstverständlich nicht exklusiv zur Verfügung und mit nicht einmal der achtfachen 3. EINGESETZTE HARDWARE UND BEDINGUNGEN 11

Bandbreite eines Ports sind die Switche für eine gleichzeitige Kommunikation hunderter Knoten verhält- nismäßig schmal angebunden.

Switch 1 Switch 2 Switch 3 (Voltaire ISR 9288) (Voltaire ISR 9288) (Voltaire ISR 9288)

Sämtliche Knoten Phase1 30x Phase2: Duals+Quads 30x Phase2: Singles - 128 1-CPU Knoten - 128 2-CPU Knoten - 256 1-CPU Knoten - 102 2-CPU Knoten - 64 4-CPU Knoten (16 GB) - 24 4-CPU Knoten - 24 4-CPU Knoten (32 GB) - 2 Login Knoten (2 CPUs)

Abbildung 3.2: Inﬁniband-Vernetzung der Knoten auf der PC-Farm “Deimos”

3.2.3 Kommunikation auf dem Großrechner

Wenn Anwendungen, wie in dieser Diplomarbeit, sowohl auf Systemen mit verteiltem Speicher, als auch auf Systemen mit gemeinsamen Speicher laufen sollen, bleibt nur die Möglichkeit, portabel eine Anwendung für Systeme mit verteiltem Speicher zu schreiben. Bei verteiltem Speicher können lediglich Nachrichten zur Kommunikation über das gemeinsame Netzwerk ausgetauscht werden, lässt man den Spezialfall einer kapselnden Schicht beiseite, welche gemeinsamen Speicher simulieren würde. Al- lerdings können auf Systemen mit gemeinsamen Speicher die nachrichtenbasierten Kommunikationen emuliert werden. Als Quasi-Standard für Systeme mit verteiltem Speicher hat sich das “Message Passing Interface” eta- bliert [MPI]. Es deﬁniert eine Schnittstelle für die Kommunikation, legt aber keine Implementierung oder Protokoll fest. Dadurch wird zum einen Portabilität garantiert, zum anderen lässt es Spielraum für auf die jeweilige Hardware optimierte Implementierungen. Eine Leistungsanalyse auf der Altix kann [NAWAHV06] entnommen werden. Durch Linken der implementierenden Bibliothek ist der Einsatz umkompliziert, für das Starten der An- wendung ist allerdings ein spezieller Loader aufzurufen, bei dessen Aufruf die Anzahl der zu nutzenden Prozesse bekannt sein muss, diese Anzahl kann zur Laufzeit auch nicht mehr verändert werden.

3.2.4 Kommunikation zwischen Großrechner und Anzeige

Ein besonderer Umstand ist die räumliche Trennung von Anzeige und Berechnung. Die Fakultät In- formatik und das ZIH liegen ca. einen Kilometer Luftlinie voneinander, durch den Campus getrennt, entfernt. Für die Diplomarbeit stand eine dedizierte 1Gb-Leitung als Verbindung zur Verfügung. Der Anzeige- rechner wird dabei über eine PCIe-Karte (DLink DGE 560SX) und über Ethernet 1000Base-SX im Multi Mode an das Fakultätsnetz angebunden. Bei der beschriebenen Auflösung von 1400x1050 Bildpunkten, zwei Halbbildern und 3 Byte pro Bild- punkt im RGB-Farbformat ergibt sich ein Speicherbedarf von ca. 8,4 MB pro Bild, wodurch bei der theoretisch maximalen Bandbreite ca. 14 Bilder pro Sekunde übertragen werden können. Für einen interaktiven Betrieb, in dem es auf eine flüssige Darstellung ankommt, muss somit eine Datenkompression 3. EINGESETZTE HARDWARE UND BEDINGUNGEN 12 angewendet werden. Die Latenz im Netzwerk ist ebenfalls zu bestimmen, da diese die Antwortzeiten in einem interaktiven Betrieb beeinflusst.

3.3 Der Anzeigerechner

Der Anzeigerechner wurde in seinen Hauptkomponenten aus einem Intel Core 2 Duo E6600 2,40GHz, 2GB RAM, und einer Geforce 8800 GTS zusammengesetzt. Aufgrund des geringen Arbeitsaufwandes für diesen Rechner, er zeigt schließlich nur an, ist die genaue Rechenleistung nicht das entscheidene Kriterium. Entscheidender ist viel mehr, wie schnell Daten auf die Graﬁkkarte gesendet werden können, da dieses für jedes eintreffende Bild möglichst schnell ausgeführt werden muss. Diese Problematik wird in Kapitel 8 thematisiert. 4. DAS BILDERZEUGUNGSVERFAHREN “RAY TRACING” 13

4 Das Bilderzeugungsverfahren “Ray Tracing”

4.1 Überblick über das Verfahren

Abbildung 4.1: Rekursives Ray Tracing mit Primär- und Sekundärstrahlen

Erste Ansätze des Ray Tracing gab es schon in den 1960er Jahre [App68], der in dieser Diplomarbeit verwendete Algorithmus des rekursiven Ray Tracings geht jedoch auf [Whi80] zurück. Die Grundidee des Ray Tracing ist das Verfolgen von Lichtstrahlen von Lichtquellen durch die Szene, bis sie schließlich im Auge des Betrachters eintreffen. Da aber in der Realität nur ein Bruchteil der von einer Lichtquelle ausgesendeten Strahlen tatsächlich beim Betrachter eintreffen, und somit überflüssiger Be- rechnungsaufwand entstehen würde, wird die Richtung umgekehrt. Dieser Ansatz wird auch “Backward Ray Tracing” genannt. Es werden vom Betrachter aus Primärstrahlen durch jeden Bildpunkt der Bildebene geschossen und der, von der Bildebene aus gesehen, erste Treffer mit einem Objekt der Szene festgestellt. Für diesen Punkt auf dem Objekt wird die reflektierte Lichtintensität im einfachsten Fall durch eine lokale Beleuchtung bestimmt. Der Einfluß der lokalen Beleuchtung entfällt, wenn der Punkt auf dem Objekt im Schatten eines anderen Objektes liegt. Um dieses festzustellen, wird jeweils ein Schattenstrahl von diesem Punkt aus zu den Lichtquellen geschickt. Sollte einer dieser Strahlen ein Objekt schneiden, wird für die betrachtete Lichtquelle kein lokaler Intensitätsbeitrag mit einbezogen. Dieses einfache Modell ohne globale Beleuchtung wird auch “Ray Casting” genannt. Sollte das getroffene Objekt eine spiegelnde oder transparente Oberfläche aufweisen, werden von dem Punkt aus weitere Sekundärstrahlen in die Szene geschossen, welche weitere Beiträge zur Farbintensität liefern. Mit dieser Eigenschaft wird der Algorithmus rekursiv, da die Verfolgung der Sekundärstrahlen und die Berechnung ihres Anteils an der Farbintensität analog zu den Primärstrahlen erfolgt, und diese Sekundärstrahlen beim Auftreffen auf weitere Objekte weitere Rekursionen auslösen können. In rekursiver Schreibweise kann die Berechnung der reflektierten Intensität eines getroffenen Objektes 4. DAS BILDERZEUGUNGSVERFAHREN “RAY TRACING” 14 wie folgt beschrieben werden, wobei R einen Strahl und I (R) die Ermittlung der Intensität durch Ver- folgung eines Strahles darstellt:

I (R) = klocal · Ilocal + kreflect · I (Rreflect) + ktrans · I (Rtrans)

Die Koeffizienten fungieren dabei als Materialeigenschaften des Objektes und bestimmen den Anteil von lokaler Beleuchtung, Reflexion und Transmission an der Gesamtintensität. Auf diese Weise kann auch unaufwändig festgelegt werden, ob Sekundärstrahlen erzeugt werden sollen. Zur Berechnung der lokalen Intensität wird oftmals, und auch in dieser Arbeit, ein modifiziertes Phong- Beleuchtungsmodell [Pho73] angewendet. Wie dabei Schattenstrahlen einwirken, wird bei der Beschrei- bung der Implementierung näher beschrieben.

4.2 Abschätzung des Berechnungsaufwandes

Das Aufstellen einer verlässlichen Formel für den Berechnungsaufwand ist schwierig, da Szenen eine stark unterschiedlicher Komplexität, Art der Primitive und Materialeigenschaften auf den Objekten haben können. Es soll theoretisch aber zumindest motiviert werden, wo der hohe Berechnungsaufwand dieses Bilderzeugungsverfahrens entsteht und mit welcher Komplexität zu rechnen ist. Praktisch gemessen und nachvollzogen wird der Berechnungsaufwand anhand einer synthetischen Testzene bei der Bewertung der Bibliothek. Die Anzahl der erzeugten Primärstrahlen m ist einfach zu bestimmen. Sie wird durch die Auﬂösung der Bildebene bestimmt, durch die die Strahlen in die Szene geschossen werden. Für jeden dieser Primär- strahlen soll nun im nächsten Schritt der am nächsten zur Bildebene gelegene Schnitt gefunden werden. Da bei einem gefundenen Schnitt nicht sichergestellt ist, dass nicht doch ein weitere Schnitt existiert, der näher zur Bildebene liegt, müssen in einem naiven Ansatz alle Objekte n geschnitten werden.

Schnittberechnungen der P rimarstrahlen¨ = m · n

Auch die Anzahl der erzeugten Schattenstrahlen ist einfach zu bestimmen. Für jeden Strahl s wird nach dem Finden des nächstgelegenen Schnitts ein Schattenstrahl pro Lichtquelle l erzeugt. Da für den Schat- ten schon ein verdeckendes Objekt ausreicht, kann sich die Anzahl der Schnittberechnungen auf einen Schnitt beschränken. Doch gerade dann, wenn das Objekt nicht im Schatten liegt, werden wieder alle Objekte n geschnitten, da nur so ausgeschlossen werden kann, dass kein Objekt zwischen Lichtquelle und betrachtetem Punkt liegt. Als Obergrenze ergibt sich:

Schnittberechnungen Schattenstrahlen = s · l · n

Jedes Objekt kann maximal zwei Sekundärstrahlen durch Reﬂexion und Transmission erzeugen, welche rekursiv verfolgt werden. Dieses kann aber in jeder Rekursionstiefe geschehen. Die von der Anzahl der Primärstrahlen m bei einer maximalen Rekursionstiefe von k erzeugte Anzahl an Sekundärstrahlen ergibt sich somit aus:

Maximale Anzahl Sekundarstrahlen¨ = m · 2k 4. DAS BILDERZEUGUNGSVERFAHREN “RAY TRACING” 15

Jeder dieser Sekundärstrahlen erzeugt wieder den oben genannten Aufwand durch die Erzeugung von Schattenstrahlen. Wieviele Strahlen wirklich erzeugt werden, wieviele Rekursionen ausgelöst werden und wieviele Schnitt- berechnungen diese Strahlen bewirken, hängt von der Art der Szene ab und kann nicht seriös vorher- gesagt werden. Der Berechnungsaufwand kann sich schon durch eine Veränderung der Blickrichtung ändern. Was aber auffällt, ist der lineare Einfluss von Primärstrahlen, Objekten und Lichtquellen. Exponentiel- ler Einfluß entsteht durch die Erzeugung von Sekundärstrahlen, womit gerade die durch Ray Tracing möglich gemachten Spiegel- und Brechungseffekte einen dramatischen Einfluss auf die Berechnungszeit haben. Dieser exponentielle Einfluss der Sekundärstrahlen auf die Berechnungszeit wird bei der Bewer- tung der Bibliothek anhand von Messungen an einer Testzene demonstriert werden.

4.3 Parallelisierungsansatz

Die einzelnen Bildpunkte werden beim Ray Tracing durch das Aussenden von Strahlen durch die kor- respondierenden Zellen einer gedachten Bildebene berechnet. Somit steht beim Erzeugen des Strahles schon eindeutig fest, an welche Position der Farbwert geschrieben werden muss. Im einfachsten Fall kann man sich einen Bildspeicher vorstellen, der die Matrixform der Bildebene besitzt. Im gesamten Rechenprozess wird nur ein einziger Strahl diesen Speicher beschreiben. Somit entsteht kein Synchroni- sationsbedarf beim Schreibzugriff. Die Szene wird von keinem Strahl verändert, im gesamten Berechnungsprozess erfolgt somit auch kein Schreibzugriff auf die Szenendaten. Außerdem können die einzelnen Strahlen nicht in der Szene miteinander interagieren. Auch hier entsteht kein einschränkender Synchronisationsbedarf. Teilergebnisse müssen nicht zu einem Gesamtergebnis kombiniert werden. Jeder Strahl ist unabhängig von der Berechnung der anderen Strahlen, es muss also auch keine Abstimmung der Berechnungsrei- henfolge sichergestellt werden. Somit entsteht kein Kommunikationsbedarf. Theoretisch können also alle Strahlen gleichzeitig in die Szene geschickt werden und auch beim Schreiben der Daten kann jeder Strahl seinen Bildpunkt unabhängig setzen. Dadurch ergibt sich der naheliegende Ansatz, die Berech- nung der einzelnen Bildpunkte zu parallelisieren und im besten Fall jeden Bildpunkt in einem Thread bzw. Prozess oder auf einem Prozessor zu berechnen. Praktisch ergibt sich allerdings das Problem der Lastverteilung. Wie bei der Abschätzung des Berech- nungsaufwandes motiviert, erzeugt nicht jeder Primärstrahl den gleichen Berechnungsaufwand. Der deutlichste Unterschied läge zwischen einem Primärstrahl, der kein Objekt trifft, und nur die Hinter- grundfarbe der Szene zurückgibt und einem Primärstrahl, der aufgrund von den Materialeigenschaften des getroffenen Objektes und weiterer Objekte ähnlichen Materials mehrere Rekursionen auslöst. Dieses Problem ist in [NG97] sehr anschaulich visualisiert worden. Bei einer statischen Zuweisung der Bildpunkte auf z.B. eine gewissen Anzahl von Prozessoren wür- den einige Prozessoren ihre Arbeit eher als andere beendet haben. Da aber keine Arbeit mehr ansteht, würden alle Prozessoren warten, bis der am längsten rechnende Prozessor seine Arbeit beendet hat. War- tezeit erzeugt eine schlechte Auslastung der Resourcen und sollte durch eine dynamische Lastverteilung umgangen werden. Diese dynamische Lastverteilung erzeugt jedoch wieder einen Overhead an Kommu- nikation. 5. ENTWURF 16

5 Entwurf

Worker 1

Worker 2 Master 1GB Display ... Worker N

HRSK LCGV

Abbildung 5.1: Übersicht der Komponenten an beiden Standorten

Aus der räumlichen Trennung der Berechnungs- und der Darstellungskomponenten ergibt sich ein Client- Server-Ansatz. Dabei übernimmt die darstellende Seite am Lehrstuhl für Computergraphik und Visua- lisierung die Nutzerinteraktion und zeigt die vom Großrechner gelieferten Bilddaten an. Somit ﬂießen große Datenmengen von der Berechnungsseite zum Client. Der Client wiederum verschickt hauptsäch- lich die Benutzereingaben, welche eine Änderung der Blickrichtung in der Szene bewirken. Zusätzlich sieht der Entwurf vor, die Szenendaten auf der darstellenden Seite abzulegen, und nur beim Laden einer Szene die Daten an die berechnende Seite zu schicken, wo sie zur Verarbeitung im Hauptspeicher gehalten werden. Die zu verschickende Datengröße schwankt damit zwischen sehr kleinen Steuerinformationen und ver- hältnismäßig großen Bilddaten. Deswegen wurde der in Abbidlung 5.2 gezeigte Header gewählt, über den die Komponenten miteineinader kommunizieren. Der Typ des Headers gibt an, um welche Nach- richt es sich handelt. Bei kurzen Nachrichten können in den beiden Datenfeldern sämtliche Informatio- nen übertragen werden. Bei längeren Nachrichten wird hinter dem Header zusätzlich noch die in Size angegebene Datenmenge verschickt. Die so erhaltenen Nachrichten werden auf dem Großrechner wei- terverteilt, es erfolgt dort also keine Umwandlung in ein anderes Format. Auf dem Großrechner selber wird ein Master-Slave-Ansatz implementiert, da der beschriebene Paral- lelisierungsansatz eine dynamische Lastverteilung erfodert. Verteilt werden dabei Pakete von mehreren Bildpunkten. Die Anzahl der Bildpunkte ist dabei nicht statisch festgelegt, die Bildpunkte werden jedoch immer zeilenweise abgezählt, wobei in der linken, oberen Bildecke gestartet wird. Die Berechnung der beiden Halbbilder erfolgt nicht unabhängig, ein Arbeitsauftrag beinhaltet immer die Berechnung der Bildpunkten in beiden Halbbildern. Dadurch soll die Efﬁzienz der Komprimierung gesteigert werden, da in beiden Halbbildern aufgrund des räumlichen Zusammenhangs überwiegend ähnliche Farbwerte berechnet werden. Der Ansatz ist Demand Driven, durch das Abliefern eines berechneten Datenpaketes fordert der Slave einen neuen Arbeitsauftrag an. Serverintern wird über das Message Passing Interface (MPI) kommuniziert, da dieses die einzige praktikable Möglichkeit darstellt, den Server ohne Anpassung sowohl auf der Altix, als auch auf dem Cluster laufen zu lassen. Für die Datenorganisation der Szenen 5. ENTWURF 17

0 32 64 96 128 Length Type Data1 Data2 Datenstrom

Abbildung 5.2: Kurzer Header (4 x int) mit optional angefügten Daten wird der denkbar einfachste Ansatz gewählt, indem die Szenen in jedem Prozess als Kopie gehalten werden. Die beiden Hauptkomponenten kommunizieren über das TCP-Protokoll und unter Nutzung von Sockets. Ein Kommunikationsframework wird nicht verwendet. Zur Datenkompression wird die zlib [zli] eingesetzt, da diese auf dem Großrechner standardmäßig verfügbar ist. Als alternative Bibliothek wurde LZO [LZO] betrachtet, dann jedoch ausgeschlossen. Die Stärken dieser Bibliothek sind die schnellen Zeiten für Kompression und vor allem Dekompression, jedoch nicht die Kompressionsraten. Aufgrund der geringen Bandbreite zwischen Großrechner und Darstellungsseite wird eine möglichst stake Kom- primierung angestrebt, die Entscheidung ﬁel auf die zlib. Dabei werden die Daten gleich nach der Be- rechnung komprimiert, verschickt, und erst beim Client wieder dekomprimiert. Dadurch wird nicht nur die benötigte Bandbreite auf dem Großrechner verringert, sondern es wird auch eine Zusammenführung und Dekomprimierung der Daten auf dem Masterprozess vermieden. Für diese Zeitdauer der Datenzu- sammenführung würde nicht mit der Darstellungsseite kommuniziert, wodurch die 1Gb-Leitung nicht optimal ausgelastet wäre. Stattdessen werden schon Daten verschickt, während die nächsten Daten noch berechnet werden, wodurch Latenz und Bandbreite im Berechnungsprozess versteckt werden sollen. Außerdem ist die Verfügbarkeit des Masterprozesses bei der Lastverteilung entscheidend, und dieser soll während der Berechnung nicht mit anderen Aufgaben belastet werden. Der eigentliche Ray Tracer wird als Bibliothek umgesetzt, gegen die der berechnende Server linkt. Eine Parallelisierung der Bibliothek ist nicht notwendig, da die Parallelisierung über die aufrufenden Pro- zesse realisiert wird. Da diese Prozesse zur Berechnung Primärstrahlen zugeteilt bekommen, muss die Bibliothek eine Schnittstelle zur Berechnung von einzelnen Strahlen bereitstellen. Durch eine unparallelisierte Bibliothek ist der Ray Tracer ebenfalls weniger spezialisert und kann auch, z.B. zu Testzwecken, sequentiell eingesetzt werden. 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 18

6 Implementierung als Bibliothek

6.1 Repräsentation der Szene und Realisierung der Rekursion

Abbildung 6.1: Die zentrale Szene aggregiert Lichter und Objekte

Das zentrale Element der Bibliothek ist die Klasse Scene. Sie hält alle benötigten Szenendaten wie Geo- metrie, Lichter und Texturen. Sie enthält ausdrücklich keine Kameras, da diese nur als Strahlemitter fungieren. Strahlen können, müssen aber nicht von diesen Kameras erstellt worden sein. Die Änderung des Blickpunktes während der Interaktion wird durch Transformationen der Kameras realisiert, wobei die eigentliche Szene unverändert bleibt. Die von den transformierten Kameras erzeugten Strahlen werden daraufhin blickpunkbestimmend in die Szene geschickt. Somit ist es für die Szene nicht notwendig, die Kameras zu kennen oder auf diese zuzugreifen. Mit der TraceRay()-Methode werden die Strahlen rekursiv durch die Szene verfolgt, diese Methode ruft sich im Berechnungsprozess selber auf. Als Rückgabewert wird der berechnete Farbwert geliefert. Die Teilaufgaben Schnittpunktbestimmung, Beleuchtung, Generierung und Verfolgung von Schatten- und Sekundärstrahlen werden gemeinsam in dieser Methode realisiert. Es existieren verschiedene Arten von Lichtern und Primitiven. Um diese Variationen abzubilden, definieren die beiden Basisklassen Group und Light virtuelle Funktionen, welche von den abgeleiteten Klassen implementiert werden. Dieses ist vor allem für die Intersect-Methode der Szenenobjekte von Bedeutung, da die verschiedenen Primitive sehr unterschiedliche Schnittberechnungen ausführen. Alle Primitive stellen jedoch bei einem Treffer die berechnete Normale und einen Farbwert zur Verfügung, 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 19 welche zur Beleuchtung und ggf. zur Berechnung der rekursiven Strahlen benötigt werden. In den Ba- sisklassen werden ebenfalls einheitlich Variablen für die Materialkonstanten definiert. Die nicht in der Grafik dargestellten Klassen für Punkte, Strahlen, Vektoren, Normalen, Farben, Texturen und Transformationen sollen nicht detaillierter beschrieben werden, da für deren Implementierung keine erwähnenswerten oder von bisherigen Ansätzen abweichende Entscheidungen getroffen wurden. Um Kameras um die Vektoren ihres lokalen Koordinatensystems rotieren zu können, wurde für diesen Teil der Transformationen der in [PH04] vorgestellte, geometrische Ansatz zum Rotieren um einen beliebigen Vektor verwendet.

6.2 Schnittberechnungen

Für die in dieser Diplomarbeit implementierten Primitive soll in diesem Abschnitt vorgestellt werden, wie ein Schnitt erkannt, die Entfernung des Schnittes ermittelt und die Normale und der Farbwert am Schnittpunkt berechnet wird. Die Intersect-Methode übernimmt dabei als Parameter den Strahl und einen Zeiger auf die Variable, die die Schnittentfernung nach einem gefundenen Schnitt speichert. Der Schnitt- punkt selber wird nicht zurückgegeben, da dieser jederzeit aus dem Strahl und der Entfernung errechnet werden kann. Jedes Primitiv hält dabei in lokalen Variablen die Normale und den Farbwert des letzten Schnittes. Dadurch ist die Bibliothek nicht thread safe. Dieser Ansatz wurde verfolgt, da beim Dreiecks- schnitt die Berechnung des Schnittpunktes Zwischenergebnisse (Baryzentrische Koordinaten) errechnet, die die Berechnung von Normale und Farbwert ohne großen zusätzlichen Aufwand erlauben. Jedoch müsste beinahe die gesamte Berechnung erneut ausgeführt werden, wenn anschließend aus einem Punkt auf dem Dreieck in einem zweiten Aufruf die genannten Daten seperat berechnet werden würden.

6.2.1 Quadrics

Als Quadratic Surfaces, Flächen zweiter Ordnung, bezeichnet man Flächen, die durch ein quadratisches Polynom beschrieben werden. Zunächst soll der in dieser Arbeit verwendete, generelle Lösungsansatz für den Schnitt dieser Flächen mit einem Strahl beschrieben werden. Exemplarisch wird danach der Lösungsweg für die Kugel dargestellt, für die restlichen implementierten Quadrics werden die End- ergebnisse angegeben. Die drei implementierten Quadrics sind in Abbildung A.1 dargestellt. Es wird ebenfalls auf die Berechnung der für die Beleuchtung notwendigen Flächennormale und die Erzeugung von Texturkoordinaten eigegangen. Folgende Teilschritte werden bei der Berechnung ausgeführt: • Da ein Schnittpunkt eines Strahles mit der Fläche gefunden werden soll, wird in die Gleichung der betrachteten Fläche die Strahlgleichung

R (t) = Ro + Rd · t

eingesetzt, wobei Ro den Ursprung des Strahles angibt und mit Rd die (normierte) Richtung des Strahles bezeichnet wird. Durch den Parameter t kann ein Punkt auf dem Strahl mit der Entfernung t errechnet werden. Dieses ist bei der Schnittberechnung der gesuchte Parameter. Komponenten- weise kann für den dreidimensionalen Raum auch geschrieben werden: 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 20

x = Ro.x + Rd.x · t y = Ro.y + Rd.y · t z = Ro.z + Rd.z · t

• Die sich durch Einsetzen ergebene Formel solange umformen, bis sich eine Quadratische Glei- chung der folgenden Form ergibt:

a · t2 + b · t + c = 0

• Diese Gleichung wird mit der allgemeinen Lösungsformel gelöst: √ −b + b2 − 4ac t1 = √2a −b − b2 − 4ac t = 2 2a D = b2 − 4ac

Wobei die Diskriminante D die Anzahl der Lösungen bestimmt: – D > 0: Zwei verschiedene Lösungen – D = 0: Eine doppelte Lösung – D < 0: Keine (reelle) Lösung • Die kleinste, nichtnegative Lösung der Quadratischen Gleichung ist das gesuchte t. Durch Einset- zen in die Strahlgleichung kann der Schnittpunkt bestimmt werden • Über den Gradienten kann die Flächennormale ~n der Fläche f am Punkt mit den Koordinaten x, y, z errechnet werden:

 ∂f(x,y,z)  ∂x ~n = grad f (x, y, z) = ∇f (x, y, z) =  ∂f(x,y,z)   ∂y  ∂f(x,y,z) ∂z

Die Komponenten der Flächennormale errechnen sich also aus den partiellen Ableitungen der Fläche • Sollte eine Textur für die Fläche deﬁniert worden sein, werden die Texturkoordinaten aus der trigonometrischen Parameterisierung der Fläche errechnet

Kugel

Eine Kugel hat die Flächengleichung:

x2 + y2 + z2 = r2

Mit freiem Kugelursprung U gilt:

2 2 2 2 (x − Ux) + (y − Uy) + (z − Uz) = r

Strahl in Komponentenschreibweise in die Kugelgleichung eingesetzt: 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 21

2 2 2 2 (Ro.x + Rd.x · t − Ux) + (Ro.y + Rd.y · t − Uy) + (Ro.z + Rd.z · t − Uz) = r

Ausmultipliziert:

2 2 2 2 Ro.x + Rd.xtRo.x − UxRo.x + Rd.xtRo.x − Rd.xUxt + Rd.xt − UxRo.x − Rd.xUxt + Ux 2 2 2 2 + Ro.y + Rd.ytRo.y − UyRo.y + Rd.ytRo.y − Rd.yUyt + Rd.yt − UyRo.y − Rd.yUyt + Uy 2 2 2 2 2 + Ro.z + Rd.ztRo.z − UzRo.z + Rd.ztRo.z − Rd.zUzt + Rd.zt − UzRo.z − Rd.zUzt + Uz = r

2. binomische Formel und umgestellt:

2 2 2 (Ro.x − Ux) + t · Rd.x + t(2(Rd.x(Ro.x − Ux))) 2 2 2 + (Ro.y − Uy) + t · Rd.y + t(2(Rd.y(Ro.y − Uy))) 2 2 2 2 + (Ro.z − Uz) + t · Rd.z + t(2(Rd.z(Ro.z − Uz))) = r

Zusammengefasst und nach Null umgestellt:

2 2 2 2 (Rd.x + Rd.y + Rd.z)t +

t(2(Rd.x(Ro.x − Ux) + Rd.y(Ro.y − Uy) + Rd.z(Ro.z − Uz))) + 2 2 2 2 (Ro.x − Ux) + (Ro.y − Uy) + (Ro.z − Uz) − r = 0

Es ergibt sich die quadratische Gleichung

a · t2 + b · t + c = 0 mit den Koefﬁzienten 2 2 2 a = Rd.x + Rd.y + Rd.z b = 2(Rd.x(Ro.x − Ux) + Rd.y(Ro.y − Uy) + Rd.z(Ro.z − Uz)) 2 2 2 2 c = (Ro.x − Ux) + (Ro.y − Uy) + (Ro.z − Uz) − r Die Komponenten wieder in Vektorschreibweise und als Skalarprodukt notiert: a = Rd • Rd b = 2 · Rd • (Ro − U) 2 c = (Ro − U) • (Ro − U) − r Da aus dem Kosinussatz abgeleitet für das Skalarprodukt gilt

x • y = |x| · |y| · cos∠(x, y) und der Winkel, den ein Vektor mit sich selber einschließt gleich Null ist, kann bei einem normierten Richtungsvektor des Strahles der Ausdruck für a vereinfacht werden: a = 1 b = 2 · Rd • (Ro − U) 2 c = (Ro − U) • (Ro − U) − r Nun kan anhand der Diskriminante entschieden werden, ob die Kugel geschnitten wurde. In diesem Fall wird die Entfernung t berechnet und durch Einsetzen in die Strahlgleichung der Schnittpunkt bestimmt. 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 22

Die Berechnung der Normale vereinfacht sich bei der Kugel, da diese vom Kugelursprung auf den errechneten Punkt zeigt. Es kann also die Differenz zwischen Schnittpunkt und Kugelursprung genommen werden, durch eine Division durch den Kugelradius ist die Normale gleich normiert. Zum Erzeugen der Texturkoordinaten wurde folgende Parameterisierung gewählt:

  r · sin u · cos v   ~x(u, v) =  r · sin u · sin v  (u, v) ∈ [0, π] × [0, 2π] r · cos u u lässt sich leicht durch den arccos der Z-Komponennte der Normale bestimmen. Da die normierte Flächennormale eine Länge von Eins hat, gedanklich also eine Einheitskugel parameterisiert wird, ist der Radius der Einheitskugel auch Eins und kann vernachlässigt werden. Zum Bestimmen von v müssen zwei trigonometrische Funktionen berechnet werden. Dieses kann durch die Umrechnung der Kreisfunktionen umgangen werden:

Normaly = sin u·sin v = sin v = tan v ⇒ v = arctan Normaly Normalx sin u·cos v cos v Normalx u und v müssen nun noch in das Intervall [0,1] umgerechnet werden.

Ellipsoid

Die Berechnung erfolgt analog zu der bei der Kugel vorgestellten Berechnung. 2 2 2 (x−Ux) (y−Uy) (z−Uz) F lachengleichung¨ : a2 + b2 + c2 = 1 2 2 2 A = (Rd.x/a) + (Rd.y/b) + (Rd.z/c) 2 2 2 B = 2(Rd.x(Ro.x − Ux)/a + Rd.y(Ro.y − Uy)/b + Rd.z(Ro.z − Uz)/c ) 2 2 2 C = ((Ro.x − Ux)/a) + ((Ro.y − Uy)/b) + ((Ro.z − Uz)/c) − 1

  a · cos u · cos v   ~x(u, v) =  b · cos u · sin v  (u, v) ∈ [0, π] × [0, 2π], a, b, c : Halbachsen c · sin u

Elliptic Paraboloid

Die Berechnung erfolgt analog zu der bei der Kugel vorgestellten Berechnung. 2 2 (x−Ux) (y−Uy) F lachengleichung¨ : a2 + b2 − (z − Uz) = 0 2 2 A = (Rd.x/a) + (Rd.y/b) 2 2 B = 2(Rd.x(Ro.x − Ux)/a + Rd.y(Ro.y − Uy)/b ) − Rd.z 2 2 C = ((Ro.x − Ux)/a) + ((Ro.y − Uy)/b) − Ro.z + Uz

6.2.2 Dreicksschnitt

Der in dieser Diplomarbeit verwendete Dreiecksschnitt verläuft in zwei Phasen. Zunächst wird festgestellt, ob der Strahl die vom Dreieck deﬁnierte Ebene schneidet. Dieses wird fast immer der Fall sein, es 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 23

P 2

A 1

P A 0 P 0 A 2

P 1

Abbildung 6.2: Aufteilung des Dreiecks in Teilflächen zur Berechnung der Baryzentrischen Koordinaten vom Punkt P sei denn, der Strahl verläuft parallel zur Ebene. Im zweiten Schritt wird überprüft, ob der Schnittpunkt auf der Ebene sich in der Teilfläche des Dreiecks befindet. Ausgegangen wird beim Ebenenschnitt von der Koordinatenform der Ebene:

~n • (~x − ~a) = 0

Dabei bezeichnet ~n die Flächennormale, welche im Konstruktor beim Erzeugen des Dreiecks über das Kreuzprodukt berechnet wird. ~a deﬁniert den Vektor vom Ursprung zu einem bekannten Punkt auf der Ebene. Für diesen Punkt wurde beliebig der erste Knoten des Dreiecks gewählt. Alle auf der Ebene liegenden Punkte mit dem durch ~x bezeichneten Differenzvektor vom Ursprung erfüllen dabei die genannte Ebenengleichung. Für diesen Vektor wird die Strahlgleichung eingesetzt, nach t umgestellt:

~n • (t · R~ d + R~ o − ~a) = 0

t(~n • R~ d) + ~n • (R~ o − ~a) = 0 −~n • (R~ − ~a) o = t ~n • R~ d

Dabei wird zunächst der Nenner berechnet, verläuft der Strahl parallel zu Ebene, stehen Richtungsvektor des Strahles und Flächennormale senkrecht aufeinander, das Skalarprodukt ist gleich Null. In diesem Fall wird abgebrochen. Ansonsten errechnet sich mit t der Abstand des gefundenen Schnittes mit der Ebene. Negative Abstände kennzeichnen Schnitte, die nicht in Strahlrichtung liegen und führen ebenfalls zum Abbruch. Ansonsten wird über Einsetzen in die Strahlgleichung der Schnittpunkt mit der Ebene bestimmt. Ob der Schnittpunkt innerhalb oder außerhalb der Dreiecksﬂäche liegt, wird über die homogenen baryzentrischen Koordinaten des Punktes festgestellt. Dabei wird der Schnittpunkt P als eine Afﬁnkombina- tion der Eckpunkte P1,P2,P3 des Dreiecks dargestellt: 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 24

P = α0P0 + α1P1 + α2P2, α0 + α1 + α2 = 1

Sind alle Koeffizienten positiv und summieren sie sich zu Eins auf, liegt der Schnittpunkt in der konvexen Hülle der Dreieckseckpunkte und der gefundene Schnittpunkt mit der Ebene ist auch ein Schnittpunkt des Dreiecks. Zur Berechnung der Koeffizienten wird die Fläche des Dreiecks in drei Unterflächen aufgeteilt, indem je zwei Dreieckseckpunkte mit dem Schnittpunkt ein Unterdreieck aufspannen (Siehe Abbildung 6.2). Die Fläche dieses Unterdreiecks normiert mit der Gesamtfläche des Dreiecks ergibt den Koeffizienten des einzigen, nicht im Unterdreieck liegenden Punktes. Wird ein Dreieck ausgehend von einem Eckpunkt durch zwei Vektoren aufgespannt, entspricht seine Flä- che der halben Länge des Kreuzproduktes dieser beiden Vektoren. Insgesamt werden die Koeffizienten wie folgt berechnet: 1 −−−→ −−−→ A = |P P × P P | 2 0 1 0 2 1 −−→ −−→ |PP2 × PP1| α = 2 0 A 1 −−→ −−→ |PP0 × PP2| α = 2 1 A 1 −−→ −−→ |PP0 × PP1| α = 2 2 A

Da diese Koeffizienten im Intervall [0,1] definiert sind, können sie als Faktoren bestimmen, wie stark Attribute aus den Eckpunkten in den Schnittpunkt eingehen. In dieser Diplomarbeit werden so Tex- turkoordinaten und Knotennormalen über das Dreieck interpoliert. Aus diesem Grund wurde auch der vorgestellte Schnittest für Dreiecke gewählt. Wenn ein Schnitt erkannt wurde, stehen ohne größeren Be- rechnungsaufwand die interpolierten Werte zur Verfügung. Diese Werte werden in Variablen der Klassen gespeichert, so dass diese bei der Beleuchtung ausgelesen werden können. An dieser Stelle ist die Bi- bliothek nicht thread safe, was aber aufgrund der im Entwurf festgelegten Parallelisierung mittels MPI kein gefordertes Kriterium ist. Ein effizienterer Schnittest [MT97] ist laut den in der zitierten Arbeit ver- öffentlichten Testwerten nur unwesentlich schneller als der Test mit baryzentrischen Koordinaten, und wurde somit nicht betrachtet.

6.2.3 Schnitt mit Dreicksnetzen

Da Dreiecksnetze lediglich ein Verbund von Dreicken sind, wird der Schnitt mit den Dreiecksnetzen auf den Schnitt von Dreiecken zurückgeführt. Ein Dreiecksnetz ist dabei ein eigenständiges Szenenelement, welches intern eine Liste von beliebig vielen Dreicken hält. Durch die im Abschnitt 6.6 beschriebene Hierarchie von Hüllvolumen werden nur plausible Kandidaten für den Schnitt betrachtet, wodurch der Schnitt mit Dreiecksnetzen überhaupt erst praktikabel wird. Ausgeführt wird der oben beschriebene Dreiecksschnit mit plausiblen Kandidaten des Dreiecksnetzes, der am nächsten zum Strahlursprung liegende Dreiecksschnitt wird als Schnitt mit dem Dreiecksnetz gewertet und zurückgegeben. 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 25

Abbildung 6.3: Schnittest über Ebenenrelationen für Box und konvexe Objekte

6.2.4 Boxschnitt

Für den Boxschnitt wurde eine Lösung angestrebt, die eine beliebige Orientierung der Box erlaubt, also vor allem keine Ausrichtung an den Koordinatenachsen fordert. Außerdem sollte eine weitere Limitation entfallen, nämlich die Parallelität von je zwei Flächen der Box zueinander. Es wurde die in [KK86] vorgestellte Lösung abgewandelt. Jede Fläche des Rechtecks wird dabei durch eine Ebene beschrieben. Ausgangspunkt ist die Ebengleichung (Hessesche Normalform):

d = ~n • ~x

Wobei d den Abstand der Ebene zum Koordinatenursprung beschreibt, ~n die Normale der Ebene und ~x der Vektor vom Ursprung zu einem Punkt x auf der Ebene darstellt. Der Konstruktor bekommt die Eckpunkte der Box übergeben, bestimmt anhand der Punkte zwei aufspannende Vektoren für jede Eben und errechnet jeweils über das Kreuzprodukt die Normale. Zusammen mit einem der Eckpunkte kann dann der Abstand zum Koordinatenursprung berechnet werden. Gespeichert werden für jede Ebene die Normale und der Abstand zum Koordinatenursprung, wodurch die Ebene eindeutig definiert ist. Für die Schnittberechnung wird nun zunächst jede Ebene geschnitten, wie beim Dreiecksschnitt bereits erläutert. Am Ende der Schnittberechnungen erhält man jeweils einen Punkt auf der betrachteten Ebene. Um zu überprüfen, ob der Punkt auch in dem gewünschten Bereich der Box liegt, werden die Bezie- hungseigenschaften der Ebenen zueinander verwendet. Bei konvexen Objekten liegt ein Punkt auf dem Objekt immer auf einer der Ebenen und für alle anderen Ebenen auf der Rückseite der Ebene. Dabei definiert die Normalenrichtung die Orientierung der Ebene. In Abbildung 6.3 ist dieses dargestellt. Punkt P ist ein Treffer, da er sich auf bzw. innerhalb aller Flächen befindet. Punkt Q liegt zwar auf einer der Ebenen, befindet sich aber vor der rechten Fläche. Die rechte Abbildung zeigt, dass dieser Ansatz nicht auf Rechtecke beschränkt ist. Mathematisch wird dabei die oben erwähnte Ebenengleichung in eine implizite Form gebracht:

0 = ~n • ~x − d

Die Normale und der Abstand zum Koordinatenursprung sind beim Erstellen der Box errechnet worden, 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 26 der Punkt auf der Ebene wird durch den Schnitt und Einsetzen in die Strahlgleichung errechnet. Bei der impliziten Darstellung ist interessant, in welchen Fällen die Gleichung nicht Null ergibt. Liegt ein Punkt vor der Vorderseite der Ebene ergibt sich ein positiver Wert, liegt der Punkt hinter der Rückseite, ist das Vorzeichen negativ. Für Schnittpunkte mit einer der Ebenen wird dabei solange über alle Ebenen iteriert, bis sich ein positives Vorzeichen ergibt, und der Punkt somit als Schnittpunkt mit der Box ausgeschlossen werden kann. Oder aber der Punkt erzeugt nie ein positives Signum und wird als Schnittpunkt erkannt. In diesem Fall muss die Normale nicht mehr errechnet werden, denn sie wurde ja bereits bei der Erzeugung der Box berechnet. Es müssen nicht alle Ebenenschnittpunkte betrachtet werden. Wurde bereits ein gültiger Schnittpunkt erkannt, werden nur noch Ebenenschnittpunkte überprüft, die näher an dem Ursprung des Strahles liegen.

6.3 Kameras

Beim rückwärtsgerichteten Ray Tracing fungieren die Kameras streng genommen als reine Strahlemit- ter. Durch die Kameras wird deﬁniert, wie die Strahlen in die Szene geschickt werden und bestimmen somit den sichtbaren Bildbereich und die Auﬂösung. Zunächst soll beschrieben werden, wie die Strahler- zeugung durch eine perspektivische Kamera realisiert wird. Anschließend werden zwei perspektivische Kameras zu einer stereoskopischen Kamere kombiniert.

6.3.1 Perspektivische Kamera

pixel hw

hh LU fov/2 C

LA P LR

Abbildung 6.4: Die perspektivische Kamera als Strahlemitter

Die Implementierung der perspektivischen Kamera ist an den gluPerspective()-Aufruf aus der OpenGL Utility Library angelehnt. Die Position und Lage der Kamera wird dabei durch den Augpunkt P und den drei in Abbildung 6.4 dargestellten, normierten Vektoren für die Blickrichtung, Blickrichtung nach rechts und Blickrichtung nach oben festgelegt. Der Vektor für die Blickrichtung zeigt auf die Mitte 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 27 der Bildebene, durch die die Strahlen in die Szene geschickt werden sollen. Wie weit entfernt sich die Bildebene vom Augpunkt beﬁndet, gibt der Parameter Near an, als Vektor auf das Zentrum der Bildebene ergibt sich: −→ C~ = P + LA · Near

Die Dimensionen der Bildebene in Weltkoordinaten lassen sich aus dem (vertikalen) Öffnungswinkel der Kamera und der Auﬂösung der Bildebene errechnen. Die halbe Höhe (Gegenkathete) wird über den Tangens des vetikalen Öffnungswinkels und den Abstand der Ebene (Ankathete) errechnet:

fov hh = tan ( 2 ) · Near

Über das Seitenverhältnis der Auﬂösung kann die halbe Breite und die Ausdehnung eines Pixels berechnet werden: HorizontaleAuflosung¨ hw = hh · V ertikaleAuflosung¨ hw · 2 P ixel = HorizontaleAuflosung¨ Als Ausgangspunkt für alle folgenden Richtungsberechnungen der erzeugten Strahlen wird der Rich- tungsvektor D~ zur linken, oberen Bildecke gezogen: −→ −→ D~ = C~ − hw · LR + hh · LU

Um die Strahlen durch das Zentrum der Bildpunkte zu senden, wird abschließend noch um die halbe Pixelbreite verschoben:

~ ~ P ixel −→ P ixel −→ D = D + 2 · LR − 2 · LU

Um alle folgenden, zu erstellenden Strahlen S an Position x, y durch die Bildebene zu schicken, wird dieser Richtungsvektor um die entsprechende Anzahl von Pixelbreiten auf der Bildebene verschoben, Ursprung der Strahlen ist der Augpunkt:

SO = P −→ −→ S~D = D~ + P ixel · x · LR − P ixel · y · LU

6.3.2 Stereoskopische Kamera

Die in dieser Diplomarbeit implementierten, stereoskopischen Kameras kombinieren lediglich zwei perspektivische Kameras. Ausgehend von einem gemeinsamen Punkt P werden die Augpunkte der beiden Kameras um jeweils einen Offset-Vektor verschoben. Im einfachsten Fall schauen die beiden Kameras parallel in die Szene. Im konvergenten Fall fokussieren beide Kameras auf die gemeinsame Bildebene, indem der Richtungsvektor der Strahlen jeweils mit dem invertierten Offset verschoben wird. Der in der Anwendung beobachtete Unterschied der beiden Kameras ist nicht so groß, wie er in der Theorie erscheinen mag. Man denke sich zur Veranschaulichung einen Punkt in zwei Metern Entfernung (Ankathete), auf den beide Augen fokussieren. Bei einem Augenabstand von 6,5 Zentimetern, entspricht der halbe Augenabstand 3,25 Zentimeter (Gegenkathete). Der halbe Winkel α zwischen den beiden Seh- strahlen errechnet sich aus: 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 28

LA LA LA

- Offset Offset - Offset Offset K1 P K2 K1 P K2

Abbildung 6.5: Stereoskopische Kameras: Konvergent (links) und parallel (rechts)

3,25cm ◦ α = arctan 200cm = 0.93

Der volle Winkel zwischen den Sehstrahlen für einen Punkt in zwei Metern Entfernung beträgt also schon weniger als zwei Grad. In der Anwendung unterscheiden sich die beiden Kameramodelle nur minimal, lediglich sehr nahe am Augpunkt liegende Objekte sind mit der konvergenten Kamera angenehmer zu betrachten. Mit jeder Kamera wird je ein Halbbild in voller Auﬂösung berechnet. Bei nicht blickpunktabhängi- gen Farbberechnungen des Schnittpunktes, wie z.B. bei einfacher, diffuser Beleuchtung, kann das zweite Halbbild für die allermeisten Bildpunkte vom ersten Halbbild abgeleitet werden [AH93, ABC+91, AH92]. Für die in dieser Diplomarbeit implementierten, blickpunktabhängigen Farbberechnungen durch Rekursion ist dieses jedoch kein realistischer Ansatz und wurde somit nicht verfolgt. Sollte jedoch der wie in Kapitel 2 mehrfach beschriebene Ansatz verfolgt werden, durch Ray Tracing ohne aufwendige Re- kursionen komplexe Dreiecksnetze zu visualisieren, könnte diese Methode relevant werden. Im Idealfall könnte der Berechnungsaufwand halbiert werden.

6.4 Lichtquellen

S 2 S 3 L α L α L S S S 1 S 4

Point Light Spot Light Sharp Spot Light Area Light

Abbildung 6.6: Schematische Darstellung der implementierten Lichter 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 29

Für alle in dieser Diplomarbeit implementierten Lichter gilt, dass sie jeweils für die ambienten, diffusen und spiegelnden Komponenten des im folgenden Abschnitt beschriebenen Phong-Beleuchtungsmodell getrennte Lichtintensitäten halten. Die Lichter unterscheiden sich lediglich dadurch, wieviel dieser In- tensitäten abhängig vom übergebenen Schattenstrahl in die Berechnung eingeht. Die Intensitäten werden über Get-Methoden abgefragt, welche den Schattenstrahl als Parameter übernehmen und auswerten. Die Lichtquellen können in der Szenendeﬁnition über einen Flag an die Kamera gebunden werden. Sämt- liche Kameratransformationen werden in dem Fall auch auf die gebundenen Lichtquellen angewendet. Dadurch kann eine statische Beleuchtung der Szene durch unbewegliche Lichtquellen vermieden werden. Bei der Durchwanderung kann die Szene durch die der Kamera folgenden Lichtquellen blickpunktsab- hängig beleuchtet werden.

6.4.1 Point Light

Die einfachste Lichtquelle in der Bibliothek ist die Punktlichtquelle. Sie ist durch ihre Position in Welt- koordinaten deﬁniert und strahlt ihr Licht gleichmäßig in alle Richtungen aus. Somit werden unabhängig vom Einfallswinkel des betrachteten Schattenstrahls immer die unmodiﬁzierten Lichtintensitäten zu- rückgegeben. Die einzige auf dem Schattenstrahl beruhende Berechnung ist der Test auf Verdeckung der Lichtquelle durch andere Objekte.

6.4.2 Spot Light

Das Spot Light ist ein Strahler, welcher entlang seiner deﬁnierten Leuchtrichtung die volle Lichtintensität abstrahlt. Je größer der Winkel zwischen Leuchtrichtung und betrachtetem Schattenstrahl wird, umso geringer wird die Intensität. Ab einem Winkel von 90◦ ist die Intensität gleich Null. Eine Funktion, die dieses Verhalten modelliert ist der Kosinus, welcher sich bei normierten Richtungsvektoren über das Skalarprodukt errechnen lässt:

−−−−−−−−−−−→ −−−−−−−−−−−→ −F aktor = cos α = Schattenstrahl • Leuchtrichtung

Der errechnete Wert liegt im Intervall [-1, 0], da der Schattenstrahl zur Lichtquelle zeigt. Durch In- vertierung erhält man einen Wert im zwischen Null und Eins, welcher als Faktor zur Skalierung der auszugebenden Lichtintensität verwendet wird. Negative Faktoren werden auf Null gesetzt, da diese eine Abstrahlung entgegen der Leuchtrichtung entsprechen. Durch einen Strahlexponenten kann der Lichtke- gel fokussiert werden, durch diesen Exponenten wird der Faktor ggf. verkleinert: F aktor = F aktorExp

6.4.3 Sharp Spot Light

Das Sharp Spot Light erzeugt einen scharfen Lichtkegel. Innerhalb des Lichtkegels werden die Intensi- täten des Lichts unmodiﬁziert ausgegeben. Außerhalb des Lichtkegels strahlt die Lichtquelle kein Licht ab. Es ist gewissermaßen eine Punklichtquelle mit einem begrenzten Strahlungsbereich. Wie beim Spot Light wird über den Winkel zwischen Schattenstrahl und Leuchtrichtung der Leuchtkegel bestimmt. Ist der Winkel größer als ein bei der Erzeugung der Lichtquelle angegebener Schwellenwert, werden keine Intensitäten ausgegeben, ansonsten die vollen Intensitäten des Lichtes. 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 30

6.4.4 Area Light

Als ausgedehnte Lichtquelle zur Erzeugung von weichen Schatten wurde eine Flächenlichtquelle implementiert. Durch die Angabe von den vier Eckpunkten eines Rechteckes und der Leuchtrichtung wird dabei die strahlende Fläche deﬁniert. Durch Angabe der Anzahl von Unterteilungsschritten pro Dimen- sion wird die Fläche in ein regelmäßiges Gitter unterteilt. Jeder Knoten in dem Gitter repräsentiert dabei eine eigene Lichtquelle. Dieses Netz von einzelnen Lichtquellen approximiert die lichtabstrahlende Flä- che. Bei der lokalen Beleuchtung wird dann für jede der n Lichtquellen in dem Gitter ein Schattenstrahl er- Intensitat¨ zeugt und der Punkt mit n beleuchtet, sollte der Punkt nicht im Schatten liegen. Die weichen Schatten ergeben sich, da, anders als bei punktförmigen Lichtquellen, Bruchtteile der Gesamtintensi- tät bei der Beleuchtungsberechnung eingehen können, was der teilweisen Verdeckung der Lichtquelle entspricht. Da die Fläche allerdings in diskreten Teilschritten ausgewertet wird, hängt die Qualität der weichen Schatten von der Anzahl der Teilschritte ab. Bei wenigen Teilschritten stellt sich der weiche Schatten vielmehr als ein stufenweiser Schatten mit unterschiedlichen Helligkeitsstreifen dar.

6.5 Beleuchtung

Nach dem Auffinden des nächstgelegenen Schnittpunktes wird dieser Punkt beleuchtet. Für die lokale Beleuchtung wurde eine Abwandlung des Phong-Beleuchtungsmodells [Pho73] gewählt. Abgewandelt wurde es dadurch, dass Komponenten der Beleuchtung entfallen, sollte der Schnittpunkt für die betrachtete Lichtquelle durch ein anderes Objekt verdeckt sein und der Schnittpunkt somit im Schatten liegen. Als zusätzliche Einflüsse werden die, wie bei der Vorstellung des Verfahrens (Kapitel 4) bechrieben, rekursiv ermittelten Farbwerte für Reflexion und Transmission addiert. Koeffizienten für jede Komponente bestimmen, wie stark die jeweilige Intensität eingeht. Nur bei Koeffizienten größer Null werden rekursiv Sekundärstrahlen ausgesendet. Es ergibt sich insgesamt für die Intensität I am Schnittpunkt:

I = klocal · Ilocal + kreflect · Ireflect + ktrans · Itrans 1 = klocal + kreflect + ktrans

6.5.1 Lokale Beleuchtung

Die lokale Beleuchtung nach Phong besteht aus drei Komponenten, welche jeweils Intensitäten zur lokalen Gesamtintensität beitragen. Über die Materialkoefﬁzienten der einzelnen Komponenten wird ihr relativer Anteil während der Berechnung bestimmt. In diese Berechnung ﬂießt die von der jeweils betrachteten Lichtquelle gelieferte Intensität als Ausgangswert ein.

Ilocal = IAmbient + IDiffuse + ISpecular

Ambiente Komponente

Die ambiente Komponente simuliert Umgebungslicht, welches unabhängig vom Betrachtungswinkel oder dem Winkel zur Lichtquelle für jeden betrachteten Punkt eingeht. In dieser Diplomarbeit geht von jeder Lichtquelle die ambiente Komponente ein, und nicht ein szenenglobal gesetzter Wert. Der Gedanke 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 31 dabei ist, dass z.B. das Hinzufügen einer rötliche Lichtquelle auch einen rotfärbenden Einﬂuß auf das Umgebungslicht hat, und ein szenenglobaler Wert das Umgebungslicht nur sehr statisch und ungenau abbildet.

IAmbient = kAmbient · Iin

Abbildung 6.7: Die Intensität der diffusen Komponente ist abhängig vom Winkel zwischen der Flächen- normale und dem Vektor zur Lichtquelle

Diffuse Komponente

Bei Oberflächen mit großer Rauigkeit wird einfallendes Licht in alle Richtungen reflektiert. Die Diffuse Komponente simuliert die ideal diffuse Reflexion nach dem Lambertsches Kosinusgesetz. Die Reflexion ist nach diesem Gesetz vom Einfallswinkel des Lichts auf die Fläche abhängig, da bei einem flachen Lichteinfall auf die Fläche aufgrund der perspektivischen Verkürzung weniger Licht pro Flächeneinheit einfällt und auch reflektiert wird. Die reflektierte Intensität sinkt dabei mit dem Winkel θ zwischen Lichtrichtung und Normale um cos θ:

IDiffuse = kDiffuse · Iin · cos+ θ = kDiffuse · Iin · (L~ • N~ )+

Negative Werte aus der Kosinusberechnung werden dabei nicht betrachtet und auf Null gesetzt, da diese für eine Lichtposition hinter der betrachteten Fläche stehen würden.

Spiegelende Komponente

Die spiegelnde Komponente simuliert die ideal spiegelnde Reflexion. Dabei wird ausgehend vom Re- flexionsgesetz aus der Normalen und dem einfallenden Lichtstrahl der reflektierte Lichtstrahl berechnet, Einfalls- und Ausfallswinkel sind nach dem Reflexionsgesetz identisch. Die (ideal) spiegelnde Relexion reflektiert das meiste Licht entlang dieses Lichtstrahls, mit dem Winkel θ zwischen reflektiertem Licht- strahl R~ und Blickrichtung V~ sinkt die reflektierte Lichtintensität um cos θ. Durch einen Exponenten kann die Materialeigenschaft für die Spiegelung simuliert werden, wodurch sich unterschiedliche Spie- gelungen auf rauhen und glatten Oberflächen darstellen lassen. Bei einem sehr großen Exponenten wird 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 32

S N S

L R θ V

Abbildung 6.8: Die Berechnung der spiegelnden Komponente hängt vom Blickpunkt und der Richtung der ideal spiegelnden Reflexion ab das reflektierte Licht stark um den ideal reflektierten Lichtrahl gebündelt.

R~ = L~ + 2 · ((N~ • L~ ) · N~ − L~ ) = 2 · (N~ • L~ ) · N~ − L~

ISpecular = kSpecular · Iin · cos+ θ = kSpecular · Iin · (R~ • V~ )+

Auch hier werden negative Werte aus der Kosinusberechnung auf Null gesetzt. Der reﬂektierte Licht- strahl R~ errechnet sich dabei aus der Vektoraddition des bekannten Strahles L~ zur Lichtquelle mit dem doppelten, verschiebenden Vektor S~, der von L~ in Verschieberichtung bis zur Normale zeigt. Da der Einfallswinkel dem Ausfallswinkel entspricht, zeigt der Vektor S~ auch von der Normale zum zu berechnenden, reﬂektierten Lichtstrahl R~. Um diesen verschiebenden Vektor S~ zu berechnen, wird zunächst L~ auf die Normale projeziert. Man erhält einen Vektor, der zu dem Punkt entlang der Normalenrich- tung zeigt, auf den der gesuchte Vektor S~ zeigen würde. Um die Richtung von S~ zu berechnen, wird L~ subtrahiert.

6.5.2 Reﬂexion und Transmission

Die Berechnung der ideal spiegelnden Reflexion erfolgt völlig analog zur spiegelnden Komponente der lokalen Beleuchtung und soll deswegen nicht näher vorgestellt werden. Anstatt von dem Vektor zur Lichtquelle wird bei der Berechnung des reflektierten Lichtstrahls vom verfolgten Strahl durch die Szene ausgegangen. Der berechnete Strahl in Reflektionsrichtung ist dann der Strahl, der rekursiv verfolgt wird. Neben der Reflexion können Teile des Lichtstrahls auch transmittiert werden, das heißt sie dringen in das Medium ein und verlaufen ggf. gebrochen durch dieses Medium. An dieser Stelle wird beim Raytracing vereinfachend von einem einzigen, unteilbaren Lichtstrahl ausgegangen, unterschiedliche Wellenlängen werden nicht simuliert. Dieses ist physikalisch nicht sehr präzise, erfordert aber nur die Berechnung eines gebrochenen Lichtstrahls, welcher dann rekursiv verfolgt werden kann. Ausgangspunkt ist der eintreffende Lichtstrahl, der beim Schnitt mit einem Objekt auf die Oberfläche trifft. Diese Oberfläche ist die Grenzfläche zwischen den zwei betrachteten Medien, das Medium, durch 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 33

i i n r rn

i t i r r t 1 2 t t

t t

Abbildung 6.9: Reﬂexion und Transmission beim Übergang an zwei Medien welches der Strahl vor dem Auftreffen verlief, und das zweite Medium, in welches Teile des Strahls eindringen. Die unterschiedlichen, optischen Eigenschaften der Medien werden durch die jeweilige Brech- zahl charakterisiert. Die Brechzahl gibt das Verhältnis der Phasengeschwindigkeit des Lichts im Vaku- um verglichen mit der Phasengeschwindigkeit des Lichts im betrachteten Medium an und hängt von der Wellenlänge ab. Da an dieser Stelle nicht physikalisch korrekt simuliert wird, ist die Brechzahl in dieser Diplomarbeit eine Materialkonstante. Die Brechung erfolgt nach dem Snelliusschen Brechungsgesetz, welches das Verhältnis der Einfalls- und Brechungswinkel zu den Brechzahlen beschreibt:

η1 · sin θi = η2 · sin θt

Ziel der folgenden Berechnungen ist es, mittels der Brechzahlen η1, η2, Einfallsstrahl~i und Flächennor- male ~n den transmittierten Strahl ~t zu bestimmen. Verwendet wird ein geometrischer Ansatz [Gre06], bei dem die zu betrachtenden Strahlen zunächst in zur Grenzfläche parallele und senkrechte Komponenten zerlegt werden, um mit diesen Komponenten über Kreisfunktionen die im Brechungsgesetz genannten Winkel abzubilden. Bezeichne ~v stellvertretend die zu betrachtenden, normierten Vektoren ~i, ~r,~t. Dann kann die zur Grenzfläche senkrecht verlaufende Komponente ~vn durch die orthogonale Projection auf die Normale errechnet werden, und die parallel zur Grenzfläche verlaufende Komponente aus der Differenz der beiden schon bekannten Vektoren:

~vn = (~v • ~n) · ~n

~vt = ~v − ~vn

Der Sinus (Gegenkathete / Hypotenuse) und Kosinus (Ankathete / Hypotenuse) der Winkel kann über die berechneten Komponenten bestimmt werden: 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 34

|~vn| cos θv = |~v| = |~vn| |~vt| sin θv = |~v| = |~vt|

Damit ist der Sinus der Winkel aus dem Brechungsgesetz durch Vektoren beschrieben, und kann in die umgestellte Gleichung des Brechungsgesetz eingesetzt werden:

sin θ = η1 sin θ t η2 i |~t | = η1 |~i | t η2 t

Die beiden parallelen Komponenten sind zueinander parallel und positiv, die parallele Komponente des einfallenden Strahls kann durch die Vektoraddition ersetzt werden:

~t = η1~i = η1 (~i + cos θ ~n) t η2 t η2 i

Um den transmittierten Strahl aus den parallelen und senkrechten Komponenten zusammensetzen zu können, muss noch über den Pythagoras die senkrechte Komponente bestimmt werden, der Vektor soll entgegen der Normalenrichtung zeigen:

q 2 ~tn = − 1 − |~tt| · ~n

Nun kann der Strahl aus den Komponenten zusammengesetzt werden, die Normale wird ausgeklammert:

q 2 ~t = η1~i + η1 cos θ − 1 − |~t | ~n η2 η2 i t

Um den Betrag von ~tt unter der Wurzel zu eliminieren, kann der zuvor berechnete Zusammenhang zum Winkel ausgenutzt werden: η1 η1 p 2 ~t = ~i + cos θi − 1 − sin θt ~n (6.1) η2 η2 Wobei sich der Sinus aus dem Brechungsgesetz und der Beziehung zwischen Kosinus und Sinus ableiten lässt: 2 2 2 η1 2 η1 2 sin θt = sin θi = (1 − cos θi) (6.2) η2 η2 Aus mathematischer Sicht stellt sich die Frage, wie negative Werte unter der Wurzel zu handhaben sind. In diesem Fall existiert keine reelle Lösung. In dieser Diplomarbeit wird in diesem Fall die Rekursion abgebrochen, also keine transmittierten Strahlen mehr berechnet und somit nicht verfolgt. Physikalisch gesehen deckt dies das Phänomen der Totalreflexion ab, bei dem an einem Grenzübergang das Licht vollständig reflektiert und nicht transmittiert wird. Diese Reflexion wird beim Abbruch also nicht weiter simuliert. Bei der Implementierung ergaben sich praktische Probleme bei den Grenzübergängen. Zum einen mussten Selbstkollisionen vermieden werden, bei denen der gefundene Schnitt am Grenzübergang als Ur- sprung des transmittierten Strahles erneut als Schnittpunkt gewertet wird. Deswegen wird der transmit- tierte Strahl minimal entlang der negativen Normalenrichtung verschoben. Zum anderen mussten die beiden Brechzahlen am Grenzübergang auch bei Durchdringung von Objekten korrekt vorliegen. Bei einer Durchdringung ist nicht mehr davon auszugehen, dass nach einem Eintritt in ein Medium der nächste 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 35

Schnitt automatisch einen Austritt aus dem Medium kennzeichnet. Dem transmittierten Strahl wird dabei jeweils ein Stack mit Zeigern auf die bisher durchlaufenen Medien zugeordnet. Dabei wächst der Stack mit jedem neu getroffenen Objekt. Austritte werden erkannt, wenn das zuoberst auf dem Stack liegende Objekt identisch mit dem betrachteten Objekt ist. In diesem Fall wird das oberste Element des Stacks gelöscht.

6.6 Hüllvolumen

1,2,3,4,5

2 1,3 2,4,5

1 3 2 4,5 1 4 3 4 5 5

Void Area

Abbildung 6.10: Hierarchie von Kugeln als Hüllvolumen und resultierende Baumstruktur

Um den in der Abschätzung des Berechnungsaufwandes (4.2) angesprochenen, linearen Zusammenhang von Schnittberechnungen und Anzahl der Objekte in der Szene zu vermeiden, müssen offensichtlich unnötige Schnitte ausgeschlossen werden. In dieser Diplomarbeit werden dabei die Objekte der Szene mit als Hüllvolumen fungierende Kugeln umschlossen. Schneidet ein betrachteter Strahl bereits diese Kugel nicht, muss der gesamte Inhalt der Kugel nicht weiter betrachtet werden. Dieser sehr einfache Ansatz alleine vermeidet beim Triangle Mesh schon den Schnit mit jedem einzelnen Dreieck, solange die umgebende Kugel nicht geschnitten wurde. Der Kompromiss ist dabei die Abwägung zwischen Ein- fachheit des Schnittes und der in Kauf genommenen “Void Area”. Die Void Area bezeichnet den Raum, den das Hüllvolumen unnötigerweise abdeckt. Je größer diese Void Area ist, desto mehr Strahlen treffen das Hüllvolumen, obwohl das umschlossende Objekt gar nicht getroffen werden kann. Die Genauigkeit des Hüllvolumens macht sich demnach in der Anzahl der Schnittberechnungen mit dem umschlossenden Objekt bemerkbar. Je komplexer allerdings das Hüllvolumen konstruiert ist, desto rechenaufwendiger ist auch die Schnittberechnung mit dem Hüllvolumen. In dieser Diplomarbeit wurde die Kugel als Hülvolumen gewählt, da diese von den vorhandenen Pri- mitiven verhältnismäßig unaufwendig zu schneiden und zu konstruieren ist und im Hinblick auf eine bisher nicht realisierte, dynamische Veränderung der Szene unproblematisch zu transformieren ist. Die Kugel ist allerdings für längliche Objekte keine optimale Wahl, bei der Konstruktion des Hüllvolu- mens wäre ein automatisierter Ansatz denkbar, der unter mehreren Volumen die optimale Variante wählt [WHG84]. Hüllvolumen sind im direkten Vergleich aufwendigeren Beschleunigungsstrukturen unterle- gen [HPP00, Hav00]. Es wurde dieser Ansatz implementiert, um die Berechung von Dreiecksnetzen überhaupt zu ermöglichen. 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 36

Durch eine Hierarchisierung der Hüllvolumen kann der Berechnungsaufwand weiter verringert werden. Die Idee dabei ist, nicht nur durch einfach zu schneidende Hüllvolumen unplausible Schnitte mit kom- plexeren Objekten zu vermeiden, sondern gleich ganze Teilbereiche der Szene auszuschließen. Dabei werden alle Objekte der Szene in einem Top-Down-Ansatz mit einer Kugel umschlossen. Die von der Kugel eingeschlossenen Objekte werden dann in zwei möglichst gleich große Kindkugeln verteilt. Die- se Unterteilung findet so lange statt, bis nur noch zwei Objekte aufzuteilen sind. In Abbildung 6.10 ist dieses dargestellt. Gehalten wird diese Hierarchie in einer binären Baumstruktur, in der jeder Knoten die umhüllende Kugel enthält. Blätter des Baumes sind die einzelnen Objekte. Diese Kugelhierarchie wird für die gesamte Szene und Dreiecksnetze getrennt aufgebaut, wobei die Kontruktion unterschiedlich implementiert ist. Da die in dieser Diplomarbeit implementierten Objekte sehr unterschiedliche Oberflächen darstellen, erzeugt jedes Objekt bei der Erstellung eine sich selbst umgebende Kugel. Die Kugelhierarchie wird dann nur noch mit diesen Kugeln als Abstraktion erstellt, die einzelnen Objekte werden dabei nicht mehr betrachtet. Die Dreiecksnetze erstellen unabhängig von der Szene eine interne Kugelhierarchie, welche transparent bei der Schnittberechnung durchlaufen wird. Dadurch bleibt das Interface für die Schnittberechnung identisch zu den anderen Objekten, ermöglicht aber die effiziente Schnittberechnung von sehr vielen Dreiecken. Bei der Aufteilung der Geometrie auf je zwei Kindkugeln wird die Koordinatenachse bestimmt, in deren Richtung die betrachteten Objekte die größte Ausdehnung aufweisen. An der Hälfte dieser Ausdehungen wird gedanklich eine Grenze gezogen, die Lage relativ zu dieser Grenze entscheidet, welcher Kindkugel das betrachtete Objekt zugeordnet wird. Die beiden Kindkugeln können bei diesem Ansatz unterschiedlich viele Objekte beinhalten, wodurch der resultierende Baum unsymmetrisch sein kann. Dieses wird in Kauf genommen, da durch diesen geometrischen Ansatz unterschiedlich große Kugeln vermieden werden sollen, welche unterschiedlich oft geschnitten würden. Bei den Objekten der Szene kann die re- lative Lage zur Grenze einfach bestimmt werden, entschieden wird anhand des Kugelmittelpunktes. Die Dreiecke haben von sich aus keinen Mittelpunkt. Deswegen wird bei der Kontruktion der Dreiecke der Schwerpunkt baryzentrisch ermittelt, indem jeder Eckpunkt zu gleichen Teilen eingeht. Bei den Schnittberechnungen wird der erstellte Baum traversiert. Beim Wurzelknoten ansetzend wird für jeden betrachteten Knoten des Baumes die zugeordnete Kugel geschnitten und sollte ein Schnitt festgestellt worden sein, wird rekursiv die Äste des Baumes hinabgestiegen. Dieses wird solange fortgesetzt, bis an den Blättern ein Objekt geschnitten wird. Ziel dieser Hierarchie ist es selbstverständlich, auf einer möglichst hohen Hierarchieebene festzustellen, dass die Hüllvolumen der Äste nicht geschnitten wurden und somit die Rekursion beendet werden kann. In diesem Fall müssten ganze Äste nicht mehr betrachtet werden, man hätte Teile der Szene ausgeschlossen. Sollte ein Strahl mehrere Objekte schneiden, müssen viele Teilbäume durchlaufen werden. Um den naiven Ansatz zu vermeiden, bei dem für eine Entscheidung des Sichtbarkeitsproblems bis zu jedem Blatt- knoten in der Hierarchie hinabgestiegen wird, wird bei der Traversierung der Abstand zu einem bereits gefundenen Schnitt mitgeführt. Sollte dieser Schnitt schon näher am Strahlursprung als das betrachtete Hüllvolumen liegen, wird die Rekursion abgebrochen. Als weitere Optimierung wird bei Schattenstrah- len gleich nach dem ersten Schnitt mit einem Blattknoten die Schnittsuche beendet, da der zu beleuch- tende Punkt bereits im Schatten liegt. In [KK86] wird die naive Traversierung der Bäume vermieden, indem anstatt einer Rekursion eine itera- tive Methode mit einem sortierten Stack gewählt wurde. Auf diesem Stack werden dabei beim Abstieg 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 37 in die Hierarchie die noch zu betrachtenden Knoten gelegt und von diesem in jeder Iteration Knoten entnommen. Dieses Vorgehen vermeidet zunächst nur die Rekursion, jedoch wird der Stack sortiert. Je- der Knoten wird nur auf den Stapel gelegt, wenn der Strahl das Hüllvolumen schneidet, was bei einer rekursiven Implementierung dem Absteigen in der Hierarchie entsprechen würde. Jeder auf den Stack abgelegt Knoten hält den vom Strahlursprung aus gesehenen, errechneten Abstand des Schnittes mit dem Hüllvolumen. Anhand dieses Abstandes wird der Stack sortiert, so dass immer die Knoten mit den kleinsten Abständen oben auf dem Stapel liegen und als erstes betrachtet werden. Wird ein Schnitt mit einem Blattknoten gefunden, werden alle weiter entfernt liegenden Knoten nicht mehr betrachetet. Dieser Ansatz wurde als Vergleichstest der eigenen, rekursiven Traversierung implementiert. Es ergaben sich keine Geschwindigkeitsvorteile, da auch bei der rekursiven Methode der Abstand eines gefunden Schnittes mitgeführt wird, und somit offensichtlich unrelevante Teiläste nicht betrachtet werden. Ver- wendet wird deshalb weiterhin die eigene, rekursive Methode.

6.7 Zusammenfassung und Bewertung

Von Grund auf wurde ein rekursiver Ray Tracer geschrieben, welcher als eine noch völlig unparallelisierte Bibliothek implementiert wurde. Neben den üblichen Grundprimitiven wie ausgewählten Quadrics (Kugel, Ellipsoid, Paraboloid), Dreieck und Box können Dreicke außerdem zu Dreiecksnetzen zusammengefasst werden. Dieses erlaubt die Darstellung von beliebigen Körpern. Um Dreicksnetze efﬁzient schneiden zu können, wurde als Beschleunigungsstruktur eine Hierarchie von Hüllvolumen gewählt. Das Hüllvolumen bildet dabei die bereits implementierte Kugel, welche von den vorhandenen Primitiven verhältnismäßig unaufwendig zu schneiden und zu konstruieren ist und im Hin- blick auf eine bisher nicht realisierte, dynamische Veränderung einer animierten Szene unproblematisch zu transformieren ist. Kugeln stellen nicht immer das optimale Hüllvolumen dar, in [WHG84] wird die Konstruktion von optimalen Hüllvolumen diskutiert und statistisch betrachtet. Eine Generalisierung des vorgestellten Boxschnittes zum Erzeugen eines optimaleren Hüllvolumens wurde zunächst überdacht, dann jedoch verworfen. Denn Hierarchien von Hüllvolumen haben die gemeinsame Schwäche, dass sie den räumlichen Zusammenhang der Szene nicht berücksichtigen. Unabhängig vom Strahl und seinem Verlauf in der Szene werden Baumstrukturen der Hierarchie traversiert, vorteilhafter wäre es, den Strahl auf seinem Weg durch die Szene zu verfolgen. So kann ein betrachteter Strahl unter Umständen schon aufgrund seiner Richtung nicht alle Obekte schneiden. Könnte man die Laufrichtung des Strahls bei der Schnittberechnung beachten, könnte garantiert werden, dass der erste gefundene Schnitt auch der am nächsten zum Strahlursprung liegende Schnitt ist. Den Hierarchien aus Hüllvolumen sind raumun- terteilende Verfahren im direkten Vergleich überlegen [HPP00, Hav00]. Die Beschleunigungsstrukturen dieser Diplomarbeit sind somit nicht auf dem aktuellsten Forschungsstand, doch gerade die aktuellsten, sich auf Beschleunigungsstrukturen konzentrierenden Entwicklungen würden den Rahmen der Diplom- arbeit sprengen [WMG+]. Die Bibliothek leistet die von einem rekursiven Raytracer zu erwartenden Farbbeiträge durch Reﬂexi- on und Transmission. Neben einfachen Lichtquellen wie Punktlichtquellen und verschiedenen Strahlern können mit einer ausgedehnten Lichtquelle weiche Schatten erzeugt werden (Abbildung A.5). Mit einem vom Phong-Beleuchtungemodell durch Beachtung von Schatten abgewandelten, lokalen Beleuchtungs- modell werden die Farbwerte der Schnitte bestimmt. Dabei können den Objekten feste Grundfarbwerte 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 38

Schnitt Verfehlt Schnitt + Textur Schnitt + Textur + Normalmap Kugel 180ns 70ns 450ns 3020ns Paraboloid 210ns 40ns 400ns 3020ns Ellipsoid 240ns 70ns 540ns 3220ns Box 280ns 390ns - - Triangle 470ns 430ns 670ns 1050ns TriangleMesh 58700ns 80ns 58720ns 69950ns (Traktor, 3473 Dreiecke)

Tabelle 6.1: Zeitbedarf einzelner Schnitttests auf der Altix (Itanium II, 1.6GHz) zugewiesen werden, oder diese aus Texturen ausgelesen werden. Zusätzlich wurden einige Effekte implementiert, die kein Schwerpunkt dieser Arbeit waren, und hier somit nur undetailliert vorgestellt werden sollen. Neben den Farbwerten können die Komponenten der Texturen auch Normalen und Materialkonstanten enthalten. Als Materialkonstante wurde beispielhaft der Reflexionskoeffizient in einer Reflection Map gespeichert, so dass wie in Abbildung A.1 zu sehen die rechte Wand und hintere, rechte Kugel pixelgenau vollkommen spiegelnd oder überhaupt nicht re- flektierend sind. In Normal Maps können Normalen definiert werden, welche mit der am Schnittpunkt errechneten Normalen verrechnet werden und auf diese Weise leichte Oberflächenunebenheiten simulieren (Siehe Abbildung A.1). Bei der lokalen Beleuchtung wurden zwei Erweiterungen verwirklicht. Als erster, nicht photorealisti- scher Effekt wurden die Helligkeitsstufen der Beleuchtung in drei grobe Bereiche quantisiert. Zusätzlich wurden an den Konturen der Objekte die Bildpunkte schwarz eingefärbt, wodurch der Eindruck eines schwarzen Randes entsteht. Insgesamt erscheint die in Abbildung A.7 gezeigte Szene wie im Comic-Stil gezeichnet. Beim zweiten Effekt wird die Szene in einen Nebel getaucht. Dabei wird mit der Entfernung der Objekte zum Betrachter ansteigend mehr Nebelfarbe in die errechnete Farbe der lokalen Beleuch- tung gemischt (Abbildung A.6). Diese Effekt ist sehr einfach zu realisieren, da die Entfernung nach den Sichtbarkeitsberechnungen des Ray Tracings für jeden Bildpunkt vorliegt. Im Prozess der Sichtbarkeitsberechnung kann ebenfalls überprüft werden, ob die miteinander vergli- chenen Schnittpunkte des Primärstrahls mit den Objekten näher als ein gewisser Schwellwert zueinander liegen. In diesem Fall liegt eine Kollision der Objekte vor, die Durchdringungspunkte können visualisiert werden (Abbildung A.8).

Schnittkosten der implementierten Primitive

Die von der Geometrie und Schnitttests her unterschiedlichen Primitive wurden, wie in Tabelle 6.1 dargestellt, bezüglich ihrer Schnittkosten untersucht. Untersucht wurde dabei, wie lange ein Treffer bzw. der Ausschluß eines Treffers mit einem Strahl bei der Berechnung dauert. Außerdem wurde gemessen, wieviel die Texturierung und zusätzlich die Modiﬁkation der errechneten Normale mit einer Normalmap kostet. Als Testumgebung wurde ein minimales Programm geschrieben, welches ein Primitiv erstellt und je einen treffenden und einen verfehlenden Strahl erzeugt. Diese beiden Strahlen werden direkt an die Intersect()-Methode übergeben, und die Zeitdifferenz gemessen. 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 39

Alle Messungen wurden auf der Altix mit ihren Itanium II 1.6GHZ-Prozessoren durchgeführt. Die ansonsten auf dem Client für Messungen verwendete rdtsc-Instruktion stand auf der Altix nicht zur Verfügung, da der dort verwendet Intel-Compiler in der zum Stand der Diplomarbeit aktuellen Version 10.0 keine Inline-Assemblerbefehle akzeptierte. Ausgewichen wurde auf die gettimeofday()-Funktion, welche auf der Altix eine Auflösung von einer Mikrosekunde hat. Diese Auflösung ist für einzelne Schnittberech- nungen viel zu gering, es wurden pro Messungen 100 Schnitte ausgführt, die Zeitdifferenz gemessen und mittels Division durch 100 die einzelnen Kosten als Mittelwert bestimmt. Diese Messungen sind gerade für Schnitte mit Texturzugriffen sehr ungenau, da nach dem ersten Zugriff die relevanten Teile der Textur im Cache des Prozessors liegen, und somit bei den restlichen Schnitten keine Cache-Effekte mehr gemessen werden können. Die drei Quadrics haben erwartungsgemäß praktisch identische Berechnungszeiten, da der Ansatz zur Schnittberechnung immer identisch ist. Ein Treffer ist deutlich teurer als ein nicht treffender Strahl, da in diesem Fall die Wurzel zum Bestimmen des Abstandes von Schnittpunkt und Strahlursprung, und damit der Schnittpunkt anhand der Strahlgleichung errechnet wird, sowie die Normale bestimmt wird. Auf- grund der zum Berechnen der Texturkoordinaten verwendeten, trigonometrischen Parameteriesierung ist das Texturieren im Trefferfall noch einmal deutlich teurer. Die Modifikation der errechneten Flächen- normale beinhaltet das Transformieren der Normale aus ihrem lokalen Koordinatensystem innerhalb der Textur in das Weltkoordinatensystem und erfordert einen nicht unerheblichen Berechnungsaufwand. Die Box war, vor allem auch mit dem vorgestellen Ansatz für die Schnittberechnung, eigentlich als Hüllvolumen vorgesehen, weswegen keine Texturkoordinaten erstellt werden. Gemessen wurden deshalb nur die Kosten für den Treffer und Fehlschuss mit einem Strahl. Es fällt auf, dass ein Fehlschuss in der Messung teurer als ein Treffer mit der Box war. Dieses offenbart eine Schwäche der Iteration über die einzelnen Flächen zum Bestimmen der relativen Lage des gefunden Ebenenschnittes. Die Schnittkosten steigen, je mehr Flächen iterativ betrachtet werden müssen. Für die Effizienz des Schnitttests ist ein früher Abbruch notwendig, es ist aber a priori nicht bekannt, in welcher Iteration und damit auf welcher Ebene abgebrochen werden kann. Im schlechtesten Fall werden sämtliche Flächen betrachtet. Beim Dreiecksschnit haben Treffer und Fehlschuss praktisch identische Berechnungszeiten, da, vom Spezialfall eines zur Ebene parallel laufenden Strahls abgesehen, in beiden Fällen die baryzentrischen Koordinaten des Schnittpunktes berechnet werden. Dementsprechend teuer ist der Dreiecksschnitt schon ohne Texturierung. Mit Texturierung erhöhen sich die Kosten kaum, da die Texturkoordinaten mittels Interpolation durch die baryzentrischen Koordinaten verhältnismäßig unaufwändig berechnet werden können, und nur noch der Texturzugriff Kosten verursacht. Als Beispiel für ein Dreiecksnetz wurde das am Lehrstuhl verfügbare und und in Abbildung A.2 gezeigte Modell eines Traktors getestet. Beim Dreiecksnetz ist ein Fehlschuss nicht teurer als ein nicht schneidender Strahl bei der Schnittberechnung der Kugel, da auch eine Kugel als Hüllvolumen verwendet wird. Aufgrund der beschriebenen Hierarchie aus Hüllvolumen erfordert der gemessene Schnitt mit tausenden Dreiecken des Dreiecksnetzes keinen linearen Aufwand, erreicht jedoch nicht die theoretische best-case Komplexität bei n Dreiecken von O(log n) [SKM]. Diese Abschätzung basiert auf dem loga- rithmischen Traversierungsaufwand symmetrischer, binärer Bäume, von dieser Symmetrie ist bei dem in dieser Diplomarbeit gewählten, geometrischen Konstruktionsansatz nicht auszugehen. Generell ist die Annahme unrealistisch, dass der Baum der Hierarchie immer ohne Betrachtung falscher Äste zum entsprechenden Primitiv im Blattknoten durchlaufen werden kann. Aufgrund der Void Area werden sehr wahrscheinlich fälschlicherweise Schnitte erkannt, erst auf tieferen Hierarchieebenen wird 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 40 die Rekursion dann abgebrochen, und ggf. andere Äste weiter verfolgt. Zudem können sich die Hüllvo- lumen durchdringen, so dass diese keine Raumunterteilung mit klar abgegrenzten Bereichen definieren.

Entstehung und Schwankungen des Berechnungsaufwandes

E 1 E 2 E 3 E 4 E 5 E 6

Transparent und spiegelnd Opak

Abbildung 6.11: Aus Ebenen mit unterschiedlichen Materialeigenschaften bestehende Testzene zum schrittweisen Erzeugen des maximalen Berechnungsaufwandes. An den ersten vier Ebenen werden bei dieser Abbildung Sekundärstrahlen für Transmission und Reﬂexion erzeugt.

Für die Entstehung des gesamten Berechnungsaufwandes ist neben den einzelnen Schnittkosten vor allem die Anzahl der Schnittberechnungen ausschlaggebend. Wie bei der Abschätzung des Berechnungsauf- wandes des Verfahrens theoretisch vorgestellt (Abschnitt 4.2), kann die Anzahl der verfolgten Strahlen und damit die Anzahl der Schnittberechnungen je nach betrachteter Szene stark schwanken. Im aufwän- digsten Fall, bei dem jeder Schnitt mit einem Objekt zwei rekursiv zu verfolgende Sekundärstrahlen erzeugt, kann der Berechnungsaufwand exponentiell mit der Rekursionstiefe steigen. Anhand der in Abbildung 6.11 schematisch gezeigten Testszene wurden die Auswirkungen der Rekur- sionstiefe auf den Berechnungsaufwand untersucht. In dieser Testzene befinden sich 6 aus je zwei Drei- ecken zusammengestzte, parallel angeordnete Ebenen. Die Kamera ist dabei frontal auf den Stapel der Ebenen gerichtet, so dass die erzeugten Primärstrahlen sämtliche Ebenen schneiden. Für die Messung wurden initial die Materialeigenschaften so für alle Ebenen gesetzt, dass keine Ebene Strahlen reflektiert oder transmittiert. Für jeden Schritt in der Messung wurde dann eine Ebene nach der anderen zusätzlich mit transparenten bzw. reflektierenden Materialeigenschaften definiert. Mit jedem Schritt der Messung konnten die von der Kamera erzeugten Primärstrahlen also immer tiefer durch rekursiv erzeugte, trans- mittierende Strahlen in den Stapel eindringen. Es werden so viele Ebenen durchlaufen, wie die maximale Rekursionstiefe erlaubt, in dieser Messung war dies eine Tiefe von 5, so dass maximal 6 Ebenen geschnitten werden können. Die maximale Rekursionstiefe bei der Rekursion der reflektierten Strahlen wird erreicht, da diese Strah- len bis zum Erreichen der maximalen Tiefe zwischen den Ebenen hin- und herreflektiert werden. Ähnlich verhält es sich mit den transmittierten Strahlen, da auch diese Strahlen den Stapel der Ebenen nicht mehr 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 41

Material und Berechnungszeit # Schnitte #Strahlen #Strahlen #Strahlen Anzahl durch- (Schatten) (Reﬂexion) (Transmission) laufener Ebenen Transmission: 0 0,352s 264.600.000 2.940.000 - - Transmission: 1 0,623s 399.945.525 5.880.000 - 2.940.000 Transmission: 2 0,894s 535.286.561 8.820.000 - 5.880.000 Transmission: 3 1,263s 670.611.898 11.760.000 - 8.820.000 Transmission: 4 1,415s 805.923.599 14.700.000 - 11.760.000 Transmission: 5 1,662s 941.234.728 17.640.000 - 14.700.000 Trans + Ref: 1 0,741s 532.244.721 5.880.000 2.940.000 2.940.000 Trans + Ref: 2 4,238s 2.547.982.707 41.160.000 20.580.000 20.580.000 Trans + Ref: 3 7,218s 4.172.942.936 76.440.000 38.220.000 38.220.000 Trans + Ref: 4 8,588s 4.714.272.766 88.200.000 44.100.000 44.100.000 Trans + Ref: 5 9,130s 4.984.835.491 94.080.000 47.040.000 47.040.000

Tabelle 6.2: Exponentieller Anstieg der Berechnungszeit sowie Anzahl der Schnitte und verfolgter Strah- len (Neptun, 120 Prozessoren) bei dem in Abbildung 6.11 gezeigten, synthetischen Test verlassen können. Wie in Abbildung 6.9 gezeigt, wird bei der Berechnung der transmittierten Strahlen davon ausgegangen, dass die Flächennormale aus dem durchdrungenen Medium herauszeigt. Bei der vorgestellten Berechnung des Strahles (Formel 6.1) wird dann der eintreffende Vektor in einer Vektorad- dition mit der Flächennormalen verschoben. Die Normalen der Ebenen zeigen bei dem Test nach Links, so dass Strahlen, die den Stapel nach Links durch Transmission verlassen könnten, die Rückseiten der Ebenen treffen. Die Normale ist bei der folgenden Strahlberechung also invers zu der Normalen in der Annahme, durch eine Verschiebung mit der Normalen zeigen die transmittierten Strahlen wieder in den Stapel der Ebenen. Dadurch verbleiben in diesem synthetischen Test alle Strahlen im Stapel der Ebenen, so dass je nach Anzahl und Materialeigenschaften der Ebenen die maximale Rekursionstiefe bei Reflexion und Trans- mission erreicht werden kann. Allerdings werden die Strahlen zwischen je zwei reflektierenden Ebenen immer bis zur maximalen Rekursionstiefe erzeugt, so dass die Anzahl der Strahlen und der resultierende Berechnungsaufwand immer nur in Intervallen erhöht werden kann. Berechnet wurden jeweils zwei Halbbilder in der vollen Auflösung, so dass in jeder Messung 1400 · 1050 · 2 = 2940000 Primärstrahlen in Richtung des Ebenenstapels geschickt werden. Unabhängig von den Materialeigenschaften waren in allen Messungen die gesamten 6 Ebenen in der Szene definiert, die Materialeigenschaften bestimmten lediglich, wieviele der Ebenen von den Strahlen erreicht werden können. Somit ist der vorgestellte Be- rechnungsaufwand nicht von der Geometrie abhängig, sondern resultiert aus der Anzahl der verfolgten Strahlen. Bei der ersten in Tabelle 6.2 gezeigten Testreihe wurde schrittweise eine Ebene nach der anderen mit transparenten Materialeigenschaften definiert. Als Resultat wurde an jeder transparenten Ebene der Schnitt- punkt lokal beleuchtet und ein zur nächsten Ebene zeigender Transmissionsstrahl erstellt. Die Anzahl der Schattenstrahlen ist dabei identisch mit der Anzahl der gefundenen und berechneten Schnitte. Dadurch, dass für jeden Strahl auch nur ein einziger Sekundärstrahl erzeugt wird, sollte der Berechnungsaufwand linear steigen. Dieses ist auch der Fall, wobei allerdings die extrem hohe Anzahl der Gesamtschnitte auffällt, in diese gehen auch die Schnitte der Hüllvolumen in der Kugelhierarchie ein. Für die Kugeln 6. IMPLEMENTIERUNG ALS BIBLIOTHEK 42 als Hüllvolumen sind die eng aneinander liegenden Ebenen ein sehr ungünstiger Anwendungsfall. Die umgebenden Kugeln umschließen die Ebenen nur sehr ungenau, erzeugen eine große Void Area. Zudem durchdringen sich die Kugeln aufgrund des geringen Abstandes zwischen den Ebenen sehr stark. Mit dem linearen Anstieg der verfolgten Strahlen steigt auch die Berechnungszeit linear. In der zweiten Messreihe wurden ebenfalls immer mehr Ebenen transparent definiert, zusätzlich bekamen sie aber auch reflektierende Materialeigenschaften. An jeder Ebene mit diesen Materialeigenschaf- ten konnten somit beide Arten von Sekundärstrahlen aus einem einfallenden Strahl erzeugt werden, diese wurden dann zwischen reflektierenden Ebenen bis zum Erreichen der maximalen Rekursionstiefe hin- und hergeworfen. Die maximale Rekursionstiefe betrug 5 Rekursionen, bei den zwei erzeugten Sekun- därstrahlen pro Rekursion konnten also maximal 25 = 32 Sekundärstrahlen pro Primärstrahl resultieren. Bei 1400 · 1500 · 2 = 2940000 Primärstrahlen wurden dementsprechend in der Testszene mit maximaler Transparenz und Reflexion 2940000 · 32 = 94080000 Sekundärstrahlen erzeugt. Diese Sekundärstrah- len lösten auch alle eine lokale Beleuchtung inklusive eines Schattenstrahls aus. Die Gesamtanzahl der Sekundärstrahlen verteilt sich wie zu erwarten gleichmäßig auf die zwei Arten der Sekundärstrahlen. Die Berechnungszeit der Szene mit maximaler Anzahl von Sekundärstrahlen steigt ebenfalls annähernd um den Faktor 32 gegenüber der Testzene völlig ohne transparenten und spiegelnden Oberflächen. Die Geometrie war in allen Testzenen identisch, der unterschiedliche Berechnungsaufwand verhielt sich pro- portional zu der Anzahl der verfolgten Strahlen. 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 43

7 Parallelisierung auf den Rechnern des ZIH

In diesem Kapitel soll vorgestellt werden, wie die Bilder durch eine parallelisierte Server-Komponente unter Nutzung der bereits vorgestellten Bibliothek erzeugt werden. Da der beim Ray Tracing verwendete Algorithmus von Natur aus sehr gut zu parallelisieren ist, jedoch eine dynamische Lastverteilung erfordert, wird in diesem Kapitel weniger der Algorithmus, als viel mehr die Realisierung der Lastverteilung unter Berücksichtigung der Einﬂüsse der verwendeten Hardware diskutiert werden. In [Cha02] wird eine kurze aber prägnante Einführung in die üblichen Metriken der Leistungsbewertung gegeben, sowie die Notwendigkeit und der Einﬂuß der Kommunikation während der Berechnung vorgestellt. In dieser Diplomarbeit wird hauptsächlich jeweils der Speedup für die Bewertung betrachtet.

Diese Metrik gibt das Verhältnis von der sequentiellen Ausführungszeit T1 auf einem Prozessor und der Ausführungszeit Tn einer parallelen Berechnung auf n Prozessoren an:

Speedup = T1 Tn

Dieser Wert ist aussagekräftiger als die reinen Ausführungszeiten, da in diesen Wert die Anzahl der verwendeten Prozessoren eingeht. Als bestmöglicher Wert ist dabei der sogenannte lineare Speedup mög- lich. Dieser drückt aus, dass das Problem beim Einsatz von n Prozessoren auch n-mal schneller als im T1 sequentiellen Fall gelöst wurde, die parallele Ausführungszeit somit Tn = n betrug und sich insgesamt ein Speedup von n ergibt. Dieser lineare Speedup ist in der Praxis oftmals nicht realistisch, da eine Parallelisierung nicht ohne einen gewissen Overhead zu realisieren ist. Neben Scheduling müssen die einzelnen Prozesse vor allem in der Regel miteinander kommunizieren, wodurch Wartezeiten entstehen können. Zusätzlich ist nicht jeder Algorithmus beliebig zu parallelisieren, da gewisse Teile der Berechnung ggf. nicht nebenläuﬁg ausgeführt werden können. Dieses wurde als das sogenannte Amdahl’s Law [Amd00] formuliert. Es wird dabei davon ausgegangen, dass jeder Algorithmus aus einem sequentiellen, nicht parallelisierbaren Teil mit der Ausführungszeit s besteht, sowie einem parallelisierbaren Teil mit der Ausführungszeit p auf einem einzelnen Prozessor. Der zuletzt genannte Teil kann von einer Ausführung auf n Prozessoren proﬁtieren, so dass sich, eingesetzt in die Gleichung für den Speedup, nach diesem Gesetz ein maximaler Speedup berechnen lässt:

(s+p) 1 MaximalerSpeedup = p = p s+ n s+ n

Beim Ray Tracing existiert praktisch kein notwendigerweise sequentiell auszuführender Teil im Algo- rithmus. Dadurch kann theoretisch ein linearer Speedup erwartet werden, zusätzlich ist die Parallelisie- rung relativ unaufwändig, da nicht erst parallelisierbare Teile des Algorithmus identiﬁziert oder durch Änderungen des Algorithmus erzeugt werden müssen. Allerdings ist der zusätzliche Overhead durch die Lastverteilung und somit der Kommunikation zu beachten, so dass es im folgenden darum gehen wird, ob ein linearer Speedup erreicht werden kann, mit welchen Ansätzen dieser Speedup erreicht werden kann und vor allem bis zu welchem Grad der Parallelisierung dieses möglich ist. Da die Kommunikation 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 44 das entscheidende Kriterium ist, und die verwendete Hardware unterschiedliche Kommunikationszeiten aufweist, werden Altix und PC-Farm getrennt betrachtet und bewertet.

7.1 Entwicklung auf dem CPU-Set “Neptun” der Altix

Die Entwicklung der Server-Komponente fand ausschließlich auf dem CPU-Set “Neptun” der Altix statt. Dieses CPU-Set ist eine Testumgebung mit 128 Prozessoren, welche ohne Batch-Betrieb nicht exklusiv Prozessoren zuteilt, aber auch keine Rechenzeit in Form von CPU-Stunden berechnet. Somit müssen die Resourcen mit allen Nutzern geteilt werden, was sich in der Praxis jedoch aufgrund der geringen Belegung des CPU-Sets als problemlos erwies. Diese Testumgebung stellte eine dauerhaft zur Verfügung stehende, mit den größeren Partitionen der Altix technisch identische Testplattform dar, so dass während der Entwicklung schon aussagekräftig getestet und gemessen werden konnte. Wie im Abschnitt 4.3 “Parallelisierungsansatz” beschrieben und im Entwurf (Kapitel 5) konkretisiert, ist aufgrund der unterschiedlichen Berechnungszeiten eines Bildpunktes eine dynamische Lastverteilung notwendig. Diese Notwendigkeit wurde anhand der in Abbildung A.9 gezeigten Szene mit zwei Test- servern getestet. Diese Testszene enthält unterschiedliche Primitive und somit unterschiedliche Schnitt- berechnungen sowie spiegelnde Oberflächen und unterschiedliche Textureffekte. Der Berechnung der einzelnen Bildpunkte ist damit nicht identisch. Das erste Testprogramm hat statisch gleichgroße Bildbereiche an die verfügbaren Prozessoren aufgeteilt. Die Anzahl der Bildpunkte wurde dabei zeilenweise und in der oberen, linken Bildecke startend in mög- lichst gleicher Anzahl abgezählt. Somit erhielt jeder Prozess nur einen Arbeitsauftrag, die errechneten Bildpunkte wurden wie im Entwurf beschrieben in einem Master-Prozess gesammelt. Die Zusammen- führung der errechneten Daten wurde mittels MPI_Gatherv() realisiert, da diese Funktion der auf die Architektur optimierten MPI-Bibliothek genau diesen sammelnden Zweck erfüllt und diese Aufgabe effizient leisten sollte. Bei diesem statischen Ansatz findet während der Berechnung keine Lastvertei- lung statt, so dass die Berechnungszeiten nicht durch Kommunikation und dadurch eventuell auftretende Wartezeiten verfälscht werden. Das erste Testprogramm ergab folgende verkürzt dargestellte Programmausgabe: s8142500@neptun:~> mpirun -np 100 Test_mpi Berechnung im Prozess 1: 0s 30902us Berechnung im Prozess 2: 0s 33184us Berechnung im Prozess 3: 0s 35561us ... Berechnung im Prozess 70: 0s 109499us Berechnung im Prozess 69: 0s 109817us Berechnung im Prozess 64: 0s 111305us

Start: 1176798875s 224119us Stop: 1176798875s 338405us Zeit vergangen: 0s 114286us

Dargestellt sind die Berechnungszeiten der zuerst und zuletzt fertig werdenden Prozesse. Der Master- Prozess gibt nach Erhalt der gesamten Daten aus, wie lange die Berechnung und der anschließende Datentransfer in seiner Differenzmessung gedauert haben. 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 45

Speedup für statische und dynamische Lastverteilung

optimal 120 MPI_Gatherv MPI_Send

100

60 Speedup

20 40 60 80 100 120 Anzahl Prozessoren

Abbildung 7.1: Speedup der Testprogramme zur statischen und dynamischen Lastverteilung

Zwei Erkenntnisse wurden aus diesem Testlauf gewonnen. Zuerst ist deutlich zu erkennen, wie unterschiedlich lange die Prozesse an ihrem Arbeitsauftrag rechnen. Die ersten Prozess bekommen Bildpunkte zugewiesen, welche im oberen Bildbereich liegen und nur die Hintergrundfarbe enthalten. Die für diese Bildpunkte entsendeten Strahlen trafen keine Objekte der Szene und dementsprechend musste auch kein Arbeitsaufwand für Relexion oder Texturberechnung bewältigt werden. Die am längsten rechnenden Prozesse bekamen Bildpunkte im zentralen Bildbereich zugewiesen, in welchem mehrere Objekte mit zum Teil spiegelnden Oberﬂächen getroffen wurden. Es ergab sich insgesamt die unbefriedigende Si- tuation, dass manche Prozesse bis zu dreimal so lange rechneten wie die am schnellsten fertig werdenden Prozesse. Auf die am längsten rechnenden Prozesse musste zum Beenden der Bildberechnung gewartet werden, freie Prozesse produzierten anstatt produktiv zu rechnen nur Wartezeit. Der in Abbildung 7.1 dargestellte Speedup ist entsprechend enttäuschend. Die zweite Erkenntnis betrifft das Kommunikationsverhalten zwischen Master und Arbeitsprozessen. Die vom Master gemessene Gesamtzeit der Berechnung liegt nur unwesentlich über der Berechnungszeit des am längsten rechnenden Prozesses. Die Teilergebnisse wurden schon zum Masterprozess gesendet, während andere Prozesse noch mit der Bildberechnung beschäftigt waren. Die gesamte Kommunikati- on der Prozesse wurde also über den Berechnungszeitraum gestreckt und parallel zu den Berechnun- gen ausgeführt. Eine ﬁnale Kommunikation, bei der am Ende der Berechnungen alle Arbeitsprozesse zeitgleich ihre Daten zum Master schicken wollen und somit stoßartig das Netzwerk belegen, wurde vermieden. Dieses Kommunikationsverhalten wurde für die Kommunikation zwischen Anzeigekomponente und Großrechner übernommen. Sobald Daten berechnet worden sind, werden diese zum Anzeigerech- ner übertragen. Ziel ist das Erzeugen eines möglichst gleichmäßigen Datenstroms schon während der 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 46

Berechnung, da die Bandbreite des Netzwerkes zwischen Großrechner und Darstellungskomponente für stoßartig gesendete Gesamtdatenpakete nicht ausreichend ist. Das zweite Testprogramm realisierte die dynamische Lastverteilung mit Blöcken von Bildpunkten als Arbeitspakete in einem Demand-Driven-Ansatz. Sobald ein Prozess seine errechneten Bilddaten beim Master abgab, bekam es ggf. noch zu berechnende Bildpunkte als nächsten Arbeitsauftrag. Die An- zahl der Arbeitsaufträge, der Berechnungsaufwand und die benötigte Berechnungszeit pro Arbeitsauftrag hängen dabei von der Größe der verteilten Blöcke ab. Die Blockgröße bestimmt somit die Anzahl der Kommunikationen bei der dynamischen Lastverteilung. Es ist ein Kompromiss zwischen dem Overhead der Kommunikationen und den im Sinne einer optimalen Lastverteilung möglichst kleinen Arbeitsaufträ- gen zu ﬁnden. Sind die Arbeitsaufträge zu groß, kann der bei der statischen Lastverteilung beobachtete Effekt der unproduktiven Wartezeiten nicht ausgelasteter Prozesse auftreten. Sind die Arbeitsaufträge zu klein, wird unter Umständen mehr kommuniziert und somit Wartzeit erzeugt, als gerechnet. Beim Ray- tracing kann theoretisch jeder Bildpunkt unabhängig von den anderen als Arbeitspaket verteilt werden, was der denkbar kleinsten Granularität der Lastverteilung entspricht. Diese Verteilung ist in der Praxis aufgrund der Kommunikation nicht kostenlos, so dass eine realistische Blockgrösse deutlich größer ist. Im Folgenden soll zunächst die letztendlich verwendete, dynamische Lastverteilung vorgestellt werden. Anschließend wird diskutiert, wie die verwendete Blockgrösse gefunden wurde und wie sie sich letztlich auf die Parallelisierung der Berechnung auswirkt. Die zentrale Komponente bei der Berechnung ist der in Abbildung 7.2 gezeigte Masterprozess. Dieser realisiert die Kommunikation mit der Darstellungsseite und den Arbeitsprozessen, vermittelt die ge- schickten Nachrichten und übernimmt das Scheduling bei der Berechnung. Das Erzeugen eines Bildes beginnt, sobald der Darstellungsrechner einen die Szene verändernden Be- fehl sendet. Solange sich die Szene bzw. der Blickwinkel in die Szene nicht ändert, müssen keine Bilder berechnet werden und die Slaves produzieren solange nur Wartezeit. Verändernde Befehle müssen allen Arbeitsprozessen zugestellt werden, dieses geschieht durch die bei MPI angebotene Broadcast-Funktion (MPI_Bcast()). Diese blockierende Funktion kehrt erst mit einem Rückgabewert zurück, wenn ein Broad- cast empfangen wurde. Mit diesem Verhalten wird das Warten der Slaves realisiert, diese blockieren solange an der Funktion, bis der Master einen Befehl weitergeleitet hat. Nicht alle Befehle erfordern die Berechnung eines Bildes, so warten die Slaves z.B. nach dem Erhalt von zu ladenden Szenendaten auf den nächsten Broadcast. Ist eine Bildberechnung notwendig, weil sich beispielsweise die Kameraposition oder -orientierung geändert hat, ändern sowohl Master als auch die Sla- ves ihr Kommunikationsverhalten von einseitigen Broadcasts auf eine Punkt-Zu-Punkt-Kommunikation zwischen Master und Slaves (MPI_Send() und MPI_Recv()). In diesem Berechnungsmodus vergibt der Master einzelne Arbeitsaufträge direkt an die Slaves und empfängt die berechneten Bilddaten. Um eine initiale Kommunikation zu vermeiden gilt die Vereinbarung, dass die Slaves das erste Arbeitspaket anhand ihres Ranges im Schwarm der verwendeten Prozesse selbst bestimmen und berechnen. So würde z.B. der zehnte Prozess den zehnten von der linken, oberen Bildecke abgezählten Block von Bildpunkten berechnen. Am Ende einer Berechnung komprimiert der Slave seine Bilddaten mit der zlib und sendet die komprimierten Daten an den Master. Der Slave wartet dann durch ein blockierendes MPI_Recv() auf weitere Anweisungen. Der Master empfängt das komprimierte Datenpaket und leitet es ohne weitere Betrachtung direkt an die Darstellungsseite weiter. Die Dekomprimierung ﬁndet dort statt, der Master ist während der Berechnung nur für Scheduling und Weitervermittlung der Daten zuständig. Die Komprimierung direkt 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 47

Master:

While(1) { Auf Befehle vom Client warten; Befehle an Slaves senden (Broadcast);

if (Bildberechnung notwendig) { while (Daten stehen aus) { Daten von Slave erwarten (MPI_Recv); Daten an Client senden;

if (Noch Bildpunkte zu berechnen) Bildpunkte an Slave senden(MPI_Send); } An alle Slaves Stopsignal senden(MPI_Isend); } }

Slave:

While(1) { Auf Befehle vom Master warten (Broadcast);

if (Bildberechnung notwendig) { while (Kein Stopsignal) { Bilpunkte berechnen; Daten komprimieren; Daten an Master senden (MPI_Send);

Auf Bildpunkte/Stopsignal warten (MPI_Recv); } } }

Abbildung 7.2: Pseudocode der dynamischen Lastverteilung, getrennt für Master und Slave 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 48 auf dem Slave schont zudem Bandbreite auf dem Netzwerk des Großrechners. Nach dem Weiterleiten der komprimierten Bilddaten verschickt der Master, sofern noch vorhanden, einen neuen Arbeitsauftrag an den Slave, von dem er soeben Daten empfangen hat. Ein Arbeitsauftrag besteht dabei lediglich aus einer Pixelposition, bei der der Slave mit der Berechnung fortfahren soll. Die Größe dieser Nachrichten ist mit einem int minimal. Wieviele Bildpunkte ein Arbeitsauftrag umfasst, ist vor der Bildberechnung ausgehandelt worden, so dass diese Information allen Prozessen bekannt ist, nicht mit jedem Arbeitsauf- trag verschickt werden muss, während der Berechnung aber auch nicht variiert werden kann. Testweise wurde zur Lastverteilung “Factoring” implementiert [HSF91]. Dieses hatte jedoch nur auf dem Cluster Auswirkungen auf die Berechnungszeiten, und soll somit auch bei den Vergleichsmessungen auf dem Cluster diskutiert werden. Da die Auswirkungen minimal waren, und auf der Altix überhaupt nicht beobachtet werden konnten, wurde der Ansatz dieser Art der Lastverteilung nicht weiter verfolgt. Sind alle Bildpunkte berechnet worden, warten die Slaves weiterhin blockierend am MPI_Recv(). Deswe- gen versendet der Master an sämtliche Slaves eine Stop-Nachricht, nach deren Erhalt die Slaves wieder in die Endlosschleife fallen, in der sie auf Broadcasts des Masters warten. In Abbildung 7.1 ist der Speedup des zweiten Testprogrammes mit dynamischer Lastverteilung dargestellt. Dieser Ansatz war schon deutlich performanter als die statische Lastverteilung, aber schon auf wenigen Dutzend Prozessoren bricht der zunächst linear verlaufende Speedup ein. Vermutet wurde eine unvorteilhafte Blockgröße bei der Lastverteilung, da diese Blockgröße aufgrund der Komprimierung sehr groß gewählt wurde. Der in der zlib verwendete DEFLATE-Algorithmus verwendet neben dem Huffman-Entropiekodierer auch auch eine Substitutionskompression (LZ77), welche mit steigender Grö- ße der zu komprimierenden Daten ein efﬁzienteres Lexikon erzeugt und als Folge dessen bessere Kom- primierungsraten erzeugt. Aufgrund der verhältnismäßig geringen Bandbreite der Verbindung zwischen Anzeigerechner und Großrechner wurde eine möglichst starke Komprimierung angestrebt, und somit die Blockgröße so groß gewählt, dass sie auf dem Großrechner gerade noch zu vertreten war. Ausgehend von den in [NAWAHV06] vorgestellen Messungen von Bandbreite und Latenz auf der Altix wurde eine Blockgrösse von 2500 Bildpunkten gewählt. Bei drei Byte pro Bildpunkt im RGB-Farbformat und aufgrund der gleichzeitigen Berechnung der Bildpunkte in beiden Halbbildern ergibt sich eine Größe der errechneten Bilddaten von 2500 · 3Byte · 2 = 15000Byte. Unterstellt man eine mittlere Komprimie- rungsrate von 0.5 ergeben sich 7500Byte, welche nach den zitierten Messungen die optimale Paketgröße einer Punkt-Zu-Punkt-Kommunikation auf der Altix darstellen. Allerdings ergeben sich bei dieser Block- größe lediglich 1400 · 1050/2500 = 588 zu verteilende Arbeitsaufträge, was für eine Parallelisierung auf mehreren hundert Prozessoren schnell wieder einer statischen Lastverteilung entspricht. Dass diese aus theoretischen Überlegungen entstandene Blockgröße in der Praxis nicht zu halten war, zeigten Messungen mit dem am ZIH entwickelten Vampir[vam]. Dabei werden durch Source-Code- Instrumentierung des Programms bei der Ausführung Trace-Dateien erzeugt, welche anschließend mit Vampir visualisiert werden können. Als Testszene dieser Messungen wurde die Abbildung A.10 gezeigte, minimale Szene mit nur einer lokal beleuchteten Kugel gewählt. Diese Szenen erzeugt nur minimalen Berechnungsaufwand, so dass Bottlenecks bei der Kommunikation der Lastverteilung deutlich zu erkennen sein sollten. In Abbildung 7.3 ist der zeitliche Ablauf einer einzelnen Bildberechnung für die ersten 32 Prozesse zu sehen. Der Masterprozess wartet dabei die meiste Zeit blockierend auf einem MPI_Recv(). Dieses ist der einzugehende Kompromiss, wenn der Master möglichst schnell auf freie Arbeitsprozesse reagieren soll. Bei 120 verwendeten Prozessoren und 588 zu verteilenden Blöcken bekommt jeder Prozess bei unter- 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 49

Abbildung 7.3: Zeitlicher Verlauf der dynamischen Lastverteilung bei der Berechnung eines Bildes einer minimalen Testzene (Abgebildet sind die ersten 32 von 120 Prozessen)

Abbildung 7.4: Verhältnis von Kommunikation zu Berechnung bei der in Abbildung 7.3 gezeigten Bild- berechnung 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 50

Berechnungszeit abhängig von der Blockgröße 440 Komprimiert Unkomprimiert 430

420

410

400

390

Berechnungszeit in ms 380

370

360

350 500 1000 1500 2000 2500 3000 Blockgröße in Bildpunkten

Abbildung 7.5: Berechnungszeit der in Abbildung A.1 gezeigten Szene abhängig von der Blockgröße (Auf 100 Prozessoren) stellter, gleicher Berechnungszeit ca. 5 Blöcke zugewiesen. Die schwarzen Balken symbolisieren in der Visualisierung die Kommunikationen mit dem Master. Fünf deutliche geblockte Kommunikationsinter- valle kennzeichnen die fünf Blöcke, die jeder Prozess im Idealfall erhalten würde. Ab ungefähr der Hälfte der aufgeteilten Blöcke strecken sich die Kommunikationsintervalle jedoch zeitlich. Ab der Hälf- te der aufzuteilenden Bildpunkte wird die Kugel von den erzeugten Strahlen getroffen, so dass hier zum ersten Mal unterschiedlicher Berechnungsaufwand entsteht. Diese Visualisierung unterstreicht die Not- wendigkeit einer dynamsichen Lastverteilung schon anhand einer minimalen Testszene mit nur wenig unterschiedlichem Berechnungsaufwand. Hinsichtlich einer Bewertung der Blockgröße fällt auf, dass selbst bei einer minimalen Testszene und dem daraus resultierenden, minimalen Berechnungsaufwand die Kommunikation bei der Lastverteilung überhaupt nicht relevant ist. Abbildung 7.4 zeigt dieses anschaulich, die Arbeitsprozesse zeigen praktisch kein Kommunikationsverhalten und führen fast ausschließlich Berechnungen aus, obwohl der Berech- nungsaufwand mit maximal einer Schnittberechnung und ggf. anschließender, lokaler Beleuchtung schon minimal ist. Es ist also abzuleiten, dass die optimale Blockgröße der Lastverteilung deutlich unter den aus theoretischen Überlegungen gewählten 2500 Bildpunkten liegt. Wie sich eine Veränderung der Blockgröße auf die Berechnungszeit einer realen Szene auswirkt, wurde anhand der in Abbildung A.1 gezeigten Szene gemessen. Diese Szene beinhaltet mehrere unterschiedliche Primitive, erzeugt Sekundärstrahlen für Reﬂexion und Transmission und greift bei der Berechnung auf Texturen zu. Die Schwankungen des Berechnungsaufwandes sollten in dieser Szene also realistischer als in der minimalen Testszene sein. Durchgängig auf 100 Prozessoren wurden die Berechnungszeiten bei Veränderung der Blockgröße gemessen. 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 51

Speedup bei einer Blockgrösse von 750 Bildpunkten

optimal 120 Realer Speedup

100

60 Speedup

20 40 60 80 100 120 Anzahl Prozessoren

Abbildung 7.6: Speedup bei der Berechnung der in Abbildung A.1 gezeigten Szene mit einer Blockgröße von 750 Bildpunkten auf Neptun

Abbildung 7.5 zeigt deutlich, dass eine Reduzierung der Blockgröße die Berechnungszeit immer mehr reduziert. Besonders erfreulich ist, dass bei sehr kleinen Blockgrößen aufgrund des sehr schnellen Netz- werkes der Altix kein gegenteiliger Effekt eintritt. Es wäre schließlich denkbar, dass aufgrund des ge- steigerten Kommunikationsaufwandes das Netzwerk an seine Grenzen stößt, und die Berechnungszeiten bei kleinen Blockgrößen wieder steigt, so dass eine “Badewannenkurve” zu messen ist. Die Abbildung zeigt ebenfalls, wie minimal der zusätzliche Berechnungsaufwand durch die Komprimierung ausfällt. Als letztendlich verwendete Blockgröße wurden 750 Bildpunkte gewählt, die weiterhin zeilenweise ab- gezählt werden. Eine kleinere Blockgröße wäre nur aus Sicht der Lastverteilung möglich und auch wün- schenswert. Allerdings hatte die zlib bei den Messungen teilweise Probleme mit zu geringen Block- größen, und konnte die entstehende, nur geringe Datenmenge nicht komprimieren. 750 Bildpunkte sind somit schon ein Kompromiss, der allerdings leicht zu akzeptieren war. Abbildung 7.6 zeigt den fast linearen Speedup, der mit dieser Blockgröße bei der Berechnung der gleichen Szene erreicht wurde.

7.2 Vergleichsmessungen auf der Altix und der PC-Farm

Im folgenden werden Messungen vorgestellt, die untersuchen, wie gut der entwickelte Server auf den beiden Systemen skaliert. Durch die unterschiedlichen Netzwerke der beiden Systeme werden voneinander abweichende Ergebnisse erwartet. Auf der Altix sind zudem Messungen auf deutlich mehr als den 120 verwendeten Prozessoren der Testpartition “Neptun” interessant. Dabei soll deutlich werden, bis zu welcher Anzahl an Prozessoren das Programm quasi linear skaliert bzw. ab welcher Anzahl die ermittelte Blockgröße der Arbeitsaufträge wieder nicht ausreichend ist. 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 52

Für die folgenden Messungen wurde der Server modiﬁziert. Da die größeren Partitionen sowie die PC- Farm nicht wie die Testumgebung “Neptun” nach Belieben zu Verfügung standen, sondern im Batch- Betrieb Laufzeiten einplanen, wurde der Server so angepasst, dass er in der Warteschlange auf den Start der Bildberechnung warten kann. Bei einem interaktiven Betrieb, bei dem sich ein Client verbinden muss, um Bilder zu generieren, müssten entweder unabhängig von der Warteschlange CPUs für die Messungen reserviert werden, oder für die Messungen müsste die genaue Startzeit durch das Batch-System bekannt sein. Beides war nicht unaufwändig zu realisieren, das Problem wurde umgangen, indem der Server beim Starten eine statische Testszene erstellt, ein Bild berechnet und komprimiert, und sich dann sofort beendet. Der Prozess der Bilderzeugung verläuft dabei identisch wie bei dem interaktiven Server, lediglich auf die Nutzerinteraktion und den Datentransfer zum Client wurde verzichtet. Dadurch wurde das Programm unabhängig von zeitlich zu koordinierenden Nutzereingaben und konnte somit ohne Kompro- misse in einer Warteschlange auf seine Abarbeitung warten. Der zu messende Berechnungsprozeß eines Bildes mitsamt der Master-Slave-Architektur und der Datenkompression wurde dabei nicht verändert.

7.2.1 Messung auf der Altix

Speedup auf der Altix 180 Ideal Multiple Partitions 160 Single Partition

140

120

100

Speedup 80

0 50 100 150 200 250 300 Anzahl Prozessoren

Abbildung 7.7: Speedup bei der Berechnung der in Abbildung A.9 gezeigten Testzene auf Mars

Abbildung 7.7 zeigt die wenig überraschenden Messergebnisse auf der Altix. Der auf “Neptun” gemessene, fast lineare Speedup auf bis zu 120 Prozessoren wurde auch bei diesen Messungen annähernd erreicht. Bei steigender Anzahl an eingesetzten Prozessoren weichen die Messungen immer mehr vom idealen Speedup ab, was dem in Abbildung 7.1 gezeigten Verhalten entspricht. Dort war die Blockgröße zu groß gewählt, wodurch die dynamische Lastverteilung zu inefﬁzient wurde. Auch bei diesen Messun- gen mit deutlich mehr Prozessoren wird die Last bei gleich bleibender Blockgrösse, und damit statischer Anzahl an Arbeitsaufträgen, aber steigender Anzahl an Prozessoren immer inefﬁzienter verteilt. 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 53

Dennoch bringt der Einsatz von mehr Prozessoren, von Schwankungen abgesehen, bis zu ca. 250 Prozes- soren weiterhin einen Geschwindigkeitsgewinn. Ab dieser Grenze werden vom Scheduler Prozessoren übere mehrere Partitionen hinweg zugeteilt. Die Kommunikation zwischen den einzelnen Partitionen ist dabei nicht so efﬁzient wie die Kommunikation innerhalb einer Partition. Bei einer großen Anzahl von angeforderten Prozessoren können zudem gleich mehrere Partitionen involviert sein, es ist nicht garantiert, dass Partitionen vollständig genutzt und nur die weiteren Prozessoren aus einer anderen Partition zugewiesen werden. Folgende Ausgabe aus der durchgeführten Messung zeigt beispielhaft die Zuwei- sung von 481 Prozessoren (480 Worker, 1 Master) über drei Partitionen:

JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME 390349 s814250 RUN intermedia mars 182*saturn *l 480.txt Oct 11 20:49 256*uranus 43*mars

Dieses erklärt den katastrophalen Speedup ab ca. 250 Prozessoren. Das schnelle NUMAlink-Netzwerk der Altix erlaubt bei der dynamischen Lasterverteilung eine große Anzahl von sehr kleinen Arbeitsauf- trägen, wodurch ein fast linearer Speedup bis über 100 Prozessoren erreicht werden kann. Diese Last- verteilung erweist sich bei der ineffizienten Kommunikation über Partitionsgrenzen hinweg jedoch als Einschränkung. Die Messungen zeigen, dass ein Betrieb über mehrere Partitionen hinweg nicht praktikabel ist. Als spezielle Resourcenanforderung beim Erstellen eines Jobs kann zusätzlich angegeben werden, dass alle angeforderten Prozessoren innerhalb einer Partition liegen sollen. Dieses hat deutliche Auswirkun- gen auf die Wartezeit des Jobs, vermieden wird jedoch die ineffiziente, partitionsübergreifende Kommu- nikation. In Abbildung 7.7 ist eine zweite Messreihe für Single Partition Jobs dargestellt. Der deutliche Einbruch des Speedups wurde vermieden, indem sämtliche Jobs auf den größeren Partitionen mit 512 Prozessoren gestartet wurden. Jedoch skalierte die Bildberechnung nicht beliebig gut auf hunderten Prozessoren und der Speedup sta- gnierte auf gleich bleibendem Niveau. Dieses erschien sehr unplausibel, da Messungen mit dem bereits vorgestellten Analyse-Tool “Vampir” keinen Bottleneck bei der Kommunikation ausmachen konnte. Zu- sätzlich zeigten die Tests mit dem bei den Messungen auf dem Cluster vorgestellten “Factoring” keinerlei Auswirkungen, was bei Latenzproblemen aufgrund von zu vielen, kurzen Nachrichten eigentlich zu erwarten gewesen wäre. Das Problem offenbarte sich in den in Abbildung 7.8 vorgestellten Messungen. In der gezeigten Messrei- he sollte zunächst nur festgestellt werden, welche kleinstmögliche Größe der Arbeitsaufträge das schnelle Netzwerk der Altix zulässt. Für diese Messreihe wurde die Komprimierung der Bilddaten deaktiviert, so dass beliebig kleine Blöcke von Bildpunkten verteilt und berechnet werden konnten. Es ist zu erkennen, dass das latenzarme Netzwerk bei sehr kleinen Aufträgen von 10 Bildpunkten durchaus an seine Grenze stößt. Jedoch erscheinen Arbeitsaufträge von unter 100 Bildpunkten realistisch, was deutlich unter den - durch die Anforderungen der Komprimierung vorgegeben - verwendeten 750 Bildpunkten liegt. Jedoch erzeugen Blockgrößen in der sehr weiten Spanne zwischen 50 und 200 Bildpunkten einen praktisch identischen Speedup. Betrachtet man diese nicht nachvollziehbaren Ergebnisse mit den nicht vorhandenen Auswirkungen von Factoring, kann das Netzwerk als Bottleneck ausgeschlossen werden. Es gab offensichtlich eine feste Einflußgröße, die den Speedup nach oben begrenzte. Letztendlich konnte die Latenz beim Speicherzugriff als verantwortlicher Einfluß identifiziert werden. Eine Modifikation des 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 54

Speedup des Programms ohne Komprimierung 400 Ideal Blockgröße: 10 Bildpunkte Blockgröße: 25 Bildpunkte 350 Blockgröße: 50 Bildpunkte Blockgröße: 100 Bildpunkte Blockgröße: 200 Bildpunkte 200 Bildpunkte, 2.Lauf 300

250

200 Speedup

150

100

0 50 100 150 200 250 300 350 Anzahl Prozessoren

Abbildung 7.8: Durch Speicherlatenz beeinlusster Speedup bei der Berechnung der in Abbildung A.9 gezeigten Testzene auf der Altix mit unterschiedlichen Blockgrößen

Programms, bei der nach dem Laden der Szene mehrere Bilder berechnet werden, erzeugte für das erste Bild eine ca. 20ms längere Berechnungszeit als für die folgenden Bilder. Diese Differenz ist bei einer verhältnismäßig kleinen Anzahl von Prozessoren und daraus resultierende Berechnungszeiten von ca. 1s wenig relevant, so dass der Speedup wie zu sehen nur wenig beeinﬂußt wird. Bei hunderten Prozessoren und Berechnungszeiten von ungefähr 100ms fällt diese Zugriffslatenz jedoch sehr stark auf. Untersucht wurden vermutete Cache-Effekte. Bei der Instrumentierung für eine Analyse mit Vampir wurden als zusätzlich aufzuzeichnende Metriken die L2 Data Cache-Misses mit aufgenommen. Abbil- dung 7.9 zeigt in einem Ausschnitt der Bildberechnung die Anzahl der Cache Misses für die Berechnung des ersten und des zweiten Bildes. Beide Bilder wurden mit der gleichen Ansicht berechnet, so dass ein vergleichbarer Berechnungsaufwand enststeht. Mit nur 10% der Cache Misses in der zweiten Bildberech- nung gab es deutlich weniger Wartezeiten beim Speicherzugriff, so dass, wie in Abbildung 7.8 gezeigt, deutlich bessere Speedupwerte erreicht werden konnten. Dennoch sind auch bei der Berechnung des Bildes deutliche Peaks bei der Anzahl der Cache Misses zu erkennen. Weitere Messungen ergaben, dass diese Peaks immer in unmittelbarer Näher zu den Kommunikationen mit dem Master liegen. Durch diese weiterhin vorhandenen Wartezeiten auf Speicher knickt der Speedup weiterhin ein, allerdings deutlich später. Neben der Anzahl der Cache Misses ist zudem interessant, wie lange im folgenden Nachladen auf den Speicher gewartet werden muss. Vor alle, da die gemesenen ca. 20ms als zusätzliche Berechnungszeit relativ hoch sind. Aufgrund der NUMA-Archtektur der Altix kann der Zugriff auf Speicher unterschiedlich lange dauern [Let, hrs]. Der gemeinsame Speicher ist logisch zwar gemeinsam von allen Prozessoren ansprechbar, physisch jedoch verteilt. Jedem Prozessor steht lokal Speicher zur Verfügung, auf welchen von den anderen Prozessoren über das Verbindungsnetzwerk zugegriffen werden kann. Diese Zugriffe 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 55

Abbildung 7.9: Anzahl der L2 Data Cache Misses bei einem Ausschnit der Berechnung der in Abbil- dung A.9 gezeigten Testzene auf der Altix. Oben: Erste Bildberechnung. Unten: Zweite Bildberechnung mit nur ca. 10% der Cache Misses

über das Netzwerk dauern selbstverständlich länger, als der Zugriff auf den lokalen Speicher. Bei einer optimalen Platzierung der Daten würde jeder Prozess seine Daten im lokalen Speicher des abarbeitenden Prozessors halten, bei dem beobachteten Zugriffszeiten scheint dieses nicht der Fall zu sein. Aufgrund der “First Touch Policy” beim Data Placement auf der Altix wird beim ersten Zugriff auf eine Spei- cherseite die Seite im lokalen Speicher des zuerst zugreifenden Prozessors abgelegt [Vog]. Aufgrund der MPI-Implementierung, bei der jeder Prozess eine identische Kopie der Szene hält und auf diese lokale Kopie zugreift, sollte der Speicherplatz für diese Daten auch im lokalen Speicher allokiert werden. Da- tenmigration und Data Placement auf der Altix waren mit den zur Verfügung stehenden Tools nicht zu messen. Es bleibt festzuhalten, dass die erste Bildberechnung deutlich länger als die folgenden Berechnungen dauert. Auch in den folgenden Bildberechnungen treten deutlich messbare Latenzen beim Speicherzu- griff auf. Diese Latenzen lassen den Speedup bei einer großen Anzahl von Prozessoren einbrechen, das Netzwerk der Altix würde ohne diese Effekte beim Speicherzugriff noch weitere Geschwindigkeitszu- wächse erlauben.

7.2.2 Messung auf der PC-Farm “Deimos”

Die, verglichen mit den auf der Altix gemessenen Werten, wenig überzeugenden Messergebnisse sind in Abbildung 7.10 zu sehen. Der auf wenigen Dutzend Prozessoren zunächst noch beinahe lineare Speedup ist mit steigender Prozessoranzahl nicht zu halten. Dennoch sind bis zu ca. 100 Prozessoren Geschwin- digkeitsgewinne zu verzeichnen, ab dieser Grenze stagniert der Speedup jedoch. Der Einsatz weiterer Prozessoren lohnt sich ab dieser Grenze nicht mehr, es scheint einen Bottleneck bei der Kommunikati- 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 56

Speedup auf der PC−Farm Deimos 100 Ideal Blockgröße: 750 90 Factoring

50 Speedup 40

0 50 100 150 200 Anzahl Prozessoren

Abbildung 7.10: Speedup bei der Berechnung der in Abbildung A.9 gezeigten Testzene auf Deimos on zu geben. Bei dem eingesetzten InﬁniBand-Netzwerk hängen die Endknoten in einer über Switches kommunizierenden Umgebung [Pﬁ01]. Der Master-Slave-Ansatz erzeugt dabei sehr viel Kommunikation zwischen dem Master und den arbeitenden Knoten, jedoch keinerlich Kommunikation zischen den einzelnen Arbeitern. Die vernetzte Umgebung kann somit in keinster Weise vollständig ausgenutzt werden, die gesamte Kommunikation konzentriert sich dabei auf den Link zwischen Master-Knoten und seinem anbindenden Switch, sowie dem Verbindungsnetzwerk zwischen den einzelnen Switches. Wie in Abbil- dung 3.2 gezeigt, variieren die zurückzulegenden Kommunikationswege stark. Innerhalb eines Switch sind geringe Kommunikationszeiten möglich, kommunizieren Knoten jedoch switchübergreifend, müs- sen die Nachrichten zunächst zum anbindenden Switch des Zielknotens transportiert werden. Sind die rechnenden Knoten nicht an den selben Switch wie der Knoten des Master-Prozesses angebunden, ist dieses aufgrund der dynamischen Lastverteilung mit den vielen Nachrichten für die Arbeitsaufträge sehr oft der Fall. Folgende (verkürzte) Darstellung zeigt die vom Batch-System zugeteilten Knoten für 150 Prozessoren in der in Abbildung 7.10 aufgeführten Messungen:

Job was submitted from host by user . Job was executed on host(s) <2*p2s129>, in queue , as user . <2*p2s020> <2*p1s058> ... <2*p2d020> <1*p1s075> <1*p2s169> <2*p2d032> ... was used as the home directory. was used as the working directory. 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 57

An dieser Berechnung auf 150 Prozessoren waren über alle Switches verteilte Knoten beteiligt. Um mit dem Master zu kommunizieren waren somit viele Kommunikationen über das switchverbindende Netzwerk notwendig, die latenzarmen Kommunikationsmöglichkeiten innerhalb eines Switch konnten selten ausgenutzt werden, da die Arbeiter nicht untereinander Nachrichten austauschen. Der Ansatz der Lastverteilung mit den vielen aber sehr kurzen Nachrichten stößt auf dem Cluster mit den höheren Latenzzeiten an seine Grenzen. Am Ende der Bildberechnung ist diese häuﬁge Zuweisung von kleinen Arbeitsaufträgen unabdingbar, da nur so ein möglichst gleichzeitiges Berechnungsende aller eingesetzten Prozessoren garantiert werden kann. Zu Beginn der Berechnung ist diese Lastverteilung allerdings viel zu feingranular. Es ist schließlich nicht notwendig, dass während der Berechnung schon ein Angleichen der Berechnungszeiten stattﬁndet. Es wäre eher anzustreben, dass zu Beginn sehr große Arbeitsaufträge zugestellt werden, so dass verhältnismäßig lange ohne Kommunikation gerechnet werden kann. Die dadurch nicht zu vermeidenden, stark unterschiedlichen Berechnungszeiten müssen dann jedoch am Ende der Berechnung wieder ausgeglichen werden. Dieser Ansatz ist in der Literatur unter dem Begriff “Factoring” [HSF91] bekannt. Wie sich diese Art der Lastverteilung mit Arbeitsaufträgen sich verringenderer Größe auf die Berech- nungszeiten auswirkt, wurde mit einer minimalen Implementierung von Factoring untersucht. Dadurch, dass aufgrund der Datenkompression die Größe der Arbeitsaufträge nicht beliebig klein gewählt werden kann, lag der kleinste Arbeitsauftrag weiterhin bei einer Größe von 750 Bildpunkten. Dieses entspricht nicht dem originalen Ansatz des Factorings, bei dem die Arbeitsaufträge bis zu einer minimalen Grö- ße von einem Bildpunkt reduziert werden müssten, um am Ende der Berechnung die schwankenden Berechnungszeiten optimal ausgleichen zu können. Bei der gewählten Implementierung wurden initial 2500 Bildpunkte verteilt, sobald alle beteiligten Prozesse ein Teilergebnis geliefert hatten, wurde die Anzahl der zu berechnenden Bildpunkte halbiert. Die erzielten Ergebnisse wurden ebenfalls in Abbildung 7.10 aufgetragen. Auf dem Cluster wurde mit Factoring ein höherer Speedup erreicht, die Stagnation des Speedups konnte jedoch auch nicht mit dieser Art der Lastverteilung vermieden werden. Da auf der Altix keine positiven Auswirkungen beobachtet werden konnten, generell aber ein Betrieb auf der Altix anzustreben ist, wurde die Testimplementierung des Factoring nicht übernommen. In den bisherigen Arbeiten wurde ein vergleichbarer Ansatz erstaunlich selten angewendet, obwohl gerade bei älteren Arbeiten aufgrund von weniger performanten Netzwerken die Latenzzeiten noch domi- nierender waren. Überwiegend bestanden die Aufträge aus kleinen aber konstanten Blöcken von Bild- punkten. Ausdrücklich erwähnt wird eine (lineare) Verkleinerung der Arbeitsaufträge während der Berechnung auf Maschinen mit gemeinsamen Speicher [PSL+98, PMS+99]. Dadurch, dass Bildbereiche, welche in vorherigen Bildberechnungen den größten Berechnungsaufwand erzeugten, zuerst als Aufträge ausgegeben wurden, traten in [WSBW] die größten Berechnungszeiten ähnlich dem Factoring zu Beginn der Bildberechnung auf. Um speziell auf Clustern den Flaschenhals bei der Kommunikation aller Arbeiter mit dem Master zu vermeiden, wurde in [DGBP05] eine Auftragsvergabe untersucht, bei der initial jedem Prozess quasi statisch eine Anzahl an Aufträgen zugewiesen wird. Hat ein Prozess seine Aufträge erledigt, fordert dieser bei einem zufälligen Arbeitsprozess noch ausstehende Arbeit an. Dadurch wird die Kommunikation in Richtung des Master auf die beteiligten Arbeitsprozesse verteilt. Da in dieser Diplomarbeit allerdings der 7. PARALLELISIERUNG AUF DEN RECHNERN DES ZIH 58

Master die Daten an die Darstellungsseite weiterleitet, ist der Master-Slave-Ansatz zwingend. Es ist auch fraglich, ob bei Anfragen an zufällige Arbeitsprozesse eine gleichmäßige Verteilung der Last garantiert ist.

7.3 Zusammenfassung und Bewertung

Auf dem Test-Set “Neptun” der Altix wurde zunächst die Notwendigkeit einer dynamischen Lastver- teilung bestätigt und die anzustrebende Größe der zu verteilenden Arbeitspakete bestimmt. Als Resultat konnte auf den 120 Prozessoren ein fast optimaler Speedup erreicht werden, was den theoretischen Über- legungen zum Parallelisierungspotential von Ray Tracing entspricht. Für Vergleichsmessungen auf dem Cluster und größeren Sets der Altix wurde das Programm soweit von der Nutzerinteraktion und Kommunikation mit der Darstellungsseite unabhängig gemacht, dass es für die Bildberechnung inklusive Datenkompression in die Warteschlangen des auf den Rechnern laufenden Batch-Systems gestellt werden konnte. Die zu bewertende Parallelisierung blieb dabei völlig identisch zum interaktiven Server. Die Ergebnisse zum Berechnungsprozess sind somit aussagekräftig, was sich auch in den identischen Ergebnissen auf bis zu 120 Prozessoren zeigt. Bei den Messungen auf der Altix stellte sich heraus, dass der lineare Speedup nicht auf beliebig vielen Prozessoren aufrecht erhalten werden kann. Beim Einsatz von bis zu 200 Prozessoren ergaben sich noch Geschwindigkeitsvorteile, bei mehr Prozessoren zeigten sich dann jedoch zwei Probleme. Zum einen werden ab ca. 250 Prozessoren mehr als nur ein CPU-Set verwendet. Aufgrund der sehr häuﬁgen Kom- munikationen während der Berechnung und einer vergleichsweise schlechten Vernetzung der einzelnen Partitionen werden so nur unzureichende Berechnungszeiten erzielt. Durch eine explizite Resourcenan- forderung kann die Berechnung auf einer einzigen Partition ausgeführt werden, jedoch liegt die maximale Anzahl der nutzbaren Prozessoren dann bei der Größe der größten Partition (512 Prozessoren). Die Ergebnisse auf dem Cluster sind wenig überzeugend. Der Ansatz der dynamischen Lastverteilung sieht vor, dass sehr viele Arbeitsaufträge vom Master an die Arbeiter geschickt werden, was einen hohen Kommunikationsaufwand erzeugt. Dieses ist kein günstiger Anwendungsfall für das, verglichen mit der Altix, weniger performante Netzwerk und der sehr konzentrierten Kommunikation am Masterprozess. Durch “Factoring” wurde die Anzahl der Arbeitsaufträge reduziert, was sich auch in kürzeren Bear- beitungszeiten bemerkbar machte. Dennoch waren die erzielten Ergebnisse nie mit denen auf der Altix vergleichbar, die Altix ist dem Cluster eindeutig vorzuziehen. Eine Konzentrierung auf die Altix ist, zusätzlich zum höheren Speedup und geringeren Latenzzeiten, auch aufgrund des gemeinsamen Speichers sinnvoll. Die auf dem Cluster unvermeidbare Kommunikati- on über Nachrichten mit dem Bottleneck am zentralen Master könnte vermieden werden. Es wäre eine Queue mit Aufträgen im gemeinsamen Speicher denkbar, auf den alle Threads zugreifen. Zwar müssten Zugriffe auf diese Queue synchronisiert werden, jedoch würde die Situation vermieden, in der hunderte Threads auf die Anwortnachricht eines einzelnen Masters warten müssten. Das Zurückschreiben der berechneten Daten könnte zudem völlig synchronisationslos geschehen, da die Threads nicht auf gleiche Speicherbereiche schreiben. Zusätzlich könnte die in dieser Arbeit sehr inefﬁziente Szenenorganisation mit n identischen Kopien bei n Arbeitern vermieden werden. Da nur lesend auf die Szene zugegriffen wird, wäre eine einzige, synchronisationslose Kopie im gemeinsamen Speicher möglich, was der optimalen Datenhaltung entspricht. 8. DARSTELLUNG AUF DER POWERWALL 59

8 Darstellung auf der Powerwall

Die Darstellungsseite hat lediglich drei Aufgaben: Die vom Großrechner gelieferten Bilder auf der Po- werwall darzustellen, die Nutzerinteraktion zu gewährleisten und an die Berechnungsseite weiterzuleiten sowie das Laden und Übermitteln von Szenendaten.

8.1 Bildausgabe mit OpenGL

Die Darstellung erfolgt dabei wie in 3.1 bereits beschrieben über zwei Projektoren, welche die zwei Halb- bilder über einen Umlenkspiegel auf die Projektionsfläche projezieren. In dem auf dem Anzeigerechner laufenden Windows XP werden dafür zwei Monitore konfiguriert, welche jeweils die gewünschte Auf- lösung von 1400x1050 Bildpunkte aufweisen. Für die Anzeige wird dann in Windows der Bildbereich auf die doppelte horizontale Auflösung gestellt, so dass sich insgesamt eine Darstellung von 2800x1050 Bildpunkten ergibt. Das Betriebssystem teilt das dargestellte Bild automatisch auf die beiden Ausgabe- geräte auf. Der selbst entwickelte, darstellende Client erzeugt mit der Win-API ein Fenster im Vollbildmodus, welches sich ebenfalls über diesen Bildbereich erstreckt. Als Grafikbibliothek wird OpenGL verwendet, wobei ein einziger Viewport mit der oben erwähnten, doppelten horizontalen Auflösung erstellt wird. Zwei Texturen, jeweils eine pro Halbbild, werden auf zwei nebeneinander angeordnete, rechteckige Polygone (GL_QUADS) gemapt, welche direkt an die Near Clipping Plane gesetzt wurden. Die Darstellung reduziert sich somit auf das Übertragen von Daten für die beiden genannten Texturen, welche dann jeweils die alten Daten überschreiben. Diese Aktualisierungen der Texturen müssen jedoch bei jeder Bildübertragung erfolgen und somit müs- sen bei jedem neuen Bild die Daten möglichst schnell über den PCIe-Bus. Diese Situation entwickelte sich zu einem limitierenden Faktor, da die genannten Updates erst nach dem beendeten Übertragungs- vorgang der Daten vom Großrechner erfolgen kann, und der Texture Download auf die Grafikkarte somit als fixes Zeitintervall auf die gesamte Berechnungszeit addiert werden muss. Als Beschleunigung des Vorganges wurde die OpenGL-Erweiterung der Pixel Buffer Objects (PBO) verwendet [pbo]. Ziel dieser Erweiterung ist es, langsame Kopieroperationen durch schnelle DMA-Transfers von großen Datenmengen zu vermeiden. Dabei registriert man sich einen Puffer, der vor Schreiboperatio- nen in das eigene Programm eingeblendet wird. Durch das Einblenden erhält man einen Zeiger auf den zu beschreibenen Datenbereich. Nach dem Schreiben der Daten, wird der Puffer wieder ausgeblendet, wodurch die Daten schnellstmöglich vom Treiber auf die Grafikkarte transportiert werden. Ein anschlie- ßender Aufruf von beispielsweise glTexImage2D() bezieht seine Daten dann aus diesem Puffer, sofern man bei dem Aufruf den Parameter für den Datenbereich auf NULL setzt. Diese Optimierung hatte zunächst wenig Auswirkungen, erst ein paralleler Datentransfer durch zwei PBOs (für jede Textur jeweils ein PBO) reduzierte die Übertragungszeit um die Hälfte auf ca. 10ms. Bei 8. DARSTELLUNG AUF DER POWERWALL 60 einer Datenmenge von 2 · 1400 · 1050 · 3 ≈ 8.4MB ergibt dieses eine Übertragungsrate von ca. 841MB/s. Eine inkrementelle Aktualisierung der Texturen mittels beispielsweise glTexSubImage2D() wurde aus zwei Gründen ausgeschlossen: Zum einen aktualisiert die genannte Funktion quadratische Unterbereiche der Textur, was nicht der zeilenweisen Berechnung der Texturen entspricht. Zum anderen sind die PBOs auf den Transfer großer Datenmengen ausgelegt.

8.2 Nutzerinteraktion

Nutzereingaben werden über Maus und Tastatur realisiert. Dabei stellte sich heraus, dass die Zustellung der Tastatureingaben über die Nachricht WM_KEYDOWN der Win32-API in keinster Weise den Ansprü- chen gerecht wurde. Die Nachrichten wurden mit einer zu kleinen Frequenz zugestellt, so dass die Ta- statureingabe nicht ﬂüssig genug realisert werden konnte. Vor allem aber wurde bei gedrückt gehaltener Taste zunächst nur eine Nachricht zugestellt, und erst nach einem gewissen Zeitintervall die folgenden, was sich in einem Ruckler am Anfang einer Kamerafahrt bemerkbar machte. Aus diesen Gründen wurde die Tastatureingabe auf DirectInput umgestellt. Durch die schnelle Abfolge von kurzen Steuerinformationen ergab sich für die Kommunikation mit dem Großrechner ein Problem mit der TCP-Implementierung. Eigentlich als Optimierung gedacht, sammelt der dort implementierte Nagle-Algorithmus (Siehe RFC896 “Congestion Control in IP/TCP Internet- works”) kleine Nachrichten zunächst und verschickt sie unter Umständen erst nach einer gewissen Zeit gemeinsam in einem größeren TCP-Paket. Dieses Verhalten mag in anderen Anwendungen efﬁzienter sein, bei dem geforderten Echtzeitverhalten, bei dem die Steuernachrichten schnellstmöglich übertragen werden sollen, erzeugt dieses nur unnötige Wartezeit. Gemessen wurden nicht unerhebliche Verzöge- rungen von ca. 40ms für die Steuerinformationen. Deswegen wurde der Algorithmus für diese kurzen Nachrichten sowohl im Client, als auch im Server mit dem Flag TCP_NODELAY im setsockopt()-Call deaktiviert.

8.3 Bandbreite und Latenz

Für die 1Gb-Leitung zum Großrechner wurden die Latenz und die Bandbreite gemessen. Das standard “ping”-Programm ermittelte über das Internet Control Message Protocol (ICMP) Antwortzeiten von 0,534ms. Da die reale Kommunikation jedoch über TCP realisiert wird, wurde in einem simplen Testprogramm eine 1Byte-Nachricht verschickt, die von der Gegenstelle sofort beantwortet wurde. Hier ergab sich eine Antwortszeit von 0,466ms. Bei der Kommunikation zwischen Darstellungsseite und Großrechner werden durch die Bilddaten große Datenmengen ausgetauscht, ein TCP-Paket hat jedoch maximal nur eine verhältnismäßig kleine Größe von 65KB. Durch die in RFC1323 - “TCP Extensions for High Performance” vorgestellte Erweiterung kann die Fenstergröße jedoch erhöht werden, was den oben geschilderten Anwendungsfall efﬁzienter abbildet. Voraussetzung ist, dass diese Erweiterung von den TCP-Implementationen der Betriebssysteme unterstützt wird, was bei den eingesetzten Linux- und Windows-Systemen der Fall ist. Über den Aufruf von setsockopt() mit den Flags SO_SNDBUF und SO_RCVBUF werden auf beiden Kommunikationssei- ten vor dem Verbinden die maximalen Größen der Eingabe- und Ausgabepuffer gesetzt. Anhand dieser Größe wird beim Verbinden durch die TCP-Implementierung die maximale Fenstergröße ausgehandelt. 8. DARSTELLUNG AUF DER POWERWALL 61

Wieviel reale Bandbreite nach den oben genannten Einstellungen zur Verfügung steht, wurde zunächst mit dem Benchmark “Netio” [net] gemessen. Für einen Test über das TCP-Protokoll, gestartet auf dem Client und verbunden zur Altix, ergab sich folgende Ausgabe:

TCP connection established. Packet size 1k bytes: 67556 KByte/s Tx, 94639 KByte/s Rx. Packet size 2k bytes: 65874 KByte/s Tx, 84693 KByte/s Rx. Packet size 4k bytes: 81507 KByte/s Tx, 86671 KByte/s Rx. Packet size 8k bytes: 78920 KByte/s Tx, 89275 KByte/s Rx. Packet size 16k bytes: 73756 KByte/s Tx, 90700 KByte/s Rx. Packet size 32k bytes: 75747 KByte/s Tx, 91395 KByte/s Rx. Done.

Der Testlauf kam also zu dem Ergebnis, unabhängig von der Paketgrösse ca. 90MB/s vom Server zu empfangen. Dieses erschien unrealistisch, ein Blick in den Quelltext des Programmes offenbarte, dass die Paketgröße lediglich der Größe der Daten entspricht, die mit einem send()-Aufruf verschickt werden. Die maximale Größe des TCP-Fensters bleibt unverändert auf ca. 130KB. Da mit diesem Programm nicht die gewünschten Parameter gemessen werden konnten, wurden in einem simplen Testprogramm zehn Sekunden lang unterschiedlichen Fenstergrößen Dummy-Daten verschickt. Der empfangene Client hat dabei die Daten nur angenommen aber in keinster Weise verarbeitet, so dass es sich bei folgenden Messergebnissen um eine reine Bandbreitenmessung handelt:

TCP-Window (max) Bandbreite 50KB 70,5MB/s 100KB 91,9MB/s 150KB 100,7MB/s 200Kb 97,2MB/s

In diesem Zusammenhang sind die Ergebnisse von Netio mit einer Fenstergrösse von 130KB wieder plausibel. Client und Server verwenden aufgrund der gemessenen Daten beide eine Fenstergröße von 150KB. Real erreicht werden aufgrund der initialen Berechnungen auf dem Server und Verzögerungen durch Texture Download und Dekomprimierung ca. 73MB/s.

8.4 Szenenorganisation

Wie im Entwurf beschrieben, werden die Szenen und die dazugehörigen Daten auf der Darstellungsseite abgelegt und bei Bedarf temporär auf den Server geladen. Die Szenendeﬁnition erfolgt im XML-Format, welches unter der Nutzung von TinyXML [tin] geladen wird. Neben der Flexibilität bei der Deﬁnition verschiedener Elemente erlaubt XML vor allem eine Hierarchisierung der Elemente. Diese Eigenschaft wurde verwendet, um einen Szenengraphen mit Transformationsknoten zu realisieren. 8. DARSTELLUNG AUF DER POWERWALL 62

Folgende Szenendatei würde beispielsweise die ersten 5 Kugeln der in Abbildung A.3 gezeigten Kugel- helix deﬁnieren:

Alle Objekte in der Szene sind dabei Kindelemente von “Scene”. Die Art der Attribute sind dabei abhän- gig vom Szenenelement. Eine weitere Hierarchisierung ﬁndet nur noch an Transformationsknoten statt. Alle Transformationen der Transformationselemente werden auf alle eingeschlossenen Szenenelemente angewendet, sowie auch auf alle tieferen Hierarchiestufen. Implementiert wurde dieses mit einem Transformationsstack auf dem Server. Initialisiert wird der Stack mit einer Einheitsmatrix als Ausgangstransformation. Sobald ein Transformationsknoten auf dem Client gelesen wird, wird dem Server signalisiert, die oberste Transformation auf dem Transformationsstack zu kopieren und die Kopie auf den Stapel zu legen. Alle Transformationen aus den Attributen des gerade betrachteten Transformationsknotens werden dieser Transformation durch Multiplikation hinzugefügt. Danach werden alle Kinder des Knotens geladen. Mit dem schließenden Tag wird dem Server signalisiert, die oberste Transformation vom Stapel zu löschen. Auf alle Szenenelemente wird beim Erstellen die oben auf dem Stack liegende Transformation angewendet. Zum Laden von Texturen und Dreiecksnetzen wurden in der Klasse SceneLoader Methoden zum Lesen von Truevision TGA-Dateien und Wavefront OBJ-Dateien implementiert. Beide Dateiformate sind auf ihre Weise vergleichsweise simpel und somit verhältnismäßig leicht zu lesen. Die Loader erheben keinen Anspruch auf Vollständigkeit, da sie hinsichtlich der Anforderungen dieser Arbeit entwickelt wurden. So lädt der Texturloader nur quadratische Texturen, und der OBJ-Loader lädt ausschließlich Dreiecksnetze.

8.5 Messung und Bewertung des Gesamtsystems

Anhand der bereits für Messungen verwendeten Szenen (Abbildung A.1 und Abbildung A.10) soll nun vorgestellt werden, wie sich die Darstellungsseite bei der Erzeugung und Anzeige eines Bildes verhält, 8. DARSTELLUNG AUF DER POWERWALL 63

Server: Berechnung Berechnung Berechnung ... Berechnung

Client: Interaktion Verarbeitung Verarbeitung Verarbeitung ... Verarbeitung Anzeige

Header lesen Daten lesen Dekomprimieren Daten kopieren Texture Download Display

Abbildung 8.1: Teilschritte des Erzeugungs- und Darstellungsprozesses eines Bildes und wie der gesamte Bilderzeugungsprozess zu bewerten ist. Nachdem der parallelisierte Berechnungs- prozess auf dem Server bereits in Kapitel 7 untersucht wurde, werden sich die Messungen auf die Teilauf- gaben des Clients und die Tragfähigkeit des Ansatzes der schrittweisen Kommunikation konzentrieren. In Abbildung 8.1 ist der Berechnungsprozess schematisch dargestellt. Da Bilder nur berechnet werden, wenn sich etwas an der Szene oder dem Blickwinkel geändert hat, wird die Bilderzeugung mit der In- teraktion des Nutzers gestartet, welche an den Server geschickt wird. Dieser beginnt daraufhin mit der parallelen Berechnung von in Blöcken zusammengefassten Bildpunkten. Sobald ein Block von Bildpunk- ten berechnet wurde, wird dieser komprimiert vorliegende Block als Teilergebnis an den Client gesendet. Diese Blöcke entsprechen den Arbeitspaketen der dynamischen Lastverteilung auf dem Server und werden somit über die gesamte Dauer der Berechnung verteilt erzeugt. Die Übertragung der Ergebnisse an den Client kann somit gleichmäßig während der Bildberechnung erfolgen, wodurch die verhältnismäßig geringe Bandbreite der Anbindung effizienter ausgenutzt werden kann. Aufgrund der Datenkompression ist nach dem Erhalt der Datenpakete auf dem Client ein Verarbeitungs- schritt notwendig. Je nach Bildbereich können die Bilddaten unterschiedlich effizient komprimiert werden, so dass die komprimierten Teilergebnisse jeweils eine unterschiedliche Größe haben können. Ein Header am Anfang jeder Nachricht gibt an, wieviele Daten folgen und zu lesen sind. Diese Header wird zunächst vom Socket gelesen und ausgewertet, danach werden den Daten des Headers entsprechend die komprimierten Bilddaten gelesen. Die im nächsten Schritt dekomprimierten Bilddaten müssen final an ihre Position im Bild kopiert werden. Da die Erzeugung einzelner Bildbereiche unterschiedliche Berech- nungszeiten verursachen können, ist die Reihenfolge der eintreffenden Bilddaten nicht vorhersagbar. Ebenfalls im Header wird die Position der Bilddaten übermittelt, die Bildpunkte werden entsprechend in einem Puffer für die Textur zusammengesetzt. Liegen alle Bildpunkte vor, wird das Bild, wie in diesem Kapitel beschrieben, als Textur auf die Gra- fikkarte geladen und dargestellt. Dieser letzte Schritt kann nicht parallel zu den Berechnungen auf dem Server ausgeführt werden, so dass der Zeitbedarf für diese Darstellung immer zusätzlich zu der Berech- nungszeit in die Gesamtzeit eingeht. Um zumindest auf dem Server während dieser Darstellung keine Wartezeit zu erzeugen, werden eventuell noch vorliegende Transformationsbefehle vom Server schon bearbeitet. In Tabelle 8.1 werden Messungen der beschriebenen Teilschritte zusammengefasst. Sämtliche Messun- gen wurden als Zeitdifferenzmessung mit der rdtsc-Instruktion durchgeführt. Der Time Stamp Counter 8. DARSTELLUNG AUF DER POWERWALL 64

Standardtestszene (Abbildung A.1) Minimale Testszene (Abbildung A.10) Gesamtzeit Server 346, 079ms 17, 115ms Gesamtzeit Client 360, 567ms 52, 778ms Zusammensetzung “Gesamtzeit Client” Texture Download 11, 618ms 11, 080ms Verarbeitung 125, 129ms 35, 709ms Zusammensetzung “Verarbeitung” Header lesen 20, 454ms 10, 576ms Daten lesen 58, 690ms 2, 710ms Dekomprimieren 43, 279ms 19, 292ms Daten kopieren 2, 591ms 3, 032ms

Tabelle 8.1: Messdaten des in Abbildung 8.1 vorgestellten Berechnungsprozesses (120 Prozessoren) des x86-Prozessors wird intern bei jedem Takt inkrementiert, die genannte Instruktion liest den Zähler aus. Durch diesen Zähler werden auf dem eingesetzten 2,4GHz-Prozessor sehr genaue Messungen mit einer Auflösung unter einer Nanosekunde möglich. Die erste betrachtete und in Abbildung A.1 gezeigte Testzene erfordert einen verhältnismäßig großen Berechnungsaufwand. Dementsprechend ist zu erwarten, dass die Kommunikation zwischen Client und Server über den verhältnismäßig langen Berechnungszeitraum gestreckt werden kann, gleiches gilt auch für die Verarbeitungsschritte auf dem Anzeigerechner. Wie der Tabelle 8.1 zu entnehmen ist, liegt die im Client gemessene Berechnugszeit nur ca. 14ms über die auf dem Server für die Berechnung gemessene Zeit, was fast dem nicht zu vermeidenden, finalen Texture Download mit ca. 11ms entspricht. Der Client misst dabei die Zeit, die vom Absenden der Nutzerinteraktion bis zur vollendeten Anzeige vergeht, so dass in den verbleibenden 2, 87ms noch die nicht gemessene Latenz für die startende und beendende Kommunikation zwischen Client und Server eingeht. Außerdem wird im Server die Zeit zwischen dem Berechnungsbeginn und dem letztem, sendenen Aufruf auf das Socket gemessen, welcher sofort zurückkehrt und nicht bis zum Abschluß der Kommunikation blockiert. Wie schnell die Socket- Implementierung diese letzten Daten versendet, ist ebenfalls nicht zu bestimmen, und neben der Latenz geht somit noch etwas Übertragungszeit mit ein, so dass die 2, 87ms zwar nicht eindeutig zuzuordnen, aber auch nicht unplausibel sind. Insgesamt kann für diese Testszene festgehalten werden, dass die Zeitdifferenz zwischen der auf der Dar- stellungsseite gemessenen Gesamtzeit und der reinen Berechnungszeit auf dem Server fast ausschließlich durch den Texturtransfer entsteht. Die verhältnismäßig geringe Bandbreite der Verbindung zwischen den beiden Komponenten wird bei dieser Szene in keinster Weise zu einem limitierenden Faktor, da die Kom- munikation schon während der Berechnung erfolgen kann. Die auf dem Client notwendigerweise aus- zufürenden Verarbeitungsschritte machen mit ca. 125ms zudem nicht einmal die Hälfte der Gesamtzeit aus, so dass auf dem Client noch über die Hälfte der Zeit gewartet wird, der Anzeigerechner also nicht vollkommen ausgelastet ist. Für Szenen mit verhältnismäßig große Berechnungszeiten wird die auf dem Client unvermeidbare, sequentielle Dekomprimierung der auf dem Server parallel komprimierten Daten- blöcke also nicht zu einem Bottleneck. Die Kompressionsraten schwankten in dieser Szene aufgrund der Texturierung je nach Ansicht sehr stark. Bei einem deutlichen Anteil des eintönigen Hintergrundes am Gesamtbild, dieser Fall ist sehr günstig für die in der zlib verwendete Substitutionskompression, wurden die Bilddaten auf bis zu einem Drittel der ursprünglichen Größe reduziert. Bei einem großen Anteil von 8. DARSTELLUNG AUF DER POWERWALL 65 texturierten Objekten in der Ansicht wurden die Daten lediglich auf zwei Drittel reduziert, da wenig identische Bildbereiche entstehen. Als minimale Testzene wurde erneut die in Abbildung A.10 gezeigte, nur lokal beleuchtete Kugel verwendet. Mit einer Schnittberechnung plus Schattenstrahl pro Primärstrahl und keinen rekursiv betrachteten Sekundärstrahlen erzeugt sie den minimalsten Berechnungsaufwand. Außerdem stellt diese Szene bezüglich der Datenkompression das gegenteilige Extrem zu der zuvor diskutierten, texturierten Test- szene dar. Ein großflächiger Hintergrund und gleichfarbige Farbverläufe auf der Kugel ermöglichen eine effiziente Datenkompression. Dementsprechend wurden die Bilddaten während der Messung auf 1% bis 10% der ursprünglichen Datenmenge reduziert. Wie der Tabelle 8.1 zu entnehmen ist, liegt die benötigte Zeit für die Dekomprimierung jedoch deutlich unter der Dekomprimierungszeit für die erste Testzene mit geringeren Kompressionsraten. Die Berechnungszeit von ca. 17ms für eine einzige Kugel erschien unplausibel, verglichen wurde mit einer völlig leeren Szene, in der für jeden Primärstrahl kein Schnitt berechnet werden muss und somit nur die Hintergrundfarbe gesetzt wird. Gemessen wurde eine Berechnungszeit von 14, 11ms, der gesamte Berechnungsaufwand entfällt bei einer leeren Szene auf das Erzeugen der Primärstrahlen durch die Kameras. Jeder Primärstrahl wird dabei direkt nach dem Erzeugen normiert, da von dieser Be- dingung bei der lokalen Beleuchtung und beim Kugelschnitt ausgegangen wird. Das Normieren erfordert das Ziehen der verhältnismäßig aufwändig zu berechnenden Quadratwurzel, so dass insgesamt 1400 · 1050 · 2 = 2940000 Wurzeln berechnet werden. Die Strahlerstellung ist damit aufwändiger als die in der minimalen Testszene ausgeführte Schnittberechnung mit der Kugel, bei der nur bei einem gefundenen Schnitt die Wurzel gezogen wird. Auf der Anzeigeseite ist die Dauer für den Texturtransfer erwartungsgemäß vergleichbar mit der ersten Testzene, die benötigte Zeit für die Dekompression der Bilddaten liegt sogar deutlich unter der in der ersten Testszene benötigten Dekompressionszeit. Dennoch stellen diese beiden Zeiten bei der minimalen Testszene die relevanten Anteile dar. Die Dekompression als zahlenmäßig größter Anteil und zudem schwankend aufgrund der unterschiedlichen Komprimierungsraten, der Texturtransfer als konstante Ab- schlußoperation. Insgesamt benötigt die Verarbeitungszeit auf dem Client mit annähernd 53ms ca. die dreifache Berechnungszeit der Servers. Alleine die auf dem Client notwendigerweise sequentiell auszu- führende Dekomprimierung benötigt mehr Zeit als die Bildberechnung inklusive Kompression auf dem Server. Bei den Messungen mit der minimalen Testzene wurde der Einfluß des Nagle-Algorithmus in der TCP-Implementierung besonders deutlich. Anstatt der 53ms wurden mit aktiviertem Nagle-Algorithmus 91, 397ms für die Gesamtzeit auf dem Client gemessen, alleine durch das verzögerte Senden der star- tenden Nutzerinteraktion ergab sich diese Verdopplung. Zusammenfassend ist festzustellen, dass die verhältnismäßig geringe Bandbreite der Verbindung zwischen Großrechner und Anzeigeseite in der Praxis wenig relevant ist. Die Notwendigkeit einer dynamischen Lastverteilung auf dem Server und die daraus resultierende Segmentierung des Bildes in getrennt zu berechnende Bildbereiche konnte vorteilhaft ausgenutzt werden. Der zusätzliche Kommunikations- aufwand bei der Zuweisung von Arbeitsaufträgen und dem Einsammeln von Bildblöcken ist auf dem Server problemlos zu realisieren, dieser zusätzliche Aufwand erzeugt aber kontinuierlich über den Be- rechnungsprozess verteilt Teilergebnisse, welche sofort an den Client geschickt werden können. Dadurch kann die Verbindung zwischen Client und Server effizient und durchgängig genutzt werden. Um die Bandbreite der nun kontinuierlich eingesetzten Verbindung noch effizienter auszunutzen, wird eine Datenkompression angewendet. Diese vermindert das Problem der geringen Bandbreite, erzeugt da- 8. DARSTELLUNG AUF DER POWERWALL 66 für aber zusätzlichen Overhead. Dieser Overhead ist auf dem Server minimal (Siehe Abbildung 7.5). Die Datenkompression kann auf die durch die Lastverteilung entstehenden Blöcke von Bildpunkten angewendet werden, und somit ebenfalls parallel berechnet werden. Der Client hat diese Möglichkeit jedoch nicht, so dass beim Client die sequentielle Dekompression einen Bottleneck darstellen kann. Die parallele Berechnung auf dem Server erzeugt jedoch ausdrücklich unabhängig voneinander komprimierte Blöcke. Denkbar wäre eine parallele Berechnung, bei der alle Prozesse ein gemeinsames, für die gesamten Daten optimaleres Wörterbuch erzeugen [FRT96, HV96]. Als zweiter Ansatz wäre eine auf Blöcken operierende Datenkompression denkbar, bei der die Blöcke unabhängig voneinander und parallel berechnet werden, diese Blöcke dann jedoch zu einem Gesamtergebnis zusammengeführt werden können [Ely]. Diese Ansätze wurden jedoch nicht weiter verfolgt, da die veröffentlichten Komprimierungsraten keinen Geschwindigkeitsgewinn gegenüber der zlib versprachen bzw. die Verfahren mit einem erhöhten Berechnungsaufwand erkauft wurden. Parallele Datenkompression war zudem kein Schwerpunkt dieser Arbeit. Insgesamt ist eher eine Erhöhung der Bandbreite und ein Verzicht auf die Datenkompression anzustreben, so dass der Anzeigerechner von der Arbeit der Dekomprimierung befreit wird. 9. ZUSAMMENFASSUNG UND BEWERTUNG 67

9 Zusammenfassung und Bewertung

Zusammenfassung

Es wurde zunächst ein Ray Tracer als eine nicht parallelisierte Bibliothek entwickelt. Die beabsichtig- te Parallelisierung wurd berücksichtigt, indem die Schnittstelle nicht kapselnd Gesamtbilder berechnet, sondern einzelne Primärstrahlen verfolgt werden. Wie diese Strahlen erzeugt werden, ist nicht durch die Implementierung der Bibliothek vorgegeben. Aufgrund der gewünschten, stereoskopischen Darstel- lung werden jedoch zwei Kameras angeboten, die die beiden benötigten Halbbilder erzeugen, indem die entsprechenden Primärstrahlen erzeugt werden. Der Ray Tracer berechnet die zu erwartenden Beleuch- tungseffekte wie Schatten, Reflexion und Transmission und bietet verschiedene Arten von Lichtquellen an. Als Grundprimitive können Dreiecke, die Box und eine Auswahl von Quadrics geschnitten werden, Dreiecke können zudem zu einem Dreiecksnetz kombiniert werden. Durch Texturen können diesen Ob- jekten Farbwerte, modifizierende Normalen für Bump Mapping und beispielhaft Reflexionskoeffizienten als Materialwerte zugewiesen werden. Die Bildberechnung bei einer verhältnismäßig großen Anzahl von Objekten, vor allem beim Dreiecksnetz, wurde durch eine simple Hüllvolumenhierarchie aus Kugeln er- möglicht. Da der entwickelte Ray Tracer sowohl auf der Altix, als auch auf dem Cluster für Vergleichsmessungen laufen sollte, musste portabel parallelisiert werden. Aufgrund des verteilten Speichers auf dem Cluster bedeutete dies eine Kommunikation über Nachrichten unter Nutzung des Quasi-Standards MPI. In einem “Master-Slave”-Ansatz werden dabei als Arbeitsaufträge Blöcke von Bildpunkten verteilt. Diese Bild- punkte korrespondieren bei der Berechnung mit zu verfolgenden Primärstrahlen, die bei der Verfolgung jeweils unerschiedliche Berechnungszeiten erzeugen können. Deswegen wurde eine dynamische Last- verteilung implementiert, bei der der Master jeweils freien Slaves neue Arbeitsaufträge zuteilt. Dieses Vorgehen entspricht auch den Ergebnissen bisheriger Arbeiten, in dieser Diplomarbeit konnte jedoch das Vorliegen von Teilergebnissen während der Berechnung zusätzlich für die Kommunikation mit der Dar- stellungsseite ausgenutzt werden. Die verhältnismäßig geringe Anbindung der Darstellungsseite wurde durch das kontinuierliche Senden der Teilergebnisse und eine simple Datenkompression durch die zlib möglichst gleichmäßig und effizient beansprucht. Vergleichsmessungen auf Altix und Cluster ergaben, dass die Kommunikation aufgrund der vielen, sehr kleinen Nachrichten hauptsächlich geringe Latenzzei- ten erfordert, und weniger von der Bandbreite abhängt. Die Altix lieferte aufgrund ihres performanteren Netzwerkes die eindeutig besseren Ergebnisse. Auf der Darstellungsseite wurde ein minimaler Viewer entwickelt, der die gelieferten Daten anzeigt. Problematisch ist dabei, dass die Bilddaten jedes einzelnen Bildes auf dem Client dekomprimiert und letztendlich auf die Grafikkarte geladen werden müssen, bevor sie mittels OpenGL angezeigt werden können. Der Datentransfer wurde dabei über Pixel Buffer Objects, die Dekomprimierung erfolgt sofort nach dem Erhalten der Teilergebnisse von der rechnenden Komponente. Neben der Nutzerinteraktion übernimmt die Darstellungsseite auch das Laden der Szenendaten, welche dann temporär an den Server auf dem Hochleistungsrechner geschickt werden. Für die Szenendefinition 9. ZUSAMMENFASSUNG UND BEWERTUNG 68 wurde eine XML-Darstellung gewählt, da diese neben der einfachen Erstellung in einem für Menschen lesbaren Format auch eine Hierarchisierung der Einträge erlaubt. Diese Hierarchisierung wurde für die Definition von Transformationsknoten verwendet. Insgesamt wurden drei entwickelte Hauptkomponenten (Anzeigeseite, parallelisierender Server, Biblio- thek eines Ray Tracers) zu einem Gesamtsystem zusammengesetzt, welches ein interaktives Durchwan- dern von Szenen mit einer stereoskopischen Darstellung vor der Powerwall des Lehrstuhls erlaubt. Bei- spiele dieser Szenen finden sich im Anhang.

Bewertung und Ausblick

Ray Tracing hat aufgrund seines Algorithmus hinsichtlich seiner Parallelisierung ein großes Potential. Theoretisch ist ein idealer Speedup denkbar, bei dem ein größerer Einsatz von Resourcen eine entsprechende Verringerung der Berechnungszeiten bewirkt. Dieser lineare Speedup wurde auf dem CPU-Set der Altix auch erreicht. Jedoch ergaben sich ansonsten praktische Einschränkungen. Stark unterschiedliche Berechnungszeiten der einzelnen Bildpunkte erfordern eine dynamische Lastverteilung, welche zwangsläufig mehr Kommunkation bedeutet. Das Netzwerk des Clusters ist für die verwendete, sehr häufige Kommunikation, welche zudem noch in einem Knoten zusammenläuft, nicht ausgelegt. Durch “Factoring” konnte die Anzahl der Kommunikationen gesenkt werden, was sich auch sofort in besseren Messergebnissen niederschlug. Jedoch waren die Ergebnisse niemals mit den Resultaten auf der Altix vergleichbar, so dass der Cluster als Plattform nicht weiter betrachtet werden sollte. Auf größeren Partitionen der Altix konnte der lineare Speedup auch nicht durchgängig erzielt werden. Die vorgestellten Messungen zeigen, dass dafür nicht das Netzwerk verantwortlich gemacht werden kann, welches noch deutlich mehr Kommunikationen und somit feinere Lastverteilungen ermöglichen würde. Anstatt der Latenz bei der Kommunikation der Prozesse wurde vielmehr die Latenz beim Spei- cherzugriff zum einschränkenden Einfluss. Der Schwachpunkt ist dabei der entwickelte Ray Tracer, welcher nicht als Echtzeitraytracer entwickelt wurde. Dementsprechend existieren keine Optimierungen bei Data Placement und Data Alignment, der Ray Tracer wurde auch nicht hardwarenah oder unter Be- rücksichtigung der eingesetzten Hardware entwickelt. Bei einer Konzentrierung auf die vorzuziehende Altix könnte neben einer hardwarenäheren Entwicklung ebenfalls der Vorteil des gemeinsamen Spei- chers mehr ausgenutzt werden. Eine Kommunikation über Nachrichten wäre auf der Altix nicht mehr notwendig, eine synchronisierte Queue mit Arbeitsaufträgen im gemeinsamen Speicher wäre für die Lastverteilung ausreichend. Die einzelnen Arbeiter könnten ihre berechneten Bilddaten ebenfalls im gemeinsamen Speicher ablegen, so dass die serielle Zusammenführung im Masterprozess entfällt. Der entwickelte Ray Tracer hat noch großes Entwicklungspotential. Eine Verbesserung beim Datenzu- griff würde sich schon ergeben, wenn nicht mehr zeilenweise die Bildpunkte als Arbeitsaufträge verteilt würden, sondern als rechteckige Bildbereiche. Bei diesem lokalen Bildausschnitt wäre die Wahrschein- lichkeit größer, nur sehr wenige Objekte der Szene zu treffen und somit müssten weniger Daten betrachtet werden. Allerdings würde dieses den in [AH93, ABC+91, AH92] vorgestellten Ansatz zum Ableiten des zweiten Halbbildes aus dem ersten, berechneten Halbbild verhindern, bei dem von einer zeilenweise Berechnung ausgegangen wird. Eine Betrachtung dieses Ansatzes wäre interessant, da der Berechnungs- aufwand der beiden Halbbilder im besten Falle halbiert werden könnte. Die in dieser Diplomarbeit verwendeten Hierarchien aus Kugeln als Hüllvolumen entsprechen nicht dem 9. ZUSAMMENFASSUNG UND BEWERTUNG 69 aktuellen Forschungsstand, als zentraler Ansatz bei der Beschleunigung der Bildberechnung sind diese Beschleunigungsstrukturen ein Forschungsschwerpunkt beim Echtzeitraytracing [WMG+]. Für statische Szenen wurden kD-Trees als optimaler Ansatz identifiziert [HPP00, Hav00] und zum Zeitpunkt dieser Diplomarbeit überwiegend eingesetzt. Aktuelle Ergebnisse demonstrieren ein paralleles Erzeugen der Bäume durch mehrere Threads auf den gleichen Daten [MS07, Bik07], was bei einer Konzentrierung auf die Altix mit gemeinsamen Speicher möglich wäre. Aufgrund des Clusters mit verteiltem Speichers wurden in dieser Diplomarbeit für jeden Prozess Kopien der Szenendaten angelegt, dieses entspricht nicht der optimalen Datenhaltung. Bei gemeinsamen Speicher wäre eine einzige Kopie der Szenendaten möglich. Da zudem alle berechnenden Threads nur lesend auf Szenendaten zugreifen, ist dann keine zusätzliche Synchronisation notwendig. Die verhältnismäßig geringe Bandbreite der Verbindung zwischen Darstellungsseite und Server konnte aufgrund der eingesetzten Datenkompression und kontinuierliches Senden von Teilergebnissen effizient ausgenutzt werden. Bei den Messungen mit den Testszenen wirkte die Bandbreite sich nicht negativ aus. Die eigentlich Overhead erzeugende, dynamische Lastverteilung bei der Berechnung konnte bei der Kommunikation vorteilhaft ausgenutzt werden. Allerdings ist der Einsatz der Datenkompression nur ein Kompromiß. Bei der Bildberechnung auf dem Server können die Daten parallel komprimiert werden, wodurch die zusätzlichen Berechnungszeiten zu vernachlässigen sind. Sämtliche Daten müssen jedoch auf dem einzelnen Client dekomprimiert werden. Es ist eine größere Bandbreite der Verbindung anzustreben, so dass auf eine Komprimierung verzichtet werden kann. Zusammengefasst ist eine Konzentrierung auf die Altix aufgrund des performanteren Netzwerkes sinnvoll. Die Kommunikation über auf dem Masterprozess zusammenlaufende Nachrichten könnte vermieden werden, der Overhead durch die simulierte Nachrichtenkommunikation der MPI-Implementierung würde entfallen. Der gemeinsame Speicher würde eine optimalere Datenhaltung ohne mehrfache Kopien erlauben. Für einen weiteren Geschwindigkeitsgewinn bei der Bildberechnung ist unbedingt der Ray Tracer wei- terzuentwickeln, da dieser aufgrund des nicht optimierten Zugriffs auf den Speicher bereits den Speedup negativ beeinflußt. Unabhängig von einer Parallelisierung können Berechnungszeiten durch eine optimalere Beschleunigungsstruktur verringert werden. Literaturverzeichnis 70

Literaturverzeichnis

[ABC+91] ADELSON, Stephen J. ; BENTLEY, Jeffrey B. ; CHONG, In S. ; HODGES, Larry F. ; WI- NOGRAD, Joseph: Simultaneous generation of stereoscopic views. In: Comput. Graph. Forum 10 (1991), Nr. 1, S. 3–10. – ISSN 0167–7055

[AH92] ADELSON, Stephen J. ; HODGES, Larry F.: Visible surface ray-tracing of stereoscopic images. In: ACM-SE 30: Proceedings of the 30th annual Southeast regional conference. New York, NY, USA : ACM Press, 1992. – ISBN 0–89791–506–2, S. 148–156

[AH93] ADELSON, Stephen J. ; HODGES, Larry F.: Stereoscopic ray-tracing. In: The Visual Computer 10 (1993), Nr. 3, S. 127–144

[Amd00] AMDAHL, Gene M.: Validity of the single processor approach to achieving large scale computing capabilities. (2000), S. 79–81. ISBN 1–55860–539–8

[App68] APPEL, Arthur: Some Techniques for Shading Machine Renderings of Solids. In: Pro- ceedings of the Spring Joint Computer Conference, 1968, S. 37–45

[araa] “Architecture of a Real-Time Ray-Tracer”. Architekturbeschreibung des Echtzeitraytra- cers “Arauna”. http://softwarecommunity.intel.com/articles/eng/1520.htm

[arab] Demo und Quelltexte des Echtzeitraytracers “Arauna”. http://rt07.raytracing.nl/

[Bik07] BIKKER, Jacco: Real-time Ray Tracing through the Eyes of a Game Developer. In: Interactive Ray Tracing, 2007. RT apos;07. IEEE Symposium on. 2007. – ISBN 978–1– 4244–1629–5, S. 1–1

[BP90] BADOUEL, Didier ; PRIOL, Thierry: An Efﬁcient Parallel Ray Tracing Scheme for High- ly Parallel Architectures. In: GRIMSDALE, R. (Hrsg.) ; KAUFMAN, A. (Hrsg.): Advan- ces in Computer Graphics Hardware V, Tutorial on Perspectives of Computer Graphics. New York : Springer-Verlag, 1990, S. 93–106

[BWSF06] BENTHIN, Carsten ; WALD, Ingo ; SCHERBAUM, Michael ; FRIEDRICH, Heiko: Ray Tracing on the CELL Processor. In: Technical Report, inTrace Realtime Ray Tracing GmbH, No inTrace-2006-001 (submitted for publication) (2006)

[Cha02] CHALMERS, Alan: Introduction to parallel processing. (2002), S. 3–30. ISBN 1–56881– 179–9

[CHH02] CARR, Nathan A. ; HALL, Jesse D. ; HART, John C.: The ray engine. In: HWWS ’02: Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware. Aire-la-Ville, Switzerland, Switzerland : Eurographics Association, 2002. – ISBN 1–58113–580–7, S. 37–46 Literaturverzeichnis 71

[CM93] CORRIE, Brian ; MACKERRAS, Paul: Parallel Volume Rendering and Data Coherence. In: CROCKETT, Thomas (Hrsg.) ; HANSEN, Charles (Hrsg.) ; WHITMAN, Scott (Hrsg.): ACM SIGGRAPH Symposium on Parallel Rendering, 1993, S. 23–26

[dei] Konﬁguration des Linux Networx Clusters “Deimos” an der TU Dresden. http://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/zih/dienste/ rechner_und_arbeitsplatzsysteme/pc_farm/deimos/hardware

[DGBP05] DEMARLE, David E. ; GRIBBLE, Christiaan P. ; BOULOS, Solomon ; PARKER, Ste- ven G.: Memory sharing for interactive ray tracing on clusters. In: Parallel Comput. 31 (2005), Nr. 2, S. 221–242. – ISSN 0167–8191

[Die] DIETRICH, Andreas D. Interactive Visualization of Exceptionally Complex Industrial CAD Datasets

[DPH+03] DEMARLE, D. ; PARKER, S. ; HARTNER, M. ; GRIBBLE, C. ; HANSEN, C. Distributed interactive ray tracing for large volume visualization. 2003

[Ely] ELYTRA, Jeff G. Parallel Data Compression With Bzip2

[FRT96] FRANASZEK, P. ; ROBINSON, J. ; THOMAS, J.: Parallel compression with cooperative dictionary construction. In: DCC ’96: Proceedings of the Conference on Data Compres- sion. Washington, DC, USA : IEEE Computer Society, 1996. – ISBN 0–8186–7358–3, S. 200

[Gre06] DE GREVE, Bram: Reﬂections and Refractions in Ray Tracing. (2006)

[Hav00] HAVRAN, Vlastimil: Heuristic Ray Shooting Algorithms, Department of Computer Science and Engineering, Faculty of Electrical Engineering, Czech Technical Univer- sity in Prague, Ph.D. Thesis, November 2000

[HPP00] HAVRAN, V. ; PRIKRYL, J. ; PURGATHOFER, W. Statistical Comparison of Ray- Shooting Efﬁciency Schemes. 2000

[hrs] HRSK User Guide. http://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/zih/publikationen/ schriften/benutzerinformationen_und_technische_kurzinformationen/

[HSF91] HUMMEL, Susan F. ; SCHONBERG, Edith ; FLYNN, Lawrence E.: Factoring: a practical and robust method for scheduling parallel loops. In: Supercomputing ’91: Proceedings of the 1991 ACM/IEEE conference on Supercomputing. New York, NY, USA : ACM Press, 1991. – ISBN 0–89791–459–7, S. 610–632

[HV96] HOWARD, Paul G. ; VITTER, Jeffrey S.: Parallel lossless image compression using Huffman and arithmetic coding. In: Inf. Process. Lett. 59 (1996), Nr. 2, S. 65–73. – ISSN 0020–0190

[int] Interactive Ray Tracing, Implementierungsdetails des Echtzeitraytracers “Arauna”. http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/games/245711.htm

[irt] The Internet Ray Tracing Competition. http://www.irtc.org Literaturverzeichnis 72

[Kat03] KATO, Toshi: Kilauea: parallel global illumination renderer. In: Parallel Comput. 29 (2003), Nr. 3, S. 289–310. – ISSN 0167–8191

[KK86] KAY, Timothy L. ; KAJIYA, James T.: Ray tracing complex scenes. In: SIGGRAPH ’86: Proceedings of the 13th annual conference on Computer graphics and interactive techniques. New York, NY, USA : ACM Press, 1986. – ISBN 0–89791–196–2, S. 269– 278

[Lef93] LEFER, Wilfrid: An efﬁcient parallel ray tracing scheme for distributed memory parallel computers. In: PRS ’93: Proceedings of the 1993 symposium on Parallel rendering. New York, NY, USA : ACM Press, 1993. – ISBN 0–89791–618–2, S. 77–80

[Let] LETSCHE, Todd. A Quick Introduction to the SGI Altix Platform. www.becat.uconn.edu/hpc/pdf/SGIpresentation1-20-06.pdf

[LZO] Markus Oberhume. LZO-Compression Library verfügbar unter der GPL. http://www.oberhumer.com/opensource/lzo/

[MPI] Message Passing Interface Forum. http://www.mpi-forum.org/

[MS07] MAXIM SHEVTSOV, Alexander K.: Highly Parallel Fast KD-tree Construction for In- teractive Ray Tracing of Dynamic Scenes. In: Computer Graphics Forum Volume 26. 2007, S. 395–404

[MT97] MÖLLER, Tomas ; TRUMBORE, Ben: Fast, Minimum Storage Ray-Triangle Intersection. In: journal of graphics tools 2 (1997), Nr. 1, S. 21–28

[NAWAHV06] NOR ASILAH WATI ABDUL HAMID, Paul C. ; VAUGHAN, Francis: Comparison of MPI Benchmark Programs on an SGI Altix ccNUMA Shared Memory Machine. In: Proc. of Workshop on Performance Modeling, Evaluation, and Optimization of Parallel and Distributed Systems (PMEO-PDS’06), Rhodes, Greece, April 2006., 2006

[net] netio, ein freies Benchmarkprogramm zum Ermitteln der Bandbreite über Sockets. http://freshmeat.net/projects/netio/

[NG97] NOTKIN, Irena ; GOTSMAN, Craig: Parallel Progressive Ray-tracing. In: Comput. Graph. Forum 16 (1997), Nr. 1, S. 43–55

[PBMH02] PURCELL, Timothy J. ; BUCK, Ian ; MARK, William R. ; HANRAHAN, Pat: Ray tracing on programmable graphics hardware. In: ACM Trans. Graph. 21 (2002), Nr. 3, S. 703– 712. – ISSN 0730–0301

[pbo] Speziﬁkation und Anwendundungsbeispiele der OpenGL-Erweiterung “Pixel Buffer Ob- jects”. http://www.opengl.org/registry/specs/ARB/pixel_buffer_object.txt

[Pﬁ01] PFISTER, Gregory F.: An Introduction to the InﬁniBand Architecture. In: JIN, Hai (Hrsg.) ; CORTES, Toni (Hrsg.) ; BUYYA, Rajkumar (Hrsg.): High Performance Mass Storage and Parallel I/O: Technologies and Applications. New York, NY : IEEE Com- puter Society Press and Wiley, 2001, Kapitel 42, S. 617–632 Literaturverzeichnis 73

[PH04] PHARR, Matt ; HUMPHREYS, Greg: Physically Based Rendering: From Theory to Im- plementation. San Francisco, CA, USA : Morgan Kaufmann Publishers Inc., 2004. – ISBN 012553180X

[Pho73] PHONG, Bui T.: Illumination for computer-generated images., Diss., 1973

[PMS+99] PARKER, Steven ; MARTIN, William ; SLOAN, Peter-Pike J. ; SHIRLEY, Peter ; SMITS, Brian ; HANSEN, Charles: Interactive ray tracing. In: Symposium on Interactive 3D Graphics, 1999, S. 119–126

[PSL+98] PARKER, Steven ; SHIRLEY, Peter ; LIVNAT, Yarden ; HANSEN, Charles ; SLOAN, Peter-Pike: Interactive ray tracing for isosurface rendering. In: VIS ’98: Proceedings of the conference on Visualization ’98. Los Alamitos, CA, USA : IEEE Computer So- ciety Press, 1998. – ISBN 1–58113–106–2, S. 233–238

[Pur02] PURCELL, Tim: Parallel ray tracing on a chip. (2002), S. 329–336. ISBN 1–56881– 179–9

[SBB+06] STEPHENS, Abraham ; BOULOS, Solomon ; BIGLER, James ; WALD, Ingo ; PARKER, Steven G.: An Application of Scalable Massive Model Interaction using Shared Memory Systems. In: Proceedings of the 2006 Eurographics Symposium on Parallel Graphics and Visualization, 2006, S. 19–26

[SKM] SZIRMAY-KALOS, Laszlo ; MARTON, Gabor. Worst-Case Versus Average Case Com- plexity of Ray-Shooting

[tin] TinyXml - A C++ XML parser. http://sourceforge.net/projects/tinyxml

[vam] Vampir - Ein graﬁsches Analysewerkzeug zur Visualisierung und Analyse von parallelen Anwendungen. http://www.vampir.eu/

[Vog] VOGELSANG, Reiner. SGI Altix NumaTools. http://tu-dresden.de/die_tu_dresden/zentrale_einrichtungen/zih/veranstaltungen/ nutzerschulungen/dateien/altix_numatools.pdf

[Wal04] WALD, Ingo: Realtime Ray Tracing and Interactive Global Illumination, Computer Gra- phics Group, Saarland University, Diss., 2004

[WBS] WALD, Ingo ; BENTHIN, Carsten ; SLUSALLEK, Philipp. A Simple and Practical Method for Interactive Ray Tracing of Dynamic Scenes

[WHG84] WEGHORST, Hank ; HOOPER, Gary ; GREENBERG, Donald P.: Improved Computatio- nal Methods for Ray Tracing. In: ACM Trans. Graph. 3 (1984), Nr. 1, S. 52–69. – ISSN 0730–0301

[Whi80] WHITTED, Turner: An improved illumination model for shaded display. In: Commun. ACM 23 (1980), Nr. 6, S. 343–349. – ISSN 0001–0782

[WMG+] WALD, Ingo ; MARK, William R. ; GÜNTHER, Johannes ; BOULOS, Solomon ; IZE, Thiago ; HUNT, Warren ; PARKER, Steven G. ; SHIRLEY, Peter: State of the Art in Ray Tracing Animated Scenes. In: Eurographics 2007 State of the Art Reports Literaturverzeichnis 74

[WS01] WALD, I. ; SLUSALLEK, P. State-of-the-Art in Interactive RayTracing. 2001

[WSBW] WALD, Ingo ; SLUSALLEK, Philipp ; BENTHIN, Carsten ; WAGNER, Markus: Interactive Distributed Ray Tracing of Highly Complex Models, S. 277–288

[WSBW01] WALD, Ingo ; SLUSALLEK, Philipp ; BENTHIN, Carsten ; WAGNER, Markus: Interactive Rendering with Coherent Ray Tracing. In: CHALMERS, A. (Hrsg.) ; RHYNE, T.-M. (Hrsg.): EG 2001 Proceedings Bd. 20(3). Blackwell Publishing, 2001, S. 153–164

[zli] Zlib Home Page. http://www.zlib.net/ ANHANG A. SCREENSHOTS 75

A Screenshots

Alle folgenden Screenshots wurden mit zwei Halbbildern in voller Auﬂösung (1400x1050) erzeugt.

Abbildung A.1: Reﬂexion und Transmission, ca. 3fps auf 120 CPUs

Abbildung A.2: Texturiertes Dreiecksnetz mit Knotennormalen, ca. 4fps auf 120 CPUs ANHANG A. SCREENSHOTS 76

Abbildung A.3: Kugelhelix, Beispiel für Scenegraph, ca. 6fps auf 120 CPUs

Abbildung A.4: Spiegelraum, maximale Rekursionstiefe der Reﬂexion, < 1fps auf 120 CPUs ANHANG A. SCREENSHOTS 77

Abbildung A.5: Ausschnitt einer Szene mit weichen Schatten, < 1fps auf 120 CPUs

Abbildung A.6: Nebel und Spotlight, ca. 6fps auf 120 CPUs

Abbildung A.7: Cel-Shading, ca. 6fps auf 120 CPUs ANHANG A. SCREENSHOTS 78

Abbildung A.8: Visualisierung von Durchdringungen, ca. 10fps auf 120 CPUs

Abbildung A.9: Testszene für Lastverteilungstests in einer frühen Entwicklungsphase

Abbildung A.10: Minimale Testszene, ca. 20fps auf 120 CPUs Danksagung 79

Danksagung

Ausdrücklich gedankt werden soll dem “Zentrum für Informationsdienste und Hochleistungsrechnen” (ZIH) unter der Leitung von Prof. Dr. Wolfgang E. Nagel sowie seinen Mitarbeitern. Ohne die zur Verfü- gung gestellten Resourcen wäre die Diplomarbeit in dieser Form nicht möglich gewesen. Bei Problemen und Fragen waren die Mitarbeiter stehts ansprechbar.