Mikroruckler bei Grafikkarten: Der Status quo bei AMD und Nvidia

FRAPS am Limit

Wir konnten Mikroruckler schon immer in Worte fassen, sie exakt zu messen war dagegen unmöglich. FRAPS diente uns zwar für eine Tendenzaussage, dem exakten Bildinhalt haben die Ergebnisse aber nur selten entsprochen. Um zu verstehen, warum das so ist, müssen die Renderingpipeline eines 3D-Titels und die Stelle, an der FRAPS eingreift, betrachtet werden.

Die Game Engine selbst läuft in der so genannten „Gametime“ (T_game in der Grafik genannt), einer spielinternen Uhr, die versucht, alle Abläufe zu synchronisieren und in einem fest definierten Zeitablauf zu halten. Darunter fallen zum Beispiel die Grafik-, Physik und KI-Berechnungen. Schließlich sollen der Spieler im Spiel in einer bestimmten Geschwindigkeit laufen und Gegenstände in einem bestimmten Tempo fallen, unabhängig vom System, auf dem das Spiel läuft.

Darauf folgt im Renderingprozess der „Presentcall“ (T_present), in dem die Spiele-Engine mit der Grafikkarte kommuniziert. Hier teilt die Engine der Hardware mit, dass alle notwendigen Daten auf Grundlage des aktuellen Spielgeschehens für ein weiteres zu renderndes Bild vorliegen. Die Engine hat festgelegt, was auf dem nächsten Bild wie zu sehen sein muss, jetzt gilt es dieses Bild zu erstellen (rendern).

Bereits an dieser Stelle greift FRAPS sämtliche Messdaten ab. Dabei ist es noch ein weiter Weg, bis das Bild tatsächlich auf dem Monitor wiedergegeben wird. Es gilt das Betriebssystem über die API DirectX anzusprechen, die wiederum den Grafikkartentreiber mit ins Boot holt, woraufhin die Grafikkarte das Bild rendert, bevor es ausgegeben wird. Von all diesen Schritten bekommt FRAPS nichts mit. Und das ist insbesondere bei Multi-GPU-Karten, bei denen hier noch eine Menge passieren kann, das Problem.

In vielen Grafik-Engines versucht T_game zwar, die Bildabfolge so gleichmäßig wie möglich zu gestalten, das funktioniert aber nur selten. Wenn T_game dann die Frames in unterschiedlichen Zeitabständen an die Grafikkarte weiter gibt, misst FRAPS diese Unregelmäßigkeit, obwohl der Spieler eine gleichmäßige (oder gleichmäßigere) Wiedergabe auf dem Monitor erhält. Denn wenn der T_render-Schritt fertiggestellt ist, kann beispielsweise der Treiber die Ausgabe (T_display) so lange verzögern, bis die Frames möglichst gleichmäßig auf dem Bildschirm erscheinen. Aber auch der andere Fall kann eintreten: Frames, die gleichmäßig an die Grafikkarte wandern, werden beim Rendern aus dieser Ordnung gerissen.

Darüber hinaus gibt es ein weiteres Problem. So kann es zum Beispiel passieren, dass einige Frames, die von T_game erstellt worden sind, gar nicht erst auf dem Monitor dargestellt werden, da der nächste Frame bereits fertiggestellt ist, womit der Ältere verworfen wird („Dropped Frame“). Des Weiteren gibt es Frames, die zwar auf dem Monitor dargestellt werden, jedoch nur zu einem derart kleinen Bruchteil (zum Beispiel bei einer horizontalen Auflösung von 1.080 Pixeln nur zehn Pixel), dass der Frame überhaupt nicht auffällt und damit nicht spürbar die Leistung verbessert („Runt Frame“). Ein möglicher Grund dafür ist ein ungünstiges Timing zwischen T_rendering und T_display, sodass das nächstfolgende Frame so schnell fertiggestellt ist, dass der alte, weniger aktuelle Frame nie gänzlich dargestellt wird. Neben Zeitverzögerungen nach T_game bekommt FRAPS auch diese beiden Aspekte nicht mit, was die Aussage hinsichtlich Mikrorucklern verwässert.