Kommentar: Die Zukunft der 3D-Grafik mit GPU-Computing und Raytracing

Einleitung

Bereits zwei Mal haben wir uns auf ComputerBase der Zukunft der 3D-Grafik gewidmet. Im Januar 2007 gewährte unser Gastautor Daniel Pohl unter dem Titel „Raytracing in Spielen - Einblicke in ein alternatives Rendering-Verfahren“ einen tiefen Einblick in die Raytracing-Technologie, ausgeschmückt mit Beispielen aus seinem im Alleingang gestemmten Projekt „Quake 4: Raytraced“. Gut ein Jahr später, im März 2008, erschien mit „Raytracing in Spielen 2.0 – Fortschritte im Reich der Strahlen“ eine Fortsetzung des erfolgreichen ersten Teils. Der große Unterschied: Mittlerweile war Daniel Pohl bei Intel angestellt, der Bericht auch in diesem Zusammenhang zu betrachten (Stichwort Projekt „Larrabee“).

Raytracing als Ablösung der auf GPUs heutiger Generationen eingesetzten Rasterisierung? Ein Hybrid-Ansatz aus beiden Verfahren nicht überzeugend? Die Berichte stießen abseits von Intel nicht überall auf Zustimmung. Erst recht nicht bei Nvidia.

Zwei Parteien, zwei Meinungen. Mehr braucht es nicht für eine gehaltvolle Diskussion. Und so freuen wir uns, dass wir unseren Lesern heute erneut einen ganz besonderen Artikel auf ComputerBase bieten können. Quasi als Antwort auf die von Daniel Pohl veröffentlichten Artikel präsentieren wir heute in deutscher sowie in englischer Fassung einen Beitrag von David Kirk, seines Zeichens Chefwissenschaftler bei Nvidia.

Deutsch

Die Zukunft der 3D-Grafik

In den letzten Jahren haben wir ein enormes Interesse daran, die immense Rechenleistung parallel ausgelegter GPUs jenseits der Verarbeitung klassischer 3D-Grafik nutzen zu können, beobachten dürfen. GPUs haben sich weit über die einfache Implementierung von Pipelines, die auf feste Funktionen beschränkt sind, hinaus entwickelt. Sie sind zu flexiblen, programmierbaren, vielfach parallelen Recheneinheiten geworden. Gleichermaßen hat sich die 3D-Grafik an sich entwickelt und umfasst heute viele Formen visueller EDV-Anwendungen. GPUs werden heute, da viele der mit fixen Funktionen belegten Bausteine der Grafik-Pipeline programmierbar geworden sind, als „Computational Graphics Engines“ angesehen. Und bisher haben wir lediglich den Anfang dieser Transformation beobachten können.

Die GPU führt die Evolution zur Multi-Core-Bearbeitung

Die moderne, programmierbare und flexible GPU ist eine der leistungsfähigsten Rechenapparate auf diesem Planet. Seit dem Jahr 2000 verarbeitet jeder individuelle Rechenkern einer GPU Daten mit IEEE-Gleitkomma-Präzision, genau wie herkömmliche CPUs (alias „echte Rechner”). Die rohe Floating-Point-Leistung einer modernen GPU ist jedoch wesentlich größer und wächst schneller als die der aktuellsten Multi-Core-CPUs. Eine Eigenschaft, die viel Aufmerksamkeit in der EDV-Gemeinschaft auf sich gezogen hat. Ja, es hat sich gar ein gänzlich neues Tätigkeitsfeld namens GPGPU (General Purpose Processing on GPU – Mehrzweck-Berechnungen auf einer GPU) gebildet, das das Verlangen nach der Nutzung der ganzen GPU-Leistung für breiter gefächerte Anwendungen – nicht nur für Grafik – widerspiegelt. Erst vor kurzem wurde dieser breite Ansatz, den wir „GPU Computing“ nennen, mit Einführung der programmierbaren Nvidia-CUDA-Plattform (Compute Unified Device Architecture) vereinfacht. CUDA ermöglicht es, GPUs durch Einsatz der Programmiersprache C für nicht-grafische Anwendungen zu programmieren.

Nicht nur GPUs sondern alle Prozessoren entwickeln und ändern sich mit der Zeit. Gut zu sehen ist dies zurzeit am Beispiel der herkömmlichen CPUs und ihrem Wechsel von einem auf mehrere Kerne. Aufgrund von Problemen mit der Hitzeentwicklung und der Leistungsaufnahme war es nicht mehr länger möglich, immer schnellere CPUs zu erschaffen, die einfach auf höheren Taktraten laufen. Dabei ist es zwar recht einfach, mehrere CPU-Kerne auf einem Chip zu vereinen – doch damit endet die Einfachheit auch schon. Denn für Programmierer ist es schwer zu fassen, wie sich Multi-Core-CPUs effizient programmieren lassen. Darüber hinaus reicht es das erste Mal seit Jahrzehnten nicht mehr nur aus, dass Programmierer 18 bis 24 Monate abwarten und zusehen, wie ihre Single-Thread-Applikationen mit immer höheren CPU-Taktraten ihre Geschwindigkeit verdoppeln. Industrieweite Bemühungen sind neuerdings notwendig, die bestehenden Algorithmen neu zu ordnen („Refactoring“), sie auf Multi-Core-Prozessoren laufen zu lassen und die Einführung von GPU Computing, der Berechnung von Daten auf dem Grafikprozessor, gibt Programmieren ein mächtiges Werkzeug in die Hand. Nur wenige Anwendungsprogramme profitieren heute vom Einsatz einer Multi-Core-CPU, während sich GPUs dank APIs und der Programmiersprache C unkompliziert und einfach programmieren lassen. Während der Schritt zur parallelen Bearbeitung verschiedener Aufgaben auf einer GPU zur natürlichen Evolution dieses Bausteins gehört, ist der Versuch, nachweislich parallele Grafik-Aufgaben zu bearbeiten, für die CPU von Natur aus herausfordernd – schlicht und ergreifend deshalb, weil die einfache Gruppierung vieler CPUs noch keinen integriert-parallelen Prozessor schafft. Die GPU hingegen besteht von Grund auf aus vielen parallelen Prozessorkernen, die integriert zusammen arbeiten.

Grafikchips sind seit beinahe zehn Jahren Multi-Core-Prozessoren gewesen. Nvidias TNT aus dem Jahr 1998 war mit zwei Pixel-Pipelines und zwei TMUs ausgestattet. Und wir haben niemals zurück gesehen – die aktuelle GeForce GTX 200 verfügt über 240 Prozessorkerne. Und nicht genug damit, dass sie 240 Prozessoren besitzt, jeder der Prozessoren kann darüber hinaus viele Threads, oder Kopien eines Programms, gleichzeitig ausführen. Die GeForce GTX 200 bearbeitet über 30.000 Threads zur selben Zeit – jeder einzelne davon bearbeitet Pixel, Vertex oder Triangles. Ist ein derartiges Level an Parallelisierung und Durchsatz auf Dual- oder Quad-Core-CPUs vorstellbar? Nein, ist es nicht. Aber das ist nicht alles. Neben den über 30.000 parallel möglichen Pixel- oder Vertex-Threads werden viele Tausend weitere simultane Operationen durch die GPU bearbeitet. Textur Mapping, Rasterisierung, Z-Buffer (das Entfernen der für den Betrachter nicht einsehbaren Bestandteile der Szenerie), Color Blending für Transparenzen und Anti Aliasing (Kantenglättung) finden alle gleichzeitig statt. Ohne die auf genau diese Anwendungen spezifisch ausgelegten Bestandteile einer GPU würde es mehrere Hundert, ja wenn nicht gar Tausend Prozessorkerne benötigen, um die Leistung einer GPU zu erreichen.

Ist Raytracing bereit für den Alltagseinsatz?

In einigen Blogs und Presseberichte war zu lesen, dass die Zukunft der 3D-Grafik auf einem Feature namens “Raytracing” basieren wird, die hier und jetzt gezeigte Leistung der Rasterisierung deshalb unter dem Strich keine Rolle spielt. Während auch wir große Fans von Interactive Raytracing (IRT) sind, bleibt es allerdings dabei, dass das Verfahren gewaltige Mengen an Rechenpower benötigt. IRT wird, ebenso wie eine Reihe anderer Ideen, die wir verfolgen, zwar auch die kommenden zehn Jahre nachhaltig Möglichkeiten zur Innovation liefern und die Industrie lebendig halten. Aber anstatt eine neue Architektur von der Pike auf aus dem Boden zu stampfen, glauben wir, dass es die großen Investitionen der gesamten Industrie zu erhalten gilt, die tief in DirectX und OpenGL verankert sind. Wir glauben, dass die wertvollsten Architekturen die sind, die die bestehende Technologiebasis erweitern und nicht die, die sie unterbrechen. Als Beispiele seien x86, Windows, HTML und TCP/IP genannt. Diese Investitionen zu erhalten, ist nicht nur notwendig, um die Produktivität aktueller Anwendungen und Entwickler aufrecht zu erhalten, sondern auch, um Investitionen in zukünftige Anwendungen zu ermutigen. Darüber hinaus ist Raytracing weder ein Allheilmittel noch ein für sich greifbares Ziel. Raytracing ist – potentiell – ein weiterer Weg, bessere Bilder einfacher auf den Monitor zu zeichnen. Auch wenn einige der Meinung sind, dass Raytracing akkurater und “der richtige Weg” ist, sowohl Raytracing als auch Rasterisierung sind lediglich Annäherungsverfahren für das physikalische Phänomen der Lichtreflektionen auf Oberflächen. Keines ist aus sich heraus besser oder schlechter – sie sind schlichtweg unterschiedlich.

Drei mögliche Gründe, die für die Anwendung von Raytracing sprechen, sind 1.) die Einfachheit der Programmierung, 2.) schnellere visuelle Effekt und 3.) die Möglichkeit zu besseren visuellen Effekten. Reden wir über alle drei Gründe separate:

1. Die Komplexität bzw. der Schwierigkeitsgrad ist bei der Programmierung von 3D-Grafik sowie andere Applikationen von großer Bedeutung. Von Raytracing wird allgemein angenommen, dass es einfacher ist als Rasterisierung, weil es alles mit einem einzigen, einheitlichen Ansatz umsetzen kann. Doch auch wenn es wahr ist, dass Strahlen für jeden nur erdenklichen visuellen Effekt eingesetzt werden können, ist es nicht notwendigerweise der schnellste Ansatz.
2. Raytracing wird, wenn es um den Einsatzbereich Sichtbarkeitprüfung (d.h. die Frage, welche Objekte der Betracher sieht und welche nicht) geht, nie so schnell wie Rasterisierung in Hardware sein. Und Sichbarkeit ist nicht genug, wir wollen auch Anti Aliasing (d.h. das Weichzeichnen von Kanten). Raytracing kann diese Effekte erreichen, indem einfach mehr Strahlen verfolgt werden, doch dieser Weg ist aufwendiger und langsamer als würde man die Aufgaben durch die GPU (per Rasterisierung) oder durch dedizierte Anti-Aliasing-Hardware erledigen lassen.
3. Ein visueller Effekt, der mittels Rasterisierung nur mit Schwierigkeiten gut umzusetzen ist, sind Schatten. Es ist kompliziert, scharfkantige Schatten ohne schroffe Ränder zu rendern, und es existieren zurzeit noch nicht wirklich verlässliche Ansätze zur Erzeugung weicher Schatten oder des damit korrespondierenden Effektes des mehrfach wechselseitig-reflektierenden Lichtes. Dies sind visuelle Effekte, für die Raytracing in der Tat ein allgemeingültigerer Ansatz ist. Auch weil Licht von jeder Oberfläche auf jede andere Oberfläche scheint und jedes einzelne Objekt einer Szene sowohl Lichtquelle als auch verdeckendes Objekt ist. Um das “perfekte” Bild zu zeichnen, müsste man jedoch einen Strahl von jedem Punkt auf jedem Objekt in jede Richtung werfen. Eine ganze Menge Strahlen wäre notwendig, um das umher springende Licht zu simulieren. Was sich theoretisch einfach anhört, artet in der Praxis in mehr Rechenaufwand aus, als ihn moderne CPUs bewerkstelligen können.

Auch parallel ausgelegte GPU-Hardware kann Strahlen verfolgen. Ein Bild zu zeichnen, dass spürbar besser ist als das, was Rasterisierung heute bewerkstelligen kann, ist ein schweres aber lohnendes Ziel. Einer der aufregendsten Aspekte auf dem Feld der Computer-Grafik ist: Wir sind niemals fertig. Es gibt immer irgendetwas, das es noch zu erreichen gilt. Das Bild der Kathedrale in diesem Artikel beispielsweise ist in zwei unterschiedlichen Versionen dargestellt. Bild 1 könnte entweder mit Ray Tracing oder mit Rasterisierung gerendert werden. Es gibt in ihm keine speziellen Anstrengungen, Schatten oder die korrekte globale Ausleuchtung darzustellen. Bild 2 hingegen ist inklusive globaler Ausleuchtung gerendet worden. Globale Ausleuchtung beschreibt den Effekt wechselseitiger Lichtreflektionen zwischen Oberflächen. Die Rückseite der Kathedrale (hinter dem Licht) wird in diesem Fall von dem Licht, das die Wände vor der Lampe reflektieren, ausgeleuchtet. Übrigens, beide Bilder wurden auf einer GPU gerendert. Die Quintessenz: Eine GPU kann heute jedes Bild zeichnen, das eine CPU erstellen kann – egal ob per Rasterisierung oder Raytracing. Die Kombination aus auf einen speziellen Zweck ausgelegter Hardware (GPU) und APIs (DirectX und OpenGL) in Bezug „auf Computational Graphics“ ist mächtig.

Die GPU kann es alles

Die alte Debatte Raytracing vs. Rasterisierung wird geführt, seit es Raytracing und Rasterisierung gibt. Neuerdings hat sich die Debatte in die Diskussion Raytracing vs. GPUs gewandelt. Doch eine Methode (Raytracing) mit einem Baustein (GPU) zu vergleichen, ist ein witziger Weg um den Vergleich zu führen. Vergleichbar mit der Frage, ob denn der Treibstoff oder das Automobil besser sei. Höchstwahrscheinlich ist die Antwort auf beide Fragen „beides“. Nicht nur, dass GPUs die Rasterisierung unter dem Einsatz konventioneller, programmierbarer und auf APIs basierender Pipelines effizient ausführen können. Die Berechnung auf der GPU verspricht darüber hinaus, auch andere Rendering-Ansätze ausführen zu können. Es ist wahrscheinlich, dass Spieleentwickler, Filmstudios, Animateure und Künstler es bevorzugen werden, einen Vorteil aus sämtlichen Vorzügen der Ansätze Rasterisierung und Raytracing sowie einer Vielzahl andere Techniken ziehen zu können – und zwar zur selben Zeit. Also warum eine Wahl treffen, wenn man alles haben kann? Eine der besten GPGPU-Anwendungen könnte interessanterweise... 3D-Grafik sein!

[Anm.d.Red.: Anlässlich der SIGGRAPH 2008 hat Nvidia der Öffentlichkeit am 15. August 2008 einen tieferen Einblick darin gewährt, wie die Kombination aus GPU, GPGPU-Anwendungen und Raytracing aussehen könnte: Nvidia zeigt Rayctracing auf der GPU. Bereits auf der CeBIT im März gab es erste Häppchen hinter verschlossenen Türen zu sehen.]

Über den Autor

Seit 1997 ist David Kirk Chefwissenschaftler bei Nvidia. Er hat unter anderem maßgeblich zur Entwicklung der heute populären Consumer-Grafikkarten-Plattformen beigetragen. 2006 wurde David Kirk in Folge seiner Verdienste in die National Academy of Engineering (NAE) berufen. Die Wahl in die NAE gehört zu den höchsten Auszeichnungen auf dem Entwicklungssektor in den USA. 2002 erhielt David Kirk den „SIGGRAPH Computer Graphics Achievement Award“ für seine Rolle, hochperformante Computer-Grafik auf dem Massenmarkt zu etablieren. Von 1993 bis 1996 war David Kirk Chefwissenschaftler und CTO beim Spieleentwickler Crystal Dynamics. Von 1989 bis 1991 war David Kirk Entwickler bei der AAollo Systems Division von Hewlett-Packard Company. David Kirk ist der Erfinder hinter 50 Patenten und Patentanmeldungen in Verbindung mit Grafikdesign und hat mehr als 50 Artikel zu diesem Thema verfasst. Dr. Kirk besitzt einen Bachelor sowie Master in Maschinenbau des Massachusetts Institute of Technology (MIT) sowie einen Master und Doktortitel in Computer Science des California Institute of Technology