ATi CrossFire X gegen Nvidia Quad-SLI im Test: Ultimativer Schlagabtausch der Multi-GPUs

Multi-GPU-Technologien

Wie die Multi-GPU-Technologien CrossFire und SLI mit zwei GPUs funktionieren, ist vielen Lesern sicherlich bekannt. Generell haben die Grafikkarten in unterstützten Anwendungen die Möglichkeit, auf verschiedene Arten den zweiten 3D-Beschleuniger anzusprechen. Heutzutage wird aber beinahe ausschließlich nur noch ein Verfahren benutzt: Alternate Frame Rendering (AFR). AFR zeigt nicht nur die beste Skalierung (da die Geometrie beschleunigt werden kann), es ist darüber hinaus auch mit fast allen aktuellen Rendertechniken kompatibel und ohne größeren Aufwand umsetzbar. Neben AFR gibt es noch einige weitere Rendermethoden, sie kommen in aktuellen Spielen aber nicht mehr zum Einsatz. In diesem Abschnitt behandeln wir CrossFire und SLI als absolut gleichwertig, da AFR bei beiden Herstellern gleich umgesetzt wird.

Bei AFR arbeitet jede GPU an ihrem eigenen Bild. Ist GPU A mit Frame A fertig, nimmt sie sich schon Frame C an, während GPU B an Frame B werkelt und nach der Fertigstellung Frame D angeht. Im Optimalfall werden diese Frames dann in einem synchronen und somit zeitlich identischen Wechsel der beiden GPUs an den Monitoren ausgegeben. So weit die Theorie, denn in der Praxis läuft es längst nicht immer optimal. Doch später dazu mehr.

Bei drei oder vier GPUs funktioniert das Alternate Frame Rendering im Endeffekt auf dieselbe Art und Weise. Kommen drei GPUs zum Einsatz, arbeiten die Grafikkarten einfach nicht mehr an zwei, sondern an drei Bildern gleichzeitig. Bei vier Chips sind es schließlich vier Frames, die in einem Renderdurchlauf fertiggestellt werden. Es scheint logisch, dass dabei ein so genannter „Lag“ (Verzögerung) entsteht. Denn für die Grafikkarten ist es schließlich unmöglich vorauszusehen, in welche Richtung sich der Spieler in den zukünftigen Frames bewegen bzw. welche Reaktionen er auf dem Bildschirm auslösen wird. Diese Bewegung kann man höchstens voraus ahnen. Da dies in der Praxis nicht möglich ist, arbeitet die Grafikkarte mit den Informationen, die sie hat: Die bereits erfolgten Tastatur- und Mauseingaben des Spielers. Wenn nun der Spieler die Maus bewegt und alle vier GPUs beschäftigt sind, sein Tun in Bilder umzusetzen, dauert es seine Zeit, bis eine GPU frei wird und die nun erneut erfolgten Eingaben umsetzen kann.

Dadurch entsteht eine Art „Gummibandeffekt“, da die Mausbewegung nicht in „Echtzeit“, sondern um einige Frames verzögert auf dem Monitor wiedergegeben wird. Bei nur zwei GPUs hält sich dieser Effekt in Grenzen, bei drei oder gar vier Rechenchips steigt der Lag jedoch. Hinzu kommt, dass das Verhalten bei niedrigen FPS- deutlich stärker zu bemerken ist als bei hohen FPS-Werten, da die einzelnen Frames, die vergehen, bis die Mausbewegung umgesetzt wird, mehr Zeit in Anspruch nehmen. Dabei ist es von Mensch zu Mensch unterschiedlich, wie störend dieser Lag wahrgenommen wird, da jede Person eine andere Wahrnehmung hat. Uns hat der Lag selbst bei vier GPUs nicht gestört, bei anderen Testkandidaten kann dies aber anders aussehen.

Doch dies ist nicht das einzige Multi-GPU-Problem. Ein weiteres sind die befürchteten „Mikroruckler“. Auch hier gilt wie bei der Bewegungsverzögerung, dass sie von Person zu Person anders wahrgenommen werden und sich deswegen von diesem Verhalten jeder ein eigenes Bild machen sollte. Generell kann man aber sagen, dass die Mikroruckler um einiges auffälliger und störender als die Verzögerung sind (mehr zum Thema Mikroruckler).

Die Ursache dafür liegt im Alternate Frame Rendering begründet. Die GPUs versuchen das Bild so schnell wie möglich fertigzustellen und an den Bildschirm weiterzugeben. Da die GPUs allerdings zum selben Zeitpunkt mit dem Rechnen anfangen, sind sie meistens auch zum gleichen Zeitpunkt fertig. Dadurch erhält man die zwei quasi zeitgleich fertigen Frames sehr schnell hintereinander präsentiert, doch daraufhin benötigen die GPUs wieder einige Zeit, bis die nächsten zwei Bilder fertig gerechnet sind. Somit entstehen (variierende) Pausen in der Wiedergabe, die den Spielfluss stören.

Mit dem bekannten Tool „Fraps“ kann man dieses Verhalten in Zahlen wiedergeben, wenn man die so genannten „Frametimes“ protokollieren lässt, wobei man laut Nvidia vorsichtig bei diesen Angaben sein muss. So soll der Treiber die Bilder durchaus noch manipulieren können, was Fraps aber nicht mehr mitbekommt. Nichtsdestotrotz spiegelt Fraps unserer Meinung nach das gefühlte Ergebnis sehr gut in Zahlen wieder. Die Frametimes sagen aus, zu welchem Zeitpunkt innerhalb einer Sekunde ein fertiger Frame an den Monitor weitergegeben wird. Im optimalen Fall ist der zeitliche Abstand zwischen allen Frames absolut identisch.

Die Praxis zeigt, dass dies jedoch nicht machbar ist. Schon bei einer Grafikkarte erkennt man leichter Differenzen in den Frametimes. Diese sind aber noch so gering, dass man nichts davon mitbekommt. Anders sieht es hingegen bei zwei GPUs aus, wie wir vor einiger Zeit in einem Artikel aufgezeigt haben. Und bei Quad-SLI und bei Quad-CrossFire ändert sich an dieser Problematik nichts, wie eine eigens ermittelte Frametime-Messung und auch unser Spielgefühl zeigen: Nach (in diesem Fall) jedem vierten Bild dauert es eine Weile, bis die kommenden vier Bilder ausgegeben werden. Als Beispiel haben wir einen kleinen protokollierten Abschnitt aus dem Spiel „Jericho“ mit Quad-SLI zur Einsicht bereitgestellt. CrossFire X verhält sich in dieser Hinsicht allerdings nicht anders.

Nach diversen Telefonaten mit ATi und Nvidia konnte man in beiden Unternehmen die Mikroruckler nachstellen und versucht diese seitdem in den Griff zu bekommen. ATi konnte uns allerdings keine Lösung des Problems nennen, da unter Windows Vista der Kernel das Scheduling (also die Verteilung) der Renderbefehle übernimmt und man somit keine (schnell zu erledigende) Chance sieht, in diesen Vorgang per Treiber einzugreifen – so die Aussage seitens ATi. Nichtsdestotrotz arbeitet man weiter an dem Problem und versucht, eine Lösung zu finden. Nvidia scheint dagegen schon einen Schritt weiter zu sein. So soll es in einem zukünftigen Treiber einen Scheduler geben, der die Frames auf den GPUs verzögern und somit die Mikroruckler vermindern oder gar ganz verhindern kann. Ob dies tatsächlich funktioniert, werden erste Tests zeigen müssen. Einen Zeitpunkt für die Veröffentlichung der Lösung konnte man uns nicht nennen.

Doch von den soeben behandelten Problemen einmal abgesehen, haben sich einige Leser sicherlich gefragt, warum Quad-SLI und Quad-CrossFire urplötzlich überhaupt besser funktionieren sollten als es der erste Versuch von Nvidia mit der GeForce 7950 GX2 getan hat? Schließlich hatten wir in einem entsprechenden Artikel behauptet, dass 4-Way-AFR unter Direct3D 9 nicht funktionieren kann, da die D3D9-Spezifikationen es nur erlaubt, Befehle für drei Frames im Voraus anzunehmen – und vier Befehle im Voraus sind die Grundvoraussetzung für 4-Way-AFR. Nun, anscheinend war dies primär eine Limitierung von Windows XP, denn unter Windows Vista – und nur dort funktionieren Quad-CrossFire und Quad-SLI – ist diese Limitierung in Direct3D-9-Spielen nicht mehr vorhanden. Sofern Direct3D-9-Anwendungen unter Windows XP tatsächlich nicht von diesem Verhalten abzubringen ist, ist die Insellösung Windows Vista für 4-Way-AFR also ein notwendiges Übel.