Aus diesem Grund folgt hier noch einmal eine Zusammenfassung mit Hinweisen auf meine persönlichen Highlights der Konferenz, der Ausstellung und der Sessions.

Zunächst aber zum künftigen Highlight für Spiele-Entwickler aus Deutschland und der ganzen Welt: Unter dem Titel „LEVEL UP 2011“ startet Intel in Kürze einen Wettbewerb für Game Developers, den Sie unter keinen Umständen verspassen sollten. Denn die Gewinnmöglichkeiten sind einzigartig:
Neben attraktiven Geldpreisen in einer Gesamthöhe von rund 10.000 US-Dollar erhalten die Sieger die Möglichkeit, ihre Spieleidee auf dem Valve’s Steam Online Gaming Portal zu präsentieren und später mit Hilfe von Valve auf den Markt zu bringen und kommerziell zu vertreiben. Das ist Ihre einmalige Chance, mit Ihrer Spiel-Idee Furore zu machen und auch gutes Geld zu verdienen!

Die genauen Teilnahmebedingungen und den Startschuss erfahren Sie auf der offiziellen Level Up 2011-Seite und natürlich bei uns. Auf dieser Seite habe ich bereits die wichtigsten Eckpunkte für den Wettbewerb zusammengefasst. Weitere News dazu werden selbstverständlich in Kürze folgen.

Zurück zur GDC Europe: Vor allem die sehr entspannte Atmosphäre unter Ausstellern und Besuchern hat mich beeindruckt. Dazu haben Tom und ich gleich zu Beginn ein nettes Video mit ein paar Stimmen und Stimmungen  zur GDC Europe produziert.

Zudem waren die Sessions erstklassig: Sehr gute Präsentationen von sehr guten Referenten, die detailliert auf die Fragen der Teilnehmer eingegangen sind. Kein Wunder, dass die Säle immer voll waren – trotz 25 Grad Außentemperatur.

Eine der besten Präsentationen war meines Erachtens der Vortrag “Hotspot Flops & uOps” von Levent Akyil. Levent demonstrierte, wie sich hardwarenaher Code generieren lässt, der die Ressourcen von CPU, GPU und Cache-Management optimal ausnutzt und typische Fehlerquellen umschifft. Nicht nur für Spiele-Programmiere interessant! Im Anschluss stand Levent auch für ein kurzes Interview zur Verfügung.

Last but not least möchte ich auf die Session „MAXIS-mizing Darkspore game performance with Intel GPA“ von Philipp Gerasimov verweisen. Philipp stellt hierbei ein Tool-Set ausführlich vor, das jeder Spieleprogrammierer kennen sollte, weil es erstklassige Analysefunktionen bietet und völlig kostenlos ist: Intel Graphics Performance Analyzers.

Viel Spaß mit den Beiträgen und den Videos!

Philipp Gerasimov während der GDC Europe 2011

Zunächst gab es ein Intro zu GPA 4.1, dann ein Sneak Peek von Darkspore und schließlich interessante Einblicke in die Nutzung von GPA.

GPA ist eine Tool-Sammlung, die im Wesentlichen aus drei Analyse-Funktionen besteht:

• System Analyzer HUD (Performance-Echtzeitmessung und Aufspüren von Bottlenecks)
• Frame Analyzer (exakte Analyse der Frames bis auf Pixel-Ebene)
• Plattform Analyzer (Messung der Ressourcennutzung von CPU/GPU)

GPA läuft on top der Games, die es analysieren soll. Unterstützt werden übrigens alle aktuellen Windows- und DirectX-Versionen bis 11.0. GPA ist für alle neueren Intel Core- und Atom-Architekturen ausgelegt.

Neue Funktion in GPA 4.1
Der System Analyzer HUD wird über den GPA-Monitor gestartet und bietet nun verbesserte Konfigurationseinstellungen und neue Profile. Es ist nun deutlich leichter, interessante Frames „einzufangen“ und zu analysieren, beispielsweise mit What-if-Experimenten. Sie können beispielsweise so genannte Draw Calls ausschalten, um die Auswirkung auf CPU und GPU auszutesten.

Im Anschluss erzählte Philipp, auf welche Probleme die Entwickler von Darkspore gestoßen sind und wie sie die meisten Probleme bei Rendering-und Raytracing-Aufgaben lösen konnten.

GPA im Einsatz
Eine erste Analyse mit GPA ergab ein Overall-Optimierungspotenzial von 30 Prozent. Das bedeutet, mit entsprechenden Code-Optimierungen sind bis zu 30 Prozent mehr Performance bei der Berechnung von Bildern möglich.
Vor allem ging es darum, an „unwichtigen Stellen“ die Detailgenauigkeit der Objekte geschickt zu reduzieren, ohne dass die Qualität darunter leidet. So hatte beispielsweise die Visualisierung von Blutspritzern deutlich mehr Pixel als nötig. Grotesk: Die Bäume wurden im Game samt Wurzeln berechnet, die auf dem Bildschirm natürlich nicht sichtbar waren. Auch die Spielfiguren und deren Texturen waren zu aufwändig animiert – wie GPA ermitteln konnte. Allein die Reduzierung dieser unnötigen Berechnungen brachte einen spürbaren Geschwindigkeitszuwachs – ohne, dass der Spieler später davon etwas bemerken würde.

Philipp zeigte, wie sich die gewünschten Code-Änderungen vor der finalen Korrektur mit GPA simulieren lassen, so dass die Auswirkungen auf Grafikeinheiten und CPU sofort sichtbar sind. Das gilt übrigens nicht nur für Frames und Pixel, sondern auch für Farbtiefe, DirectX-Einbindung und vieles mehr.

Neben den vielen Analyse-und Optimierungs-Tools von GPA wies Philipp abschließend auf zwei unschlagbare Argumente hin, die GPA für jeden Spieleprogrammierer unverzichtbar machen: Das Toolset ist absolut intuitiv bedienbar und dazu noch völlig kostenlos!
Hier finden Sie weitere Infos zu GPA und den Link für Ihren kostenlosen Download!

Im Interview erklärt er, wer GPA unbedingt braucht, welche Verbesserungen die Version 4.1 gegenüber dem Vorgänger verspricht und wie Sie sehr, sehr günstig an die aktuelle Version kommen, um die Grafikleistung auch Ihrer eigenen Spiele zu optimieren.

Hier das sehr sehenswerte Video dazu:

Später werde ich von noch von seiner Session berichten.

Levent Akyil auf der GDC Europe 2011

Anfangs zeigte Level, wie sich die Anforderungen der Programmierer im Zuge der aktuellen Hardware-Architektur verändert haben. Neuerungen wie der modulare Aufbau, die Integration der GPU und die Abkehr von der klassischen Crossbar zu Anbindung des Last Level Cache bringen reihenweise Performance-Vorteile in Sandy Bridge. Beispielsweise ermöglicht AVX (Advanced Vector Extension) mit dem erweiterten SIMD-Register (256 Bit) nun ein neues SIMD-Instruktionsformat für SSE-Operanden. Spiele-Programmierer werden diese Neuerungen lieben, da sich nun auch komplizierte Rendering-Berechnungen beschleunigt ausführen lassen.

Alte Probleme sind hingegen scheinbar geblieben, etwa die Speicherfrage: Wie lassen sich mehr Daten möglichst einfach vom Speicher in den Cache schieben, um die Ablaufgeschwindigkeit zu erhöhen? Wie lassen sich Hotspots und Latenzzeiten im Code ermitteln und ausschalten? Die Antworten auf diese Fragen sind zweiteilig: Zum einen muss der Entwickler die Algorithmen optimieren und gleichzeitig Hardware-nah arbeiten. Das klingt zunächst widersprüchlich, denn mit den bereinigten Algorithmen möchten Entwickler plattformunabhängig bleiben. Mit dem richtigen Tool lassen sich aber beide Ziele gemeinsam erreichen – selbst bei Third-Party-Code, den ich nicht en detail kenne und komplett verstehe.

Levent empfiehlt hierzu den Intel VTune Amplifier XE , der mit seinen vordefinierten Analyse-Funktionen den Code sehr schnell prüft und typische Probleme wie Hotspots, Slow Frames oder faule call stacks blitzschnell ermittelt und damit die Grundlage für die Optimierung bietet. Eine Reihe sehr detaillierter Artikel zum VTune Amplifier finden Sie übrigens auch hier im Blog.

Hier noch ein Ausschnitt seiner Live-Präsentation vom Vormittag:

Leigh Davies auf der GDC Europe 2011

Leigh erläuterte zunächst die wichtigsten Gründe, um Anwendungen, vor allem aber grafisch anspruchsvolle Spiele von der ersten Code-Zeile an konsequent auf Mehrkern-Systeme auszurichten. Spieler auf der ganzen Welt sind typische „Early Adopters“, wenn es um innovative Technologien geht. Schon jetzt nutzen mehr als 40 Prozent der Spieler über die internationale Games-Plattform “Steam” PCs mit 4 oder mehr Prozessorkernen. Dank dieser Systeme profitieren die User von einem höheren Spielefluss und deutliche besseren Bildern – dazu gleich mehr.

Entwickler stehen demnach mehr denn je vor der Aufgabe, sequentiellen Code in task-basierten (aufgabenbasierte) Code zu übersetzen. Anhand der Tasks können Sie die Rechenaufgaben Ihrer Anwendung auf einige oder alle Kerne verteilen. Dabei lassen sich die Threads unabhängig voneinander steuern oder auch in sinnvoller Abhängigkeit zueinander starten, um Ressourcen optimal zu nutzen. Damit wird die Anwendung skalierbar.

Die notwendigen Tools hat jeder Programmierer bereits zu Hand – zum Beispiel mit den Threading Building Blocks (TBB). Der Scheduler hilft bei der Organisation, der Reihenfolge und beim Starten der Threads: So lassen sich Tasks nacheinander oder auch parallel starten, um eine bestmögliche Auslastung der Hardware (CPU und GPU) zu gewährleisten.
Einen sehr guten Grundlagenartikel zu diesem Thema samt Code-Beispielen finden Sie übrigens hier.

Leigh erläuterte das Vorgehen en detail bei der Frame-Berechnung (Animation Samples) grafisch anspruchsvoller Spiele, die heute für maximale Rendering-Ergebnisse fast immer auf parallelen Code angewiesen sind.

Um die Darstellung von Körpern unter wechselnden Lichteinflüssen und Perspektiven exakt und schnell darzustellen, kam bislang zur Kantenglättung meist die Multisample Anti-Aliasing (MSAA)-Technologie zum Einsatz. Bessere Resultate liefert das Morphological Anti-Aliasing (MLAA). MLAA nutzt dafür einen Post-Processing-Effekt: Das Bild wird nach Ende der Berechnung anhand von Farbunterschieden analysiert und die Kanten werden per Shader geglättet. Dabei kommen nicht alle Pixel auf den Prüfstand, sondern eben nur die zuvor analysierten Kante  – was zu dem besagten Performance-Gewinn beim Bildaufbau führt. Zudem wird der Löwenanteil der Arbeit von der GPU übernommen und die CPU entlastet.

Übrigens: Ein unverzichtbares Werkzeug bei der Code- und Frame-Kontrolle ist die neue Toolsuite Intel Graphics Perfomance Analyzers (). Leigh stellt Ihnen das Tool gerne am Intel Stand Nr. 150 ausführlich vor. Aber ich werde auch in einer der nächsten Einträge ausführlich über GPA 4.1 und die Neuerungen gegenüber der Version 4.0 berichten.

Heute stelle ich die beiden Dienstags-Sessions in den Vordergrund.

Dienstag, 16.8.2011: Ab 9:30 Uhr spricht Levent Akyil zum Thema “Hotspot Flops & uOps”.  Levent wird verdeutlichen, wie sich seriell und parallel programmierte Anwendungen durch eine recht simple Optimierung auf Registerebene weiter beschleunigen und Fehler wie Bottlenecks in Quellcode aufspüren und beheben lassen. Dabei geht Levent detailliert auf die Möglichkeiten der aktuellen Sandy Bridge-Architektur mit AVX ein – von der sowohl Programmierer als auch Spieler erheblich profitieren.

Wenn Sie sich zuvor über die Advanced Vector Extension, eine verbesserte Vektorisierung von Gleitkomma- und Ganzpunktzahlen, informieren möchten, empfehlen wir Ihnen unseren Grundlagenartikel „Sandy Bridge: Schnellere Apps dank breiteren AVX-Registern“.  Zudem lohnt ein Streifzug durch diesen Blog, denn AVX im Zusammenhang mit der Programmierung und der verbesserten Grafikleistung von 3D-Games war sehr häufig Thema bei uns.

Levent habe ich übrigens im Mai beim Black Belt Event in München getroffen, wo er die aktuellen Programmier- und Analyse-Tools vorgestellt hat, allen voran natürlich Intel Parallel Studio XE mit dem Composer, dem Inspector und dem VTune Amplifier. Anhand der Amplifier-Werkzeuge zeigte Levent, wie sich typische Speicherprobleme im Code ausfindig machen lassen und wie Entwickler feststellen können, wo sich im Code Performance-Schwachstellen verbergen.

Hierzu empfehle ich auch meinen Report von der Intel Software Conference in Dubrovnik vom April dieses Jahres: Intel Software Developer Conference 2011 (II): Intel VTune Amplifier XE in Action.
Levent ist nicht nur ein hervorragender Redner, sondern auch sehr sympathisch. Sie sollten die Chance nutzen, seine Session zu besuchen und vielleicht auch ein paar Worte mit ihm am Intel-Stand zu wechseln.

Die offizielle Ankündigung zu seiner Session können Sie auf der GDCE-Seite abrufen.

Dienstag, 16.8.2011: Ab 17:40 Uhr kommt dann Philipp Gerasimov zu Wort. Er wird in seiner Session zeigen, wie sich der Action-RPG-Titel Darkspore mit Hilfe des Analyse-Toolsets Intel GPA für Notebooks optimieren lassen konnte. Hierzu gehört detailliertes Wissen über die Version 4.0 des Tools, aber auch die Neuerungen der Version 4.1 wie der verbesserte Platform Analyzer und das In-Game-HUD werden vorgestellt. Im Einzelnen wird Philipp auf den Frame Analyzer näher eingehen und außerdem zeigen, wie sich mit dem Platform Analyzer der eigene Spieletitel auf die Multicore-Fähigkeiten hin untersuchen lässt.

Die offizielle Ankündigung zu seiner Session können Sie auf der GDCE-Seite abrufen.

Intel GPA war und ist ebenfalls immer wieder Thema dieses Blogs, so dass Sie über diese Seiten sehr gut vorbereiten oder auch einiges nachlesen können. Empfehlenswert auf jeden Fall die Beiträge: „Das sagen bekannte Spieleentwickler über Intel Graphics Performance Analyzers“ und „Wie LEGO Univers mithilfe von Intel GPA optimiert wurde“ . Letzter Tipp für alle, die die neue Version GPA 4.1 selbst ausprobieren möchten: Auf dieser Seite finden Sie eine kostenlose Download-Option.

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).

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.

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.

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!