Werbung
Im ersten Teil unserer Betrachtung von FCAT haben wir uns die Symptome in der Theorie angeschaut und die Methodik erklärt, die hinter dem Frame Capture Analysis Tool steckt. Die eigentliche Ursache sowie einige Seiteneffekte haben wir vorerst ausgespart. Bevor wir uns aber den ersten Ergebnissen widmen wollen, sollte verstanden werden, warum es überhaupt zu Mikrorucklern oder dem Tearing kommt und welche Auswirkungen Eingriffe wie die vertikale Synchronisierung (Vsync) auf das Spielgeschehen haben.
Zunächst einmal muss verstanden werden, warum Mikroruckler überhaupt auftreten: Sowohl AMD wie auch NVIDIA verwenden in ihrer Multi-GPU-Umsetzung das Alternate Frame Rendering (AFR). Mithilfe dieser Methode soll die Darstellung der Frames auf zwei oder mehr GPUs aufgeteilt werden. Wie der Name schon sagt, wechseln sich beim AFR die GPUs bzw. Grafikkarten beim Rendering der Frames ab. Frame1 wird von GPU1 berechnet und Frame2 von GPU2. Dies funktioniert auch mit drei oder vier GPUs, die Methodik bleibt die Gleiche. CrossFire und SLI unterstützen theoretisch auch noch andere Methoden, wie das Split Frame Rendering, diese sind allerdings wesentlich schwieriger abzustimmen und skalieren für die Durchschnitts-FPS auch nicht sonderlich gut.
Das Load-Balancing zwischen zwei GPUs klingt in der Theorie also recht einfach, stellt die Hersteller in der Praxis aber vor gewaltige Probleme. Schon das Rendering eines einzigen Frames ist eine massive Aufgabe, die über parallele Prozesse auf Block- und Pixelebene gelöst wird. Solche parallelen Prozesse gleichen sich aber nie, selbst bei aufeinanderfolgenden Frames. Die Game-Engine gibt die zu berechnenden Daten an die Grafikkarte und diese wiederum versucht den darzustellenden Frame schnellstmöglich zu berechnen. Je nach Komplexität der Szene dauert dies unterschiedlich lange. Bei 60 Frames pro Sekunde benötigt die Karte im Schnitt 16,7 ms. Dies ist allerdings nur ein Durchschnittswert, denn in der Realität sind die Abstände zwischen den Frames sehr unterschiedlich. So kann es vorkommen, dass Frame 1 bereits nach 10 ms die Rendering-Pipeline verlässt und für den Frame 2 40 ms benötigt werden.
Hinzu kommt, dass nur eine Grafikkarte in einem Multi-GPU-System an den Monitor angeschlossen ist. Jeder zweite gerenderte Frame muss also zunächst einmal von GPU2 an GPU1 übertragen werden. Dies geschieht bei AMD und NVIDIA über den proprietären CrossFire- oder SLI-Anschluss. Dual-GPU-Karten wie die Radeon HD 7990 und GeForce GTX 690 lösen dies über die interne PCI-Express-Verbindung (wie einige Low-End-Multi-GPU-Varianten auch). Aber nicht nur fertig gerenderte Frames werden übertragen, auch Rendering-Informationen müssen je nach Engine ausgetauscht werden, was über das PCI-Express-Interface geschieht und ebenfalls Latenzen verursacht.
All diese Effekte sorgen für die bereits erwähnten unterschiedlichen Zeiten, die ein Frame benötigt um auf dem Display dargestellt zu werden. Diesen Unterschied in den Frametimes nimmt der Spieler als Ruckler wahr und auch Effekte wie das Tearing, Runts und Drops rühren daher. Mit Hilfe von FCAT können diese nun besser als zuvor dargestellt werden, da FCAT an einer anderen Stelle des Rendering-Prozesses analysiert, als dies mit FRAPS möglich ist.
[h3]Frame-Metering[/h3]
Sowohl AMD als auch NVIDIA ist sich der Problematik bewusst und beide arbeiten an Lösungen bzw. haben diese zum Teil bereits umgesetzt. Während NVIDIA sogar über einige Details spricht, hält sich AMD in dieser Hinsicht sehr zurück. Dennoch konnten wir erst kürzlich einen Blick auf einen "Prototypen-Treiber" von AMD werfen, der das sogenannte "Frame-Pacing" verwendet, um die Frametimes etwas anzugleichen. Bei NVIDIA soll sich sogar ein signifikanter Anteil an "Hardware" auf einer GPU damit beschäftigen, die Mikroruckler und andere Effekte zu minimieren. Dazu werden zu jeder Zeit die durchschnittlichen FPS ermittelt und Schwankungen in den Frametimes ausgeglichen - das sogenannte Frame-Metering. Diese Techniken befinden sich laut NVIDIA bereits seit der G80-Generation (GeForce-8000-Serie) in deren GPUs.
Wie auch beim AFR klingt das Frame-Metering in der Theorie sehr einfach, bringt allerdings auch einige Nachteile mit sich. Sind GPUs und deren Rendering-Pipeline eigentlich dazu ausgelegt einen Frame schnellstmöglich auszugeben, verzögert dies das Frame-Metering künstlich. Angriffspunkt ist das Ende der Rendering-Pipeline und die Ausgabe an das Display. Dies führt aber nicht nur zu einer Verzögerung des Frames, sondern auch der Eingaben des Nutzers - dem Input-Lag. Allerdings wird das Input-Lag nicht per se durch die Verwendung von Frame-Metering erhöht und auch die Aktivierung von Vsync wirkt sich nicht zwangsläufig positiv aus.
Hinzu kommt, dass nicht nur der verwendete Treiber oder die GPU eine Variable sind, sondern auch die Game-Engine. In späteren Tests werden wir sehen, dass nicht nur Optimierungen im Treiber zu besseren oder schlechteren Ergebnissen führen, sondern diese auch maßgeblich von der jeweilig verwendeten Engine abhängen.
[h3]Input-Lags[/h3]
Auch hierzu ein wenig Theorie:
Input-Lags treten nicht nur bei Multi-GPU-Systemen auf, sondern sind grundsätzlich vorhanden. Taktung von Game-Frame und des Inputs (beispielsweise einer Maus) unterscheiden sich und laufen nicht synchron. Oben ist ein Worst-Case-Szenario dargestellt. Input 1 wird erfasst, bevor Frame n gerendert wird. Die Darstellung von Frame n mit Input 1 erfolgt gemeinsam. Input und Ausgabe auf dem Display liegen also nur wenige Millisekunden auseinander. Wird Input 2 nun kurz nach der Ausgabe von Frame n erfasst, kann die Darstellung erst erfolgen, nachdem Frame n+1 gerendert wurde und ausgegeben wird. Diese Verzögerung nimmt der Nutzer als Input-Lag war.
Bei ausgeschaltetem Vsync und mit Frame-Metering stellt sich dies wie folgt dar: Input 1 wird erfasst und gemeinsam mit Frame n dargestellt, der von GPU0 berechnet wird. Von der Eingabe bis zur Darstellung vergeht nur die Zeit des Renderings. Input 2 wird kurz darauf erfasst, kann aber nicht mehr in Frame n dargestellt werden. Da GPU1 dank AFR alternierend bereits mit Frame n+1 beginnen kann, wird hier der Input 2 am Ende des Renderings dargestellt. Im Unterschied zur Single-GPU kann Input 2 also etwa 50 Prozent schneller umgesetzt werden.
Dies gilt natürlich nur in der Theorie und wenn wir von Single-GPU zu Dual-GPU von den doppelten FPS ausgehen und das Frame-Metering die Frametimes auf immer den gleichen Wert bringen kann.
Ohne Frame-Metering sehen wir ein Szenario, das wir schon von der theoretischen Betrachtung im Single-GPU-Betrieb her kennen. Input 2 wird zu spät erfasst, um in Frame n und Frame n+1 dargestellt zu werden. Erst mit Frame n+2 erfolgt die Ausgabe, die Input 2 für den Nutzer wiedergibt.
Vsync gilt als Möglichkeit den Input-Lag zu reduzieren. Durch Vsync aber bewegen wir uns in fixen Wiederholfrequenzen von 60, 30 Hz usw. Da wir aber immer wieder Änderungen in den Frametimes sehen, wechseln Monitor und Grafikkarte entweder dauernd zwischen den Wiederholfrequenzen oder müssen Frames verzögern, was dann auch die Ausgabe des Inputs verzögert.
Unser aktuelles Fazit zur Input-Lag-Problematik: Wie auch bei den Mikrorucklern hilft es Input-Lags zu vermeiden, in dem man sich in Frame-Bereichen um 50-60 FPS bewegt. Darunter kann es im Single-GPU-Betrieb oder bei Multi-GPU-Systemen ohne Frame-Metering zu Verzögerungen kommen, die nicht nur optisch vom Nutzer wahrgenommen werden, sondern auch bei Eingaben spürbar sind und teils extrem störend sind. Messbar sind diese Input-Lags leider nicht. Dazu müsste es eine Schnittstelle ähnlich dem Angriffspunkt für die FCAT-Messungen geben, die es erlaubt, die Zeitenunterschiede zwischen Eingabe und Ausgabe der Nutzereingaben zu messen. Auch hier könnte eine Art Farbcode-Overlay verwendet werden. Uns ist allerdings nicht bekannt, ob sich so etwas durch eine Zusammenarbeit zwischen Engine-Entwickler und Grafikkarten-Hersteller realisieren ließe.
Im bald folgenden letzten Teil schauen wir uns erste Ergebnisse der FCAT-Messungen an. Darin vergleichen wir das Verhalten einer GeForce GTX Titan gegen das eines SLI-Systems aus diesen Karten sowie Ergebnisse einer Radeon HD 7970 und 7990 mit und ohne dem neuen "Prototypen-Treiber" von AMD mit Frame-Pacing/Frame-Metering.