Frameverläufe

Die selektive Betrachtung von Frameratenverläufen ist eine andere Methode, die bisher viel zu selten Einsatz gefunden hat. Prinzipiell ist diese selektive Betrachtung nichts anderes, als was wir in den letzten beiden Diagrammen sehen konnten. Anhand aufgezeichneter Frameratenverläufe wird eine längere Szene im Spiel oder Timedemo analysiert. Durch Vergleiche und verschiedene Einstellungen können somit ungleich mehr Informationen gewonnen werden.

Anstelle des einzelnen Minimums rückt die Gesamtheit aller Werte in den Vordergrund. Im letzten Diagramm lässt sich somit nicht nur erkennen, dass die 150 fps Spitze eher die Ausnahme sind, sondern dass der Spieler in der Regel mit Werten zwischen 30- und 60 fps rechnen kann. Kennt man die ausgewählte Szene, lassen sich zudem Reserven und Schwächen von CPU und GPU relativ gut abschätzen.
 
Mit folgendem Diagramm lässt sich einer der weiteren Vorteile demonstrieren.

Abbildung 3: Vergleich mit 16xQ- & Transparenz-Antialiasing

Dabei zeigt der blaue Verlauf die uns bereits bekannte Timedemo aus Comanche4, nutzt jetzt allerdings eine höhere Auflösung. Am prinzipiellen Verlauf ändert sich wenig, limitiert doch die CPU in nahezu jeder Situation. Würde man beide Verläufe übereinander legen, ließe sich auch genau dies erkennen.

Wir haben uns allerdings für den neuen roten Verlauf entscheiden, welcher die gleiche Timedemo mit 16xQ-Antialiasing und Supersampling-Transparenz-Einstellung zeigt. Innerhalb weniger Sekunden lässt sich nun erkennen, wo die Grafikkarte schlapp macht (siehe die ersten 9 Sekunden) oder die CPU noch immer den Miesepeter spielt (z.B. 15.-21. Sekunde). Als großen Pluspunkt vermerken wir also neben der Gesamtbetrachtung die direkte Vergleichbarkeit von Timedemos und Ergebnissen.

Diese Methode hat allerdings auch ihre Schwierigkeiten – damit meinen wir nicht den leider viel zu hohen Aufwand für den Redakteur. Es ist sicherlich sofort aufgefallen, dass der blaue Verlauf früher endet. Zugleich tritt der schwere Einbruch auf unter 40 fps viel früher ein. Dies liegt an der Eigenheit des Comanche4-Timedemos, die Szene mit voller Framerate abzuspielen. Logischerweise erreicht es spezifische Punkte damit eher und endet früher. Erfreulich ist, dass in diesem Fall relevante Stellen im Ablauf relativ einfach im Kopf übereinandergelegt werden können.

Abbildung 4: Das Diagramm lässt sich übereinander legen

Mit etwas Übung und Glück lässt sich sogar eine statische Verzögerung festlegen, und die schnellere Demo im Diagramm später starten. Das funktioniert allerdings nur in den wenigen Fällen, in denen viele Stellen identische Performance aufweisen, so gut wie hier:

Abbildung 5: Überlagertes Diagramm der beiden Durchgänge

Durch die hier eingefügte Konstante (schwarz) bei 120 fps verliert man zwar etwas an Vergleichskraft, was die ersten Sekunden betrifft, erreicht dafür allerdings eine gute Übereinstimmung im Rest der Demo. Jetzt fällt auch ohne Übung sofort auf, dass nach dem ersten Drittel der Demo nahezu ausschließlich die CPU limitiert. Es liegt sicherlich an der Engine von Comanche4, trotzdem ist die Sache eigentlich ein Armutszeugnis für die CPU. Was vielleicht noch auffällt: Die recht holprige Anfangsphase wirkt im blauen Verlauf arg geglättet. Dieser Effekt ist typisch für Stellen, an denen die CPU nichts zu sagen hat. Allerdings ist der Effekt in der Regel nicht so extrem ausgeprägt wie hier.

In wenigen Schritten haben wir so eigentlich die ganze Timedemo analysiert. Ob man nun mit verschiedenen Taktraten, Sound oder Auflösungen experimentiert, ist relativ egal. Mit dem bisherigen Wissen lässt sich entweder jeder Verlauf abschätzen oder unerwartete Ergebnisse zumindest erklären. Wiederholt man das Ganze noch mit der Szene aus dem eigentlichen Spiel, hätte Comanche4 als Benchmark jedes Geheimnis eingebüßt. Aber es geht uns ja um Windows Vista und nicht um Hubschrauber-Simulationen.