Interaktives Raytracing auf Hochleistungsrechnern

Fakultät Informatik Institut für Software- und Multimediatechnik, Professur Computergraphik und Visualisierung
Interaktives Raytracing auf
Hochleistungsrechnern
Verteidigung der Diplomarbeit, Daniel Grafe
Dresden, 21.02.2008
Übersicht
I. Motivation und bisherige Arbeiten
Möglichkeiten und Zeitbedarf, Interaktive
Anwendungen, pragmatische Entwicklungen
II. Hardware und Bedingungen
IV. Bilddarstellung, Datenhaltung,
Bewertung der Berechnung
Display, Berechnung und Transport
Gemessen an zwei Testszenen
V. Zusammenfassung / Ausblick
Bilderzeugung, Bilddarstellung, Transport
VI. Programmvorführung
III. Ray Tracing
Algorithmus, Parallelisierungsansatz,
Berechnungsaufwand, BVH
III. Entwurf und Bibliothek
Komponenten, Funktionsumfang der Bibliothek
IV. Parallelisierung
Dynamische Lastverteilung, Arbeitsaufträge,
Entwicklung auf Neptun, Vergleichsmessungen
auf Deimos und den Partitionen der Altix
Motivation
Irtc.org: First Place Jan-Feb 2006
RENDERER USED:
POVRAY 3.6
RENDER TIME:
37 hours @ 1280x1024 px
HARDWARE USED:
Dell PC, Pentium 4 (w/HT), 3 Ghz, 1 GB
RAM
Motivation
Irtc.org: Second Place May-June
2001
RENDERER USED:
MegaPov 0.7
RENDER TIME:
5 hours 14 minutes @ 999x562 px
HARDWARE USED:
Athlon 1 Ghz 256 MB
Beobachtung:
•
•
Realistisch wirkende Szenen aufgrund von
– Licht- und Schatteneffekte
– Spiegelung und Brechung
Aber: Hoher Berechnungsaufwand
Bisherige Arbeiten
Steven Parker et al., Interactive Raytracing, 1999
•
•
512x512, 60 CPUs, ca. 75.000 Polygone, ca. 4fps
SGI Origin 2000
– 128 CPUs
– Angeschlossenes Display
– Szenendaten im gemeinsamen
Speicher
Annähernd idealer Speedup bis 128 CPUs
Bisherige Arbeiten
Ingo Wald, State of The Art in Interactive Raytracing, 2001
•
•
•
•
640x480, 50 Millionen Dreiecke, 7 Dual
Pentium-III 800, 3.4 fps
Echtzeit-Raytracer, Festlegungen:
– Dreiecke als Grundprimitive
– SSE-Optimierungen
– Speicherzugriffe und
Datenorganisation hinsichtlich
Caches optimiert
Visualisierung großer Datensätze
Parallelisiert auf einem Cluster von
Desktop-PCs
Fast idealer Speedup
Bisherige Arbeiten
Stephens, Boulos, Bigler, Wald, Parker: An Application of
Scalable Massive Model Interaction using Shared-Memory
Systems, 2006
•
•
System: SGI Prism (128 x Itanium 2, 256GB Speicher)
Modell: Boeing 777
– ca. 350 Millionen Dreiecke
– 28GB Geometrie
– 29GB kd-tree (vorberechnet)
•
Gemeinsamer Speicher: Vermeidung von mehrfacher
Datenhaltung
Ray Tracing: Visualisierung, nicht Photorealismus
Annähernd idealer Speedup
•
•
Übersicht
I. Motivation und bisherige Arbeiten
Möglichkeiten und Zeitbedarf, Interaktive
Anwendungen, pragmatische Entwicklungen
II. Hardware und Bedingungen
IV. Bilddarstellung, Datenhaltung,
Bewertung der Berechnung
Display, Berechnung und Transport
Gemessen an zwei Testszenen
V. Zusammenfassung / Ausblick
Bilderzeugung, Bilddarstellung, Transport
VI. Programmvorführung
III. Ray Tracing
Algorithmus, Parallelisierungsansatz,
Berechnungsaufwand, BVH
III. Entwurf und Bibliothek
Komponenten, Funktionsumfang der Bibliothek
IV. Parallelisierung
Dynamische Lastverteilung, Arbeitsaufträge,
Entwicklung auf Neptun, Vergleichsmessungen
auf Deimos und den Partitionen der Altix
Eingesetzte Hardware - Bilderzeugung
SGI Altix 4700
•
•
Relevante Vorteile:
•
•
•
Gemeinsamer Speicher
Schnelles Netzwerk
Interaktive Testumgebung mit 128 Prozessoren
2048 Cores Intel Itanium 2 1.6GHz
– Organisiert in 5 Partitionen
– Login + 348 Batch-Betrieb,
3x506 Batch-Betrieb,
128 Interaktiv
Innerhalb der Partitionen
– Gemeinsamer Speicher
– NumaLink4-Netzwerk
(MPI Latency: 1-3 microseconds)
Eingesetzte Hardware - Bilderzeugung
PC Farm Deimos
•
•
2576 Cores AMD Opteron X85 2.6GHz
– 724 Knoten mit 1, 2 und 4 CPUs
Netzwerk: Drei 288-Port IB Switche
– Infiniband, MPI Latency:
• 3.5 – 5 microseconds
• < 420ns switchintern
(Herstellerangabe)
Relevante Vorteile:
Relevante Nachteile:
•
•
•
•
Höherer Prozessortakt (x1.625) als auf der Altix
Kein gemeinsamer Speicher
Netzwerk mit höheren Latenzen
Heterogenes System
Eingesetzte Hardware - Bilddarstellung
Darstellung auf der Powerwall
•
•
•
•
•
3D-Darstellung mittels passiver Stereoskopie
Den beiden Augen wird je ein Halbbild
angeboten
Auflösung: 2 x SXGA+ (1400 x 1050)
Projektion über einen Umlenkspiegel auf die
Rückprojektionsleinwand (272 cm x 204 cm)
Trennung der Halbbilder durch
Polarisationsfilter
Bedingung: Das Erstellen der Halbbilder simuliert
die unterschiedlichen Ansichten der
Augen
Effekt:
Tiefeneindruck bei der Darstellung
Eingesetzte Hardware - Datentransport
Räumliche Trennung von Berechnung und Darstellung
•
•
•
Distanz: ca. 1km Luftlinie vom Trefftz-Bau zur Fakultät Informatik
Gigabit Ethernet (1000Base-SX)
Bandbreitenproblem bei zwei Halbbildern im RGB-Format (ca. 8.4MB): 120MB / 8.4 = 14.2
Optimierung der Bandbreite
•
•
Problem: Große Datenmengen zu erwarten, aber geringe TCP-Fenstergröße (65KByte)
– Viele verhältnismäßig kleine Pakete werden verschickt
Optimierung: “TCP Extensions for High Performance” – RFC 1323: TCP Window Scale
– Fenstergröße auf 150KByte erhöht: Real erreichte Bandbreite von 73MB auf 103MB
erhöht
Optimierung der Latenzzeiten
•
•
•
Messung Latenzzeit: ICMP ECHO_REQUEST: 0.534ms, TCP-Ping: 0.466ms
Problem: „Nagle-Algorithmus“ – RFC896 „Congestion Control in IP/TCP Internetworks”
– Kleine Pakete werden vom Algorithmus gepuffert, um größere Pakete zu erzeugen
– Steuernachrichten mit Echtzeitanforderungen wurden bis zu 40ms verzögert
Optimierung: Algorithmus für Steuernachrichten deaktiviert
Übersicht
I. Motivation und bisherige Arbeiten
Möglichkeiten und Zeitbedarf, Interaktive
Anwendungen, pragmatische Entwicklungen
II. Hardware und Bedingungen
IV. Bilddarstellung, Datenhaltung,
Bewertung der Berechnung
Display, Berechnung und Transport
Gemessen an zwei Testszenen
V. Zusammenfassung / Ausblick
Bilderzeugung, Bilddarstellung, Transport
VI. Programmvorführung
III. Ray Tracing
Algorithmus, Parallelisierungsansatz,
Berechnungsaufwand, BVH
III. Entwurf und Realisierung
Komponenten, Funktionsumfang der Bibliothek
IV. Parallelisierung
Dynamische Lastverteilung, Arbeitsaufträge,
Entwicklung auf Neptun, Vergleichsmessungen
auf Deimos und den Partitionen der Altix
Raytracing – 1. Schritt: Sichtbarkeit
Backward Raytracing
•
•
•
•
•
Betrachter
Bildebene
Objekt 1
Bildebene und Augpunkt
definieren
Primärstrahlen vom Augpunkt
durch die Bildebene in die
Szene schicken
Schnittpunkt mit kürzester
Distanz zum Strahlursprung
bestimmen
Am Schnittpunkt Farbwert
bestimmen, lokal beleuchten
Bildpunkt identisch mit Kachel
der Bildebene
Raytracing – 2. Schritt: Schattenstrahl
Lichtquelle
Test auf Schattenwurf
•
•
•
Objekt 1
Strahl vom Schnittpunkt zur
Lichtquelle schicken (jeweils)
Bei Schnitt mit einem Objekt
zwischen Strahlursprung und
Lichtquelle: Verdeckung der
Lichtquelle
Bei Verdeckung: Lokale
Beleuchtung ohne Lichteinfluss
Raytracing – 3. Schritt: Reflexion und Transmission
Rekursion
Objekt 2
•
•
•
r1
•
t1
Objekt 1
t2
Weitere Farbbeiträge durch
Reflexion und Transmission
Sekundärstrahlen erstellen und
rekursiv verfolgen
Farbwertberechnung analog zu
Primärstrahlen
Materialkoeffizienten
bestimmen Einfluß der Beiträge
I ( R ) = klocal ⋅ I local +
k ref ⋅ I ( Rref ) +
ktrans ⋅ I ( Rtrans )
Raytracing – Parallelisierungsansatz
=>
Datenzugriff und -organisation
Strahlenbündel
•
•
•
•
Szenendaten: Nur lesender Zugriff
Keine Änderung der Szenendaten
durch Strahlverfolgung
Schreibzugriff: Bildpunkte
– Aber: Durch Strahlerstellung
Position bekannt
– Kein Zusammenführen von
Teildaten
•
•
Voneinander unabhängige
Primärstrahlen
Keine Interaktion einzelner Strahlen
Berechnungsreihenfolge unerheblich
Primärstrahlen verteilen und parallel
verfolgen
Raytracing – Berechnungsaufwand
Schnittpunktbestimmung und Schatten
•
Naiver Ansatz: Mit allen Objekten schneiden, um
den nächsten Schnittpunkt definitiv zu bestimmen
Anzahl Schnittberechnungen = m ⋅ n
•
Pro Schnitt zusätzlich ein Schattenstrahl pro
Lichtquelle, (pessimal) mit allen Objekten
schneiden
Schnittberechnungen Schattenstrahlen = s ⋅ l ⋅ n
•
Lineare Einflüsse
Rekursionskosten
•
Maximal 2 Strahlen pro Rekursionstiefe, jeweils
mit dem oben genannten Aufwand
Anzahl Sekundärstrahlen = 2 k
•
Exponentieller Einfluß
m:
n:
l:
s:
k:
Anzahl Primärstrahlen
Anzahl Szenenobjekte
Anzahl Lichtquellen
Anzahl Schnittpunkte
(maximale) Rekursionstiefe
Hierarchie aus Hüllvolumen
•
•
•
•
Traktor
(3400 Dreiecke)
Box
Disk
Ziel: Naives Schneiden mit allen
Szenenobjekten vermeiden
Hüllvolumen: Umschließt den Inhalt
stellvertretend
– Möglichst einfacher Schnitt
– Nur bei Schnitt Inhalt betrachten
Hierarchiesierung: Nur bei Schnitt
tiefer in die Hierarchie hinabsteigen
– Auf möglichst hoher
Hierarchieebene abbrechen
– Mit jedem Schritt Äste des binären
Baumes ausschließen
Problem:
– Kugelschnitt verhältnismäßig
aufwendig
– Verhältnismäßig viele Strahlen
schneiden das Hüllvolumen ohne
tatsächlich den Inhalt zu schneiden
Übersicht
I. Motivation und bisherige Arbeiten
Möglichkeiten und Zeitbedarf, Interaktive
Anwendungen, pragmatische Entwicklungen
II. Hardware und Bedingungen
IV. Bilddarstellung, Datenhaltung,
Bewertung der Berechnung
Display, Berechnung und Transport
Gemessen an zwei Testszenen
V. Zusammenfassung / Ausblick
Bilderzeugung, Bilddarstellung, Transport
VI. Programmvorführung
III. Ray Tracing
Algorithmus, Parallelisierungsansatz,
Berechnungsaufwand, BVH
III. Entwurf und Bibliothek
Komponenten, Funktionsumfang der Bibliothek
IV. Parallelisierung
Dynamische Lastverteilung, Arbeitsaufträge,
Entwicklung auf Neptun, Vergleichsmessungen
auf Deimos und den Partitionen der Altix
Entwurf
Worker 1
Worker 1
...
Master
1GB
Display
Worker N
HRSK
•
•
•
LCGV
Client-Server-Ansatz
– Server hält Verbindung mit Darstellungsseite
– TCP/IP über Sockets
– Komprimierung: zlib
Master-Slave-Ansatz
– Realisiert dynamische Lastverteilung, Primärstrahlen als Aufträge
– MPI wegen Portabilität
Ray Tracer
– Unparallelisierte Bibliothek, berechnet Primärstrahlen des linkenden Workers
Funktionsumfang des Ray Tracers
Geometrie
•
•
•
•
Quadrics
– Kugel, Ellipsoid, (elliptic) Paraboloid
Box
Dreieck
Dreiecksnetz
– Zusammenfassung von Dreiecken
über BVH
Beleuchtung
•
•
Phong (lokal), Reflexion, Transmission
Lichtquellen
– Punktlichtquelle
– Strahler (weicher und harter Rand)
– Flächenlicht für weiche Schatten
Texturdaten
•
•
•
Farbwerte
Normalen
Materialkonstanten(PoC)
Sonstiges
•
•
•
Cel-Shading
Nebel
Durchdringungsvisualisierung
Beispielabbildungen
Übersicht
I. Motivation und bisherige Arbeiten
Möglichkeiten und Zeitbedarf, Interaktive
Anwendungen, pragmatische Entwicklungen
II. Hardware und Bedingungen
IV. Bilddarstellung, Datenhaltung,
Bewertung der Berechnung
Display, Berechnung und Transport
Gemessen an zwei Testszenen
V. Zusammenfassung / Ausblick
Bilderzeugung, Bilddarstellung, Transport
VI. Programmvorführung
III. Ray Tracing
Algorithmus, Parallelisierungsansatz,
Berechnungsaufwand, BVH
III. Entwurf und Bibliothek
Komponenten, Funktionsumfang der Bibliothek
IV. Parallelisierung
Dynamische Lastverteilung, Arbeitsaufträge,
Entwicklung auf Neptun, Vergleichsmessungen
auf Deimos und den Partitionen der Altix
Notwendigkeit der dynamischen Lastverteilung
Notkin, Gotsman, Parallel Progressive Ray-Tracing, 1997
Berechnungsaufwand der Primärstrahlen schwankt stark
•
•
•
Visualisierung in der gezeigten Abbildung: Graustufen zeigen Berechnungsaufwand
– Verlauf: geringer Aufwand(Weiß) bis hoher Aufwand (Schwarz)
Reflexion und Transmission mit potentiell exponentiellem Aufwand
Vorhersage durch Änderung der Ansicht während Interaktion schwierig
=> Gefahr von Load Imbalance, dynamische Lastverteilung notwendig
Untersuchte Scheduling Schemes
Statisch
P1
P2
Dynamisch
•
•
•
Aufteilung in N gleich große Arbeitsaufträge
Vorteil: Minimale Kommunikation
Nachteil: Am längsten rechnender Prozess bestimmt
die gesamt Berechnungsteit
•
•
•
Zerlegung in viele Aufträge, dynamische Zuteilung
Vorteil: Vermeidung von Imbalance
Nachteil: Kommunikationsintensiv, aktiver
Scheduler notwendig
•
•
Zerlegung in kleiner werdende Aufträge
Vorteil: Weiterhin kleine Aufträge am Ende der
Berechnung, am Anfang Kommunikation reduziert
Nachteil: Bestimmung der Auftragsgröße, aktiver
Scheduler notwendig
t
P1
P2
t
Factoring
P1
P2
t
•
Dynamische Lastverteilung
Master
Slave
Broadcast
Befehle vom
Client empfangen
Befehle vom
Master empfangen
Nein
Bildberechnung
notwendig?
Bildberechnung
notwendig?
Nein
Punkt-Zu-Punkt
Ja
Nein
Daten stehen aus?
Ja
Ja
1.
2.
Daten lesen
Weiterleiten
an Client
Haltesignal?
Ja
MPI_Send()
Nein
1.
Nein
Bildpunkte zu
berechnen?
Haltesignal senden
Ja
Bildpunkte an Slave
senden
MP_Isend()
MPI_Send()
2.
3.
Bildpunkte
berechnen
Komprimieren
An Master senden
Haltesignal oder
Bildpunkte empfangen
Bildpunktgruppen als Arbeitsaufträge
Bildpunktgruppen
•
•
•
Zeilenweise abgezählt, beginnend mit linker,
oberer Bildecke
Kürzere Berechnungszeiten bei kleinen
Gruppen von Bildpunkten
Wenig Einfluß von Blockgrößen kleiner 500
Bildpunkten
Komprimierung
•
•
•
Kaum zusätzlicher Berechnungsaufwand
Ineffizient bei Blockgrößen deutlich kleiner als
750 Bildpunkten
Deswegen Blockgröße von 750 Bildpunkten
gewählt
Abbildung: Testszene für gezeigte und die folgende Messung
Ergebnisse auf Neptun
Linearer Speedup
•
•
•
Erzielt durch möglichst kleine
Arbeitsaufträge von 750 Bildpunkten
Geringe Latenzzeiten erlauben hohe
Anzahl von Kommunikationen
Vermeidung von Load Imbalance
Dynamische Lastverteilung
•
•
Master-Prozess: Nur Scheduling und
Kommunikation mit Client
Slaves: Praktisch auschließlich
Berechnung
Messungen auf den größeren Partitionen (Interaktionslos)
Latenzabhängige Lastverteilung
•
•
•
Zuteilung von Prozessoren über
mehrere Partitionen ab p=250
Dynamische Lastverteilung setzt
schnelles Netzwerk voraus
Mit Resourcenanforderung explizit Jobs
auf einer Partition starten
Cache-Effekte beobachtet
•
•
•
Bisheriger Ansatz der möglichst kleinen
Arbeitsaufträge versagt bei hoher
Prozessoranzahl
Netzwerk nicht verantwortlich
Unoptimierter Speicherzugriff und
-Organisation begrenzen Speedup
Vergleichsmessung auf Deimos (Interaktionslos)
Netzwerk mit höheren Latenzen
•
Ungünstig für verwendete
Lastverteilung
•
Factoring: Leichte Verbesserung
•
Speedup mit den Werten auf der Altix
überhaupt nicht vergleichbar
•
Cluster nicht weiter betrachtet
Übersicht
I. Motivation und bisherige Arbeiten
Möglichkeiten und Zeitbedarf, Interaktive
Anwendungen, pragmatische Entwicklungen
II. Hardware und Bedingungen
IV. Bilddarstellung, Datenhaltung,
Bewertung der Berechnung
Display, Berechnung und Transport
Gemessen an zwei Testszenen
V. Zusammenfassung / Ausblick
Bilderzeugung, Bilddarstellung, Transport
VI. Programmvorführung
III. Ray Tracing
Algorithmus, Parallelisierungsansatz,
Berechnungsaufwand, BVH
III. Entwurf und Bibliothek
Komponenten, Funktionsumfang der Bibliothek
IV. Parallelisierung
Dynamische Lastverteilung, Arbeitsaufträge,
Entwicklung auf Neptun, Vergleichsmessungen
auf Deimos und den Partitionen der Altix
Display und Datenhaltung
1800 Bildpunkte
Tex1
Tex2
1050
Kopie 2
Windows XP
.obj
Kopie 1
Master
binär
Loader
...
.xml
Kopie N
Projektor1
Projektor2
Anzeige
•
•
•
•
Fenster: Doppelte Horizontale Auflösung
Betriebssystem teilt Bereiche den
Projektoren zu
Problem: Texture Download auf
Grafikkarte über PCIe
Pixel Buffer Objects: Verdoppelung der
Bandbreite auf ca. 840MB/s
.tga
HRSK
LCGV
Datenhaltung
•
•
•
Szenendaten werden auf dem Client
abgelegt und geladen
Temporäre Kopien auf den Slaves im
Hauptspeicher
N-fache Datenhaltung
Bewertung des Berechnungsprozesses an zwei Testzenen
Standardtestszene
Minimale Testszene
Bewertung des Berechnungsprozesses
t
Server:
Client:
Berechnung
Interaktion
Berechnung
...
Berechnung
Verarbeitung Verarbeitung
...
Verarbeitung Anzeige
Header lesen Daten lesen Dekomprimieren Daten kopieren
Größe
Download Display
Position
Standardtestszene
346,079 ms
Berechnung
79,144 ms
45,87 ms
223,82 ms
360,567 ms
Minimale Testszene
17,115 ms
Berechnung
13,286 ms
Header lesen
Daten lesen
52,778 ms
22,324 ms
Dekomprimieren
Daten kopieren
5,98 ms
Latenz
ggf. Wartezein
11,08 ms
Texture Download
Konstant: ca. 11ms
Zusammenfassung
• System bestehend aus Ray Tracer, Server und Darstellungsseite
• Ray Tracer (Bibliothek) mit den üblichen Funktionalitäten
• Parallelisierung durch den Server mit dynamischer Lastverteilung
•
•
•
Performance abhängig von Netzwerklatenzen
Auf der Altix linearer Speedup bis zu 120 Prozessoren möglich
Cache-Effekte beschränken den Speedup
• Ausnutzung der Bandbreite durch simple Komprimierung aber kontinuierliches
Senden
• Interaktion, Anzeige und Datenhaltung auf der Darstellungsseite
Ausblick
• Konzentration auf die Altix (Gemeinsamer Speicher, Netzwerklatenzen)
• Echtzeitraytracer
•
Speicherzugriffe optimiert auf Architektur
•
Für den Anwendungsfall optimale Beschleunigungsstrukturen
•
Beschleunigte Schnittberechnungen
• Zweites Halbbild aus der Berechnung des ersten Halbbildes ableiten
• Erhöhung der Bandbreite, Verzicht auf Komprimierung
Fragen?
Vielen Dank für Ihre Aufmerksamkeit
Switchinterne Kommunikation auf Deimos
•
•
Switch (Voltaire ISR 9288):
– Latenz < 420ns
Messwerte switchintern mit denen
auf der Altix vergleichbar
Beschränkungen:
•
•
•
Switch mit 288 Ports
Warteschlange (Large): 256 CPUs
Knoten mit privatem Adressbereich
– Von außerhalb nicht erreichbar
– Verbindungsaufbau von Knoten
nach außerhalb möglich
Einfluss von Texturen auf Chache-Effekte
•
Schlechte Lokalitätseigenschaften
•
Verhältnismäßig große Datenmenge
•
Mehr Misses bei Texturierung
Kameras
Stereoskopische Kameras
Offset
-Offset
LookUp
=>
LookAt
P
LookRight
-Offset
Perspektivische Kamera
•
•
Definiert durch
– Position, Raumlage, Bildebene
– Öffnungswinkel, Auflösung
Erlaubt effiziente Änderungen des
Blickpunktes und der Blickrichtung
Offset
-Offset
Offset
Parallel
Konvergent
•
•
•
Kombination aus zwei
perspektivischen
Kameras
Augenabstand:
Verschiebung um Offset
•
Zusätzlich
Fokussierung auf
Bildebene
Anpassung bei
Strahlerstellung