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“ [1] 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“ [2] 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“ [3]).
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:
- 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.
- 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.
- 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 [4]. 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
English
The Future of 3D Graphics
In recent years we’ve seen tremendous interest in utilizing the immense parallel processing power of GPUs for uses beyond classic 3D graphics processing. GPUs have evolved far beyond simply implementing a fixed function graphics pipeline to becoming flexible, programmable, massively parallel computers. Similarly, 3D graphics has evolved to encompass many forms of visual computing applications. GPUs are now considered “computational graphics” engines, as many of the fixed function parts of the graphics pipeline have become programmable. And we have only seen the beginning of this transformation.
GPUs Lead Evolution to Many-Core Processing
The programmable and flexible modern GPU is one of the most powerful computing devices on the planet. Since the year 2000, the individual processing cores within GPUs have processed data using IEEE floating point precision, just like standard CPUs (aka “real computers”). The raw floating point processing power of a modern GPU is much larger and growing faster than even the latest multi-core CPU. This feature has attracted a lot of attention in the computing community. In fact, an entire field of effort has been spawned called GPGPU, or General Purpose Processing on GPUs, reflecting the desire to use the power of the GPU for broader applications than just graphics. More recently, this broader effort, which we call GPU Computing, has been made easier by the introduction of NVIDIA’s CUDA (Compute Unified Device Architecture) programming environment. CUDA allows GPUs to be programmed using the C language for non-graphics applications.
All processors evolve and change with time, not just GPUs. We are seeing this with the difficult transition that CPUs are making from single-core to multi-core. Due to problems with heat dissipation and power consumption, it is no longer possible to create faster CPUs that simply run at ever higher clock rates. However, it’s quite easy to add multiple CPU cores to a single chip -- but that’s where the simplicity ends. It is difficult for programmers to grasp how to program multi-core CPUs effectively. Also, for the first time in several decades, programmers can no longer simply wait 18-24 months for their single-threaded programs to double in speed as processor clock speeds increase. An industry wide effort to “refactor” algorithms to run on multi-core CPUs is taking place while, at the same time, the emergence of GPU Computing gives programmers a new powerful tool. Today, few application programs benefit from multi-core CPUs. In contrast, the GPU programming model aided by graphics APIs and the C programming language is straightforward and easy to use. Although applying GPUs to a variety of parallel computing tasks is a natural evolution, trying to process demonstrably parallel graphics workloads with multi-core CPUs is inherently challenging – because simply grouping together many CPUs will not produce an integrated parallel processor. A GPU consists of many parallel processor cores integrated to work together from the ground up.
Graphics processors have arguably been multi-core processors for almost ten years. In 1998, NVIDIA’s TNT product was built with two pixel pipelines and two texture mapping units. We never looked back -- the current GeForce GT200 chip has 240 processor cores. And, not only does it have 240 processor cores, but each core can run many threads, or program copies, at a time. The GeForce GT200 processes over 30,000 threads at once -- each processing pixels, vertices, or triangles! Imagine achieving that kind of parallelism and throughput with dual- or quad-core CPUs. It’s just not possible. But, that’s not all. In addition to the 30,000+ pixel or vertex threads, there are many thousands of other concurrent operations being processed by the GPU. Texture map calculations, rasterization, Z-buffer hidden-surface-removal, color blending for transparency, and anti-aliasing (edge smoothing) are all happening simultaneously. Without the special-purpose hardware included in every GPU to perform these operations, it would require hundreds if not thousands of CPU cores to match the performance of a single GPU.
Is Ray Tracing Ready for Mainstream Use?
Some blogs and press reports have commented that the future of 3D graphics will be based on the feature known as “ray tracing,” and therefore the performance of rasterization is unimportant. While we are enormous fans of interactive ray tracing (IRT), it still requires a massive amount of processing power. IRT, along with many other ideas that we are pursuing, will provide at least another decade of innovation opportunity for GPU designers. The sustainable innovation opportunity will keep the GPU industry vibrant. But rather than a “start from scratch” architectural approach, we believe we need to preserve the massive investments of all the industries that are deeply invested in OpenGL and DirectX. We believe the most valuable architectures are those that extend rather than disrupt the installed base, such as x86, Windows, HTML, and TCP/IP. Preserving these investments is important not only for maintaining the productivity of current applications and developers, but also for encouraging investment in future applications. Furthermore, ray tracing is not a panacea or really a goal in itself, but rather -- potentially -- a way to make better pictures more easily. Although some people may say that ray tracing is more accurate or “the right way,” both ray tracing and rasterization are approximations of the physical phenomena of light reflection from surfaces. Neither is inherently better or worse -- just different. Three possible reasons for adopting ray tracing are 1.) ease of programming, and 2.) faster visual effects, and 3.) the possibility of better visual effects. Let’s talk about these reasons separately.
- Ease of programming is important for 3D graphics as well as for many other applications. Ray tracing is believed to be “easier” for programmers than rasterization because ray tracing can do everything in a single unified approach. Although it is true that rays can be traced for every possible visual effect, this is not necessarily the best and fastest approach.
- Ray tracing will never be as fast as hardware rasterization for the purpose of visibility (i.e., which objects the eye sees directly). Simple visibility is not enough, however. We also would like anti-aliasing (i.e., the smoothing of edges). Ray tracing can accomplish this effect by simply tracing more rays, although this is more expensive and slower than allowing the GPU hardware to perform this task through rasterization and dedicated anti-aliasing hardware.
- One visual effect that is difficult to do well with rasterization is shadows. It is complicated to render sharp-edged shadows without having jagged edges, and there are no really robust approaches for making soft-edge shadows or the corresponding effects of multiple inter-reflections of light. These are visual effects for which ray tracing is indeed a more general solution. Also, as light reflects from each surface to shine on other surfaces, every single object in a scene is both a light source and an occlude (an object that blocks light). In order to make the “perfect” picture, you would need to trace a ray from every point on every object in every direction. A lot of rays would be required to simulate all of that light bouncing around. Although this is conceptually simple, it is more work than is practical with modern CPUs.
Parallel GPU hardware can trace rays as well. Making a picture that is noticeably better than what rasterization can do today is a difficult but worthy goal. That is one of the most exciting parts of the field of computer graphics -- we’re never done. There is always something more to accomplish. The picture of the cathedral in this article is shown in two versions. Figure 1 could be rendered either with ray tracing or rasterization. There is no special effort involved in making shadows or correct global illumination. Figure 2 is rendered using global illumination. This is the effect of light inter-reflecting between surfaces. The back of the cathedral--behind the light--is lit by the reflection of the light off of the surfaces in front of the light. By the way, both of these images are rendered using a GPU. The bottom line is that a GPU can now make any picture that a CPU can make, rasterized or ray traced. The combination of special purpose GPU hardware and APIs (DirectX and OpenGL) with computational graphics is powerful.
The GPU Can Do It All
The old debate of ray tracing vs. rasterization has been going on as long as there has been ray tracing and rasterization. The debate has now morphed into ray tracing vs. GPUs. But, comparing an approach (ray tracing) with a device (GPU) is a funny way to express the comparison. That’s like asking which is better, fuel or automobiles? Most likely, the answer to both questions is both. Not only do GPUs perform rasterization efficiently using the conventional API-based programmable graphics pipeline, but GPU computing has the promise of performing other rendering approaches as well. It is likely that game developers, film studios, animators, and artists will prefer to take advantage of all of the benefits of ray tracing and rasterization, as well as a variety of other techniques, all at the same time. Why choose when you can have it all? Interestingly, one of the best GPGPU applications may be… 3D graphics!
About the Author
David Kirk has been NVIDIA's Chief Scientist since January 1997. His contribution includes leading NVIDIA graphics technology development for today’s most popular consumer entertainment platforms. In 2006, Dr. Kirk was elected to the National Academy of Engineering (NAE) for his role in bringing high-performance graphics to personal computers. Election to the NAE is among the highest professional distinctions awarded in engineering. In 2002, Dr. Kirk received the SIGGRAPH Computer Graphics Achievement Award for his role in bringing high-performance computer graphics systems to the mass market. From 1993 to 1996, Dr. Kirk was Chief Scientist, Head of Technology for Crystal Dynamics, a video game manufacturing company. From 1989 to 1991, Dr. Kirk was an engineer for the Apollo Systems Division of Hewlett-Packard Company. Dr. Kirk is the inventor of 50 patents and patent applications relating to graphics design and has published more than 50 articles on graphics technology. Dr. Kirk holds B.S. and M.S. degrees in Mechanical Engineering from the Massachusetts Institute of Technology and M.S. and Ph.D. degrees in Computer Science from the California Institute of Technology.