GCMUC09: 3D-Games und Multicore-Programmierung
Um 15 Uhr war Aaron Coday von Intel auf dem GameCamp Munich 2009 mit seiner Techsession “3D-Games und Multicore-Programmierung” dran. Zwar war der Raum nicht ganz voll, dafür war die Diskussion umso lebhafter und brachte den Anwesenden wohl eine ganze Menge an Erkenntnissen:
Aspekt #1: Single-Core-Maschinen werden immer mehr von Multicore-Rechnern abgelöst. Das hat damit zu tun, dass sich der CPU-Takt nicht weiter erhöhen lässt.
Problem #1: 3D-Game-Programmierung ist nicht trivial, weder sequenziell noch parallel. Was schon geschieht ist ein zeitversetztes “Update World” und “Rendering” (z.B. auf der Xbox 360).
Hoffnung #1: Viele Dinge bei der 3D-Programmierung lassen sich parallelisieren, z.B. Rendering, Physics, KI, Particles.
Herausforderung #1: Wie verteile ich das Spiel auf die notwendigen Threads und auf die vorhandenen Ressourcen (= Core)?
Parallele 3D-Programmierung #1: Mach aus einzelnen Tasks – wie KI, Physics, Rendering, Update World – Subtasks!
Herausforderung #2: Definiere Abhängigkeiten der einzelnen Tasks!
Lösung #1: Intel TBB hilft Gaming-Entwicklern dabei, die anfallenden Tasks möglichst gut auf die vorhandenen Cores zu verteilen. Hierzu bedient sich Intel TBB eines Thread Pools, der für jeden Task einen eigenen Thread bereit hält.
Analogie #1: Beim Verwalten von Tasks geht es genauso zu wie im Supermarkt: Sobald ein Task-Queue frei wird (=Kasse), wird ein bereits wartender Task in eine freie Queue verschoben ( =Task-Stealing).
Lösung #2: Die “Größe” einer Task wird vom Task Partitioner bestimmt, um ein Load Imbalancing zu vermeiden.
Lehre #1: Wenn mehr Game Designer mehr über parallele Programmierung und deren Grenzen/Möglichkeiten wüssten, würden sich die Spieleprogrammierer ein gutes Stück leichter tun.
Ausblick #1: Larrabee wird eine Manycore-GPU-Lösung sein, die wohl Ende nächsten Jahres auf den Markt kommen wird.
Ausblick #2: Eines Tages werden CPUs und GPUs verschmelzen und zu einer leistungsfähigen Einheit mutieren.
Ausblick #3: OpenCL wird die Programmiermethoden verändern (und hoffentlich verbessern).
GamesCamp Munich 09: 3D-Games und Multicore
In etwa einer halben Stunde wird Aaron Coday die Bühne betreten und eine ganze Menge über das Thema “Parallelprogrammierung und 3D-Games” erzählen. Dabei geht es um die Methoden und Techniken, die zum Einsatz kommen sollten, um ein Spiel in C++ nicht sequenziell, sondern parallel zu programmieren. Dann klappt’s nämlich auch mit den schönen Bildern, intelligenten Gegnern, extremen Wetterverhältnissen und anderen Dingen.
Außerdem wird Aaron wohl das ein oder andere über Larrabee erzählen, die zukünftige GPCPU-Lösung von Intel, mit der sich sehr parallel und sehr schnell nicht nur 3D-Berechnungen, sondern auch ganz allgemeine Aufgaben durchführen lassen.
Deshalb: Kommet doch alle um 15 Uhr in den Raum Quantm auf dem GamesCamp Munich 2009.
Eurographics 2009: Tech-Session Ray Tracing vs. Rasterisierung
Direkt im Anschluss an die Larrabee-Session von Mat Pharr war Manfred Ernst an der Reihe, um über das Thema Ray Tracing zu referieren. Am Anfang zeigte Manfred eine angepasste Quake Wars-Demo, die nicht auf Basis der klassischen Rasterisierung generiert wird, sondern mithilfe von Ray Tracing. Sehr beeindruckend!
Ray Tracing zeichnet sich durch vier wesentliche Aspekte aus: Flexibilität, Qualität, Einfachheit und Robustheit.
Flexibilität: Auf Basis der Rasterisierung lassen sich unterschiedliche Perspektiven nur mit viel Aufwand darstellen. Vor allem dann, wenn die Zahl der darzustellenden Datenobjekte sehr groß ist. Ray Tracing ist hierfür viel besser geeignet. Aber: Rasterisierung ist schneller als Ray Tracing. Daher ist für akzeptables Ray Tracing leistungsfähige Hardware notwendig.
Qualität: Die erzielbare Bildqualität ist mit Ray Tracing deutlich höher als mit Rasterisierung. Dies betrifft vor allem Schatten, spiegelnde Flächen wie Wasseroberflächen etc. Doch wer braucht diesen Level an realistischer Bildqualität? Nun, vor allem Architekten, Produktdesigner, Animationsfilmer und natürlich Spieleentwickler.
Einfachheit: Die Implementierung einer Rasterisierung-Engine ist im Vergleich zu Ray Tracing deutlich einfacher, aber bei der Programmierung neuer Effekte haben Ray Tracer große Vorteile. So lassen sich bestehende und neue Shader-Effekte mit weniger Programmierzeilen in eine 3D-Anwendung implementieren.
Robustheit: Rasterisierungs-Implementierung sind meist nicht robust genug. Vor allem die Zunahme verschiedener Effekte innerhalb einer Szene überfordert Rasterisierungs-Engines zusehend. Dieses Problem lässt sich mit Ray Tracing recht einfach lösen. Das geht allerdings mit großen Anstregungen hinsichtlich der Render-Engines einher. Denn eines ist klar: Robuste 3D-Engines sind äußerst wichtig, da gerade beim Erstellen von 3D-Szenen etc. viel Zeit und damit viel Geld aufgewendet wird.
Eurographics 2009: Tech-Session Larrabee
Jetzt sitze ich hier also seit über zehn Jahren zum ersten Mal wieder in einem Hörsaal, wartend auf den Beginn der Intel-Session zu den Themen Ray Tracing und Larrabee. Das wird zwar nicht unbedingt in Live-Blogging ausarten, aber während das Diktiergerät alles aufzeichnet, werde ich während der zwei Vorträge von Manfred Ernst und Mat Pharr die Highlight-Statements schon mal veröffentlichen. So, lean back and enjoy the show.
Der Saal ist gut gefüllt, die Themen scheinen also voll im Trend zu liegen. Als erster ist Mat Pharr dran, der sich bei Intel um das Thema Larrabee kümmert.
Matt beginnt mit einer kurzen Einführung: Fließpunkt-Arithmetik ist mittlerweile ausreichend vorhanden und 3D existiert in Software und nicht mehr ausschließlich in Hardware. Das bedeutet, das Prozessoren immer flexibler werden, vor allem, wenn man an neue Anwendungsgebiete wie 3D-Darstellungen denkt.
Ein kurzer Rückblick: 2001 war die Darstellung von 3D-Daten sehr gebunden an die Hardware. Mittlerweile kann das dank der enormen Rechenleistung vollständig in Software geschehen.
Was ist Larrabee? Letztlich der Zusammenschluss einer Multicore-CPU und einer programmierbaren, parallelisierten Grafikeinheit.
Schöner Versuch: Was bringt die Erhöhung der verfügbaren Prozessorkerne um den Faktor fünf in Sachen Rechenleistung? Den Faktor 160!
Das Larrabee-Blockdiagramm zeigt vor allem eins: Es gibt einen gemeinsamen L2-Cache, auf den sämtliche Prozessorkerne zugreifen.
Die Lehre der nächsten Folie: Sowohl das Berechnen einer 3D-Szene als auch Rendern dieser fertigen Szene sind in höchstem Maße parallelisierbar. Daher ist der Rasterisierer von Larrabee natürlich bestmöglich parallelisiert.
Dank Larrabee lässt sich in Zukunft die komplette 3D-Berechnung in Software realisieren und so der komplette 3D-Workflow als Software-Pipeline abbilden. Das macht Spezialhardware wie Grafikkarten selbst für aufwendige 3D-Berechnung künftig überflüssig.
Larrabee versteht sich auf das unmittelbare Umwandeln zwischen verschiedenen Datenformaten. So lassen sich FP32-Daten problemlos in FP16-Daten konvertieren, falls dies notwendig ist.
Problem heutige 3D-Spiele: Es gibt keinen ausgewogenen Workload, da jedes Game seinen eigenen Schwerpunkt hat in Sachen Alpha Blending, Pixel Shading, Rasterisierung, Vertex Shading etc. Mit Larrabee wird sich dieses Problem einfacher lösen lassen, da Larrabee sehr viel flexibler mit unterschiedlichen Workloads umgehen kann.
Die GPU-Programmierung wird sich mit Larrabee vollständig ändern: Sie wird parallel programmierbar!
