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.
Das war die GDCE 2010: Videointerviews und mehr, Teil 1
Letzte Woche war ich ja auf der Game Developers Conference Europe, und daher ist es jetzt an der Zeit, eine große Rückschau zu halten. Das geschieht in drei Teilen, damit ihr euch das Ganze Stück für Stück einverleiben könnt. Viel Spaß beim Angucken der Videos, die wir an den drei Tagen in Köln gedreht, geschnitten und online gestellt haben.
Am ersten Tag ging es gleich mal sehr animationsmäßig los und wir hatten die Gelegenheit, uns die Havok Physics Engine näher anzusehen, mit deren Hilfe Spieleentwickler recht einfach und schnell bestimmte Effekte in ihre Games einbauen können. Dazu gehören Dinge wie Deformationen, berstende Gegenstände, etc. Und auch vollanimierte Kleidungsstücke lassen sich mit Havok generieren, ohne dass der Entwickler genau wissen muss, wie das funktioniert. Dass es funktioniert, belegen die zugehörigen Videos sehr gut.
Das Thema Spiele beschäftige uns natürlich weiterhin (sic!). So konnten wir mit Jerome Muffat-Meridol von Intel über seine Techsession reden, in der es um das Thema Multithreading von 3D-Spielen mithilfe von DirectX 11 ging. Dabei zeigte er anhand der so gennanten Nulstein-Demo, dass sich Spiele sehr gut parallelisieren lassen, wenn man den richtigen Taskscheduler und DirectX 11 für die einzelnen Phasen beim Erzeugen von 3D-Bildern dazu einsetzt, das ganze System so gut wie möglich zu parallelisieren. Und das skaliert dann problemlos auf 12 Threads, ohne dass der Entwickler große Dinge vollführen muss.
Weiter ging’s dann mit einem ganz anderen Thema, das auf dem IT-techBlog sehr viel besser aufgehoben wäre: Netbook-Games. Hierzu zerrten wir Leigh Davies vor die Kamera, um ihm drei schlaue Fragen zu stellen. Dabei kam heraus, dass Leigh in seiner Session etwas darüber verraten hatte, wie sich Spiele für Netbooks verkaufen lassen und wie man Netbook-Games für die GPU und CPU optimieren kann.
Natürlich durfe auch der Hinweis nicht fehlen, dass sich Netbooks weiterhin gut verkaufen und dass Intel bis zum Jahr 2013 mit zirka 140 Millionen verkauften Mininotebooks rechnet. Es ging außerdem auch um technische Aspekte wie die eingeschränkte Auflösung (1024*600) und die daraus resultierenden Konsequenzen. So rät Leigh zum Einsatz von Icons statt Text. Darüber hinaus sollte man sich als Spieleentwickler klar machen, dass ein Netbook wegen der guten bis sehr guten Akkulaufzeiten und des geringen Gewichts in höchstem Maße mobil ist. Auch das gilt es beim Gamedesign zu berücksichtigen.
Aber nicht nur Spiele für tragbare Computer standen bei Intel auf de GDCE 2010 auf dem Programm. Auch die neuesten Version des Analysetools Intel Graphics Performance Analyzers wurde vorstellt, und hierum kümmerte sich Steve Hughes von Intel, der uns ein bisschen was über die neuen Features von Intel GPA 3.0 erzählte, wie man damit Flaschenhälse und andere Verklemmungen in 3D-Spielen findet und wie Entwickler die Toolsuite optimal für ihre Zwecke einsetzen können. Besonders begeistert zeigte er sich von der neuen Platform View, die systemübergreifend zeigt, wie gut ein Spiel auf einer Multicore-Maschine skaliert.
So, das war`s erstmal, Teil 2 und Teil 3 folgen morgen. Darin wird es um die nächste Version von Intel GPA gehen, um das Parallelisieren von Spielen mithilfe der Intel TBB, um einen selbstgezimmerten Taskscheduler mit Taskstealing und um eine Live-Demo, die anhand von drei Teilen genau zeigt, wie sich Intel GPA einsetzen lässt.
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!
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!
Parallel Talk: Warum Ct und Rapidmind gut zusammenpassen
Auf dem diesjährigen IDF in San Francisco wurde ich selbst “Opfer”, als ich mich unversehens vor dem Whiteboard von Aaron Tersteeg wiederfand. Aber zum Glück ging es nicht nur mir so, sondern auch unter anderem Stefanus, Michael und Anwar von Intel, die etwas sagen sollten über die Ct-Technologie und warum diese mit den Paralleltechniken von Rapidmind so gut zusammen passt.
Nur so viel: Ct soll noch in diesem Jahr als Beta verfügbar sein und Software-Entwicklern dabei helfen, ihre Anwendungen noch eleganter zu parallelisieren als bisher. Und genau dieses Bestreben verfolgen auch die Jungs von Rapidmind. Das dürfte wohl der wesentliche Grund gewesen sein, warum Intel und Rapidmind seit Ende August gemeinsame Sache machen.
Aber am besten lassen wir Stefeanus, Michal und Anwar selbst zu Wort kommen …
Wie .NET-Entwickler mit VTune Bottlenecks finden können
Vergangene Woche auf der Microsoft TechEd Europe 2009 hatten wir die Gelegenheit, uns von Rami Radi zeigen zu lassen, wie .NET-Entwickler mithilfe des Profiling- und Samplingtools VTune Performance Analyzer Schwachstellen in ihren Anwendungen aufspüren und beheben können. Dabei geht es beispielsweise sehr oft um Schleifenkonstrukte, die unverhältnismäßig viel CPU-Zeit in Anspruch nehmen, was mit den richtigen Tricks gar nicht notwendig wäre. Für alle, die also in Zukunft mehr aus ihrer Software herausholen wollen, sei dieser Video-Workshop wärmstens empfohlen.
TechEd09: Wie die CCR .NET-Entwicklern bei der Parallelprogrammierung hilft
Die erste Session, die ich hier am vierten Tag der Microsoft TechEd besucht habe, wurde von Ralf Westphal gehalten, der in gewohnt unterhaltsamer und fundierter Weise das Thema asynchrone Programmierung vorstellte. Hauptsächlich auf Basis der Concurrency Coordination Runtime (CCR), die Microsoft mit Einführung des .NET-Frameworks 3.5 implementiert hat. Für alle, die mit dem Begriff CCR nicht so viel anfangen können, gibt’s auf MSDN einen kurzen Überblick.
Die erste interessante Aussage, die Ralf während seiner 75-Minuten-Session abgefeuert hat, war die Erkenntnis, dass Software-Entwickler sich selbst um das Parallelisieren ihrer Anwendungen kümmern müssen und dies nicht nur dem Betriebssystem oder anderen Instanzen überlassen dürfen. Ein weiterer Satz war nicht ganz überraschend und auch nicht neu, dafür umso wichtiger: “The free lunch is over!” Dieser Ausspruch stammt übrigens nicht von Ralf, sondern von Herb Sutter, der das bereits 2005 formuliert hat. Die Grundaussage dahinter lautet:
Künftige Prozessoren werden nicht mehr unendlich schneller, sind dafür mit immer mehr CPU-Kernen ausgestattet. Daher müssen Programmierer umdenken, um ihre Anwendungen in Zukunft zu beschleunigen.
Videochat: Die Zukunft der Parallelprogrammierung
Jetzt weiß ich zumindest, was eine “Birds of a feather”-Session ist: Viele interessierte Menschen kommen in einem mittelgroßen Raum zusammen, hören einem gut informierten Spezialisten bei seinen Ausführungen zu und mittendrin entsteht eine lebhafte Diskussion, die viele neue (aber auch bekannte) Erkenntnisse bringt. So geschehen heute Mittag am dritten Tag der Microsoft TechEd Europe 2009, wo ich der Techsession von Tiberiu Covaci beiwohnte, auf der er eine Menge zum Thema “Zukunft der Parallelprogrammierung” beizutragen hatte.
Sein Vortrag hatte allerdings eher den Charakter eines technischen Workshops, indem er selbst zunächst eine Menge zum Thema Intel, Microsoft und Multicore-Shift inklusive .NET 4 und Visual Studio 2010 erzählt hat. Auszüge gefällig?
TPL of .NET 4 delivers the right number of threads regarding the available number of cores/threads.
Needs around 200.000 instruction cycles to create a thread and 100.000 for releasing it again. As a developer you have take this into account!
TPL delivers several parallel classes like Parallel.For() and Parallel.Invoke which abstracts threads to tasks.
Visual Studio 2010 will deliver the appropriate debugger tools for parallelized applications.
Was seiner Techsession allerdings ein wenig fehlte war der Blick in seine Glaskugel, die uns Anwesenden etwas über die Zukunft der Parallelprogrammierung hätte erzählen können. Zumindest war ich genau aus diesem Grund in seinem Vortrag. Das ließ sich allerdings ganz schnell nachholen, indem wir unsere Videokamera aufgebaut und Tiberiu drei schlaue Fragen gestellt haben. Die erste handelt vom Inhalt seiner Präsentation, Nummer zwei beschäftigt sich mit seiner Podiumsdiskussion vom Montag und mit der Beantwortung von Frage drei ließ er uns in die Zukunft der Parallelprogrammierung blicken.
Nur so viel dazu: Laut Tiberiu müssen sich Software-Entwickler ab sofort mit Multithreading und Co. auseinander setzen, denn der Multicore-Shift hat schon längst begonnen. Und den Rest schaut ihr euch am besten selbst an, sobald unser Videointerview fertig und online ist.
Update: Das Video ist fertig!
Videochat: Wie .NET-Entwickler von Multithreading profitieren
Der dritte Tag der Microsoft TechEd Europe 2009 begann mit der sehr anschaulichen und technisch höchst anspruchsvollen Techsession von Rami Radi, der bei Intel als Software-Ingenieur arbeitet und anderen Entwicklern hilft, ihre Anwendungen multicore-tauglich zu machen.
Zunächst einmal muss festgehalten werden, dass die Session genauso gut besucht war wie die gestrige von Steve Teixeira. Darüber hinaus wurde schnell klar, dass die meisten Anwesenden weder wussten, dass Intel noch etwas anderes produziert als Mikroprozessoren, noch die Intel-Tools wie VTune Performance Analyzer kannten (was angesichts des “weder” keine Überrraschung war).
Ramis Präsentation befasste sich mit drei Kerngebieten: Intels aktuelle und zukünftige Mikroprozessor-Architekturen, .NET-4-Verbesserungen in Sachen Multithreading und wie Intel-Tools wie der besagte VTune Performance Analyzer Software-Entwicklern helfen können, ihre Apps auf Korrekheit hin zu überprüfen. Zu diesem Behufe sagte Rami einige bemerkenswerte Dinge:
Moore’s law doesn’t help software developers anymore as frequencies aren’t going up anymore. The good news: the number of core does!
With Nehalem you get Non Uniform Memory Acess (NUMA) which connects every CPU and memory to each other which has huge advantages.
Come to Intel booth in hall 4.2 to see one of the first desktop PCs which is able to run 128 threads in parallel!
Multithreading is not equal parallelism!
Poor scaling .NET applications can be powered up with the help of Intel VTune Performance Analyzer and Visual Studio 2010 / .NET 4
.NET 4 provides the Background Garbage Collection which speeds up managed code significantly.
Worker stealing within .NET 4 will help to achieve better multithreaded balanced managed applications.
VTune profiles and samples .NET applications in order to find critical code sections where a lot of computing time is being wasted
Vtune also helps identifying false sharing problems. Means VTune will detect and solve cache line misses.
To eliminate false sharing problems helps to speed up your .NET apps on 8 core system by 70x!
