Videobeweis: "Mikroruckler" zerstören den leistungssteigernden Effekt von Multi-GPU-Lösungen

Mit diesem Thread im 3D-Center-Forum wurde eine Welle ausgelöst, die mittlerweile fast jede hardwarebezogene Webseite erreichte. Der Tenor des Erstellers: SLI ermögliche zwar höhere Frameraten, das gefühlte Ergebnis liege aber oft nicht über den niedrigeren Fps-Raten einer Solo-Grafikkarte. Mittlerweile ist klar, dass nicht nur (Triple-)SLI, sondern auch Crossfire betroffen ist. Und wie wir im Rahmen unserer Multichrome-Tests feststellten, macht es auch S3 Graphics nicht besser als AMD/Ati und Nvidia.

Darüber, wann eine Bewegung für das menschliche Auge "flüssig" erscheint, scheiden sich die Geister. Fakt ist jedoch, dass 30 Frames pro Sekunde (Fps) von fast jedem Menschen als flüssig empfunden werden. Eine Sekunde besteht aus 1.000 Millisekunden, logisch betrachtet sollte man also annehmen, dass alle 33 Millisekunden ein Frame ausgegeben wird (eine Sekunde geteilt durch die Framerate). Die Frames, also Einzelbilder, erscheinen in dieser Rechnung in regelmäßigen Intervallen, wodurch unser Auge eine harmonische, flüssige Bewegung wahrnimmt. Der Rhythmus stimmt.

Das Phänomen
Hier beginnt das offengelegte Problem: Multi-GPU-Systemen gelingt oft keine regelmäßige Ausgabe der Frames; es kommt zu großen Zeitintervallen zwischen Einzelbildern - "Mikrorucklern" -, trotz vermeintlich flüssigen Frameraten. Ein Beispiel: Auf Frame 1 folgt nach 10 Millisekunden Frame 2, was einer Kadenz von 100 Fps entspricht. Frame 3 hingegen erblickt erst nach weiteren 40 Millisekunden den Schirm, gefolgt von Frame 4 nach weiteren 10 ms. Die Folge ist fatal: Die "gefühlte" Framerate eines Multi-GPU-Systems liegt im Ernstfall unter der einer Einzelkarte, und das obwohl die angezeigten Fps höher sind. Kritisch ist dieses Verhalten primär bei niedrigen Frameraten, etwa den genannten 30 Fps. Denn je weniger Fps, desto größer sind die möglichen Intervalle zwischen ihnen und umso wichtiger wird eine regelmäßige Verteilung.

Die Messung
Um die subjektive Empfindung mit harten Fakten zu untermauern, eignet sich das nützliche Tool Fraps. Es ermöglicht nämlich die Protokollierung der "Frametimes", der Ausgabezeit eines jeden Einzelbildes. Wir können mit allen drei Multi-GPU-Technologien je nach Spiel mehr oder minder ausgeprägte Frame-Verzögerungen bestätigen. Das Problem tritt nicht überall auf und ist oft nur angedeutet vorhanden, es existieren aber kritische Fälle. Need for Speed Pro Street, Unreal Tournament 3, Crysis und der 3D Mark 06 sind prominente Beispiele. Werfen wir doch mal einen Blick auf die ersten 30 Frames (X-Achse) eines Pro-Street-Rennens:



Klar ersichtlich: Die Visualisierung der Frames einer Single-GPU gleicht einer Geraden, die Abstände zwischen Zeit und Frames ist also regelmäßig. Anders bei zwei GPUs, bei der sich "Zacken" bilden, die Verzögerungen symbolisieren. Diese Werte stammen von einer Radeon HD3870 X2, einmal mit und einmal mit deaktiviertem Onboard-Crossfire. Zwei HD3870-Karten verhalten sich identisch, Geforce-8-SLI und S27-Multichrome zeigen vergleichbare Störungen der Frameintervalle.

Videobeweis
Damit Sie sich endlich selbst ein Bild der Auswirkungen machen können, haben wir ein Video angefertigt, das mittels NfS Pro Street und UT3 zeigt, wie sich das Mikroruckeln auswirkt. Das Video gibt es Flash oder auch als hochauflösendes WMV zum Download für registrierte User. Achten Sie bei Pro Street auf die Fps-Anzeige: Das Crossfire-Setting gibt ähnliche angezeigte Frameraten aus wie die Solokarte, das Geschehen wirkt jedoch ruckeliger. Noch deutlicher ist es bei UT3: Crossfire sorgt für eine Fps-Anzeige zwischen 25 und 30, eine GPU rendert zwischen 15 und 18 Fps. Subjektiv ruckeln aber beide gleich stark, die Einzelkarte wirkt tendenziell sogar flüssiger.

Lösungen?
Zuverlässige Lösungsmethoden existieren noch nicht, AMD und Nvidia sind aber informiert. Das Problem rührt vermutlich von den überall eingesetzten Verfahren zur Aufteilung der Rechenarbeit auf mehrere GPUs. Beim Alternate Frame Rendering (AFR) berechnet jeder Grafikprozessor im Wechsel mit dem anderen ein Frame. Offenbar fehlt hier eine Instanz, die diese Frames mit einer Harmonie versieht, auf dass sie regelmäßig ausgegeben werden. Kommende Grafiktreiber könnten für das nötige Balancing sorgen.