> > > > FCAT Teil 2: AFR und Input-Lag

FCAT Teil 2: AFR und Input-Lag

DruckenE-Mail
Erstellt 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.

Social Links

Ihre Bewertung

Ø Bewertungen: 5

Tags

Kommentare (36)

#27
customavatars/avatar2550_1.gif
Registriert seit: 20.08.2002
in der Nähe von Cottbus
Korvettenkapitän
Beiträge: 2049
Eins vorweg: Ich verteufele FCAT nicht per se. Aber ich habe bei einigen Punkten halt Bauchschmerzen.

Zitat scully1234;20638858
Benchmarksequenzen ist u sind noch nie standardisiert gewesen unter den Redaktionen oder gab es da jemals Absprachen?


Da hast du natürlich recht. Es gibt keinen Standard. Doch einige Spiele nutzen Timedemos, die gern genutzt werden, weil man als Reviewer dadurch eine nahezu perfekt reproduzierbare Szene hat - und die ist natürlich bei allen Redaktionen gleich. Zudem kristallisiert sich auch manchmal heraus, dass bei fehlenden Timedemos die gleichen Level verwendet werden. Zum Beispiel habe ich bei Battlefield 3 verdammt oft gelesen, dass Operation Swordbreaker als Benchmark verwendet wird. Klar ist das Level lang und man kann verschiedene Szenen nehmen, aber schon allein, dass es häufig eingesetzt wird, bringt eine gewisse Vergleichbarkeit mit sich.

Grundsätzlich hast du natürlich recht, was die heutige Situation angeht. Aber das bischen Vergleichbarkeit, was es heute noch gibt, kann mit FCAT auch noch flöten gehen. Kann, muss nicht.


Zitat scully1234;20638858
Zudem produziert es noch etwas nämlich Druck,Druck auf die Hersteller das hier und jetzt bei der Treibergestaltung nicht schleifen zu lassen,da die Redaktionen jetzt ein probates Mittel an der Hand haben zu analysieren

Und die Analyse der Redaktionen gibt den Herstellern vielleicht auch wieder ein Feedback wo man noch Ansätze hat etwas zu optimieren


Im Endeffekt kommt es nur dem Anwender selbst zu gute wenn AFR zumindestens die Symptome gelindert bekommt wenn auch die Krankheit dieser Technik selbst nie ganz verschwindet


Diese Vorteile gibt es in der Tat und ich begrüße sie auch. Nur empfinde ich die Einschränkungen derzeit größer als die Vorteile.



Jetzt mal ganz weg von meinen Befürchtungen. Ich habe noch eine Frage speziell zu der Herangehensweise von Hardwareluxx:

Die Capture-Daten werden ja in eine Ramdisk geschrieben. Diese ist zwar recht üppig dimensioniert, im Vergleich zu den anfallenden Daten jedoch schnell gefüllt. Kurze Benchmark-Sequenzen wären hier also an der Tagesordnung. Wie würde das in Bezug auf Boost-Szenarien geregelt, wie zum Beispiel bei Titan? HT4U hat je recht ausführlich gezeigt, dass es sich bei Boost 2.0 ohne irgendwelche Eingriffe in PT und TT quasi um ein Benchmark-Feature handelt, da bei längerer Belastung immer häufiger nur noch der Standardtakt anliegt.

Da ich davon ausgehe, dass sowohl NVIDIA als auch AMD weiter in Richtung Boost investieren werden (es möglicherweise irgendwann zum Standard jeder Grafikkarte gehört), könnten kurze Benchmark-Sequenzen solchen Boost-Szenarien prinzipiell in die Karten spielen.

Gibt es bereits Überlegungen, wie damit umgegangen werden soll ("vorheizen" oder nicht)?
#28
customavatars/avatar145021_1.gif
Registriert seit: 12.12.2010

Banned
Beiträge: 5646
Zitat Hardwareluxx
Allerdings wird das Input-Lag nicht per se durch die Verwendung von Frame-Metering erhöht


Könntest du nochmal erklären Don, wie ihr darauf kommt? Danke!
#29
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31959
Zitat Schaffe89;20642381
Könntest du nochmal erklären Don, wie ihr darauf kommt? Danke!


Neja, in dem Fall, das das Metering die Zeit nicht angleichen muss, erhöht sich auch das Inputlag nicht...
Und sofern sontin recht behält mit seiner Aussage, dann setzt das Metering nicht bei der Ausgabe an und verzögert, sondern weit vorher. Mit dem Vorteil, eben auf die jeweils aktuellen Inputs direkt vor dem Rendering zugegriffen wird. Somit entsteht kein wirkliches Inputlag an der Stelle. Bzw. ggf. nur ein unwesentliches... Der Nachweis dafür steht aber wohl noch aus. Zumindest ist daraus nichts aus den NV Folien zu entnehmen.
Eher sogar das Gegenteil, denn die MGPU ohne Metering Folie zeigt den Extremfall... Praktisch wird Frame 0 und 1 nicht (bildlich) so nahe beieinander liegen. Denn bei um die 30 FPS schwankt die Frametimerate eher irgendwo bei 10 zu 50 oder 20 zu 40. Sprich der zweite Frame würde entgegen der NV Folie ein Stückweit später (aber vor der Position mit Metering) anfangen. Und hätte auch den Input 2 inkludiert.

Aber scheinbar hab ich das Inputlag entgegen ein paar Aussgen hier doch verstanden. Denn meine Ausführungen im ersten Teil vom Test besagen einen ziemlich identisches Resultat. ;)
#30
customavatars/avatar145005_1.gif
Registriert seit: 12.12.2010

Oberleutnant zur See
Beiträge: 1352
Nein, ohne Frame-Metering ist der Abstand der Verarbeitung zwischen den beiden Karten minimal. Die Frametimes spielen keine Rolle, da Karte 2 ja das Ergebnis von Karte 1 immer sofort überschreibt. Und nur dadurch entstehen diese Lücken von 8 - 24 - 8 - 24ms bei Fraps.
Die Verarbeitung wäre aber immer nur 1,4,17,20,33,36ms...

Wenn der Input-Buffer aber nun 0ms (Sichtbar 17ms später), 5ms (sichtbar 28ms später!) , 18ms (sichtbar 18ms später) etc. ist, dann hat man das Problem, dass Eingaben deutlich später erscheinen, nicht erfasst werden oder sogar in die Frames wandern, die sofort von Karte 2 überschrieben werden.
#31
customavatars/avatar3377_1.gif
Registriert seit: 15.11.2002
www.twitter.com/aschilling
[printed]-Redakteur
Tweety
Beiträge: 29105
FCAT Teil 3: Eine erste Analyse
#32
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31959
Zitat sontin;20643363
Nein, ohne Frame-Metering ist der Abstand der Verarbeitung zwischen den beiden Karten minimal. Die Frametimes spielen keine Rolle, da Karte 2 ja das Ergebnis von Karte 1 immer sofort überschreibt. Und nur dadurch entstehen diese Lücken von 8 - 24 - 8 - 24ms bei Fraps.
Die Verarbeitung wäre aber immer nur 1,4,17,20,33,36ms...


Ja, das schon klar mit dem überschreiben.
Nur 8 - 24 - 8 - 24 - ... sind im Schnitt 16 ms.
Das heist knapp 60 FPS.
Irgendwoher müssen diese 8ms ja kommen...
Wäre der Umstand so minimal, wie auf der dritten Folie, müsste es eher 1 - 33 - 1 - 33 sein. Macht nämlich am Ende ebenso knapp 60 FPS.

Und die von dir angesprochenen 8 von 34 sind weit mehr wie der Abstand zwischen Frame 1 und n+1 der Folie ;) Das mein ich damit. Auch wenn die Folie nur eine Illustation sein soll schaut mir das nach etwas zu viel Worstcase aus...
8 ms Abstand als niedrigste Ausgabe ist bei mir bei nem Durchschnittswert von 16ms Ausgabezeit im Schnitt alles andere als "sofort überschreibt".
Bildlich wäre dies auf der Folie also ziemlich exakt mittig zwischen dem metered und dem unmetered Bild angeordnet. (mit den Werten von dir)

Zitat MusicIsMyLife;20637603
3. Mich stört ein wenig das festgesetzte Limit auf 21 Zeilen, ab welchem ein Bild erst gezählt wird. Klar muss man irgendwo eine Grenze ziehen, allerdings hat das auch einen Nachteil. Man stelle sich den Vergleich zweier Grafiklösungen vor, die beide konstant 100 FPS liefern. Bei Lösung 1 wird jeder zweite Frame mit genau 20 Zeilen dargestellt (und deshalb als runt gewertet) und bei Lösung 2 wird jeder zweite Frame mit 21 Zeilen dargestellt (und deshalb komplett gewertet). Obwohl die Lösungen technisch gesehen nur um 5 Prozent differieren (20 vs. 21 Zeilen), liegen ihre observed FPS glatt 100 Prozent auseinander (50 vs. 100 FPS). Das dieser Unterschied in der Realität Niemandem auffallen dürfte, versteht sich von selbst (und wer das merkt, hat meinen tiefsten Respekt! -> das meine ich ernst! :)).


Praktisch dürften es ja weit weniger RUNT Frames sein ;)
Auch bei den PCP Messungen scheint das CF zwar da etwas höher zu liegen als das SLI, in Summe dürften aber eher die DROP Frames das Problems ein...
Ansonsten sehe ich das aber auch wie du, denn diese wenigen Zeiten nutzen einem wenig bis nichts...

Interessant wäre ggf. noch die Auswertung der RUNT Frames. So nach dem Motto, wie viele Zeilen sind so und so oft vertreten.
Würde mich mal interessieren wie dort die Verteilung ist.

Auch wäre dies interessant, was die DROP Frames angeht. Denn ein weggelassenes Frame ist genau so gut (oder schlecht) wie zwei aufeinander folgende Frames mit dem selben Inhalt. Da CF scheinbar teils sehr viele Frames dropt (PCP Messungen) müsste man das mal gegenhalten. Keine Ahnung ob man den Bildinhalt selbst mit FCAT auswerten kann auf Veränderungen. :( dürfte aber wohl schwer werden.

Zitat MusicIsMyLife;20637603
4. FCAT hin oder her - die gleichmäßige Bildausgabe mag man damit messen können. Den Bildinhalt kann man damit jedoch nicht automatisch analysieren, weshalb ein FCAT-Ergebnis auch etwas aussagen könnte, was in der Praxis nicht so ist. Denn ich vermute wie fdsonne, dass man nur fertig gerenderte Frames so verzögern kann, dass die Ausgabe möglichst homogen erfolgt. Das hat dann aber zur Folge, dass Bildinhalte ausgegeben werden, die zum Zeitpunkt der Berechnung noch ganz woanders hingehören und deshalb bei der Ausgabe quasi an der falschen Stelle zu sehen sind. Auf Seiten von FCAT würde man ein super Ergebnis erhalten (weil die Bilder mit gleichmäßigen Abständen ausgegeben werden), das Spielempfinden könnte aber nach wie vor hakelig ausfallen (zwar wahrscheinlich deutlich besser als ohne Eingriff, aber noch immer nicht perfekt).


Jupp richtig, wobei man das schon machen kann mit dem Verzögern...
Die Frage ist halt, ob es am Ende auch wirkt.
Denn man will ja mit FCAT auch das Problem aufzeigen, das nach der Frapsmessung unterschiedlich lange Zeit noch an Verarbeitung drauf kommt... Würde man hier "vorn" verzögern, wäre hintenraus diese Zeit immernoch stark schwankend. Was das Ergebnis eher zunichte macht.

Komisch ist auch, die Messungen, wo das SLI vergleichsweise schlecht abschneidet (also wo die Timings schwanken), da zeigen die Werte trotzdem ein ähnliches Bild zu AMD. Heist widerkehrendes Schwanken von große Zahl auf kleine Zahl und das recht gleichmäßig. Das widerspricht zumindest der Theorie, dass das Schwanken mitunter maßgeblich erst nach dem Teil kommt, den Frames messen kann...
#33
customavatars/avatar145005_1.gif
Registriert seit: 12.12.2010

Oberleutnant zur See
Beiträge: 1352
Zitat fdsonne;20643703
Ja, das schon klar mit dem überschreiben.
Nur 8 - 24 - 8 - 24 - ... sind im Schnitt 16 ms.
Das heist knapp 60 FPS.
Irgendwoher müssen diese 8ms ja kommen...
Wäre der Umstand so minimal, wie auf der dritten Folie, müsste es eher 1 - 33 - 1 - 33 sein. Macht nämlich am Ende ebenso knapp 60 FPS.


Das ist Fraps. Mit FCAT ist der Abstand sogar größer, da hier ja Pixellinien gemessen werden. Hier erreicht man also wirklich diese 1 - 33 - 1 - 33ms Abstände. Und 20pixel sind nichtmal 2% der Zeit. Also bei 33ms pro Bild weniger als 1ms.

Zitat

Und die von dir angesprochenen 8 von 34 sind weit mehr wie der Abstand zwischen Frame 1 und n+1 der Folie ;) Das mein ich damit. Auch wenn die Folie nur eine Illustation sein soll schaut mir das nach etwas zu viel Worstcase aus...
8 ms Abstand als niedrigste Ausgabe ist bei mir bei nem Durchschnittswert von 16ms Ausgabezeit im Schnitt alles andere als "sofort überschreibt".
Bildlich wäre dies auf der Folie also ziemlich exakt mittig zwischen dem metered und dem unmetered Bild angeordnet. (mit den Werten von dir)


8ms wäre Fraps. In Wirklichkeit ist man ohne Framemetering wesentlich tiefer. Damit hat man ohne Framemetering auch keinen besseren Input-Lag. Der läge hier also eigentlich auf dem selben Niveau als wenn man ohne AFR spielen würde.
Jetzt mal abgesehen, ob "besser" bei AFR überhaupt stimmt.
#34
customavatars/avatar145021_1.gif
Registriert seit: 12.12.2010

Banned
Beiträge: 5646
Zitat fdsonne;29
Neja, in dem Fall, das das Metering die Zeit nicht angleichen muss, erhöht sich auch das Inputlag nicht...


In den Fall sollte das so sein ja, allerdings betrachtet man ja schon die ganze Zeit AMD´s fehlendes Metering mit Nvidias Metering und bei AMD sieht es halt immer kacke aus was die Flüssigkeit der Bildabfolge betrifft, insofern sollte es (außer Nvidia hat noch andere Mittel zur µrucklerbekämpfung) fast ausnahmlos zu einem höheren Input respektive Outputlag führend und da sehe ich persönlich das Problem wenn man die neuen Treiber beider Hersteller am Ende vergleichen will.

AMD könnte beispielsweise die Bildabfolge öfter stärker verzögern um bessere FCAT Ergebnisse zu erreichen, was aber den Outputlag stellenweise stärker ansteigen lassen würde als bei Nvidia.
Nur kann man dies nicht messen, das halte ich für das Problem.
#35
customavatars/avatar89889_1.gif
Registriert seit: 19.04.2008
PorscheTown
Flottillenadmiral
Beiträge: 5162
Zitat MusicIsMyLife;20641588

Jetzt mal ganz weg von meinen Befürchtungen. Ich habe noch eine Frage speziell zu der Herangehensweise von Hardwareluxx:

Die Capture-Daten werden ja in eine Ramdisk geschrieben. Diese ist zwar recht üppig dimensioniert, im Vergleich zu den anfallenden Daten jedoch schnell gefüllt. Kurze Benchmark-Sequenzen wären hier also an der Tagesordnung. Wie würde das in Bezug auf Boost-Szenarien geregelt, wie zum Beispiel bei Titan? HT4U hat je recht ausführlich gezeigt, dass es sich bei Boost 2.0 ohne irgendwelche Eingriffe in PT und TT quasi um ein Benchmark-Feature handelt, da bei längerer Belastung immer häufiger nur noch der Standardtakt anliegt.

Da ich davon ausgehe, dass sowohl NVIDIA als auch AMD weiter in Richtung Boost investieren werden (es möglicherweise irgendwann zum Standard jeder Grafikkarte gehört), könnten kurze Benchmark-Sequenzen solchen Boost-Szenarien prinzipiell in die Karten spielen.

Gibt es bereits Überlegungen, wie damit umgegangen werden soll ("vorheizen" oder nicht)?

Wow, das finde ich mal gut kombiniert, Watson! :bigok:

Zitat sontin;20644166
Das ist Fraps. Mit FCAT ist der Abstand sogar größer, da hier ja Pixellinien gemessen werden. Hier erreicht man also wirklich diese 1 - 33 - 1 - 33ms Abstände. Und 20pixel sind nichtmal 2% der Zeit. Also bei 33ms pro Bild weniger als 1ms.



8ms wäre Fraps. In Wirklichkeit ist man ohne Framemetering wesentlich tiefer. Damit hat man ohne Framemetering auch keinen besseren Input-Lag. Der läge hier also eigentlich auf dem selben Niveau als wenn man ohne AFR spielen würde.
Jetzt mal abgesehen, ob "besser" bei AFR überhaupt stimmt.

Sollte sich ein Einzelbild nicht auch einfach zur 2 Karten Transferieren lassen mittels CF/SLI Brücke?
Also ich finde mein CfX schon besser als eine Karte in den meisten Spielen, sonst wäre sicher nur noch eine HD7970 drin. ;)

Zitat Schaffe89;20645174
In den Fall sollte das so sein ja, allerdings betrachtet man ja schon die ganze Zeit AMD´s fehlendes Metering mit Nvidias Metering und bei AMD sieht es halt immer kacke aus was die Flüssigkeit der Bildabfolge betrifft, ...

Eigentlich gibt es ja 4 Himmelsrichtungen bei Egoshootern, also sollten soviele Bilder wie möglich vorbereitet werden, auch wenn diese im nachinein verworfen werden weil der user sich in eine andere Richtung bewegt.
Sieht halt sch... aus im Diagramm, aber vor dem Schirm ist ein wohltat im vergleich zur zähen Single GPU.
#36
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31959
Zitat sontin;20644166
Das ist Fraps. Mit FCAT ist der Abstand sogar größer, da hier ja Pixellinien gemessen werden. Hier erreicht man also wirklich diese 1 - 33 - 1 - 33ms Abstände. Und 20pixel sind nichtmal 2% der Zeit. Also bei 33ms pro Bild weniger als 1ms.


Die Messungen von Don beim CF ohne den Prototyp Treiber zeigen aber irgendwie was anderes...
http://www.hardwareluxx.de/images/stories/galleries/reviews/2013/fcat/analyse/crysis3-amd-prototyp-frametimes.png
Da sehe ich speziell im rechten drittel irgendwas mit 6 zu 26.

Oder ist das via Fraps gemessen?

Zitat Phantomias88;20649399
Wow, das finde ich mal gut kombiniert, Watson! :bigok:


In dem Zusammen hat aber der Boost so gar keine Bewandnis. Klar, die Karte wird ein Stückweit schneller in der kurzen Szene... Aber das ändert ja am Verhalten der Frames nix.
Mir wäre nicht bekannt, das sich die Frametimes Taktabhängig verhalten. Das gleiche gilt fürs Inputlag.
Was beeinflusst wird, ist die Geschwindigkeit. Also mehr Boost = kürzere Frametimes. Tendentiel wird dadurch bestenfalls die Vergleichbarkeit etwas schwer, weil die Abstände kleiner. Am Verhalten ändert sich aber nix.
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Roundup: 5x GeForce GTX 1070 mit Custom-Design im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/5X-GTX1070/GTX1070_CUSTOM_ROUNDUP-TEASER

Nachdem wir bereits eine Reihe von Boardpartner-Karten der NVIDIA GeForce GTX 1080 ausführlich getestet haben, holen wir gleiches nun für das kleinere Schwestermodell nach, denn auch von der NVIDIA GeForce GTX 1070 gibt es viele Custom-Modelle mit höheren Taktraten, eigenen Kühlsystemen und... [mehr]

Drei Custom-Modelle der GeForce GTX 1060 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/3X-GTX1060/GTX1060_ROUNDUP_TEST-TEASER

Anders als bei der GeForce GTX 1080 und GeForce GTX 1070 trudelten wenige Stunden nach unserem Test zur Founders Edition der NVIDIA GeForce GTX 1060 schon die ersten Boardpartner-Karten mit teils höheren Taktraten, eigenem Kühlsystem und überarbeitetem Platinenlayout ein. Sie dürften... [mehr]

NVIDIA GeForce GTX 1080 mit Pascal-Architektur im XXL-Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Heute ist es soweit: NVIDIA läutet mit der GeForce GTX 1080 und GTX 1070 auf Basis der Pascal-Architektur den diesjährigen Neustart bei den Grafikkarten ein. In Kürze wird wohl auch AMD seinen Beitrag zu diesem Thema leisten. Vor zehn Tagen lud NVIDIA die gesammelte Fachpresse nach Austin ein... [mehr]

Roundup: 5x GeForce GTX 1080 im Custom-Design im Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Nachdem wir uns die Founders Edition der GeForce GTX 1080 und GeForce GTX 1070 bereits angeschaut haben, folgen nun fünf Retail-Modelle, die wir in aller Ausführlichkeit unter die Lupe nehmen wollen. Aus den vielen Boardpartnern und unterschiedlichen Modellen haben wir uns solche von ASUS, EVGA,... [mehr]

AMD Radeon RX 480 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/RADEON-RX480/RADEON-RX480-REFERENCE-LOGO

Es ist also soweit: AMD startet die großangelegte Zurückeroberung des Grafikkartenmarktes mit der Radeon RX 480, die als erste Grafikkarte der Polaris-Generation mit gleichnamiger Architektur erscheint und die wir uns genauer anschauen können. Dabei versucht sich AMD an einem anderen Ansatz im... [mehr]

PowerColor Radeon RX 480 Red Devil im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/POWERCOLOR-RX480/POWERCOLOR-RX480REDDEVIL-LOGO

Mit der Radeon RX 480 will AMD zurück zu alter Stärke und hat daher über Monate hinweg die PR-Trommel geschlagen. Letztendlich dabei herausgekommen ist eine sehr gute Karte für einen niedrigen Preis, die aber nicht in allen Bereichen zu überzeugen weiß. Wohl größtes Manko der Karte sollte... [mehr]