Vor einigen Wochen tauchte der Begriff FCAT oder Frame Capture Analysis Tool erstmals auf. Die Diskussion warf viele Fragen auf, vor allem aber eine: Wie und was wird eigentlich gemessen? Kommt kein synthetischer Benchmark mit Punkte-System oder eine integrierte Version des Spiels bzw. der Engine zum Einsatz, verwenden die meisten Redaktionen und auch wir FRAPS. Damit lassen sich zwar Minima-, Maxima- und Durchschnittswerte bestimmen, doch für eine tiefer gehende Analyse eignet es sich nicht. Auch wir haben FRAPS in der Vergangenheit verwendet, um Mikro-Ruckler darzustellen, aber auch hier durfte man sich die Frage stellen, was eigentlich gemessen wird. Nun aber soll es drehen. In diesem ersten Teil wollen wir uns FCAT also in der Theorie anschauen. Teil zwei soll sich mit der Entstehung von Mikrorucklern, Tearing und anderen Effekten beschäftigen, während wir im letzten Teil einen ersten Blick auf die eigenen Ergebnissen werfen wollen.
Eines wollen wir von Anfang an klarstellen: NVIDIA ist der treibende Motor hinter FCAT. Dies sollte zu Beginn komplett wertfrei festgehalten werden, denn FCAT funktioniert sowohl für Karten von NVIDIA wie auch AMD. Laut eigenen Angaben hat NVIDIA zwei Jahre mit der Entwicklung von FCAT verbracht. Um dem Verdacht der Befangenheit zu entgehen, hat NVIDIA den Code der Tools und Skripte freigegeben, sodass sich jeder selbst einen Eindruck davon verschaffen kann.
Warum hat NVIDIA das Frame Capture Analysis Tool entworfen? Mithilfe von FRAPS lassen sich wie gesagt auch Frametimes und damit Effekte wie das Stuttering oder die Mikro-Ruckler von Multi-GPU-Systemen messen, dies allerdings nur in einem begrenzten Rahmen. Das menschliche Auge ist aber weitaus empfindlicher und die Wahrnehmung eine andere, als dies FRAPS meist wiedergibt.
Nun wollen wir uns der Theorie hinter FCAT widmen.
Werbung
Zunächst einmal kann festgehalten werden: Was die Grafikkarte am Ausgang an Bildern pro Sekunde liefert, unterscheidet sich von dem, was an Bildern pro Sekunde an das Display geliefert wird. Während die Ausgabe in fixen Wiederholraten von 30, 60 und 120 Hz erfolgt, berechnet die Grafikkarte abhängig von ihrer Performance unterschiedliche Bilder pro Sekunde.
Zunächst einmal wollen wir versuchen zu verstehen, wo FRAPS ansetzt, um seine Messungen vorzunehmen. FRAPS greift als Software direkt nach der Ausgabe der Game-Engine ab, bevor die Daten an die DirectX-API übergeben werden. Was folgt sind noch die Rendering-Stufen in DirectX, dem Treiber und dem eigentlichen Rendering der Hardware als solches. Diese Schritte sind allerdings nicht immer in der gleichen Zeit durchlaufen, so dass die Zeitabstände für T_present stabil sein könnten (bei 30 FPS z.B. 33,3 ms), die Abstände zwischen T_render und T_display davon aber grundverschieden und vor allem wesentlich unregelmäßiger sein können.
Diese Unregelmäßigkeiten bezeichnet NVIDIA als Drop und Runt:
Drop: Ein Drop ist ein Frame, der zwar von der Game-Engine an die weiteren Rendering-Prozesse übergeben, vom Display aber nicht mehr dargestellt wird. FRAPS zählt diesen Frame dennoch.
Runt: Ein Runt ist ein Frame, der zwar auf dem Display dargestellt wird, der aber nur einen sehr schmalen Bildbereich einnimmt und daher eher für Irritationen beim Spieler sorgen könnte als eine sinnvolle Darstellung ist. Auch dieser Frame wird von FRAPS gezählt, spielt für den Spieler allerdings kaum bis gar keine Rolle.
Um die einzelnen Frames messen zu können, legt NVIDIA eine fixe Folge von farbigen Balken über die einzelnen Frames. Die Analyse-Tools kennen diese Abfolge und können daraus nicht nur ermitteln, wie viele Bilder pro Sekunde berechnet wurden, sondern auch wie lange dies gedauert hat und ob diese überhaupt dargestellt werden. In der obigen Darstellung ist dies in der Theorie zu sehen.
Links sind fünf Frames dargestellt, die mit dem jeweiligen Overlay versehen sind. Rechts ist zu sehen, wann diese auf dem Display dargestellt werden. In diesem Beispiel unterscheiden sich die Rendering- und die Display-Zeiten. Dies führt dazu, dass im Display-Refresh1 der Game-Frame1 und im unteren Drittel der Game-Frame2 dargestellt werden. Im zweiten Display-Refresh ist weiterhin der Game-Frame2 sowie der Game-Frame3 zu sehen. Den ersten Runt sehen wir im Display-Refresh3. Hier wird der Game-Frame3 nur noch zu einem kleinen Teil im oberen Bereich überhaupt dargestellt und während des Refreshs durch den Game-Frame4 ersetzt.
Wie die Darstellung eines dargestellten Frames mit mehreren gerenderten Frames aussieht, zeigt obiges Bild. Gut ist hier auch das Overlay zu sehen, das in folgender Reihenfolge die gerenderten Frames markiert:
- Weiß
- Hellgrün
- Blau
- Rot
- Blaugrün
- Navyblau
- Grün
- Aqua
- Rotbraun
- Silber
- Lila
- Olive
- Grau
- Magenta
- Gelb
- Orange
In obigem Beispiel fehlt nun ein Frame, denn zwischen dem gerenderten Frame 1 und 3 müsste ein olivenfarbiger Frame 2 angezeigt werden. Zwar hat die Game-Engine diesen Frame an die Rendering-Pipeline übergeben, diese wurde aber nicht dargestellt. Mehrere Gründe sind denkbar, warum dies geschehen kann. Fehler in der Rendering-Pipeline sind ebenso möglich, wie ein bewusstes Auslassen des Frames, da Treiber und Hardware das Game-Timig nicht einhalten konnten.
Was ein Runt ist, haben wir drei Bilder vorher schon einmal gesehen. Entstehen können sie vor allem durch zwei Gegegebenheiten: In der Theorie berechnen Multi-GPU-Systeme ihre Frames sehr gleichmäßig. In der Praxis aber sind hier zum Teil deutliche Unterschiede vorhanden. Wahrscheinlicher aber ist, dass Rendering- und Display-Timing ein Worst-Case-Szenario erwischt haben. Diese Runts treten nur am oberen und unteren Bildrand auf und beschreiben Frames, die zwischen 1-4 ms dargestellt werden. NVIDIA hat diese derart definiert, dass nur 20 von 1080 Pixel bei einer Auflösung von 1920 x 1080 Pixel von diesem Runt gezeichnet werden.