Spraylight Blog

Im Netz existieren bereits einige Websites die sich mit dem Thema CPU- und (3D-)Grafikperformance des SGS II im direkten Vergleich zu seinen Konkurrenten befassen, zB http://www.anandtech.com/show/4177/samsungs-galaxy-s-ii-preliminary-performance-mali400-benchmarked um nur ein Beispiel zu nennen. An dieser Stelle wollen wir nun ins selbe Horn stoßen und ebenfalls eine kleine Performance-Analyse durchführen.

Während beim iPhone4 und beim Samsung Galxy S noch ein Single Core Prozessor mit ARM Cortex-A8 zum Einsatz kam, verwendet das SGS II bereits einen Dual Core Prozessor mit ARM Cortex-A9 Technologie. Bei der GPU wurde nicht mehr auf die bewährte PowerVR Technik von Imagination Technologies gesetzt, sondern der neue Mali-400 MP Graphikprozessor von ARM verwendet.

Viele Benchmarkergebnisse die Grafikleistung betreffend sind auf der Website http://www.glbenchmark.com zu finden. Wir haben ein paar Werte für iPhone 4, SGS und SGS II hier zusammengefasst:

Nach diesen vielversprechenden Testergebnissen der Web-Community sind für uns natürlich ein paar Fragen von besonderem Interesse: Kann unsere Game-Engine diese Ergebnisse bestätigen? Gibt es Möglichkeiten, die effektive Leistung noch weiter zu steigern? Kommt die Murl-Engine überhaupt an die Performance und Effizienz eines GLBenchmark 2.0 heran?

Die ersten hausinternen Testfälle zeichnen ein äußerst positives Bild: Skeleton-Animation via GPU-Vertex-Skinning läuft erwartungsgemäß mit konstanten 60fps. Der mit einem um einiges aufwändigere Pixel-Shader (Per-pixel lighting, Fresnel-Reflektionen, Doppeltes Bump-Mapping etc.; mit zwei 2D-Texturen und einer Cube Map) durchgeführte zweite Test, der auf dem iPhone 4 mit nativer Auflösung (960×640) gerade einmal 10-15fps erreicht, läuft auf dem SGS II ebenfalls mit knappen 60fps; unter Berücksichtigung der etwas geringeren Auflösung (800×480) ergibt sich hier eine Steigerung der GPU-Leistung um den Faktor 2,5-3,5.

So weit, so zufriedenstellend.

Natürlich gehört es heutzutage für jede (3D-)Game-Engine schon quasi zum guten Ton, mit einem ganz bestimmten Feature aufwarten zu können: Rendering von Dungeons à la Quake III. Demzufolge handelt es sich beim dritten Test unserer Reihe um einen solchen Dungeon, im speziellen um die Map “chiroptera” (http://www.map-factory.org/quake-3/deathmatch/chiroptera-372), die auch als Sample in der frei verfügbaren OGRE Engine Verwendung findet (http://www.ogre3d.org).

Die Überraschung war groß. Der Frust auch. Von ruckelfreien 60fps des iPhone 4 (960×640) und Samsung Galaxy (800×480) konnte auf dem SGS II bei diesem Test keine Rede sein: die Framerate erfuhr einen massiven Einbruch auf ca. 10fps, im krassen Gegensatz zu den Erwartungen.

Eine schlaflose Nacht später war die Ursache des Problems entdeckt, eine weitere schlaflose Nacht später auch die Lösung implementiert (Achtung: Jetzt wirds technisch):

Im Falle der “chiroptera”-Map verwendet die Murl-Engine in der ursprünglichen Implementierung ein einzelnes statisches Vertex Buffer Object (VBO) um alle Eckpunkte der Map zu speichern; jeder der insgesamt 85 Render-Batches verwendet ein dynamisch erzeugtes Index-Array, dessen Elemente mehr oder weniger verstreut in dieses VBO indizieren. Die erste Vermutung für den Performance-Einbruch bezog sich auf die dynamische Generierung der Index-Buffer und daraus resultierende mögliche GPU-Stalls, was sich jedoch glücklicherweise als falsch herausstellte. Die zweite Vermutung bezog sich auf die verstreute Anordnung der Index-Buffer-Elemente und eine möglicherweise zu hohe Anzahl von Cache-Misses der GPU; eine Umordnung der Einträge im VBO brachte jedoch auch keine Verbesserung der Situation. Der Erfolg stellte sich erst mit der dritten Vermutung ein: Ein Aufsplitten des einzelnen VBOs in mehrere kleine (exakt: Ein VBO pro Index-Buffer) brachte das gewünschte Ergebnis: Konstante 60fps auf dem SGS II!

Der Frust war wieder weg. Das Aufatmen groß.

Die Lösung ist nun, die Map so zu konvertieren, sodass für jeden dynamischen Index-Buffer exakt ein statisches VBO zur Verfügung steht. Der Nachteil dieser Lösung ist jedoch, dass es bei jedem Render-Batch notwendig wird, auch das VBO neu zu binden, d.h. alle notwendigen Attribute-Pointer neu zu setzen. Im Sinne eines immer wieder gepredigten sparsamen Umgangs mit OpenGL State-Switches erscheint diese Vorgehensweise recht ineffizient; in der Praxis ist der Performance-Verlust zwar nicht vernachlässigbar, aber immerhin noch vertretbar.

Fazit: Die im SGS II verbaute Mali-400MP GPU von ARM zeigt im Allgemeinen eine bestechende Leistung, sie tut sich jedoch mit dem ausgelieferten Grafiktreiber offenbar enorm schwer, vereinzelte geometrische Primitives aus einem übergroßen Vertex-Array (bzw. VBO) zu indizieren. Im Falle der Murl-Engine ließ sich dieses Problem mit relativ geringem Aufwand beheben; es sind jedoch andere Situationen oder Rendering-Techniken vorstellbar, in denen es nicht so ohne weiteres möglich ist das Daten-Layout anzupassen. In einem solchen Fall kann diese Einschränkung zu massiven Performance-Problemen führen. Es bleibt zu hoffen, dass dieses Eigenheit lediglich aus einer sub-optimalen Implementierung des OpenGLES-Treibers resultiert; in Anbetracht der Tatsache, dass es sich bei besagter GPU um ein recht neues Stück Technik handelt, erscheint diese Möglichkeit als sehr wahrscheinlich. Wir sind schon auf das nächste Update gespannt.