1. Hardwareluxx
  2. >
  3. Tests
  4. >
  5. Hardware
  6. >
  7. Grafikkarten
  8. >
  9. FCAT Teil 2: AFR und Input-Lag

FCAT Teil 2: AFR und Input-Lag

Veröffentlicht am: von

fcat-logoIm 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.

FCAT in der Theorie

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.

Frame-Metering

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.

Input-Lags

Auch hierzu ein wenig Theorie:

FCAT in der 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.

FCAT in der Theorie

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.

FCAT in der Theorie

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.

Welche ist die beste Grafikkarte (GPU)?

Unsere Kaufberatung zu den aktuellen NVIDIA- und AMD-Grafikkarten hilft dabei, die Übersicht nicht zu verlieren. Dort zeigen wir, welche Grafikkarten aktuell die beste Wahl darstellen – egal, ob es um die reine Leistungsfähigkeit oder das Preis-Leistungs-Verhältnis geht.


Social Links

Das könnte Sie auch interessieren:

  • Gigabyte GeForce RTX 2070 Super Gaming OC 8G im Test

    Logo von IMAGES/STORIES/2017/GIGABYTE-RTX2070SUPER

    Mit der Gigabyte GeForce RTX 2070 Super Gaming OC 8G wollen wir uns heute das zweite Custom-Modell der GeForce RTX 2070 Super anschauen. Anstelle von zwei Axiallüftern kommen hier gleich drei zum Einsatz und demnach wird es sicherlich interessant werden zu sehen, wie gut sie sich hinsichtlich... [mehr]

  • Zweimal RDNA als Navi: Die Radeon RX 5700 und Radeon RX 5700 XT im Test

    Logo von IMAGES/STORIES/2017/RADEON-RX-5700XT

    Mit den Karten der Radeon-RX-5700-Serie positioniert sich AMD klar in der Mittelklasse und will dieses umsatzstarke Segment besetzen. Die Details der RNDA-Architektur haben wir uns bereits angeschaut, nun geht es darum was die Hardware leisten kann. Dazu haben wir die Radeon RX 5700 und Radeon RX... [mehr]

  • Powercolor Red Devil Radeon RX 5700 XT im Test

    Logo von IMAGES/STORIES/2017/POWERCOLOR-RADEONRX5700-DEVIL

    Der erste Schwung der Custom-Navi-Karten hat uns erreicht und mit der Powercolor Red Devil Radeon RX 5700 XT schauen wir uns ein Modell an, welches laut Hersteller schneller, leiser und in allen Belangen besser sein soll. Ob man diese hohen Ziele auch erfüllen kann, schauen wir uns auf den... [mehr]

  • Sapphire Nitro+ Radeon RX 5700 XT 8G im Test

    Logo von IMAGES/STORIES/2017/SAPPHIRE-NITRO-RADEONRX5700XT

    Der erste Schwung der Custom-Modelle für die Navi-Karten von AMD ist verfügbar. Aber noch längst nicht alle der wichtigsten Modelle haben wir uns angeschaut. Die Sapphire Nitro+ Radeon RX 5700 XT ist laut diverser Empfehlungen eine dieser Varianten, auf die man einen genauen Blick... [mehr]

  • Erste Custom-Navi: Sapphire Pulse Radeon RX 5700 XT im Test

    Logo von IMAGES/STORIES/2017/SAPPHIRE_PULSE_RADEON_RX5700XT_TEST-TEASER

    Mit der Radeon RX 5700 und der Radeon RX 5700 XT zwang AMD Anfang Juli seinen Konkurrenten dazu, sein bestehendes Grafikkarten-Produktportfolio mit den ersten drei Super-Modellen aufzufrischen, musste dafür jedoch noch vor dem eigentlichen Marktstart die Preise nach unten korrigieren. Nun... [mehr]

  • Super-Ausbau: GeForce RTX 2060 Super und GeForce RTX 2070 Super im Test

    Logo von IMAGES/STORIES/2017/GEFORCE-RTX-SUPER

    Das Versteckspiel hat nun endlich ein Ende. NVIDIA lässt die Katze aus dem Sack und schlägt AMD damit ein Schnippchen, denn der Konkurrent wird erst am kommenden Sonntag, den 7. Juli, seine neuen Radeon-RX-5700-Karten offiziell auf den Markt bringen. NVIDIA legt mit seinen neuen Super-Modellen... [mehr]