Interaktives Remote Path-tracing unter Verwendung des HPC-Clusters des HLRS

170717 DKoerner Artikel header

Den HPC-Cluster wie eine traditionelle Renderfarm einzusetzen ist relativ unkompliziert. Jedes Bild wird auf einem einzelnen Compute-Knoten des Clusters berechnet und das Ergebnis wird auf dem Dateisystem gespeichert. Auf diese Weise wird der HPC-Cluster allerdings nicht entsprechend seiner Stärke eingesetzt, welche die schnelle Verbindung zwischen den Knoten mit hohem Datendurchsatz und niedriger Latenz ist.

Eine der Missionen des Media Solution Center BW ist es, Anwendungen in der Medienproduktion zu finden und zu entwickeln, welche speziell von den Stärken des HPC-Clusters profitieren. Im Bereich Rendering, ist das interaktive Path-tracing eine solche Anwendung. Hier wird anstelle eines einzelnen Bildes pro Knoten, ein Bild verteilt auf mehrere Knoten berechnet. Die niedrige Latenz ist dabei sehr wichtig für eine reibungslose Nutzerinteraktion. Zusätzlich ist der Anwender nicht am HLRS vor Ort, sondern entfernt an seinem Arbeitsplatz. Daher ist das auf dem Cluster verteilt rechnende Backend über das Internet mit einem Frontend, wie z.B. einer Web-Anwendung, verbunden.

 

Das folgende Video zeigt den entwickelten Prototypen:

Bildschirmvideo des interaktiven path-tracing Prototypen in Benutzung. Bei diesem Beispiel wurden 30 Knoten des HPX clusters, mit einer Gesamtmenge an 720 CPU Kernen, eingesetzt.

 

Im Folgenden erläutern wir die verschiedenen Aspekte der Prototyp Umsetzung. Der komplette Quellcode ist auf GitHub: https://github.com/MSC-BW/msc-liverendering

Das Rendering Backend

Das Backend ist er Teil der Anwendung, der auf den Compute-Knoten des Clusters ausgeführt wird. Es empfängt Änderungen der Szene vom Frontend und führt diese aus. Zudem produziert es kontinuierlich ein Bild des aktuellen Szenenzustandes von immer besserer Qualität. Die Änderungen entsprechen den vom Nutzer gewünschten Aktualisierungen der Szene, wie zum Beispiel eine neue Kameraperspektive, geänderte Objektparameter, sowie dem Hinzufügen oder Entfernen von Elementen.

Eine wichtige Frage ist hierbei die Wahl der Rendering-software. Eine eigene Entwicklung war keine Option, und somit wurde ein Renderer gesucht, der insbesondere die schnelle Verbindung der Knoten berücksichtigt. Zusätzlich sollte der Renderer Open-Source Software sein, für den Fall das Änderungen für die Anwendung notwendig waren.

Nachdem einige Optionen, wie Cycles, Luxrender, Appleseed und andere evaluiert worden waren, fiel die Entscheidung letztendlich auf OSPRay (http://www.ospray.org), einem Renderer, welcher von einem Team bei Intel entwickelt wird. Der Hauptgrund für diese Entscheidung war der, dass OSPRay speziell für den Betrieb auf HPC-Clustern entwickelt worden war. Insbesondere nutzt es das Message Passing Interface (MPI) für die Kommunikation zwischen den Knoten und unterstützt damit Aries, welches auf dem Cluster des HLRS zur Kommunikation eingesetzt wird. Kein anderer Open-Source Renderer hatte diese Eigenschaft.

 

Ein Nachteil ist der, dass der Renderer hauptsächlich für Anwendungen im Bereich der wissenschaftlichen Visualisierung (SCIVIS) entwickelt wurde. Es ist allerdings ein aktueller Trend in SCIVIS, physikalisch basiertes Rendering zu nutzen, um ansprechendere Bilder mit besserer Lesbarkeit zu erzeugen. Daher besitzt OSPRay physikalisch basierte Lichtquellen, Kameras, Materialien und enthält damit alle grundlegenden Bausteine zur Lichttransportsimulation. Dies war für unsere prototypische Anwendung ausreichend, allerdings raten wir davon ab, OSPRay für das Rendering in der Produktion einzusetzen.

Ein anderer wichtiger Aspekt ist die Komprimierung der Bilddaten, welche zum Frontend geschickt werden. In der ersten Implementierung werden die Bilder per JPEG komprimiert, und dann versendet. Sollte die Netzwerklatenz und Nutzerentfernung ein Problem werden, können fortgeschrittenere Verfahren, wie das Video-streaming eingesetzt werden.

Kommunikation

Dieser Teil verbindet das Backend mit dem Frontend. Bilder werden kontinuierlich vom backend an das Frontend übertragen, während die Änderungen der Szene vom Frontend an das Backend nur sporadisch bei einer Nutzerinteraktion gesendet werden. Dieser Teil stellte eine Herausforderung dar, da keine direkten Verbindungen zwischen Compute-Knoten und der Außenwelt möglich sind. Dies zum einen aus Sicherheitsgründen, und zum anderen weil bei traditionelle HPC-Anwendungen Eingaben eines entfernten Nutzers während der Simulation nicht notwendig sind. In unserem Anwendungsfall ist das anders.

 

Bei der Umsetzung des Prototyps wurde dieses Problem mit der Implementierung einer kleinen Proxy-anwendung gelöst. Diese läuft im inneren des HLRS-Netzwerks, aber außerhalb des HPC-Clusters. Von da kann sich der Proxy gleichzeitig mit den Compute-Knoten und dem Frontend (per SSH Tunnel) verbinden. Sobald die Verbindung aufgebaut ist, werden Nachrichten einfach in beiden Richtungen von einem Endpunkt zum anderen weiter geleitet.

 

Ein nützlicher Nebeneffekt eines solchen Proxies ist, dass er als Brücke verschiedener Kommunikationsprotokolle dienen kann. Das Browser-basierte Frontend kommuniziert mit Hilfe von Websockets, während das Backend ausschließlich einfache TCP Pakete erwartet. Der Proxy ermöglicht gleichzeitig eine Websocket-verbindung hin zum Frontend, und eine gewöhnliche TCP Verbindung zum Backend (welche mit ZeroMQ realisiert wurde). Eine TCP Verbindung zu einer Standalone-Client-Anwendung wäre ebenfalls möglich.

 

communcation

Figure 1: Outline of the communication setup for our prototype

Front-end

Das Frontend ist eine Javascript Web-Anwendung, welche im Browser innerhalb einer HTML-Seite läuft. Sie empfängt kontinuierlich Bilder vom Backend und stellt diese dar. Nutzerinteraktionen, wie das Ändern eines Parameters, oder das ändern der Kameraperspektive, werden zur Übertragung als Befehle in ein Binärformat gepackt und versendet.

Die Frage, wie eine Szene und deren Änderungen in einer Verteilten Anwendung repräsentiert wird, stellt Scene-API’s vor interessante Herausforderungen. Scene-API’s sind Programmierschnittstellen, welche die Speicherung und interne Repräsentation einer Szene abstrahieren. Moderne Scene-API’s, wie die Universal Scene Description von Pixar (https://github.com/PixarAnimationStudios/USD), oder das Nodal Scene Interface von 3Delight (www.3delight.com/nsi.pdf), sind für den Einsatz in verteilten Anwendungen ausgelegt. Um die Dinge einfach zu halten, entschieden wir uns eine eigene kleine API in Anlehnung an NSI zu entwickeln.

 

sceneapi

Figure 2: Scene API in interactive distributed applications

Ausblick

Unsere prototypische Implementierung zeigt, das interaktive Anwendung mit einem entfernten Anwender auf dem Cluster möglich sind. Allerdings benötigt die Ausführung des Prototyps das Anlegen eines SSH Tunnels und das manuelle Ausführen der Backend- und Proxyanwendung über ein Terminal. In Zukunft möchten wir diesen und ähnliche Prozesse mit Hilfe einer Softwareplattform einfacher machen, welche einige Infrastrukturfunktionen anbietet und deren Komplexität verbirgt.

Eine andere offene Frage betrifft das Planen und Ausführen von interaktiven Sitzungen auf dem Cluster mit einem Batch-system, welches für nicht-interaktive Aufgaben entworfen wurde. Das Anfordern von 30 Knoten auf dem Cluster benötigt im Mittel eine nicht unerhebliche Wartezeit. Das ist für interaktive Anwendungen nicht praktikabel.

 

Links:

Kompletter Quellcode:  https://github.com/MSC-BW/msc-liverendering

OSPray: http://www.ospray.org

Pixar’s Universal Scene Description:  https://github.com/PixarAnimationStudios/USD

Nodal Scene Interface from 3Delight:  www.3delight.com/nsi.pdf

Facebooktwittermail

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.