Das war die GDCE 2010: Videointerviews und mehr, Teil 3
Sodala, nachdem Teil 1 und Teil 2 der GDCE-2010-Rückschau draußen sind, folgt jetzt das dritte und letzte Kapitel meiner Trilogie in Sachen Spieleentwicklung. Den Abschluss soll ein Dreiteiler bilden (sic!), der sich mit der Analysetool-Suite Intel Graphics Performance Analyzers beschäftigt.
Den Anfang macht der System Analyzer, mit dem sich in Echtzeit analysieren lässt, was während des Gameplays alles passiert. Um das Testsystem von rechenintensiven Aufgaben zu befreien, läuft der System Analyzer auf einem anderen Rechner als das zu testende Spiel. Dabei stehen verschiedene Funktionen wie die CPU-Diagnose, das Ermitteln der Anzahl der Locks per Frame und der Framerate selbst sowie andere wichtige Parameter zur Verfügungung.
Praktisch am System Analyzer sind die vorhandenen Hardware-Diagnose-Tools, mit denen sich auf Intel-Systemen Dinge wie die Auslastung der vorhandenen Execution Units untersuchen lassen. Aber auch bestimmte Ansichten auf die aktuelle Spielszene erlauben das Analysieren des Spiels. So lassen sich beispielsweise mit der Gitterdarstellung verborgene Objekte entdecken, die dort gar nicht hingehören und nur überflüssige Rechenzeit verbraten.
Der Frame Analyzer geht dann richtig in die Tiefe und lässt jedes einzelne Bild eines Spiels analysieren. So kann man anhand der DirectX-Drawcalls feststellen, welche Bereiche eines Frames besonders viel Rechenzeit beanspruchen und diese Bereiche gegebenenfalls optimieren. So zeigen beispielsweise versteckte Objekte hohes Optimierungspotenzial, da sie zum Gameplay nichts beitragen, aber trotzdem Rechenzeit kosten. Um die möglichen “Störenfriede” zu eliminieren, kann man aber auch experimentell vorgehen, indem man einzelne Parameter ausschaltet um zu sehen, wie sich das auf die Szene und die Renderleistung auswirkt.
Das dritte Tool schließlich, Platform View, ist zum einen “neu” in der Version 3.0 von Intel GPA und bietet zum anderen einen detaillierten Blick auf den Parallelisierungsgrad des Spiels. Dabei kann man sich sämtliche Threads anzeigen lassen, die gerade aktiv sind und diese in der Detailansicht genau analysieren. So lässt sich beispielsweise herausfinden, warum die CPU auf die GPU warten muss oder auch anders herum.
Das war die GDCE 2010: Videointerviews und mehr, Teil 2
Wie ich gestern versprochen habe, folgt heute der zweite Teil des großen GDCE-2010-Rückblicks. Waren gestern die Havok Physics Engine, das Multithreaden von Games mithilfe von DirectX 11, Netbook-Games und Intel GPA dran, folgen heute Erkenntnisse rund um die nächste Version von Intel GPA, um das Parallelisieren von Spielen mithilfe von Intel TBB und einer Task-Stealing Engine der Marke Eigenbau.
Zum Thema “Nächste GPA-Version” konnte wir den dafür zuständigen Intel-Mann Aaron Davies überreden, vor der Kamera ein wenig in seine Glaskugel zu blicken. So verriet er uns, dass die nächste Version Anfang kommenden Jahres zur GDC 2011 in San Francisco vorgestellt wird. Dass Intel GPA 4.0 für die nächste Prozessorgeneration Sandy Bridge optimiert sein wird, überrascht genauso wenig wie die Tatsache, dass das Analysetool die noch in der Beta-Phase befindliche Platform View integrieren wird, da es sehr postives Feedback seitens der Entwickler gab. Die gute Nachricht: Intel GPA und andere Tools von Intel bleiben kostenlos für Entwickler, da der Chiphersteller seine große Fangemeinde weiterhin mit dieser Art der Dienstleistung beglücken will.
Von der Zukunft zurück in die Gegenwart ging es dann mit Mario Deilmann, der es sich zum Ziel gesetzt hatte, die anwesende Entwicklerschar während seiner Techsession davon zu überzeugen, dass mit Intel TBB ein Tool zur Verfügung steht, mit der sich Spieletitel an vielen Stellen parallelisieren lassen. Wie er anschließend vor unserer Kamera verriet, lieben Spieleentwickler Open-Source-Tools wie Intel TBB, da sie die gesamte Kontrolle über den Sourcecode des Tools haben. Auf der anderen Seite gibt es natürlich eine kommerzielle Version von Intel TBB für diejenigen, die auf Support nicht verzichten wollen.
Gut an Intel TBB ist aus Marios Sicht vor allem, dass sich der zu parallelisierende Code nicht mehr als Low-Level-Threads, sondern als abstrahierte Tasks darstellen lässt, was die Parallelisierung von Spielen erheblich vereinfacht. Aber auch die verschiedenen Abstraktionsebenen machen aus Intel TBB ein echtes Gaming-Dev-Tool. So kann man mit Konstrukten wie Concurrent Container und Concurrent Allocator genauso arbeiten wie mit Low-Level-APIs wie dem TBB Scheduler, um damit die besten Ergebnisse zu erzielen. Einen weiteren Pluspunkt sieht Mario in der Plattformunabhängigkeit von Intel TBB, das von Windows, Mac OS und anderen Betriebssystemen und Plattformen unterstützt wird.
Last but not least hatten wir gegen Ende der GDCE 2010 die Gelegenheit mit Dierk Ohlerich zu reden. Dierk ist Head of Technology bei 49Games aus Hamburg, die sich vor allem auf Konsolentitel aus dem Bereich Sportsimulationen konzentrieren. In seinem Videointerview erzählt er uns, dass er seine eigene Task-Stealing Engine geschrieben hat, mit deren Hilfe Spiele optimal auf unterschiedlichen Multicore-Systemen skalieren.
Das Hauptziel seines Projekts ist die Integration einer solchen Task-Stealing Engine in die Rendering Pipeline. Dabei galt es jedoch diverse Klippen zu umschiffen wie das genaue Vorhersagen des Datenaufkommens, wofür dynamische Datenspeicher notwenig sind. Aber auch die richtige Reihenfolge beim “Zeichnen” einer Spielszene stellt laut Dierk ein echte Herausforderung dar, wenn es um das Parallelisieren der Render Engine geht.
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!
Wie multicore-optimiert ist Office 2010?
Wer immer noch glaubt, dass Multicore-Optimierungen, Multithreading und Co. nur etwas für Highend-Software-Lösungen sind, sollte sich mal etwas näher mit Office 2010 beschäftigen. Denn was Microsoft hier an Mühen insvestiert hat, um die aktuelle All-in-One-Lösung für den modernen PC-Arbeiter für vier, sechs und mehr Kerne zu optimieren, ist aller Ehren wert – und diesen Blogbeitrag.
Die einzelnen Bereiche und Tools wurden wie folgt an die moderne CPU-Architektur angepasst:
- Sämtliche Anwendungen wurden einem Multithreading unterzogen, was unter anderem schnelleres Öffnen und Speichern von Dokumenten ermöglicht.
- Beim Starten von Outlook werden mehrere Threads gleichzeitig gestartet, was dazu führt, dass parallel die Bedieneroberfläche aufgebaut, die Kalendereinträge geladen und die Voransicht der erhaltenen E-Mails angezeigt werden. Jeder Task bekommt also seinen eigenen Thread zugewiesen.
- Word erledigt dank Multithreading die Paginierung im Hintergrund, was Raum für andere Aufgaben zur selben Zeit lässt.
- In Excel werden Pivot-Tabellen parallel und damit deutlich schneller sortiert.
- Multithreading wird in Excel aber auch dazu eingesetzt, Berechnungen in den Hintergrund zu schieben, während gleichzeitig grafisch orientierte Arbeiten wie das Ändern der Zeilenhöhe oder das automatische Anpassen der Zellenbreite an die Inhalte vorgenommen werden.
Allerdings stand Microsoft beim Optimieren von Office 2010 an Multicore-Rechner vor einem erheblichen Problem: Wie können Tools wie Word oder Excel so verbessert werden, dass sie die häufigen Wartezeiten, die sich bei der Mensch-Maschine-Interaktion ergeben, möglichst minimieren? Daher wurden diejenigen Flaschenhälse identifiziert, die sich beispielsweise beim Start der Anwendung oder beim Öffnen oder Speichern einer Datei ergeben und Wartezeiten verursachen. Daran wurde dann verstärkt gearbeitet.
Nur setzt Microsoft immer noch sehr auf das funktionale Multithreading, bei dem die unterschiedlichen Aufgaben der Software eigenen Threads zugewiesen werden. Das ist zwar nicht sehr effizient (da diese Methode nicht optimal skaliert), aber wohl angesichts der hohen I/O-Aktivitäten zu vernachlässigen.
Intel TBB 3.0 mit neuen Funktionen und VS2010-Support
Schon letzte Woche erreichte mich eine E-Mail, in der die aktualisierte Version der Intel Threading Building Blocks angekündigt wurde. Tja, und da genau heute Intels Bibliothekensammlung für C und C++ offiziell vorgestellt wird, gibt es dazu natürlich auch einen entsprechenden Blogbeitrag.
Auf den ersten Blick bietet Intel TBB 3.0 zwei wesentliche Verbesserungen: die volle Kompatibilität mit Visual Studio 2010 und .NET 4 sowie die Unterstützung des künftigen ISO/ANSI-Standards für C++, der noch unter dem Arbeitsnamen C++0x geführt wird. Aber auch andere Features wie eine neue Containerklasse und verbesserte Debugger-Merkmale flossen in die neue Version der Intel TBB 3.0 ein. Im Detail sieht das wie folgt aus:
Optionaler C++0x-Support
- die neue Funktion parallel_pipeline() verbessert die alte Warteschlange-Funktion mithilfe von Lambda-Support und anderen Features
- TBB_USE_CAPTURED_EXCEPTION() verbessert das Exception Handling
- verbesserte Synchronisierung auf Basis konditioneller Variablen
Handbuch “Pattern Design”
Dieses von TBB-Entwickler Arch Robison geschriebene Handbuch zeigt, wie Pattern Design funktioniert
Kompatibel mit Microsoft Visual Studio 2010
- Support der Concurrency Runtime
- kompatibel mit der Parallel Pattern Library
- kompatibel mit reader_writer_lock() and critical_section_lock()
Neue Container-Klasse
concurrent_unordered_map() (natürlich C++ 0x-kompatibel)
Verbessertes Debuggen
- Task Scheduling, Vorhersagen und Reaktionszeiten wurden verbessert
- voneinander unabhängiges Verwalten von Tasks für mehrere Masterthreads
- verbesserte Vermeidung von Deadlocks
- weiterentwickelte Hinweise für Parallel Amplifier und Parallel Inspector
Scheduler-Support (task::enqueue)
- unterstützt FIFO-Warteschlagen
- nützlich für das Emulieren von Task-Prioritäten und die Interaktion mit GUI-basierten Threads
Leistungsverbesserungen
- Beschleunigung der Funktion numerable_thread_specific() und Kombinationen davon
- verbesserte Speicherverteilung bei großen Speicherblöcken
und einiges mehr.
Wer mit Intel Threading Building Blocks Software entwickeln und parallelisieren möchte, kann dies in zweierlei Hinsicht tun: entweder bezahlt man 299 Dollar für die Windows- oder Linux-Variante und erwirbt damit das kommerzielle Paket von TBB 3.0. Dazu gehört auch ein professioneller Support seitens Intel. Oder man begibt sich auf www.threadingbuildingblocks.org, besorgt sich die Open-Source-Variante des Pakets und bekommt damit eine GPLv2-Lizenz. Diese ist natürlich kostenlos.
Ausführliche Übersicht zur Multicore-Programmierung
Zugegeben, es ist auf diesem Blog ein wenig still geworden rund um das Thema Multicore-Programmierung. Das liegt daran, dass ich mich mit dem Thema hier schon ausführlich beschäftigt habe und sich die Themen grade ein wenig verschieben. Mit der Ankündigung des Intel AppUp Center während des letztjährigen Intel Developer Forum rückte das Netbook mit all seinen Facetten in den Mittelpunkt.
Das wird sicherlich auch noch ein wenig so bleiben, was aber nicht bedeutet, dass auf dem Software Dev Blog die parallele Verarbeitung von Programmcode keinen Platz mehr findet. Um dies unmittelbar zu belegen, möchte ich heute auf eine sehr ausführliche Übersicht aufmerksam machen. “Ultimativ” klingt immer ein wenig anbiedernd und angeberisch, aber in diesem Fall kommt der Begriff ziemlich nah an das heran, was die amerikanischen Kollegen unter dem Titel “Intel Guide for Developing Multithreaded Applications” zusammengetragen haben.
Diese wirklich umfangreiche Sammlung betrachtet sämtliche Aspekte der Parallelprogrammierung. Ob das das Multithreaden von Anwendungen im Allgemeinen ist oder spezielle Themen wie die Daten- und Ablaufsynchronisation oder das Speichermanagement – so detailliert konntet ihr euch dem Thema wohl selten widmen. Ok, das Ganze findet zwar auf Englisch statt, aber das sollte doch keine echte Hürde darstellen.
Ach ja, natürlich darf eine genaue Beschreibung sämtlicher Intel-Tools nicht fehlen, wenn es um das Multithreaden von Anwendungen geht. Also so Themen wie Intel Compiler, Parallel Inspector, OpenMP, Parallel Amplifier und viele mehr. Na, dann kann ich euch nur noch “Gut Stöber” wünschen und dass ihr möglichst viele Antworten auf eure parallelen Fragen findet. Die gibt es natürlich auch hier auf dem Software Dev Blog. Probiert doch einfach mal die Suchfunktion aus!
Maxon setzt auf Intel Softwaretools für optimierte Apps
Dass Maxon alles dafür getan hat, ihre Software-Anwendungen wie Cinema 4D für die aktuellen Intel-Prozessoren zu optimieren, darüber habe ich schon vor längeren gebloggt. Und wie es der Zufall wollte (ok, der natürlich keiner war), konnten wir mit Maxon höchstpersönlich darüber reden, wie sie es immer wieder schaffen, dass ihre Anwendungen besonders performant auf Rechnern mit Intel-Architektur laufen.
Ein wesentlicher Punkt ist unter anderem der Einsatz des Intel C++ Compilers, der laut Maxon schon mal ohne nennenswerte Änderungen am Code etwa 15 Prozent mehr Speed bringt. Aber auch der Intel Thread Profiler steht bei Maxon ganz oben auf der Liste, wenn es darum geht herauszufinden, wie sich das parallelisierte Programm verhält, ob also die anfallenden Threads möglichst gleichmäßig auf die vorhandenen Ressourcen verteilt werden (Skalierung ist hier das Zauberwort).
Darüber hinaus kommen VTune Performance Analyzer und Intel Threading Building Blocks zur Sprache. Ok, dann würde ich mal sagen, den Rest solltet ihr euch am besten selbst ansehen. Viel Spaß dabei!
Apps unter Mac OS X multicore-tauglich machen
Disclaimer: Dieser Beitrag ist ein Extrakt des Artikels “Mehrkern-Beschleuniger”, der in der mac-developer 1/2010 erschienen ist. Autor dieses Beitrags ist Maximilian Götzfried.
Ende August war ich bei Apple, um ein wenig mehr über deren Multicore-Beschleuniger Grand Central Dispatch zu erfahren. Diese in Snow Leopard implementierte Technik erlaubt es Anwendungsentwicklern, mit relativ wenig Aufwand, ihre Anwendungen multicore-tauglich zu machen. Und das ohne größeren Programmieraufwand, sondern lediglich mithilfe der C-API und den NSOperation-Klassen.
Das Tolle an GCD ist deren einfache Verwendung: Anstatt selbst Threads auf Basis von Tasks oder anderen Objekten zu erzeugen, kümmert sich GCD selbst darum. Das bedeutet aber für den Software-Entwickler, dass er sich für eine optimale Ausnutzung der vorhandenen Prozessorressourcen grundsätzlich Gedanken machen muss über die Programmlogik. Das Resultat seines überarbeiteten Programms sind einzelne Tasks, die je nach Programmablauf an die vorhandenen Multithreading-Queues übergeben werden können, wo sie von GCD bestmöglich verarbeitet werden.
Wie bereits angedeutet, stellt GCD zwei Möglichkeiten zur Verfügung, Programmcode zu multithreaden: Mithilfe der NSOperation-Klasse und der C-API. Beides soll kurz beleuchtet werden.
NSOperation: Warteschlangentechnik für asynchrone Tasks
Für das asynchrone, also zeitversetzte Ausführen von Anwendungen ist lediglich das Erstellen von NSOperation-konformen Objekten erforderlich, die dann an die zugehörige Warteschlange übergeben werden, die die Queue nach dem FIFO-Prinzip verarbeitet. Hierfür werden Tasks im Hintergrund ausgeführt, pausiert und zu Ende geführt. Es ist sogar möglich, die Anzahl der maximalen Threads festzulegen, was in Extremfällen ein einziger sein kann. Natürlich erlaubt GCD die ständige Rückkehr zum Main Thread.
Weitere Details zu Intels Cloud-Service “Parallel Universe”
Erst gestern habe ich darüber berichtet, dass Intel einen ganz neuen cloud-basierten Service vorgestellt hat, der sich Parallel Universe nennt. Dahinter verbirgt sich das kostenlose Angebot an Software-Entwickler, in häufiger Ermangelung eines Opto-Core-Rechners ihre parallelisierten Anwendungen auf deren Skalierbarkeit zu überprüfen. Das ist wirklich eine pfiffige Idee und könnte so manch einem Anwendungsentwickler (a) die Augen öffnen und (b) beim korrekten Multithreaden helfen.
Für ein paar weitere detaillierte Informationen rund um diesen Service hatte ich gestern Abend die Gelegenheit, an einer Telefonkonferenz mit James Reinders teilzunehmen. James ist Director Intel Software Development Products und beschäftigt sich schon seit vielen Jahren mit dem Thema Parallelprogrammierung. So springt er beispielsweise gerade auf der Supercomputing Conference 2009 herum, um dort vermutlich unter anderem sein paralleles Universum vorstellen. Von ihm erfuhren wir ein paar sehr interessante Details zum neuen Cloud-Service:
- Technisch gesehen ist es nicht nur ein Cloud-Rechner, sondern es sind bis zu drei Nehalem-basierte Server, die mit jeweils zwei Quadcore-CPUs bestückt sind. Das ermöglicht inklusive Hyperthreading 16 echte und parallele Hardware-Threads. Sollte ein Parallelrechner nicht ausreichen, werden ein oder zwei weitere automatisch dazugeschaltet. Dies bleibt dem Anwender natürlich vollständig verborgen. In Zukunft werden je nach Erfolgt von Intel Parallel Universe leistungsfähigere Maschinen eingesetzt, mit denen sich auch mehr parallele Threads simulieren lassen. Aber für die aktuellen Anwendungen ist eine Skalierung von maximal 16 Threads völlig ausreichend.
- Sämtliche Analysen, die von Software-Entwicklern eingereicht werden, wandern in eine Warteschlange, sodass es zwar Wartezeiten geben kann, diese allerdings kaum auffallen werden, da die Ergebnisse unmittelbar nach deren Berechnung im Webbrowser dargestellt werden.
