FCAT Teil 1: Die Theorie

Don

[printed]-Redakteur, Tweety
Thread Starter
Mitglied seit
15.11.2002
Beiträge
27.220
<p><strong><img src="/images/stories/galleries/reviews/2013/fcat/fcat-logo.jpg" alt="fcat-logo" style="margin: 10px; float: left;" height="100" width="100" />Vor einigen Wochen tauchte der Begriff FCAT oder Frame Capture Analysis Tool erstmals auf. Die Diskussion warf viele Fragen auf, vor allem aber eine: Wie und was wird eigentlich gemessen? Kommt kein synthetischer Benchmark mit Punkte-System oder eine integrierte Version des Spiels bzw. der Engine zum Einsatz, verwenden die meisten Redaktionen und auch wir FRAPS. Damit lassen sich zwar Minima-, Maxima- und Durchschnittswerte bestimmen, doch für eine tiefer gehende Analyse eignet es sich nicht. Auch wir haben FRAPS in der Vergangenheit verwendet, um Mikro-Ruckler darzustellen, aber auch hier durfte man sich die Frage stellen, was...<br /><br /><a href="/index.php/artikel/hardware/grafikkarten/26372-fcat-teil-1-die-theorie.html" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Super Review Danke HWl, solche Beiträge sind sehr Nutz voll.
 
Jetzt hat es glaub jeder Verstanden! super!
+1
 
Aber es geht noch etwas weiter: Thema AFR und Input-Lag. Sitze aber noch dran.
 
Aber es geht noch etwas weiter: Thema AFR und Input-Lag. Sitze aber noch dran.

Schade das man diese Inputlag Geschichte nicht so messen u in einer Scala (störend/nichtstörend) einordnen kann das es objektiv sowie bereits subjektiv nun endlich mal ein Ende hätte mit hervorgeholten Vermutungen
 
Zuletzt bearbeitet:
naja, mache mir auch noch gedanken zu Freund Zufall. Wenn in Zukunft so gebencht wird, Könnte es möglich sein, das mehrere gleiche Tests im gleichem szenario und gleichen Systemen, unterschiedliche Ergebnisse ans Tageslicht bringen.

Bin gespannt auf den zweiten Teil. Sehr schön beschrieben Don!
 
Finde das Thema sehr spannend. Freu mich schon auf Teil 2 und andere Themen in diese Richtung!
 
Das nenne ich mal ein ordentliches System um sämtliche Qualitätsverluste bei der Bildwiedergabe darstellen zu können und vor allem richtig zu erklären.
Ist schon ein mords Aufwand mit 1500 Euro Hardware + Splitter und genügend schnellen Aufnahmemedium ect. Aber nur so lässt sich endlich mal objektive Tests durchführen.
Aussagen wie "Ich sehe nix" oder "Ich weiß garnicht was das ist" zählen dann nicht mehr. Vor allem in der AFR-Problematik. ;)

Da kann man NVIDIA nur für loben, dass sie soviel Aufwand betrieben haben und dies auch noch frei zugänglich machen. Nun können alle Grafikkartenhersteller ihre Hard- und Software besser anpassen und gegen messen.
Klar gibt es unterschiedliche Ergebnisse, je nachdem wann gestartet wird, aber bei so vielen Frames ist am Ende der Durchschnittswert maßgebend.
 
Schade das man diese Inputlag Geschichte nicht so messen u in einer Scala (störend/nichtstörend) einordnen kann das es objektiv sowie bereits subjektiv nun endlich mal ein Ende hätte mit hervorgeholten Vermutungen

Ja die Input-Zeiten und Latenzen kann man leider nicht messen, sondern nur in der Theorie betrachten und dann subjektive Eindrücke weitergeben. Dazu im 2. Teil mehr.
 
Ja die Input-Zeiten und Latenzen kann man leider nicht messen, sondern nur in der Theorie betrachten und dann subjektive Eindrücke weitergeben. Dazu im 2. Teil mehr.

Das ist das fatale daran denn nur mit subjektiven "es ist nicht schwammiger gegenüber Crossfire ohne Metering" bekommst du die hartnäckigen Zweifler nicht gestoppt
 
Zuletzt bearbeitet:
Das Wort heisst Tearing nicht "Teering". Tear wie Reißen.

Spricht sich auch nicht wie "Tier" sondern wie Teer (Straßenbelag im Deutschen)
 
THX Don ;)

@scully,
die Gegenpartei aber auch nicht ;)
Der Vorteil bleibt doch aber, das die jenigen, die davon nix mitbekommen (oder nix mitbekommen wollen) trotzdem ihren Spaß dran haben können und werden...
Das gleiche wie mit dem MRs. Manche nehmens war, manche eben nicht... In einem Spiel fällts massiv auf, im anderen eher gar nicht.

Selbst wenn man es messen könnte, würde sich am subjektiven Verhalten nix ändern. Die Werte hingegen könnten abschrecken. Und das bei beiden Herstellern ;)
 
@scully,
die Gegenpartei aber auch nicht ;)
Der Vorteil bleibt doch aber, das die jenigen, die davon nix mitbekommen

Gab es denn bis zur Messung mit FCAT überhaupt ne Partei/Gegenpartei für erhöhten/störenden Inputlag bei Nvidia ?

Oder anderst gefragt hat vorher schonmal einer subjektiv wahrgenommen "oh das SLI System ist aber schwammiger wie ein gleichgewichtiges Multi GPU System im Crossfire Mode"?

Beides kann man wohl bis zu dem Zeitpunkt als nicht existent bezeichnen, traurig/schade ist in dem Zusammenhang nur das man es mit objektiven Messungen nicht nachweißen kann

Genau diesen Umstand machen sich die Zweifler nämlich zu Nutze;)
 
Zuletzt bearbeitet:
Das sehe ich auch so fdsonne das beide Hersteller abschrecken könnte. AMD oder NV beide haben Vor und Nachteile. Spannend ist wie sich CF und SLI wirklich Skalliert ich sehe oder Merke nichts von MR außer bei FarCry 3 und das sind richtige Lags alle paar Sekunden.
Ob das jetzt MR sind möchte ich zweifeln weil sobald ich CPU Kerne über TaskManger zu Ordne dann läuft FC3 Flüssig.

Spannend ist für mich mit FCat zu sehen ob sich DUAL GPU Lohnt oder auch nicht einer seits läuft bei mir alle meine Spiele zu Perfekt obwohl ich DUAL GPU habe und was ist wenn FCAT was anderes Zeigt und ich Trotzdem der Meinung bin das ich MR nicht war nehme.

Das ist auch was DON bereits geschrieben hat jeder nimmt MR anders auf. Was mich sehr stört das ich selber nicht mit FCAT mein System Testen kann. Interessant ist auch das eine SSD nicht ausreicht für diesen Test. Kann dann MR System abhängig Enstehen ich sage mal Frech ja wie einzelne Komponente nicht Harmonisch Laufen : Störfaktor Störsenker und einzelne Bauteile.
 
Zuletzt bearbeitet:
Zwischen SLI und CF meine ich nicht...
Aber zwischen Single GPU und Multi GPU im allgemeinen schon.

Ich persönlich kenne niemanden, der wirklich arg aktiv! Multiplayershooter auf nem MGPU System betreibt. (irgendwelche Ligen, irgendwelche offiziellen Wettbewerbe usw.) Aber ich kenne einige, die MGPU klar verneinen, weil eben das Imputlag hoch bzw. höher ist.
IdR sind das aber dann auch Personen, die weniger Wert auf die direkte Optik legen als auf die Spielbarkeit... Sprich FPS bis der Arzt kommt, 120Hz TFT, besser sogar noch 100Hz+ CRT für schnelle Shooter ;)
Ob nun Pest oder Cholera. Total egal, denn es ist beides scheiße aus Sicht des Inputlags.
 
In der Theorie sollte der Input-Lag bei Multi-GPU ja sogar geringer sein, weil du bei gleichen Settings mehr Frames machst und somit die Inputs schneller dargestellt werden. Ohne Metering gibt es Worst-Case-Szenarien, die denkbar sind - die sind aber bei Single-GPU ebenfalls vorhanden.
 
Zwischen Singel GPu und Dual GPu bin ich mir sehr sicher das man mit einer Karte besser Ergebnisse erreicht mit FCat die Frage ist halt dann ob man bestimmte Spiele mit eine GPU auf höchste Details Spielen kann. Wenn man sich mit Dual GPU aus kennst und Einstellungen vornimmt und Limiter benutz läuft CF / SLI nahe zu Perfekt.

Ein sehr gute Beispiel ist Metro Last Light es läuft sehr sehr weich man könnte sagen ich Spiele mit einer Karte, obwohl ich keine 100% Auslastung habe ist das Spielgefühl zu Perfekt.
 
Zuletzt bearbeitet:
In der Theorie sollte der Input-Lag bei Multi-GPU ja sogar geringer sein, weil du bei gleichen Settings mehr Frames machst und somit die Inputs schneller dargestellt werden. Ohne Metering gibt es Worst-Case-Szenarien, die denkbar sind - die sind aber bei Single-GPU ebenfalls vorhanden.

Neja ne ;)
Denn durch AFR werden eben die Frames gleichzeitig berechnet. Heist also, du kannst bestenfalls in jedem zweiten Frame deine Eingaben überhaupt sichbar auf dem Schrim machen.
Hast du nun im optimalen Fall doppelte FPS bei MGPU, so ist der Inputlag allgemein ziemlich exakt gleichgroß dem, welches ne SGPU bei eben halber FPS Rate erreicht.
Nur in der Praxis erreicht man idR ja nicht wirklich doppelte Leistung. Eher um die 70-80%. Teils auch mal mehr...
Dennoch wird aber oftmals die MGPU Mehrleistung in BQ gesteckt. Sprich man spielt bei gleicher FPS Rate zum Single GPU System zwar mit mehr BQ, verliert somit aber den FPS Vorteil durch und erkauft sich das höhere Inputlag.

Wenn man nun als Hersteller dort weiter ansetzt und durch Anpassen der Frametime vereinfacht gesagt, noch ein paar ms drauf packt, verschlechtert sich das Inputlag zweifelsfrei noch ein Stückchen.
Die Frage, die scully (zurecht) dort aufwirft ist nun, ob man diese Verschlechterung im Vergleich zum Konkurenzverfahren ohne Frametimeanpassung überhaupt messen kann. Und hier scheint es auf ein klares nein rauszulaufen. Denn es ist wohl nicht messbar :(
 
Zuletzt bearbeitet:
Neja ne ;)
Denn durch AFR werden eben die Frames gleichzeitig berechnet. Heist also, du kannst bestenfalls in jedem zweiten Frame deine Eingaben überhaupt sichbar auf dem Schrim machen.

Ich habe mir das aber folgendermaßen erklären lassen:

Input1 kommt, GPU0 beginnt das Rendering von Frame n und gibt diesen gemeinsam mit Input1 aus.
Input2 kommt, reicht nicht mehr für Frame n und kommt daher auf GPU1 bei Frame n+1 drauf. Frame n+1 wird aber schon berechnet, während Frame n gerade ausgegeben wird. In einem Single-GPU-System wäre Frame n+1 von GPU0 erst ausgegeben worden, wenn Frame n fertig ist, was bei gleichen Settings (theoretisch doppelten FPS) bei einem Mulit-GPU-System 50 Prozent früher ist.
 
Zuletzt bearbeitet:
Ja die Input-Zeiten und Latenzen kann man leider nicht messen, sondern nur in der Theorie betrachten und dann subjektive Eindrücke weitergeben. Dazu im 2. Teil mehr.

Don was ist wenn für dich dein subjektives betrachten für dich gut ist sagen wie Perfekt oder das Gegenteil sein sollte sehr Negative. Heist also das ich oder jemand andere anders Empfinde kann dann brauch man über MR nicht mehr weiter Diskutieren oder nicht. Natürlich sind diese Probleme da aber so störend wie vor einem Jahr ist das nicht mehr hier hat AMD und NV dran gearbeitet nur Spiele Entwickler sind hier weniger Freundlich es gibt Spiele wo Dual GPU fast zu 97% Skalliert dann gibt es Spiele die mit optimierte Treiber auch absolut schlecht Laufen.

Ich habe das Gefühl das Dual GPU auch Spiel Engine abhängig ist z.B. läuft DICE Engine einfach gut + CPU Auslastung und wenn ich sehe wie COD mit CF Skaliert ist einfach Absolut schlecht.
 
Zuletzt bearbeitet:
Ich habe mir das aber folgendermaßen erklären lassen:

Input1 kommt, GPU0 beginnt das Rendering von Frame n und gibt diesen gemeinsam mit Input1 aus.
Input2 kommt, reicht nicht mehr für Frame n und kommt daher auf GPU1 bei Frame n+1 drauf. Frame n+1 wird aber schon berechnet, während Frame n gerade ausgegeben wird. In einem Single-GPU-System wäre Frame n+1 von GPU0 erst ausgegeben worden, wenn Frame n fertig ist, was bei gleichen Settings (theoretisch doppelten FPS) bei einem Mulit-GPU-System 50 Prozent früher ist.

Ohne Framepuffer u damit erweiterten Lag soll das die Tasks so abarbeiten Don?
 
Zuletzt bearbeitet:
Ab Vista arbeitet D3D immer mit Buffer - mindesten ein Frame wird verzögert.
nVidia verzögert beim Framemetering den kompletten Verarbeitungsschritt bei der Berechnung des Frames. Das heißt, man greift bei SLI schneller wieder auf dem Input-Buffer zu als bei einer Technik, die kein Framemetering oder nur eine Ausgabeverzögerung durchführt.
 
Don könntest du auch mit Win8 Testen ich habe das Gefühl das mit Win8 CF besser läuft auch Powerplay hat das bestätigt ich habe 2 Monate gebraucht bis er Win8 installiert und auch Testet. Seine Meinung Heute ist das mit Win8 besser läuft als mit Win7 CF.
 
Ohne Framepuffer u damit erweiterten Lag soll das die Tasks so abarbeiten Don?

Einfache Betrachtung, ohne Buffer. Aber ich sehe schon, bei Teil 2 reden wir noch einmal drüber, dann mit bildlicher Veranschaulichung. Kompliziertes Thema die Geschichte.

Don könntest du auch mit Win8 Testen ich habe das Gefühl das mit Win8 CF besser läuft auch Powerplay hat das bestätigt ich habe 2 Monate gebraucht bis er Win8 installiert und auch Testet. Seine Meinung Heute ist das mit Win8 besser läuft als mit Win7 CF.

Wir testen seit Anfang des Jahres auf Windows 8. Ich werde aber kaum die Zeit haben, mit Windows 7 einen Gegenvergleich zu machen. Die Tage sind schon voller Arbeit ;)
 
Perfekt dann warte ich erstmal ab und Schreibe nichts mehr solange :d
 
Ich habe mir das aber folgendermaßen erklären lassen:

Input1 kommt, GPU0 beginnt das Rendering von Frame n und gibt diesen gemeinsam mit Input1 aus.
Input2 kommt, reicht nicht mehr für Frame n und kommt daher auf GPU1 bei Frame n+1 drauf. Frame n+1 wird aber schon berechnet, während Frame n gerade ausgegeben wird. In einem Single-GPU-System wäre Frame n+1 von GPU0 erst ausgegeben worden, wenn Frame n fertig ist, was bei gleichen Settings (theoretisch doppelten FPS) bei einem Mulit-GPU-System 50 Prozent früher ist.

Erstmal vorweg, es könnte durchaus sein, ich hab nen Denkfehler, also immer rausdamit :fresse:

Aber aus meiner Sicht kann man das nicht so in direktem Zusammenhang sehen...
Denn die Inputs erfolgen ja völlig unabhängig der Berechnung.
Sprich wenn Input1 kommt, heist das nicht zwingend, das GPU0 mit der Berechnung beginnen kann, es könnte genau so sein, das GPU0 gerade eben 1ms vorher angefangen hat mit berechnen, somit liegt der Input bis zur nächsten freien GPU in der Pipeline...
Desweiten dürfte rein theoretisch betrachtet völlig egal sein, wann eine GPU anfängt mit dem Bild zu berechnen. Solange eben in der Abfolge keine "Luft" ist, wo eine (oder mehrere) GPUs warten müssen...

Bildlich sollte das ganze dann so ausschauen:
Inputlag_ilu.png

Ich hab mal versucht drei Szenen darzustellen. Einmal SGPU oben, zweimal MGPU. Letztere unterscheiden sich in der für das Beispiel exakt doppelten FPS Rate. (also halbe Framelänge) Erste MGPU und SGPU haben absichtlich gleich lange Frames... Wie angesprochen soll dies aufzeigen, was beim direkten verblasen der MGPU Leistung in BQ passiert.
Auch die Inputs erfolgen zur Darstellung an der selben Stelle für alle drei Szenen.

Schön zu erkennen ist, das die Outputs der SGPU in etwa gleichmäßig nach dem Input sind, wärend beim ersten MGPU große! Lücken zwischen klaffen.
Doppelte FPS Rate macht diesen Umstand etwas wett, denn die Zeiten verkürzen sich drastisch zum ersten MGPU Beispiel.

Das ganze soll dazu aufzeigen, das ein Input eben häufig einen Frame warten muss. Eben die Berechnungszeit wenn beide GPUs voll ackern. Beim SGPU kann man davon ausgehen, dass eben der Input auch im nächsten Frame mit drin ist. Bei MGPU muss dies nicht der Fall sein. Denn im Extremfall heist es hier fast zwei ganze Frames auf die Ausgabe warten.
Praktisch wird sich das ganze statistisch irgendwo im Mittel einsortieren... Denn ein Input erfolgt ja nicht immer direkt vor der Frameberechnung und auch nicht direkt am Ende einer Frameberechnung. Sondern zeitlich irgendwo...

Die NV Methode setzt nun an und glättet die Frameausgabe. Heist im Fall von zwei und drei, die Ausgabe erfolgt möglichst gleichbleibend. Da eine Ausgabe nie nach vorn verschoben werden kann, rückt die Ausgabe immer ein Stück weit nach hinten... Somit erhöht sich auch die Zeit zwischen Eingabe und Ausgabe ein Stück weit. Ob man das merkt oder nicht!? Keine Ahnung...


Im Fall von Multiplayer Shootern beispielsweise heist das in Summe dann, bei ner Single GPU hat man im Extremfall den Gegner nach der Frametime x auf dem Schirm und kann einen Input abgeben.
Bei MGPU im gleichen Spiel hat man aber Extremfall den Gegner erst nach Frametime x*2 auf dem Schirm und der Input erfolgt somit auch erst nach Frametime x*2. Bei 60 FPS wären das 16,67ms später, als bei 60 FPS und SGPU.
Bei doppelter FPS wären es dann (x/2)*2... Also bestenfalls gleich der SGPU Lösung...

Soweit mein Gedankengang dazu.
Das Thema, was FCAT an der Stelle noch mit aufgreift, sprich das "vergessen" von ganzen Frames oder das nur wenige Zeilen ausgeben von Frames, kommt dem Umstand übrigens theoretisch noch mit oben drauf. Dürfte praktisch in dem Fall aber keine Bewandniss haben. Denn man sieht auf dem Schirm davon ja nichts... Rein logisch müsste das sogar dem Inputlag in den Karten spielen und dieses wiederum verkürzen.
 
Zuletzt bearbeitet:
Bitte fdsonne,
du solltest dich zuerst erkundigen, wie nVidia's Framemetering funktioniert, bevor du weitere Aussagen startest.
Du hast es nämlich nicht verstanden und bist daher auch nicht in der Lage die Aussagen von Don richtig einzuschätzen.
 
Ab Vista arbeitet D3D immer mit Buffer - mindesten ein Frame wird verzögert.
nVidia verzögert beim Framemetering den kompletten Verarbeitungsschritt bei der Berechnung des Frames. Das heißt, man greift bei SLI schneller wieder auf dem Input-Buffer zu als bei einer Technik, die kein Framemetering oder nur eine Ausgabeverzögerung durchführt.

Das heist also, das NV Metering setzt vor dem Renderer an!?
Gibts dazu irgendwelche direkten Fakten?

Denn das kann ich mir nur unschwer vorstellen... Das bedeutet ja dann, die GPUs laufen ein Stückweit im leerlauf, denn sie warten ja bis der Meteringprozess ihnen grünes Licht zum Berechnen gibt. Aber woher weis die Karte denn, wie lange eben diese besagte teils stark schwankende Berechnungszeit dauert um das Ergebnis hinten möglichst glatt zu bekommen?

Bitte fdsonne,
du solltest dich zuerst erkundigen, wie nVidia's Framemetering funktioniert, bevor du weitere Aussagen startest.
Du hast es nämlich nicht verstanden und bist daher auch nicht in der Lage die Aussagen von Don richtig einzuschätzen.

Es geht doch nicht ums Metering :rolleyes:
Sondern um das Thema Inputlag...

Aber wie so oft, bevor du hier Behauptungen aufstellst, bitte ich um belegbare Fakten deinerseits.
Noch dazu steht oben im ersten Satz, das jemand einen möglichen Fehler gern aufzeigen darf.
Scheint dir bestimmt entfallen zu sein :wink:
 
Bitte sontin,
wenn Du nichts beizutragen hast außer Dein übliches "Du verstehst es nicht, also sei still!", mit dem Du immer wieder Diskussionen abzuwürgen versuchst, dann halte Dich doch einfach zurück.
Ich will dem Thema nämlich folgen ohne dummes Gespamme!
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh