FCAT Teil 2: AFR und Input-Lag

Don

[printed]-Redakteur, Tweety
Thread Starter
Mitglied seit
15.11.2002
Beiträge
26.596
<p><strong><img src="/images/stories/galleries/reviews/2013/fcat/fcat-logo.jpg" width="100" height="100" alt="fcat-logo" style="margin: 10px; float: left;" />Im <a href="index.php/artikel/hardware/grafikkarten/26372-fcat-teil-1-die-theorie.html">ersten Teil unserer Betrachtung von FCAT</a> 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.</strong></p>
<p>Zunächst einmal muss...<br /><br /><a href="/index.php/artikel/hardware/grafikkarten/26407-fcat-teil-2-afr-und-input-lag.html" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mal wieder super erklärt Don ! ;)

Aber spielt nicht nur die Ausgabe der GPUs eine Rolle beim Imput-Lag, sondern auch die CPU, die ja den Input verarbeiten und zu den GPUs zuweisen muss ?
Wenn die CPU z.B. im Multi-GPU-Systemen schon recht am Limit läuft, so vergrößert sich noch zusätzlich der Input-Lag.

Zudem ist es wohl sehr schwierig festzustellen wie groß der Input-Lag wirklich ist.
Man müsste ja ein Interface zwischen Mouse und PC schalten, welches sämtliche Bewegungen und Aktionen festhält und dies auf die Ausgabe der GPUs abgleicht, was ja eigentlich kaum möglich ist, wenn nicht sogar unmöglich, da man dazu schon ein System benötigt, welches die Veränderungen des Frames in Bewegungen analysieren kann und dies auf die, vom User gewollte Bewegungsrichtung abgleicht.
Das ist aus heutiger Sicht völlig ausgeschlossen. Dazu benötigt man quasi schon eine KI, die selbständig spielt und dies mit dem Ergebniss des Programms vergleichen kann.

Man könnte nur so eine Art Testspiel mit fester Vorgaben programmieren wo sämtlichen Bewegungsabläufe schon festgelegt sind. Je nachdem wie weit dort dann die Abweichungen sind, desto größer der Input-Lag. Vereinfacht ausgedrückt... :fresse:

Kommen wir aber lieber doch zu den etwas leichteren Messmethoden zurück.
Bin echt gespannt auf den AFR-Test und das Ergebniss.
 
Zuletzt bearbeitet:
Mal wieder super erklärt Don ! ;)

Aber spielt nicht nur die Ausgabe der GPUs eine Rolle beim Imput-Lag, sondern auch die CPU, die ja den Input verarbeiten und zu den GPUs zuweisen muss ?
Wenn die CPU z.B. im Multi-GPU-Systemen schon recht am Limit läuft, so vergrößert sich noch zusätzlich der Input-Lag.

Ich würd eher vermuten, dass das Gegenteil der Fall ist (rein auf input und verarbeitung in der CPU bezogen), denn wenn die GPU nicht limitiert, kann die CPU mehr frames berechnen. Mehr Frames bedeutet für mich, es wird schneller auf eine Eingabe reagiert.

Im GPU Limit bringt dir die Wartezeit der CPU nichts, warum sollte die CPU mehr berechnen, als ausgegeben wird?

Was jetzt allerdings ein größeren inputlag verursacht ist jetzt die große Frage, das speichern von Frames um µRuckler zu unterdrücken oder die schnellere Ausgabe der GPUs.

Das messen eines Inputlags wäre eigentlich recht einfach möglich, ein Fadenkreuz auf einem Schachbrett muster oder Gitter. Die Mausausgabe wird dann direkt von der Box gemacht, die auch die Messung durchführt (muss ja kein großer Ausschlag sein). Sollte also auch heute schon machbar sein.
 
Nach 2,5h immer noch zwei dicke Fehler in der Einleitung allein (e.: noch mehr in der ganzen ersten Hälfte)! Ich kann ja verstehen, dass die Artikel schnell online kommen sollen, aber bitte wenigstens danach ein mal Korrekturlesen! Beim ersten Teil sind auch schon einige Fehler drin.

Nichtsdestotrotz noch ein schöner Artikel! Das Video bei YT kommt also erst im dritten Teil?! Ehrlich gesagt sehe ich da nicht zu allarmierende Unterschiede. Klar, wenn man jetzt darauf achtet schon, aber ingame, wenn ich konzentriert und immersed bin, würde es mich wenig stören. Vielleicht fällt es aber bei schnelleren Bewegungen auch stärker auf.
 
Zuletzt bearbeitet:
Das Video bei YT kommt also erst im dritten Teil?! Ehrlich gesagt sehe ich da nicht zu allarmierende Unterschiede. Klar, wenn man jetzt darauf achtet schon, aber ingame, wenn ich konzentriert und immersed bin, würde es mich wenig stören. Vielleicht fällt es aber bei schnelleren Bewegungen auch stärker auf.

Das Video dient ja auch nicht dazu das Problem sichtbar zu machen,sondern nur um aufzuzeigen wie die Farbcodierungen den einzelnen Frames zugeordnet werden

Wenn es soweit wäre das du die Microruckler bereits deutlich im Video sehen könntest wäre die Ka... schon sprichwörtlich am überlaufen

So ein Szenario könntest du getrost als unspielbar betiteln;)
 
Zuletzt bearbeitet:
Das mit der Farbcodierung hab ich immer noch nicht so richtig verstanden. Werden die Frames dann auf dem Bildschirm links mit einem Farbstreifen versehen? Ist das wie auf dem Bild in Teil 1?
 
Ja, es wird ein Overlay über den darzustellenden Inhalt gelegt.
 
Ich weiß noch immer nicht so recht, wie ich mich bezüglich FCAT positionieren soll. Finde ich es gut? Oder doch nicht?

Grundsätzlich finde ich den Ansatz, das zur Messung heranzuziehen, was auch wirklich am Monitor ankommt, hervorragend. Dennoch habe ich bei einigen Aspekten so meine Bauchschmerzen.

1. Das System ist meiner Meinung nach zu aufwendig. Allein der Hardwareeinsatz für das Capture-System ist in meinen Augen schon nicht gerechtfertigt, hinzu kommt dann der benötigte Speicherplatz für die Aufzeichnungen (oder werden die sofort nach der Analyse wieder gelöscht?) und der daraus resultierende Auswertungs-Aufwand. Und solch ein Aufwand nur dafür, um Mikroruckler aufzuzeigen? Denn bei den bisherigen FCAT-Reviews habe ich noch nirgends signifikante Probleme bei SGPU gesehen (die HD 7950 Boost bei TechReport mal ausgenommen, die mit neuem Treiber aber imho wieder wie gewohnt funktioniert).

Neue Reviewsites können nun noch schwerer Fuß fassen, da die finanzielle Einstiegshürde mit FCAT exorbitant gesteigert wird/wurde.

2. Wenn ich mich recht erinnere, hat PC Perspective erwähnt, dass sie auch eigene Skripte zur Datenauswertung von FCAT heranziehen werden. Da das jede Review-Seite selbstverantwortlich machen kann, ist die Vergleichbarkeit der Reviews zwischen einzelnen Seiten noch weniger gegeben als jetzt schon. Das empfinde ich fast schon als Rückschritt.

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! :)).

Zudem stellt sich mir die Frage, ob 20 Zeilen bei 2560x1600 (meine native Auflösung zu Hause) überhaupt sinnvoll sind oder ob hier im Verleich zu FullHD etwas höhere Werte angesetzt werden sollten. Für mich persönlich wären 25 Zeilen bei 1600p weniger wert als 20 Zeilen bei FullHD. Und dennoch würde das Bild bei 1600p gezählt und bei 1080p nicht.

Meiner Meinung nach muss neben den reinen observed FPS auch eine Art Mengenverteilung mitgeliefert werden (mit wie vielen Zeilen wurden die gezählten FPS jeweils dargestellt, ähnlich macht es PCPer), damit man als User einschätzen kann, um wie viel besser es Lösung X gegenüber Lösung Y macht. Andernfalls kann es zu eklatanten Differenzen kommen (siehe mein konstruiertes worst-case-Beispiel von oben). Nur führt das zu weiterem Aufwand (beim Reviewer sowie beim Leser).

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).

Insgesamt sehe ich FCAT wohl als Schritt in die richtige Richung. Allerdings ist man meiner Meinung nach noch weit davon entfernt, perfekt zu sein. Denn auch mit FCAT bleiben einige Aspekte übrig, die sehr subjektiv sein können - die aber dank FCAT in ein festes Grundgerüst gedrückt werden, um als objektiv gelten zu können. Zudem sehe ich dadurch die Gefahr, dass man sich irgendwann auf den Standpunkt zurückziehen wird, dass kein unruhiges Bild vorkommen kann, wo FCAT grünes Licht gibt. Und die Situation empfände ich persönlich noch schlimmer als jetzt.
 
1. Ja du hast recht, aufwendig ist es und ja wird sind froh, dass uns die Gelegenheit gegeben wird, mit FCAT zu testen. Was wir daraus machen, ist ja unsere Sache. Man kann damit aber mehr aufzeigen, als nur Mikroruckler.

2. Ich bin froh, dass NVIDIA hier einen recht offenen Weg gewählt hat. Was wäre gewesen, man hätte den Source-Code der Software nicht freigegeben und auch keinen Einblick in die Skripte erlaubt? Dann wären die Schreie nach einer Bevorzugung NVIDIAs sicher groß gewesen.

3. Das Limit für Runts ist nicht festgesetzt, sondern frei wählbar. Im Analyse-Tool kann dass beliebig geändert werden. Aber irgendwo muss ich das festsetzen und da hat NVIDIA einfach die 20 Zeilen genommen und wenn ich mir das in den Screenshots der Auswertung so anschaue, ist das ganz sinnvoll. 20 Zeilen sind für mich keine Information, die ich brauche, sie können im Gegenteil sogar stören.
 
Das mit der Farbcodierung hab ich immer noch nicht so richtig verstanden. Werden die Frames dann auf dem Bildschirm links mit einem Farbstreifen versehen? Ist das wie auf dem Bild in Teil 1?

Die Software markiert jedes Bild im Renderprozess mit unterschiedlichen Farbcodes am Displayausgang greift die Capturinghardware dann den markierten Stream ab und zeichnet ihn dann auf die Ramdisk auf.
Fehlt jetzt ein Frame (Drop) oder wird nur teilweiße ausgegeben(Runt) kann die Software das anhand der immer gleichen Farbmodulation u Balkenlänge der Farbstreifen erkennen u setzt dieses in Tabellenform??? um sodas man sich daraus dann die Präsentationsfolien basteln kann

Ich nehme an das sollte so passen Don?
 
Zuletzt bearbeitet:
Vollkommen richtig. Nach der Analyse haben wir Excel-Tabellen, die wiederum durch Skripte in Diagramme umgewandelt werden oder anderweitig weiterverarbeitet werden können. Wir müssen also auch nicht die Videos aufheben, sondern nur die Tabellen nach der Auswertung.
 
Interessanter ist doch, wo die Grenze liegt: 20 Zeilen sind evtl. sogar störend, 21 Zeilen aber nicht? Wie viele Zeilen benötigt man denn, damit's sinnvoll ist? Das wird dann wohl subjektiv zu bewerten sein. Wenn man's auf die Spitze treiben will, könnte man ja mehrere Stufen analysieren lassen, z.B. 20, 100 und 500 Zeilen.
 
Zuletzt bearbeitet:
Irgendwo muss ich die Grenze ja ziehen, ich muss der Software ja einen definitiven Wert geben.

Der Euro-Crash-Test für Autos findet bei 64 km/h statt. Warum nimmt man da nicht 65 km/h? Das sind einfach Erfahrungswerte, die man nimmt.
 
Aber wenn das Limit im Analyse-Tool doch frei wählbar ist, dann könnte man ja mehrere Stufen analysieren lassen, der Mehraufwand hielte sich doch in Grenzen, oder nicht?

Ich meine das auch gar nicht als Kritik, mich interessiert nur, woher diese 20 Zeilen kommen, da es doch eben keine Erfahrungswerte gibt (?), und ob eine andere Zeilenzahl nicht doch interessanter wäre.
 
FCAT ist aufwendig genug, da jetzt noch an den Skripten herumzuschrauben, macht es nicht besser. Ich habe ja dann auch zwei oder drei Grafiken mehr, für unterschiedliche Definitionen von Runts.

Die 20 Zeilen sind einfach ein Vorschlag von NVIDIA, dem Entwickler von FCAT. Wir haben uns die Videos mit dem Overlay aber auch angeschaut und nach Runts gesucht und finden eben diese ab 20 Zeilen als verwertbar.
 
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.
Dazu hätte ich eine Idee:

Das aufzeichnende System kann auf dem Benchmarksystem einen Tastenanschlag (z.B. W für forwärts) auslösen. Gleichzeitig könnte eine Software entsprechende Markierungen am Bild anbringen. Da das aufzeichnende System weiß, wann es den Eingabebefehl abgesendet hat, kann es aus der Differenz zwischen Absenden des Befehls und des entsprechend markierten Frames die Dauer berechnen.

Der Steuerbefehl für eine Eingabe sowie eine Art Eingabebestätigung würden über Netzwerk gesendet. Die Laufzeit der Datenpakete läßt sich messen und herausrechnen.

Die Eingabe erfolgte bei ((Zeitindex der Bestätigung - Zeitindex des abgeschickten Befehls) / 2)
Die Ausgabe erfolgte bei (Zeitindex des entsprechend markierten Bildes)

SweetFX z.B. kann Spiele einfärben und läßt sich per konfigurierbarem Hotkey ein- und ausschalten. Sinnvollerweise würde man dabei die gleiche Taste verwenden wie für die Vorwärtsbewegung im Spiel. Ich weiß nur leider nicht wieviel Zeit SweetFX selbst zum Umschalten braucht.
 
Mir ist das eigentlich mit FCAT ziehmlich egal weil flüssiger als man es mit vsync+limiter hinbekommt ist es einfach nicht machbar.
Genau so bekommt man auch grundsätzlich das beste spielgefühl bei sagen wir 60HZ@58-59FPS limit. weniger imputlag kann der monitor dann auch nicht darstellen.
Will man weniger sichtbaren imputlag braucht man halt nen monitor mit mehr Hz mit z.B. 120Hz@Vsync und wenn man dann bei 118FPS begrenzt läuft das dann schon mehr als nur flüssig und der imputlag ist bei knapp 8,5ms.
Ich würde eh nie wieder phne vsync+limiter zocken!
 
Zuletzt bearbeitet:
1. Ja du hast recht, aufwendig ist es und ja wird sind froh, dass uns die Gelegenheit gegeben wird, mit FCAT zu testen. Was wir daraus machen, ist ja unsere Sache. Man kann damit aber mehr aufzeigen, als nur Mikroruckler.

Ich hoffe, dass du meinen Post nicht als Kritik an HWL verstehst. Denn das ist er nicht.

Dass FCAT mehr kann als nur Mikroruckler aufzuzeigen ist mir durchaus bewusst. Allerdings ist es gefühlt das einzige Thema, über was bisher zu lesen war. Erst als viele meinten, dass man Mikroruckler mittels VSync und Framelimiter eindämmen kann, haben genau das einige Seiten getestet. Mehr ist mir in Bezug auf FCAT noch nicht unter die Augen gekommen - und dafür empfinde ich den Aufwand als zu hoch.



2. Ich bin froh, dass NVIDIA hier einen recht offenen Weg gewählt hat. Was wäre gewesen, man hätte den Source-Code der Software nicht freigegeben und auch keinen Einblick in die Skripte erlaubt? Dann wären die Schreie nach einer Bevorzugung NVIDIAs sicher groß gewesen.

Nach dem ich einige Artikel gelesen habe, bin ich fast der Meinung, dass NVIDIA hier etwas zuviel des Ruhmes abbekommt. Denn so, wie ich es bisher gelesen habe, ist der grundsätzliche Ansatz auf dem Mist von PCPerspective gewachsen - und nicht bei NVIDIA. Zwar hat sich NVIDIA in der Folge an der Lösung beteiligt, alleinig ist man dort allerdings nicht verantwortlich. Siehe dazu das Review auf PCPer.com:

PCPer schrieb:
You may notice that there is a lot of "my" and "our" in this story while also seeing similar results from other websites being released today. While we have done more than a year’s worth of the testing and development on our own tools to help expedite a lot of this time consuming testing, some of the code base and applications were developed with NVIDIA and thus were distributed to other editors recently.

NVIDIA was responsible for developing the color overlay that sits between the game and DirectX (in the same location of the pipeline as FRAPS essentially) as well as the software extractor that reads the captured video file to generate raw information about the lengths of those bars in an XLS file. Obviously, NVIDIA has a lot to gain from this particular testing methodology: its SLI technology looks much better than AMD’s CrossFire when viewed in this light, highlighting the advantages that SLI’s hardware frame metering bring to the table.

Wie dem auch sei: Wenn FCAT mit NV-Beteiligung nicht quasi open source wäre, dann bin ich mir der Konsequenzen daraus durchaus bewusst. Das ändert aber nichts daran, dass jede Anpassungsmöglichkeit dazu führen kann, dass Reviews immer weniger miteinander vergleichbar werden.



3. Das Limit für Runts ist nicht festgesetzt, sondern frei wählbar. Im Analyse-Tool kann dass beliebig geändert werden. Aber irgendwo muss ich das festsetzen und da hat NVIDIA einfach die 20 Zeilen genommen und wenn ich mir das in den Screenshots der Auswertung so anschaue, ist das ganz sinnvoll. 20 Zeilen sind für mich keine Information, die ich brauche, sie können im Gegenteil sogar stören.

Danke für die Info. Wenn der Wert geändert werden kann, dann ist das einerseits natürlich sehr gut. Andererseits landen wir genau wieder bei dem eben genannten Punkt: Reviews sind untereinander nicht mehr vergleichbar (zumindest die Reviews verschiedener Seiten). Heute wissen wir, dass bei gleicher oder ähnlicher Hardware auch ähnliche Ergebnisse herauskommen. Bei FCAT sind aber je nach Voreinstellung des Reviewers selbst bei identischer Hardware extreme Unterschiede möglich (ich sage absichtlich möglich).

Ich selbst würde für mich einschätzen, dass ich selbst bis zu 5 Prozent meines Bildschirms nicht als relevant erachten würde - was bei 1600p mal eben 80 Zeilen ergibt, welche ich möglicherweise sogar als runt definieren würde (das nur als Vermutung, ohne je mit FCAT getestet zu haben). Der eine Reviewer verwendet 20 Zeilen auflösungsübergreifend, der andere Reviewer nimmt zwei oder drei Prozent der Auflösung, der dritte setzt widerum 50 Zeilen fest - schon haben wir ein Durcheinander in den Ergebnissen, was keiner mehr durchschauen kann. Insofern ist der "open-source-Gedanke" hinter FCAT Fluch und Segen zugleich.


Je länger ich über FCAT nachdenke (und das tue ich schon seit den ersten Artikeln), desto weniger gefällt mir die aktuelle Lösung.
 
Ist es denn so, gibt es bisher ein Chaos bei den Reviews? Ist die Vergleichbarkeit dahin? Warte doch erstmal ab und schau wie es real abläuft ...
 
Ist es denn so, gibt es bisher ein Chaos bei den Reviews? Ist die Vergleichbarkeit dahin? Warte doch erstmal ab und schau wie es real abläuft ...

Ich wüsste auch nicht wieso FCAT nun dazu beitragen sollte das Reviews untereinander nun weniger vergleichbar sein sollten wie zu Zeiten ohne FCAT

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

Also was soll hier FCAT auch ändern was nicht jetzt auch differenziert ist

Das Tool misst wie Fraps nur eben an der richtigen Stelle u mit mehr Infos zu dem was tatsächlich am Display vor sich geht

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
 
Zuletzt bearbeitet:
Je länger ich über FCAT nachdenke (und das tue ich schon seit den ersten Artikeln), desto weniger gefällt mir die aktuelle Lösung.
Das geht nicht nur dir so!
Am besten man filmt den Monitor ab mit einer Hochgeschwindigkeitskamera, aber dann könnte wieder die Bild Verbesserer des Monitor oder die Render Engine vom TV dazwischen funken. :hmm:
Die rohen Daten sind schwer zu interpretieren für einen Laien.
 
Wieder mal hast du alles richtig gemacht Don, ich warte sehn süchtig auf Teil 3

Jungs ihr könnt ruhig den Danke Button benutzen in so eine Review steckt viel Arbeit.
 
Zuletzt bearbeitet:
Eins vorweg: Ich verteufele FCAT nicht per se. Aber ich habe bei einigen Punkten halt Bauchschmerzen.

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.


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)?
 
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. ;)
 
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.
 
Zuletzt bearbeitet:
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