Baue eigene 3D-Games – for free und Multicore-optimiert

Dass Intel die Software-Gemeinde schon seit vielen Jahren mit Entwicklertools, Know-how und einer eigenen Gemeinde unterstützt, ist ja nichts Neues. Dass man aber als Spiele-Entwickler die geballte Kraft des UDK (Unreal Developer Kit) kostenlos bekommt, ist schon etwas ganz Besonderes. Finde ich.

Das UDK bietet so ziemlich alles, was man als ambitionierter Spieleentwickler braucht. Neben Unreal Engine 3 bietet es beispielsweise das integrierte Beleuchtungsmodell Lightmass, mit dem sich Lichteffekte wie Reflektionen von Glanzlichtern und verstreute Lichtquellen im Offline-Modus, also vorab, berechnen lassen. Und da UE3 höchst Multicore-optimiert ist, profitieren Game-Entwickler bei der Berechnung von Spielszenen und -Leveln von den schnellen 8- oder 12-Core-Prozessor-Maschinen, in denen eine Intel-CPU werkelt.

Aber auch die Möglichkeit, mithilfe von Unreal Swarm komplexe 3D-Berechnungen nicht nur von einem, sondern von einem ganzen Rechnernetzwerk durchführen zu lassen, spricht für Unreal Engine 3, respektive Unreal Developer Kit. Und auch weitere Features wie das Unreal Build Tool, Navigation Meshes und der Content Browser machen aus Unreal Engine 3 eine extrem leistungsfähige Entwicklerplattform für aufwändige 3D-Spiele. Und das alles für umsonst?! Kaum zu glauben…

Video: So lassen sich Spiele mit Intel GPA optimieren

Zugegeben, die Develop 2010 ist mittlerweile über eine Woche alt, und doch tauchen immer wieder nützliche Infos rund um das Thema Spieleprogrammierung auf. So auch heute auf dem SoftTalk Blog, auf dem ich ein interessantes und informatives Video gefunden habe. In diesem Fast-Fünfminüter spricht Leigh Davies neben seinem Job bei Intel vor allem über die Toolsuite Intel Graphics Performance Analyzers und wie sich damit PC-Spiele verbessern und optimieren lassen. So lernt man anhand des Videos folgende Dinge:

• Intel GPA steht derzeit in der dritten Version kostenlos zum Download bereit, was lediglich mit einer kurzen Registrierung verbunden ist.

• Mit Intel GPA lassen sich DirectX-Spiele untersuchen (DirectX 9 und 10), aber auch das PC-System kann zur Spiele-Laufzeit untersucht werden. Damit lassen sich beispielsweise CPU-Lasten ermitteln und wie das Spiel auf Basis der vorhandenen Ressourcen skaliert.

• Mit Intel GPA lassen sich aber auch einzelne Spielszenen (Frames) untersuchen und herausfinden, wie sich diese in Sachen Funktionsaufrufe, etc. verhalten. Damit weiß man ziemlich genau, an welchen Stellen es “klemmt” und auf dieser Erkenntnis kann man probehalber einzelne Prozessorkerne “abschalten”, neue oder aufwändigere Texturen laden oder den Shader “umschreiben”, um somit eine optimierte Variante der betreffenden Szene zu erhalten. Denn oft sind es Kleinigkeiten, die ein 3D-Game ausbremsen.

• Mit Intel GPA lässt sich zwar nicht nur Intel-Grafikhardware adressieren, aber aufgrund der architektonischen Unterschiede gelingt dies natürlich am besten. Damit kann man genau messen, wieviel Bandbreite die verwendeten Texturen beanspruchen, wie viel Rechenzeit die Shader verbraten, etc. Damit weiß man ganz genau, an welchen Stellen es klemmt – und was man tun sollte, um diese Flaschenhälse zu beseitigen.

Tja, und den Rest schaut ihr euch am besten selbst an. Film ab!

Infos zur Spieleprogrammierung für Netbook und Co.

Erst letzte Woche habe ich über die Develop 2010 berichtet. Auf dieser Spiele-Entwickler-Konferenz, die im englischen Brighton stattfand, ging es in rund 80 Techsessions um das Thema 3D-Games und wie Software-Entwickler davon profitieren können. Zu den Sponsoren gehörte unter anderem Intel, die natürlich auch eigene Sessions abhielten.

Über eine dieser Sessions habe ich letzten Freitag schon berichtet, und heute erreichte mich die Nachricht, dass es zu den Intel-Aktivitäten eine eigene, kleine Webseite gibt, auf der sich weitere Infos zur Develop 2010 befinden. Dazu gehören unter anderem die Präsentationen in Form von Folien, die die Vorträge kurz und knackig abbilden. Hierunter sind folgende Themen:

1. Building Games for Netbooks
2. PC Profiling Made Easy with Intel Graphics Performance Analyzers (Folien)
3. Vectors of Performance in Gaming (Folien)

Zu Nummer eins habe ich selber schon das ein oder andere gesagt und sogar schon einen eigenen Vortrag gehalten. Zu Nummer zwei gibt es hier auf diesem Blog ebenfalls weiterführende Infos und einen Videobeitrag. Tja, und Nummer drei handelt von solch technischen Dingen wie SIMD, SSE4, Intel AVX und einiges mehr.

Also, ihr Spieleentwickler da draußen, besorgt euch die Präsentationen und schaut, wie ihr das Ganze in eure eigene Arbeit einfließen lassen könnt!

Wie sich 3D-Spiele optimieren lassen

Ja doch, die Fußball-WM 2010 ist Geschichte, hat einen neuen Weltmeister gekürt und England war mal wieder verdammt früh Zuhause. Das hat aber den Kollegen Leigh Davies von Intel UK nicht davon abgehalten, seine Techsession anlässlich der Develop 2010 mit einem Fußballspiel-Beispiel zu eröffnen.

Er hatte nämlich seinerzeit mit einem echten Problem zu kämpfen: Warum ist dieses Soccer-Game, das er gerade entwickelte, nur so langsam? Also haben er und seine Kollegen nach und nach alles ausgeblendet, was auszublenden war: Stadium, Spieler, etc. Bis einer von den Programmierern auf die Idee kam, sich den Ball mal genauer anzusehen, und siehe da: Das runde Leder (das ja eigentlich gar nicht rund ist) bestand aus 5.000 Polygonen! Und das in einer Zeit, als sich 3D-Objekte eher aus 300 Polygonen zusammensetzten. Tja, damit war der Schuldige also gefunden (wie so oft der Ball).

Und, was lehrt uns das? Dass es beim Optimieren von 3D-Spielen oft mit dem Teufel zugeht und man auf den ersten und zweiten Blick gar nicht erkennt, warum bestimmte Spielsequenzen ruckeln oder auf einem Netbook beispielsweise gar nicht laufen. Wie gut, dass es mittlerweile für solche Herausforderungen Tools gibt wie die Intel-Suite Graphics Performance Analyzers.

Das Gute an Intel GPA ist ihre Flexibilität: Egal, ob man sein 3D-Spiel auf einem Core-i3- oder i5-System mit integrierter Grafik testen will oder gar auf einer diskreten Grafikkarte – das Toolset unterstützt beide Spielarten. Intel GPA besteht übrigens aus drei Teilen: System Analyzer, Frame Analyzer und Platform View. Mit dem System Analyzer lassen sich grundlegende Dinge wie die Framerate, Prozessorauslastung, Vertex-Lock-Zeiten und einiges mehr herausfinden.

Mit dem Frame Analyzer begibt man sich dann auf die eingegrenzte Fehlersuche, indem man beispielsweise eine spezielle Szene herausgreift und diese genau analysieren lässt und somit den Fehler (hoffentlich) findet. Und mithilfe von Platform View lernt man alles über die im Hintergrund laufenden Threads, die sich zur Laufzeit ergeben. Dies schärft das Verständnis für das Spiel “unter der Haube” und erlaubt eine genaue Analyse, wo es klemmen könnte. Hierfür muss man allerdings ein paar Zeilen Quellcode einfügen, im Gegensatz zum System und Frame Analyzer.

So, und wer jetzt mehr wissen will über Intel GPA, dem sei dieser englischsprachige Artikel empfohlen oder dieses Video von der GDC09. Oder ihr wartet auf unsere Berichterstattung live von der GDC 2010, die vom 16. bis 18. August in Köln stattfinden wird. Dort wird Intel GPA ebenfalls vertreten sein.

Spiele-Entwickler auf der GDC 2010: Start your engines!

Heute habe ich meine Presseakkreditierung in Sachen GDC 2010 beantragt. Und da ich dann schon mal so schön beim größten europäischen Entwicklerevent der Gaming-Branche bin, werde ich natürlich mal wieder darüber berichten, was sich  in Köln vom 16. bis 18. August 2010 so alles tut.

Also, um es gleich (wieder) klar zu machen: Ich fahre wie jedes Jahr für Intel auf die GDC, um vor Ort alle relevanten Themen abzubilden, die aus Intel-Sicht wichtig sind. Zu diesem Zweck begebe ich mich nicht alleine nach Köln, sondern habe wie so oft Tom Papadhimas dabei, der mir seine Video-Expertise zur Verfügung stellen wird. Soll heißen, dass wir drei Tage lang interessante und bekannte Leute vor die Kamera holen, ihnen ein Mikro unter die Nase halten und ihnen schlaue Fragen stellen werden. So wie immer halt.

Dieses Jahr schickt Intel wieder einen Schwung eigener Leute nach Köln, die unter anderem über folgende Dinge reden werden:

• Leigh Davies wird zeigen, wie sich Spiele für Netbooks konzipieren und entwickeln lassen. Hierzu gibt es diverse Tools, eine komplette Community und sogar einen eigenen App Store, wo man das Netbook-Game einstellen und verkaufen kann.

• Steve Hughes demonstriert während seiner Techsession, wie sich mithilfe der Tool-Suite Intel Graphics Performance Analyzer Flaschenhälse und ähnliche Dinge innerhalb eines Spiels aufspüren und eliminieren lassen. Darüber hinaus erlaubt Intel GPA das Optimieren von 3D-Games für unterschiedlichste Plattformen – vom Netbook bis Highend-Laptop.

• Mario Deilmann hat die Intel Threading Building Blocks im Gepäck und wird zeigen, wie sich mit dieser Threading-Bibliothek hochkomplexe Spiele at-its-best optimieren lassen. Natürlich geht es dabei auch um die neuen Features der Version 3.0.

• Jerome Muffat-Meridol kümmert sich verstärkt um das Thema DirectX 11 und warum es mit der Grafik-API von Microsoft einfacher wird, parallel ablaufende Spiele zu programmieren, und das rein mit DirectX-Bordmitteln.

Ja, diese Jungs werden wir auf jeden Fall zu ihren Techsessions vor Ort befragen und herausfinden, wie Spiele-Entwickler davon profitieren können. Und natürlich gibt es auf diesem Kanal in den nächsten Wochen mehr und mehr Infos rund um die GDC 2010.

Artikelempfehlungen rund um Parallelprogrammierung

Heute gibt es auf dem Sofware Dev Blog vier Artikelempfehlungen, die sich mit dem Thema Multicore und Parallelprogrammierung beschäftigen. Die Beiträge sind stellenweise zwar nicht mehr ganz taufrisch, haben aber an Aktualität nichts eingebüßt. Im Gegenteil.

Der Beitrag Programmiermodelle für moderne Mehrkernarchitekturen geht ganz rudimentär auf die verschiedenen Ansätze ein, wie aus sequentiell programmierten Anwendungen parallel ablaufende Applikationen werden. Dabei zeigt der Autor die Unterschiede auf, die es unter anderem bei OpenMP, Thread-Bibliotheken, Java, C# zu berücksichtigen gilt. Ein guter Einstieg in die Welt der Parallelprogrammierung.

Der zweite Artikel setzt dort an, wo der erste quasi aufhört: bei einem dieser Modelle, und zwar OpenMP. Dabei will der Autor allerdings keine umfängliche Darstellung von OpenMP leisten, sondern den praktischen Nutzen darstellen. Dies geschieht mithilfe vieler nützlicher Beispiele. Und natürlich werden auch mögliche Stolperfallen wie Data Races besprochen.

Der dritte Artikel Parallelisierung mit der POSIX Thread Bibliothek beschäftigt sich mit einem Thema, das hochkomplex, aber auch sehr fundamental ist: Wie multithreade ich eine Anwendung mithilfe plattformunabhängiger Pthreads? Dieses Konzept ist zwar nicht mehr State-of-the-Art, bietet dafür aber die Möglichkeit, hochperformante, parallel ablaufende Anwendungen zu programmieren. Und das Verständnis rund um das Thema Parallelprogrammierung wird mithilfe der Pthread-Kenntnisse ebenfalls geschärft.

Tja, und auf den vierten Artikel habe ich bereits letzte Woche aufmerksam gemacht. Na dann, viel Spaß beim Lesen!

Parallelprogrammieren lernen mit Schach

Der werte Kollege Deilmann von Intel hat mir ein paar Internetlinks zukommen lassen, deren Inhalte sich mit dem Thema Parallelprogrammierung beschäftigen. Ein Beitrag hierzu ist auf den ersten Blick zwar ziemlich oberflächlich, bietet aber auf den zweiten Blick viele nützliche Infos zum Thema Multicore und Multithreading. In Form eines 34-seitigen pdfs wird nämlich das N-Queens-Problem detailliert dargestellt und gezeigt, wie sich dieses per Parallelprogrammierung lösen lässt.

Zur Erinnerung: das sogenannte “Damenproblem” stammt aus der Mathematik und beschäftigt sich mit der Frage, wie viele Damen auf einem Schachbrett so aufgebaut werden können, dass sie sich gemäß der Schachregeln nicht gegenseitig schlagen können. Auf einem 8×8-Schachbrett gibt es übrigens 12 eindeutige Lösungen.

Nur, wie lässt sich das für eine größere Zahl n berechnen, und wie geschieht das auf einem Parallelrechner möglichst schnell? Genau damit beschäftigt sich der pdf-Workshop, der sehr anschaulich und anhand vieler Codebeispiele mögliche Ansätze und Konzepte miteinander vergleicht und natürlich auch verrät, welche Lösung die beste ist, wenn man solche Probleme möglichst elegant und parallel lösen möchte.

Der Download ist kostenlos und jedem Einsteiger in die Parallelprogrammierung sehr zu empfehlen.

Infos aus erster Hand zu Cilk

Wie ich ja kürzlich per Twitter vermeldet habe, saß ich am Dienstag mit Mario Deilmann von Intel beisammen, um über ein paar mögliche Themen für das Software Dev Blog zum Thema Multicore-Programmierung zu reden. Und so haben wir diverse Themen evaluiert und identifiziert, und als erstes Ergebnis veröffentliche ich heute ein paar Infos zu Cilk, die mir Mario in mein iPhone diktiert hat. Und so gibt es dann nach und nach zu Cilk und den anderen Themen weitere interessante Informationen.

Die Idee von Cilk ist recht einfach: Man erhält ein serielles Programm, wie man das schon von OpenMP kennt. Allerdings kann das mit OpenMP “unterwandert” werden, indem man Abhängigkeiten in den Code einbaut. Bei Cilk hingegen werden die zu parallelisierenden Codeteile einfach mithilfe bestimmter Spawn-Konstrukte ausgelagert. Zudem können die so parallelisierten Abschnitte wieder serialisiert werden, indem man die Spawn-Befehle einfach wieder aus dem Code herausnimmt. Daneben gibt es ein weiteres Cilk-Konstrukt, das mittels einer for-Methode Schleifen parallelisiert.

Das Tolle an Cilk ist der zugeghörige Scheduler, der sehr schlau ist und task-orientiert arbeitet, und nicht wie bei OpenMP thread-basiert. Dabei werden stets möglichst viele Tasks an den Scheduler übergeben, der diese mit einem intelligenten Algorithmus auf die vorhandenen Thread-Ressourcen verteilt. Der Scheduler ist übrigens derart skalierend, dass auch große Rechensysteme optimal ausgenutzt werden.

So skalierte ein cilk-optimiertes Schachprogramm auf einem Rechner mit 512 Kernen so gut, dass es den dritten Platz in einem großen Schachturniert belegte. Der Trick des Cilk-Schedulers besteht übrigens darin, dass die Tasks per Zufall auf die Threads verteilt werden und nicht nach “menschlichen” Kriterien. Ach ja: Das Work Stealing hat seinen Ursprung im Cilk-Scheduler und wurde sukzessive in die Microsoft-Scheduler eingebaut.

Daneben muss mit Cilk nicht darauf geachtet werden, dass die zu parallelisierenden Aufgaben (Tasks) logisch angeordnet sind. Einzige Voraussetzung für eine cilk-basierte Parallelisierung ist die Unabhängigkeit der Tasks zueinander, so dass jeder Task eine Spawn-Methode zugewiesen werden kann. Darüber hinaus dürfen die jeweiligen Codeabschnitte nicht von globalen Variablen abhängen beziehungsweise diese nicht modifizieren. Ansonsten bekommt man es ganz leicht mit Data Races zu tun.

Allerdings ist zu berücksichtigen, dass es mit Cilk wie bei OpenMP, TPL und PPL vor allem um eine Lastverteilung geht, und nicht um eine Verteilung von Funktionalitäten auf die vorhandenen Ressourcen.

Schön an Cilk ist auch die einfache Handhabung: Außer den beiden Spawn- und For-Konstrukten muss man nichts lernen, sodass selbst ungeübte C- und C++-Entwickler Cilk ziemlich schnell einsetzen können. Das Gute an Cilk ist auch seine Vorhersehbarkeit: Sobald das cilk-optimierte Programm vorliegt, kann man anhand der gegebenen Parameter genau berechnen, was die Parallelisierung in Sachen Rechenleistung bringen wird.

Eine Besonderheit an Cilk sind die sogenannten Hyperobjects, mit denen ein parallelisierter Codeabschnitt seine eigene Sicht auf globale Variablen bekommt. Soll heißen, dass jeder Thread seinen eigenen Zugriff auf die globalen Variablen erhält, ohne diese zu verändern, so dass es nicht zu Data Races kommen kann. Dabei wird das Ganze lock-frei realisiert, da für jeden Thread eine eigene Speicherzelle angelegt wird, deren Inhalte am Schluss wieder zusammen geführt werden, so dass das richtige Ergebnis in der globalen Variable steht. Praktisch an Hyperobjects ist auch die Tatsache, dass man eigene anlegen kann. Damit ist Cilk ein ganzes Stück flexibler als OpenMP oder TBB.

Review: Multicore-Programmierung auf den dotnetpro.powerdays, Teil 2

Zugegeben, die dotnetpro.powerdays sind schon wieder eine Woche her, was mich aber nicht davon abhalten soll, den zweiten Teil meiner Rückschau zu veröffentlich. Sorry Leute, ich bin einfach nicht früher dazu gekommen. War ziemlich viel los seitdem.

Nach der Keynote-Session von Mario Deilmann (mit dem ich übrigens gestern zusammen saß, neuer Geschichten wegen) waren Bernd Marquardt und Volker Jungbluth an der Reihe, die eine Menge über PPL, TPL und OpenMP zu erzählen hatten.

Bernd begann mit seiner PPL-Session, die sich mit der Parallel Pattern Library beschäftigte. PPL richtet sich an native Programmierer und soll die Parallelprogrammierung deutlich vereinfachen, da sich Entwickler nicht um das Verteilen des parallelisierten Quellcodes auf die zugehörigen Threads kümmern müssen. Dabei sollte man laut Bernd aber trotzdem sicher stellen, dass der seriell erstellte Code fehlerfrei läuft, bevor man sich ans Parallelisieren macht. Ach ja: Die PPL lässt sich nur mit Visual Studio 2010 einsetzen.

Die PPL besteht vor allem aus thread-sicheren Algorithmen, Containern, Objekten und der Task-Parallelisierung. Ein wesentlicher Bestandteil dabei sind sogenannte Lambda-Funktionen, mit denen Code als Parameter in einem Methodenaufruf übergeben werden kann. Dies geschieht mithilfe spezieller Funktionen wie parallel_for() und parallel_for_each(). Besonders interessant ist die Funktion parallel_invoke(), mit der sich bis zu 10 Lambda-Funktionen parallelisieren lasssen, die allerdings alle möglichst gleich lang sein sollten.

Es gibt darüber hinaus Methoden wie try() und throw(), mit denen parallele Schleifen unterbrochen werden können. Und mit der combinable-Klasse erlaubt die PPL den gemeinsamen Zugriff auf eine Variable, ohne dass Data Races entstehen. Schließlich machte Bernd noch darauf aufmerksam, dass die Task-Parallelität das asynchrone Ausführen von Anwendungen erlaubt, indem Task-Gruppen definiert werden. Und ein wichtiger Tipp lautete abschließend: Fehlerfreie Parallelprogrammierung hat sehr viel mit lokalen Variablen zu tun, auf die man nicht von außen zugreifen darf.

Anschließend gab Volker Jungbluth sein Wissen ins Sachen Task Pattern Library (TPL) zum Besten. TPL entspricht in vielen Aspekten der PPL, ist allerdings für die Parallelisierung von Managed Code entwicklelt worden. Ein wichtiger Bestandteil des .NET4-4-Frameworks ist übrigens PLINQ, mit dem man sich als Programmierer laut Volker unbedingt beschäftigen sollte. So sind beispielsweise mit der Methode AsParallel() parallele Abfragen auf Datenstrukturen recht einfach möglich. Interessant fand ich auch die Feststellung, dass Parallel_for-Konstrukte mit dem Partitioner deutlich schneller laufen als ohne.

Weitere Erkenntnisse der Jungbluth’schen Techsession:

• Mit parallel_invoke() lassen sich mehrere Aufgaben auf Threads verteilen, ohne dass man sich explizit darum kümmern muss

• Mit Futures lassen sich task-basierte Ergebnisse im Hintergrund berechnen

• Mit continuation() lassen sich Task-Ketten erstellen, die dank der Lambda-Funktionen Ergebnisse übergeben können.

Nach soviel Parallelprogrammierung unter .NET 4 kam Bernd nochmals auf OpenMP zu sprechen, dass sich zwar am Thread-Konzept orientiert, aber gerade für das Parallelisieren von einfachen Schleifenkonstrukten prima geeignet ist. Daher ist OpenMP vor allem für mathematische Algorithmen eine gute Alternative zu TPL oder PPL, die in der Anwendung doch recht kompliziert sind.

Das Gute an OpenMP ist der Schalter /openmp, der beim Compileraufruf verwendet wird – oder auch nicht. Das erleichtert das Parallelisieren von seriellem Code erheblich, da beim Auftreten von Problemen der OpenMP-Schalter einfach nicht zum Einsatz kommt und die Anwendung zu Testzwecken seriell ausgeführt wird. Ach ja: Auf Basis des Intel-C++-Compilers lassen sich mit dem richtigen Switch fehlerhafte OpenMP-Konstrukte aufspüren.

Toll an OpenMP sind aber auch andere Aspekte:

• Für nicht-ausgewogene Schleifen verteilt OpenMP mit der Mehtode parallel_for_schedule() ganze Schleifenteile gleichmäßig auf auf jeden Thread. Das garantiert eine effiziente Ausführung von parallelen Schleifen.

• Mithilfe der OpenMP-API open_set_num_threads(int) wird die Anzahl der vorhandenen Thread-Ressourcen bestimmt und somit optimal genutzt.

• OpenMP-Variablen sind standardmäßig “shared”. Private-Variablen müssen daher explizit deklariert werden.

• Was für die TPL/PPL der Invoke-Befehl ist, heißt bei OpenMP “sections”.

• Mit dem OpenMP-Pragma omp parallel for if(Anweisung) lassen sich bedingte OpenMP-Schleifen bauen.