The Tech Report: HighSpeed-Videos zeigen Micro-Stuttering [Archiv] - Seite 4

Gipsel

2013-04-04, 17:50:27

Aber was Du schreibst macht wenig Sinn.Für Gipsel offenbar schon...
Ziel der Messung ist nicht festzustellen, wo die Zeit genau verloren geht. nVidia weiß das sicher selbst (die haben Messpunkte im Treiber). AMD scheint da eher ahnungslos zu sein (ihrer eigenen Aussagen nach).
Das würdest du damit auch nicht. Du würdest nur sehen, ob eben gravierende Unterschiede auftauchen, die mit sauberen Frametiemes korrelieren. Du hast es scheinbar noch immer nicht verstanden, ich weiß allerdings nicht mehr, wie ich es noch erklären soll :(

Gipsel kannst du es mal versuchen? Du schaffst es deutlich besser derartige Sachen leicht verständlich darzustellen als ich. Ich bin in sowas total untallentiert leider ;D

Das Ziel der Messung ist klar festzustellen, wie viele Frames beim Anwender letztlich sichtbar werden und wie groß der zeitliche Abstand zwischen den sichtbar gewordenen Frame ist. Unterhalb einer gewissen Grenze (ziemlich willkürlich auf "21 Zeilen" festgelegt) gilt das Frame als wertlos.
Richtig, aber ist es nicht etwas scheinheilig, die Methode, wie das erreicht wird (bewusst?) auszuklammern und nicht zu untersuchen? Ein Schelm wer böses dabei denkt :rolleyes:

Und die womöglich komplett falschen Aussage bzgl Latenz lässt man eben unkommentiert. Was kann man denn dafür, dass die Leute nicht lesen können, und anfangen sich irgendwelchen "Scheis" zusammen zu fantasieren? :rolleyes:
Okay. My take:

Der Ansatz mit dem Framecapture und dem Overlay ist sicherlich interessant und liefert zusätzliche Daten. Auch ist es lobenswert, daß mal die ganze Pipeline zum Rendern dargestellt wird, da sicher viele bisher nicht so viel darüber nachgedacht haben. In einigen Artikeln (und in einigen Diskussionen dazu) wurde explizit herausgestellt, wie wichtig das Zusammenspiel aller Komponenten hierbei ist. Das fängt bei der Engine selber an (die kann selber auch FrameMetering betreiben und ist eigentlich sogar der beste Ansatzpunkt dazu!), geht über die DirectX-Runtime, den Treiber und umfaßt auch das Thread-Scheduling des Betriebssystems. Optimalerweise will man Aussagen über alle diese Komponenten haben und zwar nicht irgendwie pauschal, sondern für jeden Frame. Sprich, man will wissen, wie lange es dauert, bis die Engine alle Drawcalls für den Frame fertig hat (und den Frame mit dem present call sozusagen abschließt), wie lange das in den Framequeues rumhängt, wie groß der Treiberoverhead ist usw. usf. Dabei sind sowohl die absoluten Zeitdauern (Lag) als auch die Abweichungen zwischen den Frames wichtig. Nur alles zusammen ergibt ein komplettes Bild.

Es kann im Prinzip durchaus der Effekt eintreten, daß sich laut FCAT absolut gleichmäßig ausgegebene Bilder entweder einen größeren absoluten Lag aufweisen und/oder auch deutlich ruckliger anfühlen als laut FCAT ungleichmäßig ausgegebene Bilder, auch wenn man argumentieren kann, daß dies konstruiert und eher unwahrscheinlich ist. Für perfekt flüssige Darstellung (definiert dadurch, daß die Simulationszeitschritte in der Engine perfekt mit der Anzeige auf dem Bildschirm übereinstimmen) muß man wesentlich Latenz opfern, wenn man nicht übermäßig viele Annahmen über das Wohlverhalten aller Komponenten der Pipeline treffen will (die von hinten aufgezäumte "Lösung" würde vermutlich so aussehen, daß man je nach Anforderung eins oder gar mehrere fertige Frames puffern müßte, damit man sie mit der passenden Verzögerung ausgibt :freak:). Im Prinzip führt das immer zu einem Kompromiß, der aber immer Schwächen haben wird, sobald eine der Annahmen (daß die "Bearbeitungsdauer" in den Pipelinestationen eines Frames nicht von Frame zu Frame schwankt) zusammenbricht.

Optimalerweise würde eine Engine darauf achten, daß sie die Presents nicht einfach so schnell wie möglich raushaut, sondern in halbwegs gleichmäßigen Abständen, also z.B. die Abnahme der Zeitdauer zwischen zwei Presents auf z.B. 15% limitiert (oder 3 ms, was auch immer größer ist). Die Aufgabe der Treiber und des OS-Schedulings wäre dann lediglich, irgendwelche Spikes in ihrem Verantwortungsbereich zu vermeiden.

Denn gibt es einen Schluckauf in den Present-Abständen (bisher grob alle 20ms und mit einem Mal kommt ein Present erst 40ms nach dem vorhergehenden) geht sonst das Gerate für den Treiber los. Verzögert man das Frame, dessen Present später kam (angenommen die Queue ist nicht komplett leergelaufen, Arbeiten im GPU-Limit, Rendern dauert immer ~20ms), damit die Bufferflips die Abstände der Presents abbilden? Oder verzögert man erst das nachfolgende Frame (dessen Present wieder im gewohnten 20ms Abstand kam), um auf die 40ms zu kommen, die eventuell, vielleicht aber auch nicht dem Zeitschritt für dieses Frame in der Simulation der Engine entspricht und eventuell oder aber auch nicht einen Spike in der Latenz kompensiert oder erst verursacht. Wenn das Ganze nicht im GPU-Limit sondern im CPU-Limit läuft, hat man bei so einem Spike irgendwie schon verloren (weil die Queue leer ist und demzufolge die Frames gar nicht mehr gleichmäßig ausgegeben werden können und das aktuelle Frame sowieso später als üblich ausgegeben wird). Man kann allerdings trotzdem zusätzlich die Ausgabe des nächstens Frames ebenfalls künstlich verzögern um den Effekt des Mismatches von Simulationszeitschritten und Ausgabezeitschritten zu minimieren. Aber das ist auch ein Gerate, ob man es dadurch besser oder schlechter macht.
Zusammengefaßt zeigt einem eigentlich bereits ein sehr zappliger Abstand zwischen den Presents ein Problem (ich würde sagen ein Engineproblem, wenn der Treiber oder das OS nicht irgendwas verbocken), was sich für den allgemeinen Fall (manchmal geht es schon, nämlich wenn man weiß, was die Engine verbockt) nicht wieder vernünftig hinbiegen läßt.

Das bisher gilt ganz allgemein, also insbesondere für single GPU-Lösungen. Für AFR-Rendering würde der obige Ansatz übrigens vermutlich oft auch ziemlich gleichmäßige (in der beschriebenen Version aber nicht unbedingt perfekt glatte) Frametimes ohne µRuckeln liefern (durch die Limitierung der Abnahme des Zeitintervalls zwischen Presents in der Engine). Solange das nicht der Fall ist, bietet es sich für den Treiber an, die Bufferflips zu verzögern (und auch keine Presents der Engine für die Zeit anzunehmen), so daß sich ungefähr gleiche Abstände zwischen den GPUs ergeben. Hierzu kann man mit relativ kleinen Delays arbeiten, die die odd-even Oszillationen effektiv dämpfen (man muß nicht jedes zweite Frame immer um sagen wir mal 16ms verzögern, sondern z.B. nur 4 mal 4 ms und danach gar nicht mehr). Oder alternativ muß man das ja auch nicht unbedingt jeden Frame machen, sondern nur, wenn so eine Oszillation hinreichender Größe erkannt wird. Dann setzt man praktisch ab und zu mal die Startzeitpunkte für aufeinanderfolgende Frames auf äquidistante Abstände zurück, wenn sie sich länger als 3 oder 4 Frames um mehr als XY% unterscheiden. Nicht viel was Anderes macht nV ja offenbar bei SLI. In CPU-limitierten Szenarien stellt sich ja automatisch ein gleichmäßiger Frameabstand ein (wenn die Engine keinen Mist baut), aber im GPU-Limit kann das schon helfen, wenn die Engine nicht anderweitig (z.B. wie oben vorgeschlagen) einen glatten Verlauf der Frameabstände sicherstellt.
In diesem Zusammenhang ist übrigens interessant (und das schließt auch den Bogen zu den verschiedenen Messungen), was genau eigentlich der Treiber dort macht. Denn bei AFR ist es im Prinzip auch möglich, daß die Presents absolut gleichmäßig kommen (z.B. weil die Engine darauf achtet), aber die Ausgabe trotzdem ungleichmäßig erfolgt (im Extremfall werden die Frames einer GPU komplett verworfen). Dies hängt davon ab, wie genau der Treiber die Drawcalls auf die (in Hardware getrennten) Kontexte und Queues der GPUs verteilt. Andersrum wäre es auch nicht optimal, wenn schwankende Present-Intervalle durch dauerhafte künstliche Verzögerungen in gleichmäßge BufferFlip-Intervalle umsetzt. Für eine genaue Einschätzung benötigt man daher möglichst beides, die Schwankungen der Present- und der Bufferflip-Intervalle und das framegenau synchronisiert. Nahezu perfekt wäre es, wenn man noch die Zeit des Scanouts mit einem synchronisierten Zeitstempel taggen könnte (gibt einem das Lag zwischen Present und der Anzeige), aber das ginge wohl nur mit Modifikationen an der bzw. zusätzliche Hardware (man benötigt eine gemeinsame synchronisierte Clock für Host- und Aufzeichnungsrechner, wenn man nicht Beides im gleichen machen will). Absolut Perfekt wäre es, wenn das Spiel auch noch seinen Zeitstempel liefern würde.

Summa Summarum: Guter Ansatz, ein paar naheliegende Verbesserungsmöglichkeiten sind aber schon noch da. Jetzt, da das Ganze im Groben bekannt ist, wird sich da vielleicht irgendwer erbarmen, der in die Farben der Leisten z.B. µs-genaue Zeitstempel für die Presents codiert (die würden sich dann alle ~16 Sekunden wiederholen, bei einem Framebuffer und Ausgabe mit 10bit pro Komponente sogar nur alle ~17 Minuten, aber das steht wohl erstmal nicht zur Debatte und ist im Prinzip auch unnötig).

Gipsel

2013-04-04, 17:58:09

Nur: Die Engine taktet die Frames auf Grund der Zeitpunkte, zu denen das "Present" ausgeführt werden kann, also genau die Zeitpunkte, die auch FRAPS misst. Die im Allgemeinen ja recht gleichmäßig sind.

Wenn der tatsächliche Output aber nicht die selbe Gleichmäßigkeit hat, die eigentlich vom Spiel vorgegeben wird, dann "springen" die tatsächlich sichtbaren Frames auf der Zeitlinie immer hin und her, d.h. ein Frame wird etwas zu früh gezeigt, das nächste etwas zu spät usw.

Korrigiert der Treiber das, in dem er künstliche Verzögerungen einfügt, dann laufen die Frames gleichmäßig auf dem Zeitstrang, so wie die Engine die Frames in die Pipeline eingefüttert hat. Die Verzögerung beeinflusst also objektiv die Latenz nicht negativ. Ohne die Verzögerung kommen nur einige Frames zu früh zum Anwender, früher als die Engine das berechnet hat, und das ist wesentlich schlimmer als 10 ms mehr Latenz.So einfach ist das gar nicht. Der Treiber hat ja keine Möglichkeit zu wissen, wann genau zwischen zwei Presents die Engine ihren Zeitpunkt festlegt. Wie schon beschrieben, kommt ein Present mal später, verzögert man dann besser das dazugehörige Frame oder erst das danach? Erstere Möglichkeit paßt, wenn die Verzögerung vor der "Zeitnahme" durch die Engine erfolgt ist, zweite Möglichkeit, wenn es danach erfolgt ist. Wählt man das Falsche, verschlimmert man die Situation anstatt sie zu verbessern. :wink:
Und es funktioniert auch nur im GPU-Limit passabel (vorausgesetzt man errät richtig, welches Frame man verzögern muß), im CPU-Limit ist mit 50% Wahrscheinlichkeit das Kind bereits unwiederbringlich in den Brunnen gefallen.

Skysnake

2013-04-04, 18:02:00

Grestorn

2013-04-04, 18:09:44

Kann man damit deiner Meinung nach kurz zusammengefasst sagen das:
FCAT in der aktuellen Form also einfach nicht ausreichend ist, um die versprochene/suggerierte Genauigkeit bzgl "Spielgefühl" zu erreichen?

Das würde Dir gefallen... :)

Es ist auf jeden Fall besser, als 30-50% Frames zu produzieren, die zwar in FRAPS gezählt werden, aber vom Anwender nie gesehen werden. Das kann man nämlich eigentlich nur als Cheaten bezeichnen - auch wenn ich kein Absicht unterstellen will.

Gipsel

2013-04-04, 18:11:05

Kann man damit deiner Meinung nach kurz zusammengefasst sagen das:
FCAT in der aktuellen Form also einfach nicht ausreichend ist, um die versprochene/suggerierte Genauigkeit bzgl "Spielgefühl" zu erreichen?Es müssen ein paar Voraussetzungen erfüllt sein, damit es wirklich das Spielgefühl abbildet. Es ist natürlich grundsätzlich immer besser, dies zu überprüfen als es nur anzunehmen. Zusätzlich hätte man mit einer Erweiterung sogar ein Tool, mit dem man besser auf eine bestimmte Komponente der Renderpipeline zeigen kann, an der es hängt. Es ist natürlich interessant und spannend sagen zu können, woran irgendwelche Probleme denn nun genau liegen. Der offenbar starke Einfluß des CoreParking-Features und der Granularität des Thread-Schedulings von Windows wurde ja bereits thematisiert. Momentan gibt es oft eine Gemengelage, die eine Festlegung erschwert. Was man sagen kann, ist daß Crossfire offenbar in vielen Situationen deutliche Schwächen aufweist. Dies gibt ja AMD auch zu und verspricht Abhilfe. Also warten wir mal zwei Monate oder so was da rauskommt und dann gibt es vielleicht auch bereits aufgebohrte Versionen der Meßtools, die eine feinere Diagnose ermöglichen.

pest

2013-04-04, 18:51:45

Ganz klar ist mir auch nicht warum die Werte bei genau diesen beiden Frames nicht stimmen.

Bei den Titan-Tests sind es ein paar mehr. Bei der GTX690 immer nur 1. :confused:, Was nun korrekt ist, kann ich auch nicht sagen

Was ich mich auch Frage wie man die Dropped-Frames erkennt?

Titan@Heaven:

Links FCAT inkl. "Ruckler", Rechts FCAT ohne Ruckler

http://www.abload.de/img/fcat01t5jsz.pnghttp://www.abload.de/img/fcat02eqkti.png

Fraps
http://www.abload.de/img/fcat037lkxz.png

Hübie

2013-04-04, 19:06:40

Hier mal neues Futter: techreport.com/review/24588/the-tr-podcast-131-news-from-gdc-and-fcat-attacks

Hatte noch keine zeit das zu gucken (Arbeit) aber scheint interessant zu sein...

Skysnake

2013-04-04, 19:09:34

Es müssen ein paar Voraussetzungen erfüllt sein, damit es wirklich das Spielgefühl abbildet. Es ist natürlich grundsätzlich immer besser, dies zu überprüfen als es nur anzunehmen. Zusätzlich hätte man mit einer Erweiterung sogar ein Tool, mit dem man besser auf eine bestimmte Komponente der Renderpipeline zeigen kann, an der es hängt. Es ist natürlich interessant und spannend sagen zu können, woran irgendwelche Probleme denn nun genau liegen. Der offenbar starke Einfluß des CoreParking-Features und der Granularität des Thread-Schedulings von Windows wurde ja bereits thematisiert. Momentan gibt es oft eine Gemengelage, die eine Festlegung erschwert. Was man sagen kann, ist daß Crossfire offenbar in vielen Situationen deutliche Schwächen aufweist. Dies gibt ja AMD auch zu und verspricht Abhilfe. Also warten wir mal zwei Monate oder so was da rauskommt und dann gibt es vielleicht auch bereits aufgebohrte Versionen der Meßtools, die eine feinere Diagnose ermöglichen.
Wobei ich eben befürchte, das man "einfach" auch ein Framemetering einführt, und entsprechend dem "Test" eben die Frameausgabe verzögert, wenn man erkennt, das ein neuer Frame fertig ist, und der alte eben unter einem bestimmen Wert angezeigt wird. Sagen wir mal 100 Zeilen.

Das sollte man wunderbar einfach in Software implementieren können.

Dann muss man aber nur warten, bis eben das "verbesserte" Tool raus kommt, und der ganze Zirkus fängt von vorne an... Das könnte man sich echt sparen.

Gipsel

2013-04-04, 19:14:10

Hier mal neues Futter: techreport.com/review/24588/the-tr-podcast-131-news-from-gdc-and-fcat-attacks

Hatte noch keine zeit das zu gucken (Arbeit) aber scheint interessant zu sein...
Der FCAT-Part geht bei 55:00 los.

Godmode

2013-04-04, 19:15:04

Der FCAT-Part geht bei 55:00 los.

Danke! Ich wollte schon einen Flamepost schreiben, wie sehr ich Podcasts hasse, wo ewig geschwafelt wird. :wink:

Gipsel

2013-04-04, 19:56:00

Danke! Ich wollte schon einen Flamepost schreiben, wie sehr ich Podcasts hasse, wo ewig geschwafelt wird. :wink:
Die labern trotzdem ewig darüber. Um 1h:30min rum kommen die zu dem Punkt, daß einfach nur Glätten des Outputs auch nicht das Wahre ist und daß die Simulationszeitpunkte der Engine (also der Inhalt des Frames) im Prinzip zur Ausgabe passen müssen.

Grestorn

2013-04-04, 20:04:47

Die labern trotzdem ewig darüber. Um 1h:30min rum kommen die zu dem Punkt, daß einfach nur Glätten des Outputs auch nicht das Wahre ist und daß die Simulationszeitpunkte der Engine (also der Inhalt des Frames) im Prinzip zur Ausgabe passen müssen.

Wie will man das schaffen ohne die Latenz des Treibers und der GPU selbst auf 0 zu drücken? Das geht nicht.

Was man machen kann ist dass die Latenz möglichst konstant ist. Sprich, dass die Zeit, die der Treiber und die GPU für die Verarbeitung eines Frames braucht, möglichst unverändert bleibt.

Bei sGPU ist das auch weitestgehend der Fall. SLI macht das meistens aber nicht immer ganz gut. Crossfire schafft das viel zu oft nicht.

Alles andere ist hier leider nur schöngerede.

Das ist ja keine Katastrophe, dafür ist Crossfire ohnehin zu wenig verbreitet um das jetzt so ein Fass aufzumachen. AMD Freunde sollten das vielleicht etwas sportlicher sehen.

Gipsel

2013-04-04, 20:08:51

Wie will man das schaffen ohne die Latenz des Treibers und der GPU selbst auf 0 zu drücken? Das geht nicht.

Was man machen kann ist dass die Latenz möglichst konstant ist. Sprich, dass die Zeit, die der Treiber und die GPU für die Verarbeitung eines Frames braucht, möglichst unverändert bleibt.Man benötigt eine Rückkopplung um das im Schnitt hinzubekommen, das geht schon. Und für single Frame Spikes lies Dir einfach mal meine vorherigen Posts durch. Da kann man im Prinzip raten (d.h. das Spiel profilen und sich ansehen, was wahrscheinlicher ist und das im Spielprofil hinterlegen) ob bei so einem Schluckauf das entsprechende Frame oder das danach verzögert werden muß, damit die Frameausgabe zu den Simulationszeitpunkten der Engine passen. Zumindest im GPU-Limit dürfte das passabel funktionieren. Wie im Podcast von Techreport gesagt (irgendwo in den 1:40ern), sieht man auch bei SLI manchmal das Problem, daß nur die Ausgabe geglättet wird und die Simulationssprünge ungleich sind, was auch spürbar ist. In den Fällen fehlt die aktive Rückkopplung bzw. verzögert man das falsche Frame.

Edit:
Das steht im Prinzip auch schon im Techreport-Artikel (http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/11):
The FCAT analysis has shown us that Nvidia's frame metering tech for SLI does seem to work as advertised. Frame metering isn't necessarily a perfect solution, because it does insert some tiny delays into the rendering-and-display pipeline. Those delays may create timing discontinuities between the game simulation time—and thus frame content—and the display time. They also add a minuscule bit to the lag between user input and visual response.Meist (nicht immer!) ist das wohl ein im Vergleich zur CF-Performance kleineres Problem. Es spricht aber eigentlich nichts dagegen, trotzdem dran zu arbeiten. ;)
Und weiter schreiben sie:
We do want to be careful to note that frame delivery as measured by FCAT is just one part of a larger picture. Truly fluid animation requires the regular delivery of frames whose contents are advancing at the same rate. What happens at the beginning of the pipeline needs to match what happens at the end. Relying on FCAT numbers alone will not tell that whole story; we'd just be measuring the effectiveness of frame metering techniques. We've come too far in the past couple of years in how we measure gaming performance to commit that error now.

Schaffe89

2013-04-04, 20:15:20

Dann muss man aber nur warten, bis eben das "verbesserte" Tool raus kommt, und der ganze Zirkus fängt von vorne an... Das könnte man sich echt sparen.

Naja, die Bildausgabe etwas zu verzögern um konstante Frametimes rauszubekommen scheint die bessere Methodik zu sein, als gar nichts zu tun.

Ich finde es nur etwas komisch, dass AMD nichts sagt, obwohl sie anscheinend bei den Messungen offensichtlich durch das nichtbeachten des Outputlags benachteiligt werden.
Wahrscheinlich aus dem Grund, weil AMD genau so etwas auch einführen will.?:freak:

Hübie

2013-04-04, 20:24:48

Der FCAT-Part geht bei 55:00 los.

Danke. Steht aber sogar darunter für Leute wie godmode ;D
Wie du bereits sagtest hängt eben viel an der Engine und da wird oft geschlampt. In einem skyrim ist es dabei jedoch nicht so dramatisch wie in einem Battlefield. Ich stimme Scott zu und sage ebenfalls das wir erst am Anfang stehen.

Gipsel

2013-04-04, 20:35:04

Danke. Steht aber sogar darunter für Leute wie godmode ;D
Wie du bereits sagtest hängt eben viel an der Engine und da wird oft geschlampt. In einem skyrim ist es dabei jedoch nicht so dramatisch wie in einem Battlefield. Ich stimme Scott zu und sage ebenfalls das wir erst am Anfang stehen.Oder wie Scott selber schreibt, bastelt man am Timing in der Engine für die Messungen (bei Skyrim ändert man einen Wert namens iPresentInterval und was mißt FRAPS gleich noch mal? ;)).
Also bei CrossFire besteht ohne Zweifel Änderungsbedarf. Aber daß stures FrameMetering die allein selig machende Lösung ist, wäre auch übertrieben. Wie schon im TR-Artikel beschrieben, muß eben die komplette Pipeline von der Engine über DX und das OS und natürlich auch den Treibern zusammenpassen. Da gibt es an mehreren Stellen Optimierungsmöglichkeiten. Zukünftig hat man die Aussicht, den jeweils Schuldigen besser ausfindig machen zu können. Das hilft doch irgendwie allen.

Grestorn

2013-04-04, 20:55:41

Man benötigt eine Rückkopplung um das im Schnitt hinzubekommen, das geht schon. Und für single Frame Spikes lies Dir einfach mal meine vorherigen Posts durch.

Dir habe ich ja nie widersprochen. Ich habe nur der Aussage Skysnakes widersprochen, dass nVidia hier zusätzliche Latenzen erzeugt um einen gleichmäßigen Frameverlauf zu bekommen.

Diese Verzögerung muss ja nicht in jedem Frame eingefügt werden. Es reicht einmal an der richtigen Stelle und richtig getimed.

Angenommen es wird eine konstante Szene gerendert. Wenn die beiden Karten dummerweise in einem unsauberen Takt arbeiten, dann hat der Anwender wenig davon der mGPU Power:

1-2-------1-2-------1-2-------1-2-------1-2

Die Frames der beiden Karten fallen nahezu zusammen. Die Framerate ist hoch, aber letztlich sieht der Anwender davon nahezu nur die Hälfte. Man bekommt also nur "runts".

Einmal ein Delay eingefügt und von da an passt der Verlauf und der Anwender kann den Vorteil von mGPU voll nutzen, weil ab diesem Moment die beiden GPUs sauber in einem Tick/Tock Takt abwechselnd fertig werden:

1-ooo2----1-----2-----1-----2-----1-----2-----1

ooo wäre die eingefügte künstliche Wartezeit. Das erzeugt ganz sicher keine zusätzliche Latenz hat aber einen enormen Effekt.

Natürlich ist das ganze bei dynamischen Szenen viel schwieriger und man wird immer wieder mal ein Delay einbauen müssen. Das muss natürlich ein Regelkreis sein, wie Du das auch vorschlägst Gipsel. Nichts desto trotz führt da kein Weg daran vorbei. Und dass AMD das bisher überhaupt nicht betrachtet hat, ist gelinde gesagt schade.

Hübie

2013-04-04, 21:05:54

Oder wie Scott selber schreibt, bastelt man am Timing in der Engine für die Messungen (bei Skyrim ändert man einen Wert namens iPresentInterval und was mißt FRAPS gleich noch mal? ;)).
Also bei CrossFire besteht ohne Zweifel Änderungsbedarf. Aber daß stures FrameMetering die allein selig machende Lösung ist, wäre auch übertrieben. Wie schon im TR-Artikel beschrieben, muß eben die komplette Pipeline von der Engine über DX und das OS und natürlich auch den Treibern zusammenpassen. Da gibt es an mehreren Stellen Optimierungsmöglichkeiten. Zukünftig hat man die Aussicht, den jeweils Schuldigen besser ausfindig machen zu können. Das hilft doch irgendwie allen.

Im Falle der Creation Engine hast du bei ipresentintervall=0 den Nachteil das es irgendwann um 24:00 Uhr ingame time heller Tag ist ;) Also haben wir keinen praktischen Nutzen. Zur Messung auch nur begrenzt dienlich.

Skysnake

2013-04-04, 21:33:11

Die labern trotzdem ewig darüber. Um 1h:30min rum kommen die zu dem Punkt, daß einfach nur Glätten des Outputs auch nicht das Wahre ist und daß die Simulationszeitpunkte der Engine (also der Inhalt des Frames) im Prinzip zur Ausgabe passen müssen.
Genau DAS wird aber von extrem vielen Leuten abgestritten... Schön das man jetzt mal noch andere Leute hat, die das so sehen. Mit Argumenten kommt man bei vielen Leuten ja leider nicht weit...

Muss mir das dann aber doch noch vorher selbst genau anhören.
Naja, die Bildausgabe etwas zu verzögern um konstante Frametimes rauszubekommen scheint die bessere Methodik zu sein, als gar nichts zu tun.

Sieht so aus, wobei man schauen muss, wie groß der Vorteil dadurch am Ende wirklich ist. Das Spielgefühl unterscheidet sich ja von dem was FCAT in der aktuellen Variante anzeigt eventuell doch deutlich, eben weil es unzulänglich ist.

Man muss also schauen, ob nVidia mit ihrer Technik nicht eben ins andere Extrem verfällt, und ein "schlechtes" Spielgefühl, was ähnlich sich äußert, eben komplett andere Ursachen hat. Apriori kann man die beiden Effekte als Nutzer ja sehr sehr wahrscheinlich nicht unterscheiden. Ich wüsste zumindest nicht, wie der User die differenzieren sollte.

Ich finde es nur etwas komisch, dass AMD nichts sagt, obwohl sie anscheinend bei den Messungen offensichtlich durch das nichtbeachten des Outputlags benachteiligt werden.
Wahrscheinlich aus dem Grund, weil AMD genau so etwas auch einführen will.?:freak:
Es ist zu befürchten... Und da es eben sehr einfach zu implementieren sein sollte, muss man die Leute ja nicht noch drauf stoßen.

Es wird halt wahrscheinlich wieder nur an den Sympthome rumgedoktort, statt die Ursache mal an zugehen...

Dir habe ich ja nie widersprochen. Ich habe nur der Aussage Skysnakes widersprochen, dass nVidia hier zusätzliche Latenzen erzeugt um einen gleichmäßigen Frameverlauf zu bekommen.

Und was ist sonst das verzögerte ausgeben eines Frames? :ugly:

Diese Verzögerung muss ja nicht in jedem Frame eingefügt werden. Es reicht einmal an der richtigen Stelle und richtig getimed.

Hab ich das irgendwo gesagt, dass das an jeder Stelle passiert?

Nö.

Wäre auch dumm, weil mir die Möglichkeit, die du gleich beschreibst die ganze Zeit über klar ist. Ich bin ehrlich gesagt gar nicht auf die Idee gekommen, das man ne ganze Zeit über Delays einfügen muss (gleich mehr).

Angenommen es wird eine konstante Szene gerendert. Wenn die beiden Karten dummerweise in einem unsauberen Takt arbeiten, dann hat der Anwender wenig davon der mGPU Power:

1-2-------1-2-------1-2-------1-2-------1-2

Die Frames der beiden Karten fallen nahezu zusammen. Die Framerate ist hoch, aber letztlich sieht der Anwender davon nahezu nur die Hälfte. Man bekommt also nur "runts".

Einmal ein Delay eingefügt und von da an passt der Verlauf und der Anwender kann den Vorteil von mGPU voll nutzen, weil ab diesem Moment die beiden GPUs sauber in einem Tick/Tock Takt abwechselnd fertig werden:

1-ooo2----1-----2-----1-----2-----1-----2-----1

ooo wäre die eingefügte künstliche Wartezeit. Das erzeugt ganz sicher keine zusätzliche Latenz hat aber einen enormen Effekt.

Was ist denn die Wartezeit denn sonst als ne zusätzliche Latenz? :ugly: 2 Namen für den selben Effekt.

Im Prinzip geht das schon, apriori kann man aber nicht davon ausgehen, dass dann auch funktioniert! Wir wissen ja nicht, was der Auslöser dafür ist/war. Je nachdem kann es also passieren, dass in jedem Frame eine neue Verschiebung auftritt.

Zudem ist eben nicht klar, ob nVidia mit der Methodik, die Sie einsetzen, die Erzeugung eines neuen Frames rausschieben oder nicht. Das kann FCAT in der Form, wie es aktuell verwendet wird einfach nicht darstellen. Mit dem zeitcodierten Overlay-Balken sollte es aber möglich sein, soweit ich das gerade überblicken kann.

Natürlich ist das ganze bei dynamischen Szenen viel schwieriger und man wird immer wieder mal ein Delay einbauen müssen. Das muss natürlich ein Regelkreis sein, wie Du das auch vorschlägst Gipsel. Nichts desto trotz führt da kein Weg daran vorbei. Und dass AMD das bisher überhaupt nicht betrachtet hat, ist gelinde gesagt schade.
Naja, das was nVidia macht, ist ja auch nicht der Weißheit letzer Schluss, und so was kostet auch viel Geld in der Entwicklung. Ich kann da schon ein Stückweit nachvollziehen, das man nicht mehr Geld reinbuttert als man unbedingt muss. Für den Kunden natürlich scheise, aber wenn ich die Wahl zwischen dem und z.B. globaler Adressraum, dann entscheide ICH mich für den globalen Adressraum.

Die sollten halt echt lieber daran arbeiten so schnell wie möglich Interposer zu verwenden, und das ganze Problem an der Wurzel an zu gehen, indem man mit extrem breiten Datenpfaden arbeitet, und dann wieder simultan an einem Frame arbeiten kann.

Genau da kriegen aber eben BEIDE den Arsch nicht hoch, und servieren uns dann lieber so was wie Framemetering, was eben nur ein herumgedoktore ist, weil es VIEL zu viele Variablen gibt, auf die man nicht immer einen Einfluss hat, und dann auch noch von Game zu Game komplett unterschiedlich ist... -.-

Grestorn

2013-04-04, 21:46:34

Sorry, aber Du argumentierst sehr irrational, Skysnake. Man bekommt schon den Eindruck dass nicht sein kann was nicht sein darf.

Gipsel

2013-04-04, 21:46:49

Diese Verzögerung muss ja nicht in jedem Frame eingefügt werden. Es reicht einmal an der richtigen Stelle und richtig getimed.

Angenommen es wird eine konstante Szene gerendert. Wenn die beiden Karten dummerweise in einem unsauberen Takt arbeiten, dann hat der Anwender wenig davon der mGPU Power:

1-2-------1-2-------1-2-------1-2-------1-2

Die Frames der beiden Karten fallen nahezu zusammen. Die Framerate ist hoch, aber letztlich sieht der Anwender davon nahezu nur die Hälfte. Man bekommt also nur "runts".

Einmal ein Delay eingefügt und von da an passt der Verlauf und der Anwender kann den Vorteil von mGPU voll nutzen, weil ab diesem Moment die beiden GPUs sauber in einem Tick/Tock Takt abwechselnd fertig werden:

1-ooo2----1-----2-----1-----2-----1-----2-----1

ooo wäre die eingefügte künstliche Wartezeit. Das erzeugt ganz sicher keine zusätzliche Latenz hat aber einen enormen Effekt.

Natürlich ist das ganze bei dynamischen Szenen viel schwieriger und man wird immer wieder mal ein Delay einbauen müssen. Das muss natürlich ein Regelkreis sein, wie Du das auch vorschlägst Gipsel. Nichts desto trotz führt da kein Weg daran vorbei. Und dass AMD das bisher überhaupt nicht betrachtet hat, ist gelinde gesagt schade.Das funktioniert aber nur, wenn man eine Rückkoplung zur Engine hat, z.B. in dem für die Queue ebenfalls blockt (und zwar für ein Frame der richtigen GPU!), so daß die Engine keine neuen Drawcalls absetzen kann. Einfach nur den Bufferflip verzögern bringt da nicht viel bzw. ist eventuell sogar kontraproduktiv, weil man dann jedes zweite Frame ein Delay einfügen muß und die Frames zwar gleichmäßig ausgegeben werden, der Inhalt aber eventuell ungleichmäßig verlaufenden Zeiten entspricht (ist dann so eine Art Judder-Effekt). Ob und wie gut das funktioniert sieht man, wenn man FRAPS-Daten (besser wären noch Zeitstempel aus der Engine selbst) framegenau mit den FCAT-Daten korreliert. Oder eben die Present-Zeitpunkte direkt in die Farbe des Overlay-Balkens codiert, wie von Skysnake vorgeschlagen.

Marty98

2013-04-04, 22:18:51

Das funktioniert aber nur, wenn man eine Rückkoplung zur Engine hat, z.B. in dem für die Queue ebenfalls blockt (und zwar für ein Frame der richtigen GPU!), so daß die Engine keine neuen Drawcalls absetzen kann. Einfach nur den Bufferflip verzögern bringt da nicht viel bzw. ist eventuell sogar kontraproduktiv, weil man dann jedes zweite Frame ein Delay einfügen muß und die Frames zwar gleichmäßig ausgegeben werden, der Inhalt aber eventuell ungleichmäßig verlaufenden Zeiten entspricht (ist dann so eine Art Judder-Effekt).

Ich denke schon dass es funktioniert. Ein Verzögerung an einer richtigen stelle kann die Gesamt-Performance der GPU verbessern. Siehe diese Aussage von AMD:

"Stuttering doesn’t just impact the frame intervals, but many of those stalls where stuttering was occurring were also stalling the GPU entirely, reducing overall performance. One figure AMD threw around was that when they fixed their stuttering issue on Borderlands 2, overall performance had increased by nearly 13%, a very significant increase in performance that AMD would normally have to fight for, but instead exposed by an easy fix for stuttering. So AMD’s fixing their stuttering has not only resolved that issue, but in certain cases it has helped performance too."

http://www.anandtech.com/print/6857/amd-stuttering-issues-driver-roadmap-fraps

Grestorn

2013-04-04, 22:39:10

Das funktioniert aber nur, wenn man eine Rückkoplung zur Engine hat, z.B. in dem für die Queue ebenfalls blockt

Das ergibt sich doch ganz von selbst, da eben nur eine bestimmte Zahl von Frames im Puffer stehen können. Ist der voll, blockiert Present() und damit hast Du genau den gewünschten Effekt.

Skysnake

2013-04-04, 23:45:20

Sorry, aber Du argumentierst sehr irrational, Skysnake. Man bekommt schon den Eindruck dass nicht sein kann was nicht sein darf.
Das ergibt sich doch ganz von selbst, da eben nur eine bestimmte Zahl von Frames im Puffer stehen können. Ist der voll, blockiert Present() und damit hast Du genau den gewünschten Effekt.
Du stellst dir Gameengines und allgemein die Problematik aber VIEL VIEL VIEL zu einfach vor!

Das ist alles hochgradig komplex und nicht vorhersagbar. Weißt du was ALLES auf so ne CPU oder auch GPU passieren kann, und dich für CPU-Verhältnisse einfach Ewigkeiten blockieren kann?

Ich bin da auch überhaupt nicht "irrational", sondern ich weiß einfach nur, wie fucking komplex das alles ist, und seitdem ich nen Linux-Kerneltreiber portiere bzw teilweise neu schreibe, und das absolut lowlvl, also teilweise sogar sowas wie den IOAPIC (IO AdvancedProgrammableInterruptController) selbst anspreche usw usw. wunder ich mich, teils echt, das unsere Computer überhaupt laufen! Das ist so abartiges Zeug, was da teilweise abgeht, da schlackerste echt mit den Ohren... Erst jetzt weiß ich wirklich zu schätzen, wie "easy" Userlandprogrammierung ist :ugly:

Die Treiberjungs machen aber eben icht nur Userland. Und davor hab ich schon immer den Hut gezogen, inzwischen denk ich mir aber teils nur noch: Die armen Schweine, das ist echt nen kack job....

Grestorn

2013-04-05, 00:04:29

Du stellst dir Gameengines und allgemein die Problematik aber VIEL VIEL VIEL zu einfach vor!

Das ist alles hochgradig komplex und nicht vorhersagbar. Weißt du was ALLES auf so ne CPU oder auch GPU passieren kann, und dich für CPU-Verhältnisse einfach Ewigkeiten blockieren kann?

Klar sind es relative Ewigkeiten, die present() blockieren kann. Aber was ändert das an meiner Aussage?

Ich empfehle Dir mal die Lektüre folgenden Texts: http://forum.beyond3d.com/showthread.php?p=1689708

Nur ein kleiner Ausschnitt aus dem wirklich ausgesprochen informativen Artikel:

"[...] We need some way to respond to the actual realized throughput of the pipeline at a given time.
The way this is usually done is by observing "back-pressure" from the pipeline. If you pick a static number of frames that you are willing to buffer up at the start of the rendering pipeline (usually 1-3), when there's no more space in the queue you simply halt the game and wait until space is available. Then, assuming that pipeline is running in a relatively steady state, the game can time how long it takes from the point that it fills the queue to the point where another slot opens up to get the rate of output of the pipeline. This is what pretty much every game does, and this is the same timing that FRAPS is measuring. GPU vendors like this strategy because it ensures that the GPU usually has more work waiting in the queue and thus will run at full throughput and show high frames per second numbers."

Skysnake

2013-04-05, 00:18:01

Nein, du verstehst es nicht.

Es geht darum, was deine Hardware alles macht. Da kommt nen Interrupt von der Netzwerkkarte, oder der GPU, da wird dieses oder jenes gemacht.

Der Sheduler lässt dich nicht ran, oder er baut scheise. Deine Daten fliegen aus dem Cache raus, und du musst Sie neu aus dem RAM holen. Der PCI-E Bus ist blockiert (ok, das geht bei den neuen Intels nicht mehr). usw usw usw usw.

Es geht mir gar nicht um den present() call, sondern um den ganzen Mist, der abläuft, ohne das man es sieht. Eben die ganzen Abstraktionsebenen.

Kleines Beispiel. PCI-E/HT ist das gleiche wie PCI im Linux-Kernel. usw usw usw. Einem wird teils echt schwindelig, wenn man sich anschaut, durch wieviele Abstraktionsebenen man sich teils durchackern muss, bis man wirklich mal an den Stellen angekommen ist, die die Hardware wirklich ansprechen. Da bekommste echt das Kotzen, und bei Windows wirds nicht anders sein, eher noch schlimmer. Da wundert man sich auch überhaupt nicht, warum man so viel Leistung auf der Straße liegen lässt in nem heutigen Desktop.

Gipsel

2013-04-05, 01:04:53

Das ergibt sich doch ganz von selbst, da eben nur eine bestimmte Zahl von Frames im Puffer stehen können. Ist der voll, blockiert Present() und damit hast Du genau den gewünschten Effekt.Das funktioniert nur im absoluten GPU-Limit, also wenn die Queue immer randvoll ist. Bei einem in FRAPS sichtbaren Spike der Frametime ist das aber nicht fer Fall.
Und bei AFR (also SLI und CF) gibt es automatisch noch zusätzliche Puffer (pro GPU [mindestens] ein Frame), die zur Verfügung stehen. Wer sagt Dir denn, daß das nicht benutzt wird, um die primäre Queue (die die Anwendung sieht und kleiner ist als die Summe der Länge der internen, nur für den Treiber sichtbaren Queues für die einzelnen physischen GPUs) weiterhin Drawcalls entgegennehmen zu lassen, obwohl sie eigentlich (bei einer single-GPU-Lösung) bereits voll wäre?

Skysnake

2013-04-05, 01:09:06

Vor allem, warum will ich die GPU-Pipeline leer laufen lassen? Das ist ja das schlimmste was passieren kann. Wenns dumm läuft braucht ja gerade der nächste Fram besonders lange. Damit würde ich mir ja ins eigene Knie schiesen.

Grestorn

2013-04-05, 07:06:32

Skysnake & Gipsel:

Habt ihr den von mir verlinkten Artikel von Andrew Lauritzen überhaupt gelesen? Das ist ja nicht irgendjemand... Andrew Lauritzen @ Twitter (https://twitter.com/AndrewLauritzen)

Natürlich sind die Darstellungen vereinfacht und die angenommenen Bedingungen ideal. Er schreibt ja selbst, dass das Modell von einem GPU Limit ausgeht. Das habe ich nie bestritten. Wäre alles so einfach, würde bei nVidia auch nur eine gerade Linie und keinerlei Varianz auftreten. Es geht um eine Verbesserung, nicht darum es 100% perfekt zu machen. Das ist bei den gegebenen Bedingungen nicht möglich, wie ihr richtig schreibt.

Skysnake behauptet permanent ohne den Hauch eines Beweises oder auch nur eines Hinweises, dass nVidias Methode ernsthafte Nachteile hätte. Was man aber tatsächlich sieht sind nur Vorteile, seine angenommenen Nachteile in Form einer theoretisch etwas höheren Latenz sind zwar sicherlich vorhanden - das bringt das Prinzip mit sich - aber in einer Form die vermutlich in keinster Weise merkbar ist.

Auf die Frage, was mir eine geringfügig bessere Latenz bringt, wenn die gesehene zeitliche Abfolge der Bilder zu weit von der Zeitschiene der Engine abweicht, hat er leider nicht geantwortet.

Ich finde diese Diskussion ermüdend, mir erscheint dass hier vorverurteilt wird mit teils sehr weit hergeholten Argumenten. Und das, obwohl selbst AMD zugibt, dass sie hier etwas versäumt haben. Es scheint also so, dass Skysnake nicht nur besser Bescheid weiß als nVidia sondern auch besser als AMD selbst. Chapeau!

Skysnake

2013-04-05, 09:29:36

Skysnake behauptet permanent ohne den Hauch eines Beweises oder auch nur eines Hinweises, dass nVidias Methode ernsthafte Nachteile hätte. Was man aber tatsächlich sieht sind nur Vorteile, seine angenommenen Nachteile in Form einer theoretisch etwas höheren Latenz sind zwar sicherlich vorhanden - das bringt das Prinzip mit sich - aber in einer Form die vermutlich in keinster Weise merkbar ist.

Meine Fresse, kannst du nicht lesen, oder willst du es nicht?

Ich rede im KONKUNKTIV! Das drückt eindeutig aus, das man es eben NICHT weiß, und genau DAS ist das Problem. Wir wissen es Schlicht NICHT, die Berichte, die man zur subjektiven Wahrnehmen haben sagen aber, dass diese teils abweichen von dem was FCAT anzeigt, also sowohl bei AMD als auch bei nVidia.

Ergo kann man wohl davon ausgehen, dass die wahrscheinlich zusätzliche Latenz bei nVidia eben nicht immer scheis egal ist....

Auf die Frage, was mir eine geringfügig bessere Latenz bringt, wenn die gesehene zeitliche Abfolge der Bilder zu weit von der Zeitschiene der Engine abweicht, hat er leider nicht geantwortet.

Wenn dus noch immer nicht verstanden hast, dann tuts mir leid... Überall wo du gegen Menschen spielst hast du damit einen Nachteil, weil du eben erst etwas später eine Aktion siehst, also auch später reagieren kannst. Siehe hierzu:

Zitat Zitat von Skysnake Beitrag anzeigen
Also nochmal, rein prinzipiell, was würdest du vorziehen als "Profi"Gamer. Einen gleichmäßigen Frameverlauf, und dafür eventuell eine verzögerte Ausgabe um bis zu einen Frame, oder doch lieber ungleichmäßige Frametimes, wo man auch mal ganze Frames praktisch "verliert", dafür aber kein zusätzlicher Lag bei der Ausgabe.

Das ist wirklich eine ernstgemeinte Frage! Und mich interessiert auch gar nichts prinzipielles, sondern einfach nur, was für DICH "besser" wäre.

Für mich ist beides wahrscheinlich Jacke wie Hose, oder gleich schlimm, je nach Sichtweise. Ich werds meist wohl eh nicht merken, ich Glücklicher

Deswegen interessiert mich ja die Meinung eines Menschen, der in ner Liga spielt. Manche Leute sehen ja sogar Unterschiede zwischen nem 60 und 120 Hz Monitor, und empfingen alls was nicht 120Hz ist nur noch als "Dreck" und "unspielbar" :ugly:

Daher auch die wirklich ernst gemeinte Frage, zur persönlichen! Meinung.
Ich brauch beides! :-) Ich habe einen 120Hz Monitor daher sollte wenn möglich die FPS nicht unter 120 fallen und eine verzögerte Ausgabe ist genauso schlimm, da ich ja im dümmsten Moment einen Gegner nicht sofort sehe, er mich aber evtl. schon. Heisst er hat "die Verzögerung" mehr Zeit als ich um zu visieren. Bei mir ist es aber nicht ganz so,(je nach Map)schlimm, da ich für Fahrzeuge zuständig bin und daher nicht jedes Frame sehen muss, wenn ein Inf vor mir rumturnt. Wenn aber etwas schnelleres Jet, Heli vor mir rumfliegt und dann noch eine gewisse Distanz dazu kommt die ich ja noch "berechnen" muss beim Schuss, dann ist es auch wieder wichtig, dass beides stimmt. :-)

Kurz um, man braucht beides. flüssige Frames UND kein zusätzlicher lag, denn beides kann sehr nachteilig sein.

Ist halt die gleiche Frage, warum Leute nicht USB, sondern PS2 nehmen. Ist doch das Gleiche. Für mich ja, für dich wahrscheinlich auch, aber es gibt genug Leute, die dich lynchen würden für die Aussage. Ich nehm einfach nur zur Kenntnis, das es solche Leute gibt, auch wenn ich Sie NICHT verstehen kann. Du sagst praktisch: Die sind dumm.

Ich finde diese Diskussion ermüdend, mir erscheint dass hier vorverurteilt wird mit teils sehr weit hergeholten Argumenten. Und das, obwohl selbst AMD zugibt, dass sie hier etwas versäumt haben. Es scheint also so, dass Skysnake nicht nur besser Bescheid weiß als nVidia sondern auch besser als AMD selbst. Chapeau!
Nein, es wird eben nur endlich wirklich zumindest im Ansatz in dem Detailgrad über die Thematik geredet, die auch mindestens erforderlich. Man sollte einfach NICHT zu genau hinsehen, denn da wartet schnell der Wahnsinn...

boxleitnerb

2013-04-05, 09:44:54

Hast du selbst SLI und hast es mal selbst ausprobiert? Vielleicht gibt es tatsächlich einen messbaren Lag, aber spürbar ist er zumindest hier nicht mit 2 GPUs. Im Gegensatz dazu ist sofort ersichtlich, wenn VSync dazukommt. Einen Profi-Spieler mag es vielleicht stören, aber ich denke du übertreibst hier wieder mal maßlos. Es gibt genug Leute mit SLI, die auch schnelle Shooter spielen. Wäre es wirklich spürbar und so schlimm wie du hier tust, wäre das längst rausgekommen.

Grestorn

2013-04-05, 09:47:35

Skysnake, Du hast selbst von "Weißglut" gesprochen. Du hast die Artikel und das Verfahren mit sehr deutlichen Worten verurteilt, ja nVidia sogar durchaus absichtliche Manipulation vorgeworfen.

Jetzt spiel das nicht auf einmal runter, nur weil Dir die Argumente ausgehen!

Aber es scheint Dich ja offensichtlich mehr zu befriedigend, mir immer wieder mangelndes Verständnis vorzuwerfen. Soll der geneigte Leser selbst entscheiden wer hier die kompetenteren Argumente aufzeigt :)

Cyphermaster

2013-04-05, 10:18:26

kommt. mal. runter.

Das geht nach 2x Durchatmen sicher auch weniger emotional und freundlich-sachlicher.

Angiesan

2013-04-05, 10:59:51

Hmmm Skysnake,

ich habe dir im HWLuxx schon erklärt wie das Frammetering angeblich bei NV funktionieren soll. Das lehnt sich sehr nah an das an was Gipsel geschrieben hat nur nicht so professionell formuliert wie Gipsel, da ich weder Programmiere wie du noch Fachmann in welchem Bereich auch immer wie Gipsel bin, Noch soweit drin stecke wie Grestorn der von seinem Fachwissen mir auch meilenweit überlegen ist.
Aber ich habe 2 private Kontakte zu NV in den USA und man will es nicht glauben die Jungs spielen auch ;-).
Ich hatte die Möglichkeit ein paar Information über SLI zu erfragen und dabei kam dieses gare Halbwissen heraus.

Soweit ich das richtig interpretiere ist Grestorn mit seiner Vermutung der Frameausgabe nicht so weit weg, nur das sich hier ein anderes Problem einstellt, es besteht angeblich eine Target Framelatenzen unter 10 MS zu erreichen das hat aber denn Nachteil das man angeblich den Present-Call eben nicht belibig lange verzögert bis man denkt jetzt passt es. Im Cpu-Limit können die Probleme kurzfristig sogar schlimmer sein wie wenn man überhaupt nicht eingreifen würde weil man genau das bekommt was man heute recht oft bei AMD sieht, dieses Heartbeatstottern. Dies kann dann sogar kurzfristig heftiger ausfallen wie wenn nicht eingegriffen würde.
Woran dies liegt, kann ich dir nicht sagen, da die Jungs wohl eh schon mehr gesagt haben wie sie normalerweise dürfen. Nur so viel NV hat hier wohl eine Latenzobergrenze festgelegt und wenn die Information stimmen sollte sind dies 10 ms. Gipsel und wohl auch Du sowie Grestorn ihr könntet sicherlich mit den Informationen viel mehr anfangen wie ich aber ich kann hier leider nicht vermitteln. Hinzu kommt, dass es wohl sowas wie eine Automatik gibt die In HW arbeitet wie diese genau funktioniert scheint aber ein gut gehütetes Geheimnisse bei NV zu sein es hat aber wohl auch was mit der Boostfunktion zu tun und angeblich kann man dies aufgrund des Abfrageintervalls nicht mit herkömmlichen Tools auslesen.
Es soll auch Unterschiede zwischen SLI und SLI geben das intern am weitesten und fortschrittlichste System ist angeblich auf oder in der GTX 690 verbaut. Alle anderen Lösungen sind HW Technisch weniger anspruchsvoll was nicht gleichbedeutend mit schlechter ist. Das kannst du jetzt glauben oder sein lassen eine andere Wahl hatte ich ja auch nicht, warte mal ab es soll was kommen was bäng macht.

Grüße

Skysnake

2013-04-05, 11:27:17

Schoen und gut, nur wissen wir es eben nicht ;)

Und genau das ist doch das Problem. Wir wisen praktisch nichts, uns wird aber suggeriert wir haetten jetzt die TOTALE Information, was einfach nich stimmt. Gipsel und ich sagen so ziemlich das identische, er drueckt sich nur einfacher/besser aus. Ich weiss echt nicht, was Grestorn dann fuer ein Problem mit dem was ich sage habe, zumal ich eben hauptsachelich den Informationsmangel kritisiere, und eventuelle Schwachstellen/Trickserei aufzeige. Ob es so ist, muss sich erst zeigen, es ist aber schon verwunderlich, warum man nicht gleich FCAT richtig angeht.

Gipsel und ich sind uns ja recht einige darueber, das mein Vorschlag funktionieren sollte und eben auch die von mir gennanten Problemfelder abdeckt. Bis wir wissen, ob es zutrifft oder nicht, sollte man auf jeden Fall nicht so tun, als ob es die Problemfelder nicht gaebe, und nVidia Sie auch nicht ausnutzen wuerde. Man muss einfach festhalten, das wir es NOCH nicht wissen.

Auf den Quellcode von FCAT warte ich uebrigends noch immer...
PS: bei PCGH ist in den naechsten Tagen ein nVidia Mensch fuer eine Q&A Runde. Den koennte man bzgl der Problematik mal die Pistole auf die Brust setzen.

Gipsel

2013-04-05, 11:47:06

Skysnake & Gipsel:

Habt ihr den von mir verlinkten Artikel von Andrew Lauritzen überhaupt gelesen? Das ist ja nicht irgendjemand... Andrew Lauritzen @ Twitter (https://twitter.com/AndrewLauritzen)Ich weiß natürlich, wer das ist. Und in einem Teil meiner Argumentation beziehe ich mich auch auf seine Argumente. ;)
Natürlich sind die Darstellungen vereinfacht und die angenommenen Bedingungen ideal. Er schreibt ja selbst, dass das Modell von einem GPU Limit ausgeht. Das habe ich nie bestritten.Siehst Du, und ich habe mal in den Raum gestellt, was denn passiert, wenn die Bedingungen nicht so ideal sind, also man z.B. nicht im absoluten GPU-Limit klebt (selbst im GPU-Limit läuft bei einem in FRAPS sichtbaren Spike wie gesagt die Queue leer[er], so daß die Mechanismen versagen).
Wäre alles so einfach, würde bei nVidia auch nur eine gerade Linie und keinerlei Varianz auftreten. Es geht um eine Verbesserung, nicht darum es 100% perfekt zu machen. Das ist bei den gegebenen Bedingungen nicht möglich, wie ihr richtig schreibt.Siehst Du, ich bin bereits einen Schritt weiter und überlege, wie man es noch besser machen kann und die momentanen Schwachstellen angeht. Wenn Du es so interpretierst, ich würde sagen, daß sei nicht möglich, dann mißverstehst Du mich gründlich. Ich habe gesagt, es sei nicht so einfach daß im Treiber alleine hinzubiegen. Man benötigt optimalerweise ein gutes Zusammenspiel von Engine, DX/OS und Treiber. Aber selbst im Treiber kann man eventuell noch mehr bzw. es besser machen als es momentan beim Framemetering von nV passiert.
Als Beispiel habe ich so einen "Schluckauf" der Frametimes wie von FRAPS gemessen angeführt. Wenn Du mal Andrew Lauritzens Argumente (die auch im TR-Artikel aufgeführt sind) durchdenkst, dann kommst Du darauf, daß eben nicht eine gleichmäßige Ausgabe (die sich bei einer einzelnen GPU im GPU-Limit durch das Queueing oft von ganz alleine einstellt) das beste Ergebnis liefert, weil die Zeitsprünge der Engine ungleichmäßig sind. Andrew Lauritzen sagt (genau wie ich) daß die Zeitabstände der Ausgabe der Frames mit der Größe der Zeitschritte in der Engine zusammenpassen müssen, ansonsten hat man einen Judder-Effekt bei Bewegungen. Und hier kann es etwas tricky für den Treiber werden zu wissen, welches Frame genau er verzögern muß, um das zu kompensieren (den flüssigsten Eindruck für diesen Fall erhält man durch eine passende, ungleichmäßige Frameausgabe!), aber es ist nicht generell unmöglich (man kann es vermutlich durch Profiling und Analyse des Spiels zu einen hohen Prozentsatz richtig "erraten"). Daß das Optimum wäre, daß die Engine die Frames schon mal gleich komplett ohne Spikes liefert, bleibt ja trotzdem wahr.

Soweit ich das richtig interpretiere ist Grestorn mit seiner Vermutung der Frameausgabe nicht so weit weg, nur das sich hier ein anderes Problem einstellt, es besteht angeblich eine Target Framelatenzen unter 10 MS zu erreichen das hat aber denn Nachteil das man angeblich den Present-Call eben nicht belibig lange verzögert bis man denkt jetzt passt es. Im Cpu-Limit können die Probleme kurzfristig sogar schlimmer sein wie wenn man überhaupt nicht eingreifen würde weil man genau das bekommt was man heute recht oft bei AMD sieht, dieses Heartbeatstottern. Dies kann dann sogar kurzfristig heftiger ausfallen wie wenn nicht eingegriffen würde.Dann verzögert man offenbar den falschen Frame bzw. schiebt im schlimmsten Fall sogar eine Art "Bugwelle" von verzögerten Frames vor sich her (weil sich eine Verzögerung eventuell auch auf den Frame n+2 auswirkt, der dann verspätet in die Pipeline kommt). Hier gilt es, die verwendeten Algorithmen zu optimieren (in Verbindung mit Spielprofilen), auch wenn ich eigentlich eher ein Fan davon bin, daß die Engines selber auf eine gleichmäßige Frameausgabe achten, womit man das Problem näher an der Wurzel packt (aber wie gesagt, kann das bei AFR nicht ausreichend sein, wenn der Treiber rumspinnt).

Skysnake

2013-04-05, 12:31:05

Jup, in den Engines ist der best Ansatzpunkt.

Eine nette Idee waere natuerlich das FCAT prinzip inkl zeitabhaengiger Einfaerbung zu nutzen um Information ueber die Engine zu erhalten fuer den Treiber. Der koennte ja einfach das Bild 1 Pixel breiter machen.

Grestorn

2013-04-05, 12:34:29

Die Engine hat keine Möglichkeit festzustellen, wann ein Bild tatsächlich zur Anzeige kommt. Deswegen kann man das Problem doch auch gar nicht messen, ohne einen Zweitrechner danebenzustellen, der den Output mitfilmt.

Man müsste Direct3D um eine passende Möglichkeit erweitern, Einblick in das Timing zu erhalten. Erst dann wäre es möglich, dass sich die Engine daran anpasst. Aber das wäre für die Engineprogrammierer trotzdem ein irrer Aufwand.

Nur der Treiber kann in gewissen Grenzen (also nur wenn present() blockt, also ein GPU Limit vorliegt) versuchen das Timing so zu steuern, dass die Frames in einer möglichst gleichmäßigen Zeitfolge ausgeben werden und auch die presents() parallel dazu gleichmäßig abgeschlossen werden, so dass auch die Engine die selbe gleichmäßige Zeitfolge als Rückmeldung bekommt. Wobei sich letzteres dann eigentlich fast von selbst ergibt.

Skysnake

2013-04-05, 12:43:58

Es waere ein leichtes GPUs um die Faehigkeit zu bereichern, zu erkennen, wann ein neues Bild in den Buffer geschrieben wird, und dann eben einen CPU-Interrupt aus zu loesen. Wahrscheinlich ist das bereits heute moeglich, man muesste nur die Treiber anpassen.

Godmode

2013-04-05, 12:58:37

M4xw0lf

2013-04-05, 13:14:13

Dieser Thread ist durch die ewigen Grabenkämpfe wirklich ermüdend zu lesen geworden über die letzten Seiten.

Skysnake

2013-04-05, 13:33:16

Und das wäre dir dann transparent genug, ohne dass der Treiber wirklich offen gelegt wird?
Bzgl was?

Es waere nur ein "Werkzeug", mit dem Engineentwickler sich dem Problem der Rockler besser annehmen koennten, da Sie eben mehr informationen bekommen, und damit zumindest das auseinanderlaufen von Gametime und Ausgabezeit verhindern koennten, bze zumindest besser angehen.

Gipsel

2013-04-05, 13:39:22

Die Engine hat keine Möglichkeit festzustellen, wann ein Bild tatsächlich zur Anzeige kommt.Aber sie hat Kontrolle darüber, wie groß die Zeitschritte in der Engine sind und wann sie die Drawcalls absetzt. Und ich dachte wir sind uns inzwischen einig, daß dies möglichst auch gleichmäßig passieren sollte ;). Der Treiber müßte dann "nur" noch drauf achten, nicht auch noch zusätzliche Spikes einzuführen bzw. die eventuell trotzdem auftretenden Spikes der Engine vielleicht dann doch noch durch Verzögerung einzelner Frames (im Idealfall ohne die Queue zu blockieren, weil die Engine das selber handhabt) zu kompensieren.

MadManniMan

2013-04-05, 13:45:03

Können wir mal kurz konsensuell zusammenfassen?

1) Enginezeit und Displayzeit laufen aus verschiedenen Gründen mal regelmäßig, mal unregelmäßig auseinander, was die gefühlte Framerate verglichen mit den FRAPS-FPS verringert.

2) Vor allem bei MGPU-AFR-Methoden und hierbei insbesondere bei solchen ohne Frame-Metering ist dieser Effekt zu beobachten.

2a) Hierbei ist nicht ganz klar, ob Frame-Metering das subjektive Spielgefühl über die irgendwann nötige künstlich eingefügte Latenz hinaus verbessert.

3) SGPU-Szenarien haben in verschiedenen Engines (Far Cry 3?) bzw. in verschiedenen Setups (Techreport, mein Laptop mit Geforce Go 6600 anno 2005) ebenso mit diesen Problemen zu kämpfen, jedoch nach bisheriger Erkenntnislage weit weniger oft, als MGPU-Systeme.

4) FRAPS kann technisch bedingt die meisten "Runts" und "Drops" nicht messen, FCAT jedoch schon. FCAT ist daher die bessere Methode für das Erfassen ungleichmäßiger Frame-Ausgabe, kann jedoch technisch bedingt nicht nachweisen, dass die Gleichmäßigkeit der Frame-Ausgabe auch mit einer ebenso gleichmäßigen Engine-Zeit korrespondiert.

5) Der - momentan nicht vorhandene - Königsweg wäre eine Rückkopllung zwischen FCAT-äquivalenten Messmethoden und der Engine-Zeit.

---

Soweit richtig?

Blediator16

2013-04-05, 13:49:07

Man kann auch einen Test während einer größeren Expo machen, wo man zufällig ausgewähle Leute das selbe auf beiden Karten spielen lässt und dann wird entschieden was einem besser gefällt.

Aus der SGPU Sache wird scheinbar ein größeres Fass aufgemacht, als es nötig ist.

Gipsel

2013-04-05, 14:44:01

5) Der - momentan nicht vorhandene - Königsweg wäre eine Rückkopllung zwischen FCAT-äquivalenten Messmethoden und der Engine-Zeit.

---

Soweit richtig?Ja. Man könnte aber z.B. den Zeitstempel der Presents (was Fraps mißt und oft ein halbwegs gutes Maß für die Zeitschritte der Engine sind [aber evetuell mit einem Frame Offset, und einige Engines glätten noch darüber]) direkt in die Farbe des Balkens des Overlays umsetzen. Dann mißt man praktisch für jedes Frame beides (also im Prinzip die Variabilität der Zeitdauer zwischen Present und den eigentlichen Bufferflips) auf einmal. An die Zeitnahme der Gameengine selber kommt man ja erstmal nicht ohne Weiteres ran.

Hübie

2013-04-05, 16:23:00

Kann man nicht in einem Zeitintervall den frames einfach einen Stempel mit fortlaufender Nummer aufdrücken? =)

Edit: Der Intervall wiederholt sich natürlich fortlaufend.

Gipsel

2013-04-05, 16:26:55

Kann man nicht in einem Zeitintervall den frames einfach einen Stempel mit mit Nummer aufdrücken? =)

Edit: Der Intervall wiederholt sich natürlich fortlaufend.
Das liest sich etwas schwerer automatisiert ein, man muß dann ja eine Zeichenerkennung machen. Ist das in der Farbe kodiert, dann kann man zwar als Mensch das nicht direkt lesen, ein Skript kann jedoch den Binärwert direkt als den Wert des Zeitstempels interpretieren (und in eine Tabelle schreiben).

Godmode

2013-04-05, 16:58:02

Vor allem wäre eine Zeichenkette sicher teuer, als einfach nur ein farbiges Quad.

Grestorn

2013-04-05, 16:59:10

Und das Problem mit einer Nummer ist, dass man ja ncht weiß welcher Teil des Bildes sichtbar wird. Es können ja nur weniger Zeilen sein.

Die Farbleiste am linken Rand ist simpel und eindeutig. Da man die Farbsequenz kennt, weiß man auch immer, wenn ein Frame komplett fehlt.

N0Thing

2013-04-05, 18:06:42

Schoen und gut, nur wissen wir es eben nicht ;)

Und genau das ist doch das Problem. Wir wisen praktisch nichts, uns wird aber suggeriert wir haetten jetzt die TOTALE Information, was einfach nich stimmt.

Kannst du für die Behauptung mal nen Link posten? Die totale Information ist an mir nämlich total vorbei gegangen. Ich lesen immer nur, daß noch mehr Daten und weitere Interpretationsmethoden notwendig sind, damit man genauere Aussagen über die Messergebnisse treffen kann.

Auf den Quellcode von FCAT warte ich uebrigends noch immer...

Wow, ich hätte ja nicht gedacht, daß die an einen Externen den Quellcode rausgeben würden. :eek: Wie hast du deine Quelle dazu überreden können?

Skysnake

2013-04-05, 19:12:48

Können wir mal kurz konsensuell zusammenfassen?

1) Enginezeit und Displayzeit laufen aus verschiedenen Gründen mal regelmäßig, mal unregelmäßig auseinander, was die gefühlte Framerate verglichen mit den FRAPS-FPS verringert.

Kann muss aber nicht. Es kommt immer darauf an, was die Engine wiederum macht. Prinzipiell sollte es wohl ganz gut hinhauen.

2) Vor allem bei MGPU-AFR-Methoden und hierbei insbesondere bei solchen ohne Frame-Metering ist dieser Effekt zu beobachten.

Wissen wir schlicht nicht. Kann sein, das alle "Ruckler" die man bei nVidia sieht eben auf die Verschiebung der Zeiten herrührt. Dann wäre die Lösung unterm Strich "genau so" (auch) schlecht. SLI ist ja auch weit davon entfernt perfekt zu sein.

2a) Hierbei ist nicht ganz klar, ob Frame-Metering das subjektive Spielgefühl über die irgendwann nötige künstlich eingefügte Latenz hinaus verbessert.

Oder verschlechter. Exakt, man weiß es schlicht nicht.

3) SGPU-Szenarien haben in verschiedenen Engines (Far Cry 3?) bzw. in verschiedenen Setups (Techreport, mein Laptop mit Geforce Go 6600 anno 2005) ebenso mit diesen Problemen zu kämpfen, jedoch nach bisheriger Erkenntnislage weit weniger oft, als MGPU-Systeme.

Das kann aber GANZ andere Gründe haben. Man weiß nie so genau, was noch alles meint, es müsste irgendwas auf der GPU machen. Allein nen Desktop anzeigen oder sonst was hat teilweise EXTREME Einflüsse auf die Leistungsfähigkeit einer GPU.

Bei unseren Latenztests im Geschäft verwenden wir z.B. ne extra GPU zur Darstellung der Ergebnisse/Desktops. Dadurch sind die Ergebnisse viel besser!

4) FRAPS kann technisch bedingt die meisten "Runts" und "Drops" nicht messen, FCAT jedoch schon. FCAT ist daher die bessere Methode für das Erfassen ungleichmäßiger Frame-Ausgabe, kann jedoch technisch bedingt nicht nachweisen, dass die Gleichmäßigkeit der Frame-Ausgabe auch mit einer ebenso gleichmäßigen Engine-Zeit korrespondiert.

Und da eben beides wichtig ist, ist FCAT auch nicht besser als FRAPS. Wenn ich so nen wesentlichen Teil einfach mal ignoriere, dann bringts mir auch nichts, wenn ich wo anders super duper genau bin. Die Werte sind damit einfach wertlos.

5) Der - momentan nicht vorhandene - Königsweg wäre eine Rückkopllung zwischen FCAT-äquivalenten Messmethoden und der Engine-Zeit.

Ja, aber das wird man kaum hinbekommen, daher wäre der meiner Meinung nach einzige Weg wirklich der, nicht ne statische Farbtabelle zu nehmen, sondern eben das entsprechend einer Zeitmessung einzufärben, so wie ich es schon länger vorschlage.

Soweit richtig?
Im Großen und Ganzen ja.

Kannst du jetzt nachvollziehen was ich die ganze Zeit schon sage?

Ja. Man könnte aber z.B. den Zeitstempel der Presents (was Fraps mißt und oft ein halbwegs gutes Maß für die Zeitschritte der Engine sind [aber evetuell mit einem Frame Offset, und einige Engines glätten noch darüber]) direkt in die Farbe des Balkens des Overlays umsetzen. Dann mißt man praktisch für jedes Frame beides (also im Prinzip die Variabilität der Zeitdauer zwischen Present und den eigentlichen Bufferflips) auf einmal. An die Zeitnahme der Gameengine selber kommt man ja erstmal nicht ohne Weiteres ran.
Meine Rede, was anderes ist mir bisher auch nicht wirklich eingefallen. Ohne Zugriff auf die Engine, oder den Treiber sind die Möglichkeiten SEHR begrenzt.

Kann man nicht in einem Zeitintervall den frames einfach einen Stempel mit fortlaufender Nummer aufdrücken? =)

Edit: Der Intervall wiederholt sich natürlich fortlaufend.
Nein, das ist ja im Prinzip genau das Gleiche, was man jetzt auch schon bei FCAT macht, und es reicht schlicht nicht. Du brauchst ziwngend die Information zu den relativen Zeiten drin.

Kannst du für die Behauptung mal nen Link posten? Die totale Information ist an mir nämlich total vorbei gegangen. Ich lesen immer nur, daß noch mehr Daten und weitere Interpretationsmethoden notwendig sind, damit man genauere Aussagen über die Messergebnisse treffen kann.

Du hast also nicht mitbekommen, das FCAT das ultimative Werkzeug sein soll, um das Spielgefühl darzustellen? Und vor allem auch mit "wissenschaftlich untermauerten Methoden" (Zitat THG) arbeitet? Dann tuts mir echt leid..

Wow, ich hätte ja nicht gedacht, daß die an einen Externen den Quellcode rausgeben würden. :eek: Wie hast du deine Quelle dazu überreden können?
Nein habe ich nicht bekommen, aber es wird ja davon gesprochen, dass die Sachen Quelloffen wären. Bisher kann ich das aber noch nicht feststellen. Aber mal schauen, ich erwarte für nächste Woche ein Gespräch mit THG, um das mal zu klären. Derjenige, der den Artikel geschrieben hat, ist leider schon im Wochenende.

StefanV

2013-04-05, 19:33:35

Desweiteren hat NV seit dem NV40/G70-AF technisch nicht mehr gecheatet (Namenskuddelmuddel zählt nicht, da nehmen sich beide nix)
Und wie würdest du die falsche Information zu D3D11.1 bezeichnen?

Sorry, aber nVidia ist nicht gerade ein Laden, der besonders vertrauenswürdig wäre. Ganz im Gegenteil!
Das ist eher ein Linker Laden, der alles versucht, um halbwegs brauchbar da zu stehen und 'den anderen' 'nen Dolch in den Rücken zu stecken...
Und wenn doch, bedeutet das etwa, das ein X79 System völlig ungeeignet ist für Multi-GPU??? DAS wäre doch eine OMFG-WTF DIE WELT GEHT UNTER!!!!111einself Nachricht wert. Gerade High-End-Multi-GPU user setzen ja eher auf S2011.
THG hat den Ruf eine erweiterte Marketing Abteilung von Intel zu sein.

Ich erinnere mich da noch an den Stunt bezüglich der 'Zuverlässigkeit' von AMD und Intel Systemen, zu Zeiten des Pentium Ds. Bei diesem 'Test' ist so ziemlich alles schief gegangen, was schief gehen konnte - zum Glück!
Denn so war am Ende AMD zuverlässiger als Intel...

Gibt noch einige anderer solcher Böcke von denen...

Ronny145

2013-04-05, 19:42:18

THG hat den Ruf eine erweiterte Marketing Abteilung von Intel zu sein.

Schon lange nicht mehr. Abgesehen von ein paar zurückgebliebenen.

MadManniMan

2013-04-05, 21:05:11

Wissen wir schlicht nicht. Kann sein, das alle "Ruckler" die man bei nVidia sieht eben auf die Verschiebung der Zeiten herrührt. Dann wäre die Lösung unterm Strich "genau so" (auch) schlecht. SLI ist ja auch weit davon entfernt perfekt zu sein.

a) Es geht mir nicht konkret um Nvidia, AFR gab es auch mal von XGI.

b) Wenn Metering Verschiebungen einfügt, dann nicht bei jedem Frame. Und selbst wenn: auch Frames mit verglichen zum vorherigem Frame anderen Enginezeit-Spielezeit-Delta, aber immerhin dargestellt, verbessern das Flüssigkeitsgefühl.

Oder verschlechter. Exakt, man weiß es schlicht nicht.

Du könntest Dich auch echt mal bemühen, statt beständig weiterer gefärbter Spekulationen den Gedanken rational weiter zu spinnen.

Das kann aber GANZ andere Gründe haben. Man weiß nie so genau, was noch alles meint, es müsste irgendwas auf der GPU machen. Allein nen Desktop anzeigen oder sonst was hat teilweise EXTREME Einflüsse auf die Leistungsfähigkeit einer GPU.

Bei unseren Latenztests im Geschäft verwenden wir z.B. ne extra GPU zur Darstellung der Ergebnisse/Desktops. Dadurch sind die Ergebnisse viel besser!

Hat das auch nur irgendwas mit meiner Aussage zu tun?

Und da eben beides wichtig ist, ist FCAT auch nicht besser als FRAPS. Wenn ich so nen wesentlichen Teil einfach mal ignoriere, dann bringts mir auch nichts, wenn ich wo anders super duper genau bin. Die Werte sind damit einfach wertlos.

???

Also können wir jetzt überhaupt nicht mehr benchen.

Ja, aber das wird man kaum hinbekommen, daher wäre der meiner Meinung nach einzige Weg wirklich der, nicht ne statische Farbtabelle zu nehmen, sondern eben das entsprechend einer Zeitmessung einzufärben, so wie ich es schon länger vorschlage.

Moment, wird man es jetzt hinbekommen oder nicht?

Kannst du jetzt nachvollziehen was ich die ganze Zeit schon sage?

Nein, kann ich nicht. Weil Du außer der für mich nicht nachvollziehbaren Kritik an FCAT, welches Du auf die gleiche Stelle wie FRAPS setzt, nichts anderes sagst, als ich. Naja und dass Du außerdem ständig betonen musst, dass Nvidia bestimmt auch ganz dolle böse ist.

Ehrlich jetzt: hast Du Aktien von dem anderen Verein oder beziehst Du irgendwie Kohlen? Wir hatten schon öfter, dass bezahlte Leute hier herumgelaufen sind und ihren irritierend einseitigen Kram verbreitet haben.

samm

2013-04-05, 22:10:28

Och MadManniMann, beginn doch nicht auch noch zu zerpflücken, so wird die angenehm vernünftig lesbare Stimme in diesem Thread wieder erschwert ;)

Da ich ja seit Anbeginn *hust* der Meinung bin, dass zur Thematik Ruckeln und Spielgefühl wichtige Information verloren geht durch fehlendes Timestamping resp. fehlende Messbarkeit von [t_display - t_present] finde ich Gipsels und Skysnakes Anliegen sehr unterstützenswert. Es ist schade, wenn die eigentlichen Punkte im gegenseitigen Zerpflücken untergehen.

Ich will nur schnell auf das hier eingehen:Moment, wird man es jetzt hinbekommen oder nicht?Ihr redet da von etwas leicht anderem. Skysnakes zweiter Teil der Antwort beinhaltet eben keine Rückkopplung zur Engine, was für das Zusammenspiel von "gleichmässiger Ausgabe des Treibers" und "Game-Engine" wichtig wäre, sondern geht erst vom Zeitpunkt t_present aus. Es geht darin um die Messung des genannten Lags zwischen present und display (Skysnakes Posting: pragmatischer Vorschlag zur Verbesserung von FCAT), während man durch die Rückkopplung zwischen display-Zeitpunkt auf Engine ein besseres Spielerlebnis erzeugen könnte. Speziell, wenn die Engine dafür sorgt, dass sie gleichmässig presents hervorruft (MadManniManns Posting: idealer Vorschlag zur Optimierung eines Spielerlebnisses).
Ist damit diese Diskrepanz erklärt? :)

Und das Problem mit einer Nummer ist, dass man ja ncht weiß welcher Teil des Bildes sichtbar wird. Es können ja nur weniger Zeilen sein.

Die Farbleiste am linken Rand ist simpel und eindeutig. Da man die Farbsequenz kennt, weiß man auch immer, wenn ein Frame komplett fehlt.Richtig. Und wenn man jetzt erstens mehr Farben nutzen würde (weshalb nutzt man nicht 8bit pro Kanal?), festhalten würde, wann die erste Farbe gesetzt wird, und die nachfolgenden zeitgesteuert setzen würde, hätte man eben ein Timestamping. Was verloren ginge, wäre die Information zu dropped frames, aber runt frames würde man noch immer erkennen. Dropped frames sind letztlich nicht soo relevant, weil erstens ja gerade nur die genügend sichtbaren Frames relevant sind - *die* grosse Erkenntnis durch FCAT - und man ja den Unterschied immer noch mit einer separaten fraps-Messung erstellen könnte. Oder man macht beides mit FCAT: Dank automatischer Auswertung kann man auch einfach ein (oder x) Pixel breit die "timestamp"-Farbe einfügen, daneben ein (oder x) Pixel breit die Frame-Abfolge-Farbe wie bisher, mit der sich die dropped frames wie bisher feststellen lassen.

Da fällt mir ein: Was natürlich ultimativ wäre: Wenn man Fraps *nach* dem Overlay-Teil von FCAT zusätzlich in die Pipline hängen könnte, könnte man mit einer reinen Fraps-Messung und einer [FCAT + Fraps]-Messung den Einfluss von FCAT auf die Framerate beurteilen, oder umgekehrt :ugly: Keine Ahnung, ob so etwas umsetzbar ist, oder die Summe der beiden Overheads dann doch zu gross und die ganze Pipeline unberechenbar beeinflussen würden.

N0Thing

2013-04-05, 22:37:31

Du hast also nicht mitbekommen, das FCAT das ultimative Werkzeug sein soll, um das Spielgefühl darzustellen? Und vor allem auch mit "wissenschaftlich untermauerten Methoden" (Zitat THG) arbeitet? Dann tuts mir echt leid..

Das ist was anderes als die totale Information, von der du in dem von mir zitierten Post geschrieben hast. Das FCAT (in Verbindung mit dem gesamten Versuchsaufbau) ein bessere Tool sein soll als FRAPS habe ich mitbekommen und verstehe auch, wie man zu diesem Schluß gelangen kann. Ebenso kann ich verstehen, wie man das nun vorgestellte Verfahren als wissenschaftliche Methode bezeichnen kann. Wissenschaft zeichnet sich nicht dadurch aus alles perfekt zu machen, sondern Antworten auf Fragen zu suchen und den Weg dort hin offen zu legen. Ja, der Quellcode ist nicht für alle einsehbar, aber von der Fragestellung über den Versuchsaufbau bis hin zu den Ergebnissen ist alles offen gelegt und für die Beteiligten ist auch der Quellcode einsehbar und es wird hoffentlich in absehbarer Zeit eine Lösung ohne Beteiligung von Nvidia geben.

Nein habe ich nicht bekommen, aber es wird ja davon gesprochen, dass die Sachen Quelloffen wären. Bisher kann ich das aber noch nicht feststellen. Aber mal schauen, ich erwarte für nächste Woche ein Gespräch mit THG, um das mal zu klären. Derjenige, der den Artikel geschrieben hat, ist leider schon im Wochenende.

Scheinbar hast du meinen Beitrag dazu geflissentlich ignoriert, denn dort habe ich dir ausführlich genug dargelegt, daß FCAT nicht quelloffen im Sinne von open source ist. Ich kann mich nur wiederholen: Dafür, daß du so sehr auf dem Begriff der wissenschaftlichen Methode herum reitest, schaffst du es nahezu perfekt alles zu ignorieren, was deinen Thesen und Behauptungen widerspricht.
Solange du das nicht in den Griff bekommst, werde ich deine Beiträge ignorieren, spart mir Zeit und dem Thread unnötige Beiträge. :)

Marty98

2013-04-05, 22:40:08

Und wie würdest du die falsche Information zu D3D11.1 bezeichnen?

Sorry, aber nVidia ist nicht gerade ein Laden, der besonders vertrauenswürdig wäre. Ganz im Gegenteil!.

Alle 11.1 Sachen die ein Spiel verwenden könnte sind doch bei NVidia mit dabei, oder? Ich dachte nur ein paar 2D Sachen wurden ausgelassen.

Skysnake

2013-04-05, 23:04:50

Richtig. Und wenn man jetzt erstens mehr Farben nutzen würde (weshalb nutzt man nicht 8bit?), festhalten würde, wann die erste Farbe gesetzt wird, und die nachfolgenden zeitgesteuert setzen würde, hätte man eben ein Timestamping. Was verloren ginge, wäre die Information zu dropped frames, aber runt frames würde man noch immer erkennen. Dropped frames sind letztlich nicht soo relevant, weil erstens ja gerade nur die genügend sichtbaren Frames relevant sind - *die* grosse Erkenntnis durch FCAT - und man ja den Unterschied immer noch mit einer separaten fraps-Messung erstellen könnte. Oder man macht beides mit FCAT: Dank automatischer Auswertung kann man auch einfach ein (oder x) Pixel breit die "timestamp"-Farbe einfügen, daneben ein (oder x) Pixel breit die Frame-Abfolge-Farbe wie bisher, mit der sich die dropped frames wie bisher feststellen lassen.

Nein, die Info muss man nicht verlieren ;)
Man kann ziemlich einfach an der Stelle wo man auch den Overlay macht, einfach den Wert des Overlays in ein Array speichern, das man vorher initialisiert hat. Das kostet faktisch nichts. Das ist 1 Wert in nen Array schreiben. :ugly:

Das ist so simpel, simpler geht gar nicht. Damit hätte man jeden gedroppten Frame erfasst, würde auch sehen, wenn man z.B. was nicht mit aufzeichnet, und hätte auch eine sichere Kontrolle, ob die Treiber nicht meinen, Sie müssen an den Overlay-Farbwerten rumpfuschen. ;) Also doppelte Absicherung.

Das ist totgal trivial.

Das ist was anderes als die totale Information, von der du in dem von mir zitierten Post geschrieben hast. Das FCAT (in Verbindung mit dem gesamten Versuchsaufbau) ein bessere Tool sein soll als FRAPS habe ich mitbekommen und verstehe auch, wie man zu diesem Schluß gelangen kann. Ebenso kann ich verstehen, wie man das nun vorgestellte Verfahren als wissenschaftliche Methode bezeichnen kann. Wissenschaft zeichnet sich nicht dadurch aus alles perfekt zu machen, sondern Antworten auf Fragen zu suchen und den Weg dort hin offen zu legen. Ja, der Quellcode ist nicht für alle einsehbar, aber von der Fragestellung über den Versuchsaufbau bis hin zu den Ergebnissen ist alles offen gelegt und für die Beteiligten ist auch der Quellcode einsehbar und es wird hoffentlich in absehbarer Zeit eine Lösung ohne Beteiligung von Nvidia geben.

Wir wissen eigentlich fast nichts. Die Messdaten sind nicht zugänglich, bei THG wissen wir nicht was denn nun mit X79 ist, was dazu führt, das man die Werte von PCpen auch in Frage stellen muss. usw usw.

Das ist das reinste guddelgemuddel, wo man nichts validieren kann.

Und sorry, dass der Quellcode bei sowas nicht einsehbar ist, ist keine kleine Sache, sondern ein eklatanter Missstand!

Scheinbar hast du meinen Beitrag dazu geflissentlich ignoriert, denn dort habe ich dir ausführlich genug dargelegt, daß FCAT nicht quelloffen im Sinne von open source ist. Ich kann mich nur wiederholen: Dafür, daß du so sehr auf dem Begriff der wissenschaftlichen Methode herum reitest, schaffst du es nahezu perfekt alles zu ignorieren, was deinen Thesen und Behauptungen widerspricht.
Solange du das nicht in den Griff bekommst, werde ich deine Beiträge ignorieren, spart mir Zeit und dem Thread unnötige Beiträge. :)
Sag das den Leuten/Redaktionen, die nicht schaffen die Berifflichkeiten sauber zu trennen. Ich beziehe mich nur darauf, was einem großmotzig verkündet wird, was man denn tolles mit FCAT hätte. Wenn man aber eben das einfordert, was einem vollmundig versprochen wird, erhält man eben bisher nichts...

Ich weiß nicht, was daran so schwer zu verstehen ist.

Ist mir doch egal, ob manche Leute es einsehen dürfen und nicht alle. THG hat etwas anderes suggeriert, und so lange das dort in der Form weiter steht, werde ich es auch weiterhin einfordern. Alles andere wäre unlauterer Wettbewerb...

Alle 11.1 Sachen die ein Spiel verwenden könnte sind doch bei NVidia mit dabei, oder? Ich dachte nur ein paar 2D Sachen wurden ausgelassen.
Nein, es fehlen einige Dinge. Frag Coda. Laut ihm fehlen auch Sachen, die man gut gebrauchen könnte.

samm

2013-04-05, 23:23:53

Das Array ist schon aus mehreren Gründen praktisch, aber hm, wäre das wirklich so simpel? Man müsste es mitschreiben für die Auswertung, man kann es auch nicht einfach flushen oder neu erstellen (auch von einem dazu nötigen Zeitaufwand abgesehen, weil nach Frame zur Zeit "weiss" wieder das Frame zur Zeit "schwarz" resp. sonst ein "nieder-wertiges" kommen wird). Man kann auch nicht bei Benchbeginn ein Array mit Anzahl Plätzen = Benchdauer / Zeiteinheit erstellen, weil Zeiteinheit taktabhängig ist, oder? Ach, vermutlich denke ich gerade zu komplizert^^

[edit]Kommt die Idee des Offenlegens des Quellcodes evt. daher, das PCPer ihre Perlscripts, mit denen sie die Ergebnisse analysieren, zur Verfügung stellt?

Skysnake

2013-04-05, 23:54:04

Nimm einfach mal nen Array von 10MB. Darin kannst du dann, wenn du nen 32Bit Wert, halt den RGBA Wert schreibst, die Transparenz brauchst du nicht, aber scheis drauf, nimmst insgesamt 2621440 Frames speichern. Gehen wir mal von 100 FPS aus, dann reicht das noch immer für 26214 Sekunden, also ~439 Minuten. Ich glaube das sollte ausreichend sein ;)

Und ja, das ist sehr einfach. Das schreiben in ein bereits allociertes array hat die Komplexität O(1), also es dauert, egal wie groß das Array ist, immer gleich lang einen Wert zu schreiben, und was primitiveres als einfach einen Wert zu schreiben gibt es nicht. Die Zeit zu bestimmen ist das VIEL aufwändiger im Verlgeich dazu.

Man muss die Daten ja nichtmal auf die Platte speichern während dem Test, sondern einfach im Speicher halten, und dann später schreiben. Der Aufwand ist also wirklich minimalst.

Und bzgl. dem wiederholen von Farben:

Du hast RGBA, also einen 32 Bit wert. Wenn du den voll ausschöpfen willst, hast du also 2^32, also 4.294.967.296, Werte.

Nehmen wir mal 60 Sekunden, bei 100 FPS und 1080 vertikaler Auflösung. Da hast du dann "nur" 6.480.000 Du kannst also eine ganze Minute lang theoretisch JEDER Zeile auf JEDEM Bild einen neuen Wert geben, und bist immer noch nicht durch ;)

Du könntest das bei 100 FPS und 1080 vertikaler Auflösung ~39768 Sekunden, also knapp 663 Minuten lang machen. Ich glaube auch das sollte "gerade so" ausreichend sein ;)

Deswegen ist es ja so lächerlich, das man nur 16 Farben verwendet -.-
EDIT:
Ich hab mir nochmal die DVI-Specs angeschaut. Es werden normal nur 24Bit halt die RGB Daten übertragen. Die Transparenz kann man ja nicht auswerten! War mir nur nich mehr sicher, wie das bei DVI läuft, ob da nich noch was für die Helligkeit extra mitcodiert wird. Wirds aber nicht. Man hat also NICHT 2^32, sondern "nur" 2^24 = 16.777.216 Werte.

Das reicht bei 100 FPS und 1080 vertikaler Auflösung aber immer noch für 155 Sekunden Aufzeichnung, bevor sich etwas wiederholenmuss, wenn man jeder Zeile theoretisch einen neuen Farbwert zuweisen will. Genauer muss man eigentlich nicht sien. Von mir aus einen Faktor 2 noch genauer, einfach um sicher zu gehen. Dann sind das halt noch immer >70 Sekunden, bevor man sich auch nur einmal wiederholt. Kein Vergleich zu dem Overlay, das FCAT mit den 16 Farben nutzt. :ugly:

Also noch immer ausreichend. Wir zeichnen ja digital auf.

Ich verwende eh ne Karte zum Aufzeichnen, und lass nen Tool drüber laufen, dass die Sachen auswertet. Da ist es absolut scheis egal, ob das 11111 und 00000 ist, oder nur 00000 und 00001 Das ist ja das tolle an digitalen Daten im Vergleich zu analogen Daten.

Und falls es bei Capering probleme gibt, kein Problem, macht man halt den Abstand 10 mal so groß ;) Dann kann man halt "nur" noch 60 Minuten lang jede Zeile mit einem neuen Wert versehen, ohne das es sich wiederholt.

samm

2013-04-06, 00:06:16

Haha ok, Platz ist also genug da^^ Schreibkomplexität ist mir ja klar, ich hatte irgendwie pro Zeiteinheit einen Array-Platz gedacht, dann pro möglichem Farbwert. Beides wenig sinnvoll .Aber klar, jedes present-Frame entspricht einem Array-Platz.

Skysnake

2013-04-06, 01:20:18

Wie gesagt, ich versteh wirklich nicht, wie man auf die Idee mit der Farbtabelle mit den 16 Farbwerten kommen kann. :rolleyes:

N0Thing

2013-04-06, 01:34:23

Und sorry, dass der Quellcode bei sowas nicht einsehbar ist, ist keine kleine Sache, sondern ein eklatanter Missstand!

Warum ist es bei FCAT ein Mißstand, bei FRAPS, Afterburner, Precision, usw. aber nicht, die ebenfalls für Reviews und Performance-Messungen heran gezogen werden?
Oder habe ich deine Beschwerden zu diesen Programmen nur übersehen?

Sag das den Leuten/Redaktionen, die nicht schaffen die Berifflichkeiten sauber zu trennen. Ich beziehe mich nur darauf, was einem großmotzig verkündet wird, was man denn tolles mit FCAT hätte. Wenn man aber eben das einfordert, was einem vollmundig versprochen wird, erhält man eben bisher nichts...

Ich weiß nicht, was daran so schwer zu verstehen ist.

Ist mir doch egal, ob manche Leute es einsehen dürfen und nicht alle. THG hat etwas anderes suggeriert, und so lange das dort in der Form weiter steht, werde ich es auch weiterhin einfordern. Alles andere wäre unlauterer Wettbewerb...

Es geht nicht um das Verstehen, sondern um Behauptungen und Belege.
Ich habe dir den Artikel von PCPER verlinkt, in dem nirgendwo von open source gesprochen wird und ich habe bei THG vielleicht die entsprechende Stelle nur überlesen, aber auch dort nirgendwo die Aussage gefunden, daß FCAT open source sei. Von daher fände ich es zuvorkommend, wenn du kurz die Seite verlinkst, auf die du dich die ganze Zeit beziehst.

kruemelmonster

2013-04-06, 02:01:54

Und wie würdest du die falsche Information zu D3D11.1 bezeichnen?

Immer wieder schön wenn nur halbe Sätze zitiert werden, insbesonders wenn der nicht-zitierte Teil AMDs Verfehlungen und NVs Standpunkt diesbezüglich behandelt.
Aber bitte: für mich war die Punkt1 Geschichte kein technischer Cheat und auch kein Beweis für mangelnde Integrität (denn darum ging es in meinem Posting) sondern für die übliche NV-Arroganz: Alles, was wir nicht unterstützen ist für den Markt eh nicht relevant könnte der Gedankengang gewesen sein der dazu führte Punkt1 an exakt drei Stellen zu erwähnen: in der Pressemitteilung, im Interview mit hardware.fr und im Treiberchangelog. Auf den Kartons sowie in den Specs steht 11 und nicht mehr.
Diese zugegebenermaßen unfeine (aber mit Blick auf den Marktanteil durchaus nachvollziehbare) firmenpolitische Einstellung hat aber nichts damit zu tun dass NV ab G80 konstant technisch saubere Ergebnisse geliefert hat.
Um damit nun den Kreis zum Thema zu schließen: daher haben sie sich bei mir auch einen Vertrauensvorschuß verdient weshalb ich die Messergebnisse durch FCAT erstmal auch nicht anzweifle. Dass die Methodik nicht der Weisheit letzter Schluß ist wird hier im Thread ja herausgearbeitet, das hat aber nichts mit Vertrauen bzw Misstrauen ggü NV und ihrem Analysetool zu tun.

Sorry, aber nVidia ist nicht gerade ein Laden, der besonders vertrauenswürdig wäre. Ganz im Gegenteil!
Das ist eher ein Linker Laden, der alles versucht, um halbwegs brauchbar da zu stehen und 'den anderen' 'nen Dolch in den Rücken zu stecken...

Ah ja. :rolleyes:

Dann sag doch mal, welches börsennotierte Unternehmen hat denn Mutter Theresa und Mahatma Ghandi auf die Chefsessel gesetzt und ist moralisch so viel integerer als NV?
AMD mit Sicherheit auch nicht, Ganz im Gegenteil!
Ich traue AMD solange nicht über den Weg bis sie mal zwei, drei Kartengenerationen hintereinander auf den Markt bringen bei denen nicht irgendwas komisch oder im Argen ist: ab HD2000 (nehmen wir zur Bewertung den gleichen Zeitraum wie bei NV) gab es keine Generation die nicht irgendwelche technischen Eselsohren hatte, ob nun AF-Flimmern, AF-Banding, Oberflächenoptimierung, Tess-Schalter oder jetzt eben die Frametimes bei S wie MGPU.

Alle 11.1 Sachen die ein Spiel verwenden könnte sind doch bei NVidia mit dabei, oder? Ich dachte nur ein paar 2D Sachen wurden ausgelassen.

Leider nein, auch eine nice-to-have 3D-Funktion fehlt. Ist aber auch egal, halb schwanger gibts nicht.
Die Änderung in GPU-Z 0.6.9 bzgl. Kepler und 11.0 kam übrigens auf meine Anregung im TPU Forum, just sayin' bevor jemand wegen des Spoilers den Lüfterjungen nach mir wirft.

@mods: Sorry für semi-offtopic, StefanV hat gefragt und ich hab bei der Antwort auch versucht den roten Faden (ist NV und damit FCAT glaubwürdig?) im Blick zu behalten.

Marty98

2013-04-06, 04:06:48

Warum ist es bei FCAT ein Mißstand, bei FRAPS, Afterburner, Precision, usw. aber nicht, die ebenfalls für Reviews und Performance-Messungen heran gezogen werden?

Ganz einfach. FCAT ist von Nvidia, dem Todesfeind von Skysnake.

Skysnake

2013-04-06, 11:09:48

Warum ist es bei FCAT ein Mißstand, bei FRAPS, Afterburner, Precision, usw. aber nicht, die ebenfalls für Reviews und Performance-Messungen heran gezogen werden?
Oder habe ich deine Beschwerden zu diesen Programmen nur übersehen?

Da gibt es doch feine aber wichtige Unterschiede:
Afterburner, Precision und auch FRAPS, wie es meist verwendet wird, geben nur AVG-Werte an. Ob das jetzt da ein bischen in diese oder jene Richtung geht, spielt am Gesamtbild praktisch keine Rolle. Man geht überhaupt nicht auf die Betrachtung einzelner Frames ein, sondern eben nur von ganzen Zeitspannen. Daher relativ unproblematisch. In meinem Test zur HD7970 von XFX hab ich aber z.B. mich auch gegen FRAPS entschieden, da eben der subjektive Spieleindruck mit FRAPS, und ja, ich hab die Anzeige abgedeckt :ugly: Ruckeliger daherkommt, als ohne. Liegt wohl an den Eingriffen von FRAPS. Beim Afterburner merkt man es auch leicht an manchen Stellen, aber subjektiv für mich eher weniger. In meinem Test damals bin ich darauf nicht noch dazu eingegangen, er war aber auch schon SEHR lang. Das wäre einfach ein Overkill gewesen, das Fass auch noch auf zu machen.

Kleiner Einwurf, ich hatte mich an FinalWire gewendet, um zu fragen, ob Sie für meine Tests nicht die Refreshrate auf <1s setzen könnten, oder eben eine Option hierzu einführen könnten. Die Antwort war: Nein können wir nicht, das Auslesen dauert teils einfach schon bis zu ner halben Sekunde von den ganzen Sensoren, daher haben wir uns auf eine minimale Rate von 1 Sekunde beschränkt.

Da musste ich auch mal ziemlich schlucken.

Irgendwas muss man aber einsetzen, um zumindest die AVG-Werte zu erhalten. Ich habe mich da auch auf eine Abtastrate von 10Hz beschränkt. Damit sollte man immer noch über mehrere Frames mitteln. Für die Betrachtung, die machen wollte, war es leider erforderlich so einen kurzen Zeitintervall zu nehmen. Ich fands an der Stelle aber gerade noch! Ok. Die Frameraten waren meist >40 FPS

FRAPS ist da die Einzige Ausnahme, wenn man eben aufzeichnet UND dazu noch die Auswertung macht. Da geht man auch dahin, das man einzelne Frames betrachtet. Daran habe ich auch schon vor FCAT kritik geäußert, eben weil FRAPS selbst einen Einfluss hat, wie es mir schien bei meinen Tests. Ansonsten habe ich mich mit dieser speziellen Thematik von FRAPS jetzt auch nicht sehr umfassend beschäftigt, da es nicht so oft eingesetzt wird, und durchaus auch schon kritische Stimmen da waren. Hatte ich zumindest den Eindruck. Mir ist auch nichts, praktisch, ins Gesicht gesprungen, was mir gesagt hätte, wie man es besser machen könnte, und es hat mich auch keiner auf die Palme gebracht mit Aussagen wie "wissenschaftlich untermauerte Methoden" usw usw.

Das hat einfach meinen Spürsinn geweckt. Du hast ja sicherlich auch gemerkt, dass ich mich nicht direkt am Anfang der FCAT Thematik dazu geäußert habe. Da hat mir Schlicht das Interesse und vor allem auch die Zeit dazu gefehlt. Bin gerade voll in den Diplomsprüfungen, da habe ich eigentlich besseres zu tun... Naja, wie gesagt dann hat mich der Rappel halt doch gepackt, und ich hab mal ne Lernpause genutzt, um das Thema näher zu betrachten, tja... Und dann ist mir eben ziemlich schnell ein Licht aufgegangen, und an lernen war da eh nicht mehr zu denken :mad:

Ist halt einfach Pech bei FCAT. Hätte man den Bogen verbal einfach nicht so überspannt, hätte ich mich wohl nie näher damit beschäftigt. Tja, so kanns gehen. ;D

[quote]
Es geht nicht um das Verstehen, sondern um Behauptungen und Belege.
Ich habe dir den Artikel von PCPER verlinkt, in dem nirgendwo von open source gesprochen wird und ich habe bei THG vielleicht die entsprechende Stelle nur überlesen, aber auch dort nirgendwo die Aussage gefunden, daß FCAT open source sei. Von daher fände ich es zuvorkommend, wenn du kurz die Seite verlinkst, auf die du dich die ganze Zeit beziehst.
Kein Ding, ich quote es dir mal rein:

[quote]Aber genau das ist es, wonach wir suchen; das wäre quasi der Heilige Gral des Grafikkartenbenchmarking – eine Maßzahl, die FPS ersetzen kann. Leider gibt es sie noch nicht.
ziemlich großkotzig

Teile unseres Setups sind aber im Handel erhältlich oder Open Source.
Ich seh da überhaupt nichts, was open Source ist. Vor allem eben nicht das Overlay.

Daher hat Nvidia einige Perl-Scripts entwickelt, die die in der Datei enthaltenen Daten komprimieren und Bildwiederholrate, Bildaufbauzeit in kompakter numerischer und in graphischer Form ausgeben.

Das Gesamtsystem wird von Nvidia FCAT genannt – Frame Capture Analysis Tool.

Juhu, nVidia hat Perl-Skripte gebaut, was Bilpunkte abgleicht in nem AVI Video... Das schwierigste hier ist, das AVI Video einzulesen.

Wobei ich mich frag, warum man Perl un nicht Python nutzt, das eigentlich sich dafür eigentlich besser, aber egal...

FCAT ist das Gesamte, und oben wird gesagt, das (Teile) OpenSource wären, ja aber wo denn bitte? Da ist GAR NICHTS Open Source....

Ganz einfach. FCAT ist von Nvidia, dem Todesfeind von Skysnake.
Klar, und deswegen hab ich auch schon an nem nVidia Projekt mitgearbeitet, und dabei geholfen, dass die Messwerte besser werden ;)

Ist klar ;)

Ich kann sehr deutlich dazwischen trennen, ob mir die Firmenpolitik einer Firma nicht gefällt, und Sie versuchen mich zu bescheissen, und ob Sie nicht dennoch ein gutes Produkt haben. Und bei nVidia ist beides der Fall. Als Firma, wie Sie sich verhalten, sind Sie teils einfach nur zum Kotzen. Die Software, wie Sie machen ist aber schon gut...

Gerade CUDA. CUDA ist propritär. Das finde ich aus vielen Gründen extrem scheise. nVidia hat aber auch GPUDirect mit CUDA zusammen, und GPUDirect ist ziemlich geil... Da muss man die CUDA Kröte leider schlucken. Ich fänds aber besser, wenn Sie das in OpenCL bringen würden!

Die Welt ist halt nicht Schwarz und Weiß, sondern verdammt! viel dazwischen.

MadManniMan

2013-04-06, 12:20:44

Welchen Einfluss hat FRAPS denn? Klär uns auf.

Skysnake

2013-04-06, 13:14:29

Zumindest, wenn du die Aufzeichnungen machst, hast du recht massive Speicherzugriffe, wie es scheint, oder flusht dir die Caches what ever. Im ingame Benchmark von Batman AC fällts auf jeden Fall recht deutlich auf im Verlgeich zum Durchlauf komplett ohne irgend eine Messung.

Je stärker, und vor allem je höher die IPC+Takt ist, desto mehr kann man das Problem natürlich tot schlagen durch pure Leistung. Der Effekt bleibt aber bestehen, fragt sich nur, ob man ihn eben noch wahrnimmt.

Skysnake

2013-04-06, 17:34:50

So ich hab jetzt endlich noch den Beitrag gefunden, den ich gesucht habe:

The FCAT analysis has shown us that Nvidia's frame metering tech for SLI does seem to work as advertised. Frame metering isn't necessarily a perfect solution, because it does insert some tiny delays into the rendering-and-display pipeline. Those delays may create timing discontinuities between the game simulation time—and thus frame content—and the display time. They also add a minuscule bit to the lag between user input and visual response.

http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/11

So, jetzt hätte ich gern mal eine Stellungnahme dazu von denjenigen, die steif und fest behaupten, das Framemetering von nVidia würde keinen zusätzlichen Lag verursachen!

boxleitnerb

2013-04-06, 17:41:17

MadManniMan

2013-04-06, 18:47:56

1) Wie sollte auch etwas, das zusätzlich dargestellt wird, nicht zusätzliche Last erzeugen? Egal, ob nun als Overlay oder indirekt codiert über gefärbte Streifen, da ist plötzlich etwas, das vorher nicht da war. Das kann man aber wohl leider wirklich nur noch mit Highspeed-Kameras auswerten.

2) Nochmal zu den Delays. Wenn ein Delay eingefügt würde und somit bei angenommenen 40 FRAPS-FPS aus

-xx----------xx----------xx----------xx----------
-oo----------oo----------oo----------oo----------

(wobei "x" für Enginezeit und "o" für Displayzeit steht)

danach soetwas würde

-x-----x-----x-----x-----x-----x-----x-----x-----
-oo----------o-----o-----o-----o-----o-----o-----

dann wäre zumindest AFR-Mikroruckeln schon wesentlich flüssiger fühlbar, wenn auch dann und wann Frames eingefügt werden müssen, bei denen tatsächlich ein Enginezeit-Ausgabezeit-Delta besteht.

Und nein, nur fürs Protokoll: AFR kommt für mich sowieso nicht in Frage.

Skysnake

2013-04-06, 19:35:53

Hä?

Wie kommst du jetzt darauf?

Das hat doch absolut nichts damit zu tun, was nVidia macht :confused:

Schaffe89

2013-04-06, 20:23:05

Und um "tiny delays" und "add a miniscule bit to the lag" machst du seitenweise so ein Theater? Die relevante Frage ist doch, ob es auffällt oder eben nicht. Bei diesen Formulierungen wäre ich mir da nicht so sicher und würde eher denken, du machst aus einer Mücke einen Elefanten.

Bei niedrigeren FPS wirds wohl eher auffallen, nehme ich mal an, weil die millisekunden des delays hier viel stärker abweichen können als bei hohen FPS.
Eventuell je die gleiche Geschihcte wie bei den µrucklern, die laut PCGH bei SLi und CF im unteren FPS Bereich deutlich auffallend sind, und laut PCGH immer auffalend sind ( slight µstuttering) steht dort immer hinter der GTX 690.

du seitenweise so ein Theater?

Ja das Theater war nötig. :P

boxleitnerb

2013-04-06, 20:45:49

Bei niedrigeren FPS wirds wohl eher auffallen, nehme ich mal an, weil die millisekunden des delays hier viel stärker abweichen können als bei hohen FPS.
Eventuell je die gleiche Geschihcte wie bei den µrucklern, die laut PCGH bei SLi und CF im unteren FPS Bereich deutlich auffallend sind, und laut PCGH immer auffalend sind ( slight µstuttering) steht dort immer hinter der GTX 690.

Ja das Theater war nötig. :P

Bei niedrigen fps (sagen wir ab 45 abwärts) versagt AFR eh fast immer, ob mit Metering oder ohne.

Nein, war es nicht. Ich weiß auch gar nicht, warum du dich da jetzt einmischst ohne Angabe von Gründen, außer Trollen. Die Geschichte hätte man auch ohne Hysterie und vor allem differenzierter betrachten können. Denn dafür, dass Skysnake sich dabei einen halben Herzinfarkt geholt hat, konnte er immer noch nicht zeigen, dass dieser Zusatzlag tatsächlich spürbare negative Auswirkungen hat. Theorie und Praxis...

samm

2013-04-06, 21:06:29

boxleitnerb, das "seitenweise Theater" ging nicht um dieses zusätzliche delay durch das Einfügen des Overlays, bisher gab es dazu bloss das eine oder andere Posting.

Worum es hauptsächlich ging, war die Feststellung der lags zwischen t_present und t_display, denn wenn dieses nicht konstant ist, ist das eine weitere "Mikroruckelquelle". Zudem ist es eine zusätzliche Information zu Lags in der Pipeline. Es wäre durch ein timestamp des overlays möglich, all das (und mehr) zu messen. Es ging also um mögliche Verbesserungen des FCAT-Tools, sodass die Ergebnisse wesentlich aussagekräftiger würden und FCAT viel mehr zu dem optimalen Performance-Messtool machen würde, als das es bereits jetzt empfunden wird.

Das zweite, was in den vergangenen Seiten zu emotionalen Reaktionen geführt hat, war die Open-Source-Idee. Dadurch wäre es eben möglich, erstens gewünschte Funktionalität hinzuzufügen, wie das genannte timesamping, zweitens festzustellen, ob benachteiligende Methoden eingesetzt werden. Ausserdem behauptete THG unglücklicherweise etwas von wissenschaftlichen Methoden, und wissenschaftlichkeit bedeutet Nachvollziehbarkeit. Eine Blackbox ist nicht nachvollziehbar.

MadManniMan

2013-04-06, 21:16:17

Hä?

Wie kommst du jetzt darauf?

Das hat doch absolut nichts damit zu tun, was nVidia macht :confused:

Nvidia fügt keinen Delay ein?

samm

2013-04-06, 21:23:25

Doch, aber nur bei der Ausgabe - die Spielzeit kann nicht direkt von aussen beeinflusst werden.

Skysnake

2013-04-06, 21:33:22

Nvidia fügt keinen Delay ein?
Ich komm immer noch nicht mit, was du meinst :confused:

Sorry, ich steh wohl gerade voll auf dem Schlauch

HarryHirsch

2013-04-06, 21:36:42

Doch, aber nur bei der Ausgabe - die Spielzeit kann nicht direkt von aussen beeinflusst werden.

damit erschaffen sie doch einen inputlag? oder ist das egal?

Skysnake

2013-04-06, 22:15:21

Ja, tun Sie, wenn Sie verzögern müssen. Wie GENAU das abläuft kann FCAT wie es aktuell ist aber nicht zeigen. Mit meiner Erweiterung, die ich vorgeschlagen habe/fordere, wäre das in gewissem Maße nachvollziehbar.

PS:
Das ist mal so ein blablalba in dem Broadcast... Kommen die auch irgendwann mal auf den Punkt? :ugly:

EDIT:
Was mir schon die ganze Zeit unter den Nägeln brennt. Warum zeichnen die eigentlich das gesamte Bild auf? Es würde doch eine einzige Spalte schon reichen. Mehr Information braucht man ja nicht.

Da brüchte man nur noch 1/1920tel der Bandbreite und des Speichers :ugly:

EDIT2:

Das zweite, was in den vergangenen Seiten zu emotionalen Reaktionen geführt hat, war die Open-Source-Idee. Dadurch wäre es eben möglich, erstens gewünschte Funktionalität hinzuzufügen, wie das genannte timesamping, zweitens festzustellen, ob benachteiligende Methoden eingesetzt werden. Ausserdem behauptete THG unglücklicherweise etwas von wissenschaftlichen Methoden, und wissenschaftlichkeit bedeutet Nachvollziehbarkeit. Eine Blackbox ist nicht nachvollziehbar.
Es ist nicht nur THG, die von OpenSource sprechen, sondern auch Techreport: http://techreport.com/review/24588/the-tr-podcast-131-news-from-gdc-and-fcat-attacks

Bei 1:19:30

The core relation between the data coming out of FRAPS and coming out of FCAT is indisputable. We can talk about that, but at the same time.. What the process for the FCAT tools is also extremly transparent you capturing video with virtual doup(?). It´s, you know, totaly free, i think its openSource its free Software and you page through frame by frame and you can see the overlays you ran the extractor tool, what is kind of a black box, it´s not openSource, but what comes out of it is a csv file that saise i see this many lines of this colour and that many lines that colour that many of the other colour

Danach redet er davon, das er bei seinen Test festgestellt hat, dass die Messwerte nicht richtig gewesen wären, da anscheinend die Farben falsch erkannt worden wären.

Und was er auch noch sagt ist, dass das Overlay in 5 von 9 Tests nicht funktioniert hat.

Wo ist denn da bitte die Transparenz, die er oben benennt, wenn so vieles absolut krumm läuft, und man auf keine Daten zugreifen kann.

Danach sagt er dann noch, dass die Leute von ihm die Tools usw als Zip-file haben könnten von ihm.

Hat jemand ne Ahnung wer das ist, und wie man ihn kontaktiert?

EDIT3:
Es ist echt anstrengend ihm zu folgen... Ihm fällt es teils sehr schwer, die Sachen in Worte zu fassen.

Was aber noch bei so 1:20 bis 1:30 war, war, dass er mit FRAPS ein Stocken gesehen hätte, das, soweit ich das jetzt verstanden habe, in FCAT nicht zu sehen war, aber auf der Aufzeichnung des Videos hat man ein Ruckeln in der Animation gesehen, was prinzipiell wohl auch vom Nutzer zu sehen wäre.

Deswegen kommt er wohl auch, soweit ich das verstanden habe, zu dem Schluss, das man FCAT UND! FRAPS braucht, und es KEINE einzelne Zahl gibt, die angibt, wie das Spielgefühl ist.

kruemelmonster

2013-04-07, 00:27:53

Es ist nicht nur THG, die von OpenSource sprechen, sondern auch Techreport: http://techreport.com/review/24588/the-tr-podcast-131-news-from-gdc-and-fcat-attacks

Bei 1:19:30

Danach redet er davon, das er bei seinen Test festgestellt hat, dass die Messwerte nicht richtig gewesen wären, da anscheinend die Farben falsch erkannt worden wären.

Und was er auch noch sagt ist, dass das Overlay in 5 von 9 Tests nicht funktioniert hat.

Wo ist denn da bitte die Transparenz, die er oben benennt, wenn so vieles absolut krumm läuft, und man auf keine Daten zugreifen kann.

Junge Junge. Mal von vorn:

Er spricht von http://virtualdub.org/ als OpenSource Programm um sich das aufgenommene Video Frame für Frame anzuschauen. Jetzt sag nicht du kennst VirtualDub nicht; das wirft ein fragwürdiges Bild darauf wie du dich bisher mit dem Thema in seiner Gänze beschäftigt hast.

Danach hat er mit einer früheren Version von FCAT festgestellt dass die ausgegebenen Werte nicht mit dem übereinstimmen was er sehen bzw mit anderen Tools messen konnte. Er hat dann NV kontaktiert und der Fehler wurde behoben.

TR würde gerne Fraps neben FCAT laufen lassen, da aber das Fraps Overlay oftmals mit dem FCAT Overlay kollidiert wär es wünschenswert wenn Fraps ebenfalls das 16-Farben-Overlay bekommen und somit das NV DX-Overlayhook überflüssig machen würde.

Deswegen kommt er wohl auch, soweit ich das verstanden habe, zu dem Schluss, das man FCAT UND! FRAPS braucht, und es KEINE einzelne Zahl gibt, die angibt, wie das Spielgefühl ist.

Korrekt.

Skysnake

2013-04-07, 01:06:15

Ah danke, ich habs jetzt auch im PCper Artikel gefunden. Ich konnte mich daran wohl nicht mehr erinnern, das Sie sagten, es sei nicht praktikabel. THG verwendet es aber. Hab grad nochmal nachgeschaut, Sie erwähnen es einmalig.

Der Ablauf ist da also auch wieder anders. Ist THG eventuell also ein Problem entgangen? Wenn für PCper es so schlimm war, dass Sie sich was selbst geschrieben habe, hätte ich jetzt erwartet, das THG zumindest kurz was dazu schreibt, oder nicht :confused:

Was ich aber noch immer nicht vesteh ist, was an den Overlays kollidieren soll. Das eine hat doch mit dem anderen eigentlich nichts zu tun.

Und vor allem, wenn THG Virtualdub verwendet, PCper aber nicht, hat THG überhaupt die "gefixte" Version der Tools erhalten???

Gibts dazu eine Versionierung? Wenn ja, welche ist denn die aktuellste?

Und da spricht man von Transparenz und Nachvollziehbarkeit, dabei kommen immer mehr Fragen auf, je länger man sich damit beschäftigt :ugly:

Grestorn

2013-04-07, 09:56:32

Was hat Virtual Dub bitteschön mit FACT zu Tun.Es wird ja immer besser .Und den Wert für Runt <<<<FRAMES Legt NVIDIA fest .Ich steck mir den Finger in den Po>Po

Das tust Du offenbar, nur so lassen sich solche Postings erklären. Und offenbar genießt Du das Gefühl auch sehr ;)

Skysnake

2013-04-08, 00:26:21

Kleine Berichtigung.

DVI nutzt 24 Bit, nicht 32 Bit, ich hatte mich beim Schreiben schon gewundert, ändert aber nichts an der Grundaussage. Hier nochmals die richtige Rechnung:

Ich hab mir nochmal die DVI-Specs angeschaut. Es werden normal nur 24Bit halt die RGB Daten übertragen. Die Transparenz kann man ja nicht auswerten! War mir nur nich mehr sicher, wie das bei DVI läuft, ob da nich noch was für die Helligkeit extra mitcodiert wird. Wirds aber nicht. Man hat also NICHT 2^32, sondern "nur" 2^24 = 16.777.216 Werte.

Das reicht bei 100 FPS und 1080 vertikaler Auflösung aber immer noch für 155 Sekunden Aufzeichnung, bevor sich etwas wiederholenmuss, wenn man jeder Zeile theoretisch einen neuen Farbwert zuweisen will. Genauer muss man eigentlich nicht sien. Von mir aus einen Faktor 2 noch genauer, einfach um sicher zu gehen. Dann sind das halt noch immer >70 Sekunden, bevor man sich auch nur einmal wiederholt. Kein Vergleich zu dem Overlay, das FCAT mit den 16 Farben nutzt. :ugly:

Also noch immer ausreichend. Wir zeichnen ja digital auf.

MadManniMan

2013-04-08, 00:37:37

DVI nutzt 24 Bit, nicht 32 Bit, ich hatte mich beim Schreiben schon gewundert, ändert aber nichts an der Grundaussage. Hier nochmals die richtige Rechnung:

Ich hab mir nochmal die DVI-Specs angeschaut. Es werden normal nur 24Bit halt die RGB Daten übertragen. Die Transparenz kann man ja nicht auswerten!

:facepalm:

Skysnake

2013-04-08, 00:42:22

Mimimi.

Ich steh wenigstens dazu, wenn ich nen Fehler mache. So was passiert. Besser als es unter den Teppich zu kehren :P

Und wie gesagt, es ändert nur was an den absoluten Zahlen, nichts am Prinzip.

Grestorn

2013-04-08, 07:51:53

@Skysnake:

Mir ist zwar klar, was Du erreichen willst - nämlich eine objektive Latenzmessung - aber ich weiß nicht, ob Dein Weg zum Ziel führt.

Denn: Die Aufnahme müsste ja Millisekundengenau mit der Erzeugung der Farbscala synchronisiert warden. Nur dann kannst Du den Unterschied zwischen der Erzeugung der Farbe zu dem, was die Aufnahme wiedergibt, messen.

Ich fürchte, das ist in der Praxis kaum mit vertretbarem Aufwand durchführbar und war ja eigentlich auch gar nicht das Ziel dieser Messung.

Vergiss nicht: Wir sprechen hier von Latenzverlusten im allerschlimmsten Fall von einem Bild (bei 60 fps 1 / 60 s, also 17ms) die das Framemeetering in einigen wenigen Frames als zusätzliche Latenz einfügen muss.
Diese Genauigkeit bekommst Du mit dem genutzten Verfahren nicht, zumal die Aufzeichnung ja auch nicht latenzfrei von statten geht!

Außerdem: Ehrlich gesagt: Mücke und Elefant...

Skysnake

2013-04-08, 08:44:36

Ich fürchte, das ist in der Praxis kaum mit vertretbarem Aufwand durchführbar und war ja eigentlich auch gar nicht das Ziel dieser Messung.

Wie schon gesagt, es ist eigentlich gar kein Aufwand.

Vergiss nicht: Wir sprechen hier von Latenzverlusten im allerschlimmsten Fall von einem Bild (bei 60 fps 1 / 60 s, also 17ms) die das Framemeetering in einigen wenigen Frames als zusätzliche Latenz einfügen muss.
Diese Genauigkeit bekommst Du mit dem genutzten Verfahren nicht, zumal die Aufzeichnung ja auch nicht latenzfrei von statten geht!

Nein, wir wissen nicht wie oft das passiert. Es kann sowohl bei einzelnen Frames nur der Fall sein, aber uach bei einem Großteil, kommt ganz darauf an, was nVidia macht.

Und durch die Messung hast du keinen zusätzlichen Lag. Du greifst ja das Signal am Monitorausgang ab ;)

Nur das Overlay verursacht einen Lag, den man eventuell berücksichtigen muss.

Grestorn

2013-04-08, 08:57:21

Wie willst Du denn das aufgezeichnete Video mit der Realzeit in Übereinstimmung bringen? Das ist doch nahezu unmöglich auf ms genau, mal ganz abgesehen davon, dass die Quellmaschine und die aufzeichnende Maschine eine unterschiedliche Uhr besitzen, die nicht nur auf ms genau abgeglichen werden müssten sondern auch zusätzlich keine Abweichung zueinander haben dürfen.

Und dann muss auch noch die Aufzeichnung eine bei jeder Aufzeichnung identische Latenz haben um zumindest Vergleiche anstellen zu können. Für eine absolute Messung müsste diese Latenz noch dazu exakt bekannt sein.

Sorry, aber das ist alles andere als realistisch. Und schon gar nicht einfach.

Das Signal abzugreifen ist nicht das Problem sondern es AUFZUZEICHNEN. Wenn Du das Signal nicht aufzeichnest sondern nur online auswertest, kannst Du zwar evtl. die Latenz messen, aber wieder nicht wieviele Frames tatsächlich zur Anzeige kommen. Wenn im schlimmsten Fall nur jedes zweite Frame gezeigt wird, dann siehst Du das nicht online!

Und was soll bitte die Online-Auswertung machen? Auch dazu brauchst Du einen zweiten Rechner, der die Farbcodes in Zeitwerte rückrechnet. Auch das geschieht nicht Latenzfrei! Abgesehen davon, dass man so etwas erst mal Programmieren müsste.

Das Overlay erzeugt sicher keinen nennenswerten Lag, wieso auch. Das kannst Du getrost vergessen.

Skysnake

2013-04-08, 10:44:37

Dann les bitte nochmal die Beitraege von Gipsel und mir. Wir haben das beide jetzt schon mehrfach erklaert, wie das geht...

Und zum Overlay:
Hast du schonmal so was implementiert?
Nein?
Wie kommst du dann darauf, dass das keine relevante Latenz verursachen kann?

Grestorn

2013-04-08, 11:23:08

Dann les bitte nochmal die Beitraege von Gipsel und mir. Wir haben das beide jetzt schon mehrfach erklaert, wie das geht...Bevor ich nochmal alles lese, verlinke das doch bitte. Ich kann mich tatsächlich nicht erinnern von Euch da ein schlüssiges Konzept gelesen zu haben. Aber ich habe auch nicht JEDEN Beitrag minutiös studiert. Würde mich ehrlich interessieren, wie ihr das anstellen wollt.

Und zum Overlay:
Hast du schonmal so was implementiert?
Nein?
Wie kommst du dann darauf, dass das keine relevante Latenz verursachen kann?

Nein, habe ich nicht. Aber ehrlich: Man muss ein konstantes Rechteck mit einer konstanten Farbe einfügen. Dagegen ist jedes andere OSD (fraps, Steam usw.) Overkill im Vergleich.

Gipsel

2013-04-08, 12:03:26

Ich hab mir nochmal die DVI-Specs angeschaut. Es werden normal nur 24Bit halt die RGB Daten übertragen. Die Transparenz kann man ja nicht auswerten! War mir nur nich mehr sicher, wie das bei DVI läuft, ob da nich noch was für die Helligkeit extra mitcodiert wird. Wirds aber nicht. Man hat also NICHT 2^32, sondern "nur" 2^24 = 16.777.216 Werte.Das hatte ich schon mal geschrieben. ;)
Im Prinzip würden wohl auch 48Bits/pixel gehen, aber das ist absolut nicht praxisrelevant.
Nein, habe ich nicht. Aber ehrlich: Man muss ein konstantes Rechteck mit einer konstanten Farbe einfügen. Dagegen ist jedes andere OSD (fraps, Steam usw.) Overkill im Vergleich.
Nö, das ist so ziemlich der gleiche Aufwand. Der zusätzliche Drawcall, der beim Present noch eingefügt wird und dann durch die komplette Pipeline laufen muß, kostet so viel Overhead, daß es ziemlich egal ist, ab ich da nur ein Rechteck oder eine Zahl irgendwo drüberzeichne.

Grestorn

2013-04-08, 12:14:29

Nö, das ist so ziemlich der gleiche Aufwand. Der zusätzliche Drawcall, der beim Present noch eingefügt wird und dann durch die komplette Pipeline laufen muß, kostet so viel Overhead, daß es ziemlich egal ist, ab ich da nur ein Rechteck oder eine Zahl irgendwo drüberzeichne.
Hat mal jemand versucht zu messen, ob FRAPS mit aktiviertem und deaktiviertem OSD einen Unterschied in der Latenz verursacht? Auf die reine Framerate scheint es bei den meisten Spielen ja keinen Einfluss zu haben.

Marty98

2013-04-08, 13:03:48

Nur vom Gefühl her, hab ich Fraps öfters abgeschaltet, weil mir die Latenzen schlechter vorkamen. Kann aber auch Einbildung gewesen sein.

kruemelmonster

2013-04-10, 09:21:38

Hat mal jemand versucht zu messen, ob FRAPS mit aktiviertem und deaktiviertem OSD einen Unterschied in der Latenz verursacht? Auf die reine Framerate scheint es bei den meisten Spielen ja keinen Einfluss zu haben.

Hatte das schonmal mit dem Q3TA Benchmark getestet, dort kostet das MSI AB OSD im CPU-Limit circa 3% fps:

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=9596760&postcount=83

N0Thing

2013-04-11, 07:58:32

Nur vom Gefühl her, hab ich Fraps öfters abgeschaltet, weil mir die Latenzen schlechter vorkamen. Kann aber auch Einbildung gewesen sein.

Mir kommt es auch so vor, als ob bei einigen Anwendungen das Spielgefühl zäher wird (keine Ruckler), wenn FRAPS mitläuft. Ist aber nur ein Gefühl, Messungen habe ich nicht angestellt.

Skysnake

2013-04-11, 09:37:04

Naja, wenn man "nur" das Overlay mitlaufen lässt, dann gehts noch, aber sobald man die Daten mitloggen will, um später die Frametimes zu analysieren, wirds finde ich echt auffällig.

Grasso

2013-04-11, 23:27:24

Dann setzt doch Vsync und nehmt die Vertikalsynchronisation extern auf! Anhand der Impulse kann man das Timing sehen. Wenn Vsync bei digitalen Monitoranschlüssen noch einen eigenen Pin hat, reicht eine Soundkarte, ansonsten braucht man natürlich Logik.
Die Grundidee, das Timing extern zu messen, ist aber gut. Vielleicht über Spannungsspitzen am DC/DC-Wandler oder einer an die Filterspule geklebten Elektretmikrofonkapsel; schließlich schalten sich aktuelle Grafikkarten doch nach jedem fertigen Rahmen ab, wodurch ihr Stromverbrauch stark schwankt (siehe Spulenfiepen).

Marty98

2013-04-18, 06:03:13

Es gibt einen neuen PCPer Artikel, diesmal über Stuttering beim VSync:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Visual-Effects-Vsync-Gaming-Animation

Skysnake

2013-04-18, 08:45:00

Also die "Umfrage" ist mal ziemlich schlecht gemacht....

Man MUSS sich für eins von beiden Entscheiden. Man wird also nach dem aller aller aller kleinsten Unterschied suchen. Dazu kommt noch, das man 50% und sogar 20% Speed noch angezeigt bekommt :ugly: Man wird also kein Problem haben, die kleinsten Unterschiede zu erkennen...

Ganz ehrlich, vor 50% hab ich zwischen den Videos eigentlich keinen Unterschied gesehen. Mir kam das linke zwar teilweise flüssiger vor auf der Treppe und auch bei der Drehung, aber das lag teils an echten Rucklern und Teils an Rucklern in der Steuerung....

So kannste das doch in die Tonne treten. Man hätte NUR 100% Speed zeigen dürfen, und eben links besser, gleich gut, rechts besser

Wählen sollen, und dann eben auch freudig die Szenen mischen, also auch z.B. 3 60 FPS Szenen aufnehmen.

Man wusste so z.B. welche Szene die 60 FPS Szene ist...

MadManniMan

2013-04-18, 10:51:50

Warum überrascht es mich jetzt nicht, dass Du auch diesen Test jetzt böse, schlimm und schlecht findest?

Godmode

2013-04-18, 10:54:56

Knuddelbearli

2013-04-18, 22:01:43

hier dürfen also nur Leute mitreden die auf jedenfall was sehen? soso ^^

Godmode

2013-04-18, 22:04:33

Wenn er es nicht sieht, hat doch die ganze Debatte überhaupt keinen Sinn für ihn. Er kann sogar froh darüber sein, weil dann hat ein Kaufkriterium weniger zu beachten ;)

samm

2013-04-18, 22:35:56

Double Buffer VSync ist ein Kaufkriterium? ;)

Ist ja schön und gut, das mal zu betrachten, für mich auch deswegen, weil ich der Meinung war, dass 30-60fps schwankend immer noch besser als 30fps fix seien. Echtes Triple-Buffering wäre mal schön... Dennoch hat das weder mit FCAT noch mit dem Titelthema einen direkten Zusammenhang, bis man damit Latenzen messen kann.

Knuddelbearli

2013-04-18, 23:26:22

Wenn er es nicht sieht, hat doch die ganze Debatte überhaupt keinen Sinn für ihn. Er kann sogar froh darüber sein, weil dann hat ein Kaufkriterium weniger zu beachten ;)

In der Debatte ist auch wichtig wer es überhaupt sieht.

Am Ende sind es "komischerweise" nur solche die eh seit Jahrzehnten nur Nv und Intel kaufen und sehen was sie sehen wollen. Hoffentlich gibt es bald einen Doppelblindtest dazu ^^

AMD und Nv vertauscht und oder einfach ohne Beschriftung, vor allem ersteres wäre sicher lustig ^^
Bin da echt gespannt wie ich mich da entscheiden würde ^^

kruemelmonster

2013-04-19, 10:10:12

Am Ende sind es "komischerweise" nur solche die eh seit Jahrzehnten nur Nv und Intel kaufen und sehen was sie sehen wollen.

Andersrum wird ein Schuh draus, viele AMD Käufer stellen sich blind ggü Problemen/Unzulänglichkeiten mit ihrer Hardware. Dann müssen erst die pingeligen NV'ler das Problem breittreten und in die Öffentlichkeit zerren bis es behoben wird. Und auf einmal freuen sich dann auch der Radeonist über z.B. ein verbessertes AF oder vermindertes Banding oder (ganz böse) DX-spezifikationsverletzendes SGSSAA unter D3D10/11. :rolleyes:

AMD und Nv vertauscht und oder einfach ohne Beschriftung

Gab es schon von NordicHardware, allerdings schon etwas älter, daher nur FW310.70 und Cat12.11 Beta 11:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9603542&postcount=172

Knuddelbearli

2013-04-19, 14:39:29

ja klar alle amd user sind Fanboys ...

Den deine Aussage beinhaltet ja das sich keinerlei AMD user dazu melden

Ach ja ich bin ein NV user und ausgenommen Witcher 2 merke ich keinen unterschied ^^

Skysnake

2013-04-19, 20:20:06

Lad die Videos runter und vergiss den Youtube schice. Wenn du dann keinen Unterschied siehst, brauchst du hier nicht mehr mitreden.
Les doch was ich schreibe...

Ich hab durchaus einen geringfuegigen Unterschied wahrgenommen, ich konnte aber nicht sagen, ob das jetzt Einbildung oder wirklich wahrgenommen war....

Ohne die 50/20% haette ich daher gesagt, das beides etwa gleich gut ist, wenn auch tendenziell eher das inke Video besser aussah. Ohne eigene Steuerung faellt es halt schwer, die Ruckler durch die Maus von den Rucklern durch die geringen/ungleichmaessigen FPS zu unterscheiden...

Wenn er es nicht sieht, hat doch die ganze Debatte überhaupt keinen Sinn für ihn. Er kann sogar froh darüber sein, weil dann hat ein Kaufkriterium weniger zu beachten ;)
Wie gesagt, ich habs sogar gemerkt. Ich wuerde aber nicht meine Hand dafuer ins Feuer legen, das ich bei einem doppelten Blindtest, bei dem man auch die gleichen Settings vorgesetzt bekommt, das zielsicher auseinander zu halten.

Leider wird man durch die 50/20% genau dem leider beraubt.

Die Umfrage ist daher, wie gesagt, leider so nicht brauchbar.

Schaffe89

2013-04-24, 13:51:54

Hier mal neues Futter:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-AMD-Improves-CrossFire-Prototype-Driver

http://www.computerbase.de/news/2013-04/amd-mit-neuem-alpha-catalyst-treiber-gegen-mikroruckler/

Die Lösung scheint wohl von der usability doch etwas besser zu sein wie diese von Nvidia, immerhin gibt AMD eine optionale Möglichkeit dies einzustellen.

Grestorn

2013-04-24, 13:57:58

Alles von AMD ist besser als von nVidia und verursacht natürlich auch keinen zusätzlichen Lag. Das wussten wir alle vorher schon, nicht wahr? :)

Iruwen

2013-04-24, 14:11:51

Klar. AMD braucht zwar immer Jahre um ein Problem zu sehen, zuzugeben und dann auch noch an einer Lösung zu arbeiten, aber dann ist sie auf jeden Fall besser als die von Nvidia(!!1) Bis die dann halt eine noch bessere Lösung einbauen und AMD sich zurücklehnt. Siehe LOD.

Marty98

2013-04-24, 14:12:21

Ja, von AMD ist grundsätzlich alles besser. Kann auch Skysnake bestätigen.

derguru

2013-04-24, 14:17:27

Iruwen

2013-04-24, 14:38:46

Der PCPer Artikel hat mehrere Seiten :D

derguru

2013-04-24, 14:53:28

tatsächlich:tongue:
sieht ja so gut wie identisch aus.

boxleitnerb

2013-04-24, 15:56:52

Godmode

2013-04-24, 16:02:43

Jetzt wo er die Verbesserung auch gemessen sieht (und im Video), findet Schaffe89 Framemetering/Framepacing (bloß nicht gleich nennen! :D) ganz toll. Aber laut eigener Aussage kann er doch keinen Unterschied zwischen SLI und CF erkennen (wenn er beides jemals gehabt hat, was ich bezweifle).

Sehr schönes Video, wer das vorher nicht gesehen hat, ist blind und sollte überhaupt nicht mitreden:
https://www.youtube.com/watch?v=RIFYyDV3DKs

Am besten noch runterladen, da sieht man es noch besser:
http://api.viglink.com/api/click?format=go&key=88281df3c93f01757eeab9ef578fd1d3&loc=http%3A%2F%2Fwww.pcper.com%2Freviews%2FGraphics-Cards%2FFrame-Rating-AMD-Improves-CrossFire-Prototype-Driver&v=1&libid=1366812129515&out=https%3A%2F%2Fmega.co.nz%2F%23!1ZsV2SJb!KXdgUWSoRGGtGdv5fGNsfX6lV_5a0_uszuJY 1yQuEzo&ref=http%3A%2F%2Fwww.pcper.com%2Freviews&title=Frame%20Rating%3A%20AMD%20Improves%20CrossFire%20with%20Prototype%20Driver %20%7C%20PC%20Perspective&txt=Download%20the%20250MB%20MP4%20from%20Mega.co.nz&jsonp=vglnk_jsonp_13668121565983

Schaffe89

2013-04-24, 16:31:27

Alles von AMD ist besser als von nVidia und verursacht natürlich auch keinen zusätzlichen Lag. Das wussten wir alle vorher schon, nicht wahr?

Ich habe nie gesagt die Lösung sei schlecht, was willst du von mir? Bitte quote doch mal diese Aussage, da bin ich aber gespannt.
Ich finde AMD´s Lösung nicht besser, sondern es besser Framepacing optional zuschalten zu können.

zuzugeben und dann auch noch an einer Lösung zu arbeiten, aber dann ist sie auf jeden Fall besser als die von Nvidia(!!1)

Wer sagt das? Die Qualität lässt sich doch bisher noch eher wenig einschätzen, es geht aber schonmal in die richtige Richtung.
Aber hauptsach wieder mal so tun als ob man nicht lesen kann, damit wieder die Stimmung hier hochkocht.. lol

Das wussten wir alle vorher schon, nicht wahr?

Es geht mit um die Optionalität, welche doch bei dir sonst ach groß geschrieben wird, wenn du von Nvidia redest.
Jetzt hat AMD scheinbar einen Tesselationsschalter und einen Frame Pacing Schalter, Nvidia hat von den beiden Funktionen nichts.

Aber laut eigener Aussage kann er doch keinen Unterschied zwischen SLI und CF erkennen (wenn er beides jemals gehabt hat, was ich bezweifle).

Richtig ich merke bei meiner bisherigen Spieleausswahl keinen Unterschied, heißt ja nicht dass andere das auch so sehen müssen, ich habe auch nie gesagt dass meine Meinung für alle gilt.
Mir ging es nur darum dass eben Frame Pacing auch Nachteile hat, welche der AMD Merketingfuzzi im CB Interview anspricht, aber jene wolltest vor allem du nicht akzeptieren.

Sehr schönes Video, wer das vorher nicht gesehen hat, ist blind und sollte überhaupt nicht mitreden:

Im Video sieht man es eindeutig, aber was hat das mit meiner damaligen Aussage zu tun? Ich habe gesagt ich sehe in der Praxis keinen Unterschied.
Du vermischst Aussagen aus unterschiedlichen Schverhalten, spar dir doch sowas.

(wenn er beides jemals gehabt hat, was ich bezweifle).

Zweifel du nur grundlos alles an, mir soll das egal sein, aber bitte verhalte dich mal sachlich.
Wenn du Lust hast kann ich dir ja mal ein Bild schicken, wo man SLI CF in meinem System mit Namenszettel sieht.

boxleitnerb

2013-04-24, 16:32:14

Das habe ich nicht gesagt, du hast falsch zitiert und falsch gelesen.

Jup, ich persönlich kann keinen Unterschied feststellen zwischen Nvidia SLI und CF und greife wegen der billigeren Karten lieber zu CF
http://www.hardwareluxx.de/community/f14/amd-radeon-hd-7990-kommt-am-22-april-update-953845-6.html#post20491684

Was interessiert dich dann das Framepacing überhaupt? Scheint ja für dich auch ohne zu gehen. Wobei das absolut unvorstellbar für mich ist, wenn ich mir die Videos bei PCPER anschaue. Ist halt wie üblich - wenn die Lieblingsfirma was nicht hat, ist es egal, man spürt/sieht keinen Unterschied. Wenn sie dann Jahre verspätet damit ankommt, ist es toll und man freut sich, dass sie gleichauf ist (bleibt abzuwarten) :D

LSSJBroly

2013-04-24, 17:02:18

Am besten noch runterladen, da sieht man es noch besser:
http://api.viglink.com/api/click?format=go&key=88281df3c93f01757eeab9ef578fd1d3&loc=http%3A%2F%2Fwww.pcper.com%2Freviews%2FGraphics-Cards%2FFrame-Rating-AMD-Improves-CrossFire-Prototype-Driver&v=1&libid=1366812129515&out=https%3A%2F%2Fmega.co.nz%2F%23!1ZsV2SJb!KXdgUWSoRGGtGdv5fGNsfX6lV_5a0_uszuJY 1yQuEzo&ref=http%3A%2F%2Fwww.pcper.com%2Freviews&title=Frame%20Rating%3A%20AMD%20Improves%20CrossFire%20with%20Prototype%20Driver %20%7C%20PC%20Perspective&txt=Download%20the%20250MB%20MP4%20from%20Mega.co.nz&jsonp=vglnk_jsonp_13668121565983

Wenn der neue Treiber wirklich eine solche verbesserung bringt, hammer. Ich meine, das video mit dem 13.5 beta ist ja kaum auszuhalten, wirkt so wie 25 oder 30Fps... Und rechts... kein Vergleich:) Gut, dass da verbessert wird.

Knuddelbearli

2013-04-24, 17:03:46

Was interessiert dich dann das Framepacing überhaupt? Scheint ja für dich auch ohne zu gehen. Wobei das absolut unvorstellbar für mich ist, wenn ich mir die Videos bei PCPER anschaue. Ist halt wie üblich - wenn die Lieblingsfirma was nicht hat, ist es egal, man spürt/sieht keinen Unterschied. Wenn sie dann Jahre verspätet damit ankommt, ist es toll und man freut sich, dass sie gleichauf ist (bleibt abzuwarten) :D

Weill er es bei AMD im Gegensatz zu NV dann einfach ausschalten kann wenn er eh nichts davon merkt.

aufkrawall

2013-04-24, 17:08:45

Frame Pacing kostet bei SLI häufig nur geringfügig Leistung, sonst gäbe es seltener eine Skalierung von ~90% und 100% bei den min-fps.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=541160

Daher ist es ziemlich wurst, dass man es bei Nvidia nicht ausschalten kann.
Mir fällt kein Spiel ein, wo ich das machen würde.

Knuddelbearli

2013-04-24, 17:23:40

also ich reagioere scheinbar sogut wie garnicht auf MR ( einzig bei einem Witcher 2 Vergleichsvideo ist mir das mal aufgefallen ) aber sehr massiv auf Inputlag. Vor allem der schwankende Inputlag ( Bild 1 wird berechnet und sofort ausgegeben bild 2 wird 10ms später berechnet aber erst 30ms später ausgegeben bild 3 dann wieder sofort da usw ) würde mich bei manchen Spielen vermutlich massiv stören.
Das ist / war mein Kritikpunkt ja schon immer beim dyn Vsynch.
und im Zweifelsfall ist selber entscheiden immer besser als Vorgabe, sonst halten die NV user doch immer soviel darauf das sie beim Inspector soviel einstellen kann was man aber eigentlich nie braucht.

Ich habe mir auch wegen den ganzen Einstellungssachen eine NV gekauft, habe inzwischen aber einfach festgestellt das man sie außer zum rumprobieren ( abgesehen von SSAA ) sogut wie nie nutzt. Da finde ich dann die direkte Integration von SSAA usw in den Treiber bei AMD einfach sinnvoller und bequemer.

Aber vieleicht ist die Wiese auf der anderen Seite des Baches nur immer grüner? Mal schauen wie es nach 12 Jahren NV aussieht. Momentan wart ich noch auf die 8000er

aufkrawall

2013-04-24, 17:40:50

also ich reagioere scheinbar sogut wie garnicht auf MR ( einzig bei einem Witcher 2 Vergleichsvideo ist mir das mal aufgefallen ) aber sehr massiv auf Inputlag. Vor allem der schwankende Inputlag ( Bild 1 wird berechnet und sofort ausgegeben bild 2 wird 10ms später berechnet aber erst 30ms später ausgegeben bild 3 dann wieder sofort da usw ) würde mich bei manchen Spielen vermutlich massiv stören.
Das ist / war mein Kritikpunkt ja schon immer beim dyn Vsynch.
und im Zweifelsfall ist selber entscheiden immer besser als Vorgabe, sonst halten die NV user doch immer soviel darauf das sie beim Inspector soviel einstellen kann was man aber eigentlich nie braucht.

Wenn du eine Inputlag-Hure bist, mach halt Nvidias AFR-Vsync an.
Fluppt in BF3 wunderbar.

Ich habe mir auch wegen den ganzen Einstellungssachen eine NV gekauft, habe inzwischen aber einfach festgestellt das man sie außer zum rumprobieren ( abgesehen von SSAA ) sogut wie nie nutzt.

OT?
Sehe ich übrigens anders, bei AMD kann man ja nicht mal Vsync über den Treiber erzwingen...
Hatte vor nicht mal einem Jahr Tahiti XT, kann mich noch gut dran erinnern.

Da finde ich dann die direkte Integration von SSAA usw in den Treiber bei AMD einfach sinnvoller und bequemer.

Bitte?
Nvidia bietet kein SGSSAA über den Treiber an, oder was...
Bequemer im Sinne von geht nicht, auch toll.

Aber vieleicht ist die Wiese auf der anderen Seite des Baches nur immer grüner? Mal schauen wie es nach 12 Jahren NV aussieht. Momentan wart ich noch auf die 8000er
Kann heilsam sein.

boxleitnerb

2013-04-24, 17:59:32

Mir ging es nur darum dass eben Frame Pacing auch Nachteile hat, welche der AMD Merketingfuzzi im CB Interview anspricht, aber jene wolltest vor allem du nicht akzeptieren.

Das stimmt doch überhaupt nicht, bleib mal bei der Wahrheit.
Es ging mir immer nur um die Frage, wie relevant dieser Lag ist - nicht ob er überhaupt existiert. Wäre das so ein Problem (wie die Mikroruckler), wäre das längst irgendwo erwähnt worden. Wurde es aber nie, es ging immer nur um die Mikroruckler, die spürbar und sichtbar sind, und das auf breiter Basis in praktisch jedem Spiel. Von diesem Lag abseits der sowieso auftretenden AFR-Lags, war jahrelang nie etwas zu lesen. Es ist natürlich jetzt einfach, den Lag als Problem darzustellen, NACHDEM er in ca. 10 Jahren AFR-Geschichte erstmals so richtig thematisiert wird und wo sich die ganze Zeit über nie jemand beschwert hat. Genau DAS finde ich ja das Abstruse.
Bei den Mikrorucklern war es genau andersherum - die springen einen auch so an, wenn man von ihner Existenz überhaupt nichts weiß. Da muss man nicht groß suchen und theoretisieren, denn die sind schwerwiegend und Realität. Tombman hat sich sicher nicht hingesetzt und sich gedacht "Hm, werfen wir mal Fraps an, könnte ja was Interessantes bei rauskommen." Ursache und Wirkung.

Skysnake

2013-04-24, 18:07:01

Ja, von AMD ist grundsätzlich alles besser. Kann auch Skysnake bestätigen.
Bullshit,

die "Lösung" ist genau so bescheiden wie die von nVidia, weil sie nur Sympthome bekämpft, aber nicht an der Wurzel des Übels angreift.

Man kann es aber wenigstens ausschalten.

Optimal wäre aber, wenn die Engine mit Daten gefüttert werden könnte, und dadurch eben Ingametime und Displaytime immer versucht spekulativ anzugleichen.

boxleitnerb

2013-04-24, 18:17:10

Ich dachte so weit sind wir noch gar nicht. Man müsste zwei GPUs mit niedrigsten Latenzen und sehr breitbandig miteinander und mit dem Speicher verbinden, damit man auf AFR verzichten kann. Das lohnt sich wohl noch nicht oder ist nicht machbar.

Zudem wäre es auch nicht realisierbar mit mehreren Steckkarten. 3- oder 4-way AFR würde das Nachsehen haben. Zwei getrennte Karten finde ich auch immer besser, sieht man ja an der 690. Mit 2GB wollte ich SLI nicht machen. AMD und Nvidia würden aber weiterhin nur ein Modell auflegen und man wäre daran gebunden, auch beim Verbrauch wegen begrenzten Kühlmöglichkeiten :(

Skysnake

2013-04-24, 18:25:13

Das stimmt doch überhaupt nicht, bleib mal bei der Wahrheit.
Es ging mir immer nur um die Frage, wie relevant dieser Lag ist - nicht ob er überhaupt existiert. Wäre das so ein Problem (wie die Mikroruckler), wäre das längst irgendwo erwähnt worden. Wurde es aber nie, es ging immer nur um die Mikroruckler, die spürbar und sichtbar sind, und das auf breiter Basis in praktisch jedem Spiel. Von diesem Lag abseits der sowieso auftretenden AFR-Lags, war jahrelang nie etwas zu lesen. Es ist natürlich jetzt einfach, den Lag als Problem darzustellen, NACHDEM er in ca. 10 Jahren AFR-Geschichte erstmals so richtig thematisiert wird und wo sich die ganze Zeit über nie jemand beschwert hat. Genau DAS finde ich ja das Abstruse.
Bei den Mikrorucklern war es genau andersherum - die springen einen auch so an, wenn man von ihner Existenz überhaupt nichts weiß. Da muss man nicht groß suchen und theoretisieren, denn die sind schwerwiegend und Realität. Tombman hat sich sicher nicht hingesetzt und sich gedacht "Hm, werfen wir mal Fraps an, könnte ja was Interessantes bei rauskommen." Ursache und Wirkung.
Dann mach die Augen auf...

Es wird allenhalben von den Redaktionen davon berichtet, dass die Werte, die FCAT ausspuckt, und das was man als User wahrnimmt teilweise eklatant auseinander driften. Was willst du noch? Mach halt die Augen auf...

Ich dachte so weit sind wir noch gar nicht. Man müsste zwei GPUs mit niedrigsten Latenzen und sehr breitbandig miteinander und mit dem Speicher verbinden, damit man auf AFR verzichten kann. Das lohnt sich wohl noch nicht oder ist nicht machbar.

Zudem wäre es auch nicht realisierbar mit mehreren Steckkarten. 3- oder 4-way AFR würde das Nachsehen haben. Zwei getrennte Karten finde ich auch immer besser, sieht man ja an der 690. Mit 2GB wollte ich SLI nicht machen. AMD und Nvidia würden aber weiterhin nur ein Modell auflegen und man wäre daran gebunden, auch beim Verbrauch wegen begrenzten Kühlmöglichkeiten :(
Und? Es gibt immer Kollateralschäden...

Lieber das Problem an der Wurzel angreifen, und dann eben keine Multi-GPU mit mehreren Karten mehr, als dieses rumgedocktore an den Sympthomen...

boxleitnerb

2013-04-24, 18:30:59

Dann mach die Augen auf...

Es wird allenhalben von den Redaktionen davon berichtet, dass die Werte, die FCAT ausspuckt, und das was man als User wahrnimmt teilweise eklatant auseinander driften. Was willst du noch? Mach halt die Augen auf...

Wie ich schonmal gesagt habe:
Das sind keine belastbaren Hinweise für einen Lag im Sinne von Verzögerung zwischen Spielzeit und Ausgabezeit. Was ich will? Konkretes - nicht so lange suchen, bis man um 5 Ecken herum vielleicht irgendwas in irgendwelche schwammigen Aussagen hineininterpretieren kann.

Bis heute war es dir ja nicht möglich, etwas in dieser Richtung zu liefern.

Und? Es gibt immer Kollateralschäden...

Lieber das Problem an der Wurzel angreifen, und dann eben keine Multi-GPU mit mehreren Karten mehr, als dieses rumgedocktore an den Sympthomen...

Grundsätzlich stimme ich dir da zu. Heißt nicht, dass ich mit den negativen Auswirkungen zufrieden sein muss.

Skysnake

2013-04-24, 19:11:47

Dann beschaff mir den Source Code von FCAT, dann mach ich mich dran, die deine "Beweise" zu liefern...

Vielleicht hast du mehr Glück bei nVidia.

boxleitnerb

2013-04-24, 19:18:06

Ich mach nicht deine Arbeit. Du reitest auf dem Thema rum, kümmer dich gefälligst selbst drum. Dazu brauchst du auch kein FCAT - kauf dir zwei Geforces oder eine 690 und zwei AMDs und spiel mal 1-2 Wochen damit. Dann kannst du uns sicher was zum Lag berichten. Dann gibt es auch keine Ausrede mehr, dass du den Sourcecode nicht bekommst...

Skysnake

2013-04-24, 19:23:56

LOL...

Die Berichte von den Redaktionen ignorierst du, weil Sie nicht so "gut" sind wie die Ergebnisse von FCAT, aber ich soll jetzt mir die Dinger kaufen, und dann davon berichten, und dem glaubst du dann? ;D

Made my day...

Und bzgl nVidia. Stell dir mal vor, ich hab mich schon drum gekümmert. Mehr als du...
nVidia hat nur scheinbar keinen Bock, das Zeug raus zu rücken.... Jetzt rate mal warum...

aufkrawall

2013-04-24, 19:36:49

Die Berichte von den Redaktionen ignorierst du

Welche genau?

boxleitnerb

2013-04-24, 19:37:40

Wie oft willst du das noch behaupten? Es gibt keine Berichte über Verzögerungen (ich spreche wie schon im Luxx erwähnt explizit nicht von Rucklern - die sehe ich mit Framemetering ja selbst unter gewissen Bedingungen! - sondern von Delays)!!!
Ist das jetzt ein für alle Mal klar oder hast du es immer noch nicht verstanden?

Ich muss mich um nichts kümmern, ich bin ja nicht derjenige, der irgendwelche nicht bewiesenen Probleme in allen Foren breittreten zu versucht. Du redest und redest und redest und theoretisierst bis uns allen das Blut aus den Augen kommt. Aber irgendwas Konkretes hört man von dir nie auf Nachfrage. Da können krawall, ich und andere uns auf den Kopf stellen und 100x Fragen, da wird nichts kommen, weil du nix hast.

Btw weil das Interview mit AMD angesprochen wurde:
Natürlich sagen sie, dass sie das Framepacing bisher nicht gemacht haben, weil es auch Nachteile habe. Eine andere Begründung können sie auch gar nicht bringen. Oder erwartet man eine Antwort wie "Hat uns nicht interessiert, die Leute kaufen unsere Karten auch so" oder "Wir können es nicht" etc? Reichlich naiv. Will sagen - darauf darf man sich beim besten Willen nicht stützen.

Schaffe89

2013-04-24, 20:35:44

Und du bist vielzu unkritisch, selbst Wolle von CB ist da anderer Meinung.
Die Wahrheit liegt bekanntlich genau in der Mitte, jedenfalls meistens.

aufkrawall

2013-04-24, 20:38:11

Godmode

2013-04-24, 20:42:45

AFR ohne Frame Pacing ist aber einfach idiotisch (Mikroruckler aus der Hölle), weshalb die ganze Diskussion bzw. die Argumente für Optionalität dessen einfach nur überflüssig ist.
Mit Limiter/Vsync spielt es ja auch eh kaum noch eine Rolle...

Ja das kann ich so nur unterschreiben. Genau aus diesem Grund, habe ich damals mein 570er SLI wieder aufgelöst. Der Zugewinn der zweiten Karte war einfach nicht wirklich brauchbar.

Ich finde es gut das jetzt etwas Bewegung in die Sache reinkommt und wenn ich nicht total falsch liege, wird Nvidia in den nächsten Wochen/Monaten mit was tollem nachlegen. Schade ist es, dass das alles so lange dauert bei AMD. Die ganzen Enthusiasts lassen sie damit einfach liegen.

Skysnake

2013-04-24, 20:43:06

Godmode

2013-04-24, 20:48:20

Also schalt mal nen Gang runter, und denk mal drüber nach, warum nVidia hier so rumbockt, und die Sourcen nicht rausrückt..

Sie haben doch gesagt, dass sie das zur Zeit nicht können, da sie damit lizenzierte Patente verletzen würden.

boxleitnerb

2013-04-24, 20:51:58

Witzbold...

Wie soll man denn etwas liefern, was FCAT NICHT misst, wenn nVidia die Sourcen nicht rausrückt... Auch auf NACHFRAGE nicht!!!

Also mach mich nicht dumm von der Seite an... Es liegt NICHT an mir, das ich die Sachen nicht liefern kann, sondern an nVidia... Also schalt mal nen Gang runter, und denk mal drüber nach, warum nVidia hier so rumbockt, und die Sourcen nicht rausrückt..

Wieder FCAT...seufz.
Natürlich liegt es an dir. Denn wenn der Lag so problematisch wäre wie du ihn darstellst, könntest du ihn auch prima in der Praxis nachweisen - genau wie Mikroruckler. Da reicht ein simpler Vergleich CF/SLI in der Praxis. Von mir aus mit ein paar Kumpels als Blindtest. Dazu brauchst du kein FCAT.
Aber ist natürlich besser für dich, wenn Nvidia Schuld ist, dann kannst du mit dem Finger auf die zeigen, dich zurücklehnen und brauchst selbst keine eigenen Beweise liefern.

Schaffe89

2013-04-24, 21:54:40

AFR ohne Frame Pacing ist aber einfach idiotisch (Mikroruckler aus der Hölle), weshalb die ganze Diskussion bzw. die Argumente für Optionalität dessen einfach nur überflüssig ist.

Nicht wenn du trotzdem lieber einen Framelimiter hernimmst und nicht wenn es ohne Framepacing besser läuft als ohne, siehe den Test von Tomshardware, dort sind FCAT Testbeispiele wo AMD ohne Framepacing besser abschneidet, was wohl auch der Grund ist warum AMD einen Schalter einbaut.

Wäre dieser Schalter von Nvidia wäre das wieder ganz toll, ich weiß schon, die alte Leier.

aufkrawall

2013-04-24, 23:00:31

Nicht wenn du trotzdem lieber einen Framelimiter hernimmst und nicht wenn es ohne Framepacing besser läuft als ohne, siehe den Test von Tomshardware, dort sind FCAT Testbeispiele wo AMD ohne Framepacing besser abschneidet, was wohl auch der Grund ist warum AMD einen Schalter einbaut.

Nein. Der Framelimiter/Vsync setzt den zusätzlichen Input Lag von Frame Pacing (welcher bis jetzt wie schon 1000x von boxleitnerb gesagt von keinem Reviewer beanstandet wurde) außer Kraft und für die Performance spielt das FP wie gesagt auch nur eine untergeordnete Rolle.
Was gedenkst du also damit zu erreichen?
Es gibt keinen sinnvollen Anwendungsbereich, zumindest wenn man wie bei Nvidia gleichzeitig AFR-Vsync als zusätzliche Option hat.

Wäre dieser Schalter von Nvidia wäre das wieder ganz toll, ich weiß schon, die alte Leier.
Ich habe bereits geschrieben, dass ich nirgendwo FP ausschalten würde.
Glaub den AFR-Usern doch so was einfach mal, auch wenn sie nicht auf dein Lieblingsprodukt schwören. ;)

Schaffe89

2013-04-25, 00:34:34

welcher bis jetzt wie schon 1000x von boxleitnerb gesagt von keinem Reviewer beanstandet wurde)

Wie soll es denn auch beanstandet werden, wenn man zu 85% keinen Vergleich hat?
AMD µruckelt in der Regel mehr und das wird dannauch vom Großteil der Tester so gesehen und da hilft natürlich Framepacing.

Warum gehst du denn nicht auf die Messungen von Tomshwardware ein die zeigen, dass es auch ohne teils ganz gut lüppt, warum soll ich in jenen Fällen noch ein Framepacing aktivieren und womöglich Performance einsparen?

Ich habe bereits geschrieben, dass ich nirgendwo FP ausschalten würde.

Klar, du als Nvidianutzer kannst es ja nicht ausschalten. ;) Eine andere Option bleibt dir nicht.

Ich stelle die Aussagen der AFR User nicht in Abrede, nur wenn es Messwerte ohne Framepacing gibt die zeigend ass die 95 Percentil Werte besser als bei NV mit Framepacing sind, warum soll ich es dann aktivieren?
Beantworte doch mir mal ganz konkret diese Frage.

Dass Framepacing generell besser ist,steht außer Frage, jenes habe ich auch nie angezweifelt.

Skysnake

2013-04-25, 00:48:18

Sie haben doch gesagt, dass sie das zur Zeit nicht können, da sie damit lizenzierte Patente verletzen würden.
Wo?

Und vor allem, was soll da lizensiert sein? Das hört sich mehr nach einer Schutzbehauptung an als nach allem anderen....

http://extreme.pcgameshardware.de/nvidia-themenabend-04-2013/270063-fcat-und-die-probleme-damit.html
Da hörte sich das auch GANZ anders an... Es kam dann aber nichts mehr...

Ich hab ihn jetzt auch nochmals angeschrieben, auch wenn ich nicht glaube, das da noch was kommt.

Wieder FCAT...seufz.
Natürlich liegt es an dir.

Ich habe getan was möglich war. Wenn jemand ein Tool rauswirft, und fett die Werbetrommel damit schlägt, dann muss er auch auf Kritik reagieren, und Verbesserungen annehmen. Wenn nicht macht man sich unglaubwürdig.

Denn wenn der Lag so problematisch wäre wie du ihn darstellst, könntest du ihn auch prima in der Praxis nachweisen - genau wie Mikroruckler.

Dann sag mir wie. Eine Methode, wie es geht, habe ich schon mehrfach genannt, es scheitert aber an der Blockade von nVidia.

Die Berichte von PCGH, CB usw usw, das es eben AUCH bei nVidia trotz ihrer "göttlichen" Bildausgabe laut FCAT, Ruckler gibt, ignorierst du ja.

Das ist ja das Shizophrene bei dir.... Du sagst nVidia ist super duper toll, genau wie FCAT auch, verleugnest aber teilweise die Ergebnisse von FCAT. Laut denen dürfte es nämlich GAR KEINE! Ruckler geben im großen und ganzen. Das entspricht aber nicht der Realität.

Da reicht ein simpler Vergleich CF/SLI in der Praxis. Von mir aus mit ein paar Kumpels als Blindtest. Dazu brauchst du kein FCAT.
Aber ist natürlich besser für dich, wenn Nvidia Schuld ist, dann kannst du mit dem Finger auf die zeigen, dich zurücklehnen und brauchst selbst keine eigenen Beweise liefern.
Das ist lächerlich, und wenn du das nicht selbst weißt, dann tuts mir echt leid. Man kann die Effekte, die zu einem unrunden Spielerlebnis führen NICHT unterscheiden. Da wäre es sogar um welten einfacher die FPS auf +/- 2 FPS genau mit blosem Auge zu bestimmen....

Du machst es dir wirklich sehr einfach. Warum tust du dir so schwer dabei, das prinzipielle Problem anzuerkennen, und das man dem eben auf dem Grund gehen muss, da ansonsten das was FCAT ausspuckt eben nur die halbe Wahrheit ist?

Gipsel hat sich seltsamerweiße überhaupt nicht schwer dabei getan, meiner Argumentation zu folgen, und ich hoffe du willst jetzt nicht behaupten, das er eben ein Noob ist, der von tuten und blasen keine Ahnung hat...

Dass Framepacing generell besser ist,steht außer Frage, jenes habe ich auch nie angezweifelt.
Generell nicht, aber meistens. Das ist ein kleiner aber feiner Unterschied.

Schaffe89

2013-04-25, 01:56:28

Genau das meinte ich eig. danke.

Boxleitnerb is halt ein Nvidia User, was sollman machen?
Auch wenn noch so viele Seiten wie die PCGH oder CB von einem unrunden Spielgefühl trotz FRamepacing berichten muss es weitere Gründe geben was die Bildausgabe unregelmäßig werden lässt.

Höchstwahrscheinlich der Lag oder eher noch naheliegender die Display vs. Ingamezeit, welche der AMD Marktetingfuzzi anspricht, was eigentlich wieder einem Lag gleichkommt und wir wieder am Anfang sind.

boxleitnerb

2013-04-25, 08:31:42

Ich habe getan was möglich war. Wenn jemand ein Tool rauswirft, und fett die Werbetrommel damit schlägt, dann muss er auch auf Kritik reagieren, und Verbesserungen annehmen. Wenn nicht macht man sich unglaubwürdig.

Dann sag mir wie. Eine Methode, wie es geht, habe ich schon mehrfach genannt, es scheitert aber an der Blockade von nVidia.

Die Berichte von PCGH, CB usw usw, das es eben AUCH bei nVidia trotz ihrer "göttlichen" Bildausgabe laut FCAT, Ruckler gibt, ignorierst du ja.

Das ist ja das Shizophrene bei dir.... Du sagst nVidia ist super duper toll, genau wie FCAT auch, verleugnest aber teilweise die Ergebnisse von FCAT. Laut denen dürfte es nämlich GAR KEINE! Ruckler geben im großen und ganzen. Das entspricht aber nicht der Realität.

Das ist lächerlich, und wenn du das nicht selbst weißt, dann tuts mir echt leid. Man kann die Effekte, die zu einem unrunden Spielerlebnis führen NICHT unterscheiden. Da wäre es sogar um welten einfacher die FPS auf +/- 2 FPS genau mit blosem Auge zu bestimmen....

Du machst es dir wirklich sehr einfach. Warum tust du dir so schwer dabei, das prinzipielle Problem anzuerkennen, und das man dem eben auf dem Grund gehen muss, da ansonsten das was FCAT ausspuckt eben nur die halbe Wahrheit ist?

Gipsel hat sich seltsamerweiße überhaupt nicht schwer dabei getan, meiner Argumentation zu folgen, und ich hoffe du willst jetzt nicht behaupten, das er eben ein Noob ist, der von tuten und blasen keine Ahnung hat...

Du kannst nicht lesen oder du bist ein Troll, der hier lügt, dass die Balken sich biegen. Anders kann ich mir dein Geschreibsel nicht erklären.

Du schreibst dauernd was von Rucklern, aber um die geht es doch überhaupt nicht. Es geht um den zusätzlichen Lag (Verzögerung, Delay, Inputlag - den AMD auch anspricht).

Ruckler = Stuttering != Lag
Zumindest in meinem Sprachgebrauch nicht!

Ich verleugne also überhaupt nichts, denn ich habe nie behauptet, dass ich mit SLI überhaupt keine Ruckler empfinde. Ich habe hingegen gesagt, dass ich im Großen und Ganzen ab ca. 50fps komfortabel ohne Ruckeln spielen kann. Das ist etwas völlig anderes! Denn Ausnahmen gibt es immer. Auch das habe ich gesagt.

Und hör bitte auf, ewig auf FCAT herumzureiten. FCAT ist hier nicht primär das Thema. Das Thema zwischen uns war und ist, ob durch Framemetering ein störender Inputlag entsteht, der die Direktheit der Steuerung beeinflusst.

Dass Nvidia mit dem Framemetering gelegentlich Frames verschieben muss, bestreite ich nicht und hab ich nie - sie haben ja schließlich keine Zeitmaschine, es kann nicht anders funktionieren. Die Kernfrage ist nicht ob eine Verschiebung stattfindet, sondern ob sie so negativ spürbar ist, dass sich das Framemetering u.U. gar nicht mehr lohnt.
Und um das festzustellen, reicht erstmal ein Vergleich CF (das kein FM hat) mit SLI (welches FM hat). Denn egal was man misst - auf die Praxis kommt es doch an. Meinst du nicht, die ganzen CF/SLI-Wechsler, egal in welche Richtung, hätten sich in den letzten 5+ Jahren nichtmal zu Wort gemeldet, wenn das spürbar gewesen wäre?

Genau das meinte ich eig. danke.

Boxleitnerb is halt ein Nvidia User, was sollman machen?
Auch wenn noch so viele Seiten wie die PCGH oder CB von einem unrunden Spielgefühl trotz FRamepacing berichten muss es weitere Gründe geben was die Bildausgabe unregelmäßig werden lässt.

Höchstwahrscheinlich der Lag oder eher noch naheliegender die Display vs. Ingamezeit, welche der AMD Marktetingfuzzi anspricht, was eigentlich wieder einem Lag gleichkommt und wir wieder am Anfang sind.

Und Schaffe89 versteht wieder gar nicht, worum es geht und packt deshalb die Fanboykeule aus, statt auf das Geschriebene einzugehen.
"Unrundes Spielgefühl" ist genausowenig ein konkreter Hinweis auf Inputlag wie "bunt" ein konkreter Hinweis auf grün ist. Framemetering ist nicht perfekt, es kann dennoch Ruckler geben. Mit einem Lag hat das erstmal nichts zu tun. Und btw, du willst doch nicht ernsthaft die Ergebnisse eines schnell zusammengeschusterten Alpha-Treibers hier zur Diskussion heranziehen, ob Framepacing auch Nachteile haben kann oder nicht???

Iruwen

2013-04-25, 09:11:25

Die Diskussion ist doch fruchtlos, ich würde auch nicht mit jemandem drüber diskutieren wie man die Nordschleife am schnellsten nimmt der noch nie in einem Auto gesessen hat :freak:
Wenn sich hier jemand äußern sollte dann die Leute von HT4U, CB oder PCGH die sich tatsächlich in der Praxis mit solchen Systemen befassen und nicht nur Theorycrafting betreiben.

Skysnake

2013-04-25, 10:35:58

Boxleitnerb, dabei sitzt du aber einem Denkfehler auf.

Du kanns tnicht unterscheiden, ob ein "Ruckler" durch das Auslassen eines Frames entsteht, oder durch das Verschieben eines Frames.

Und ein Verschieben eines Frames verursacht immer! einen Lag. Wie du richtig erkannt hast, nVidia kann nicht zaubern.

Ein Ruckler ist ja nichts anderes als eine zu große Variation in delta_t=Ingametime-Displaytime .

Und dafür gibt es mehrere Gründe, entweder es wird ein Frame gar nicht auf dem Display angezeigt,oder man verschiebt eben zu weit. Der Effekt (Ruckler) ist der Gleiche und kann apriori nicht ohne technische Hilfsmittel differenziert werden. Dafür müsste man nämlich jeden einzelnen Frame mit den Augen analysieren können, und das ist schlicht unmöglich ohne Hilfsmittel.

Deine Beobachtung, das ab einer Bildrate im Bereich der Refreshrate die Problematik nachlässt ist btw auch überhauptnicht verwundelich, da das Delta_t der maximalen Verschiebung sich reduziert.

Ab einem gewissen Punkt kann man eben die Verschiebung nicht mehr Wahrnehmen. Ob das Bild jetzt 2ms früher oder später kommt wirst du nicht erkennen können. Wenns aber 8ms+ sind, wirst du das eventuell schon wahrnehmen könne.

Das Problem hierbei ist vor allem, das AUCH! in Spielen heutzutage meist die Ingamezeit nicht mehr statische Werte zwischen den einzelnen Bildern hat, sondern variabel ist, und eben auch mal daneben liegen kann, weil man eine andere Zeitspanne erwartet hat. Rein statistisch gesehen muss es schon Fälle geben, wo sich diese Effekte sich negativ aufsummieren. Und genau da wirst du meiner Meinung nach eben einen Ruckler dann wahrnehmen.

Mit der Theorie ließen sich alle Effekte erklären, die zu einem "unrunden" Spielgefühl beitragen. Mir fällt zumindest kein weiterer Effekt mehr ein, der noch mit rein spielen könnte.

Hübie

2013-04-25, 13:15:15

Na ja es gibt noch externe Faktoren wie Eingabegeräte, deren Port und auch ddie CPU. Das erzeugt ebenfalls Latenz. Denk auch mal an PCIe ;) Das summiert sich u.U. auf 25 ms und mehr. Dann merkt der ein oder andere Spieler schon ein inputlag.

maximus_hertus

2013-04-25, 13:32:42

Godmode

2013-04-25, 13:35:11

Wo?

Und vor allem, was soll da lizensiert sein? Das hört sich mehr nach einer Schutzbehauptung an als nach allem anderen....

PCPer: "Not only do we NEED to have these tools vetted by other editors, but we also depend on the community to keep us on our toes as well. When we originally talked with NVIDIA about this project the mindset from the beginning was merely to get the ball rolling and let the open source community and enthusiast gamers look at every aspect of the performance measurement. That is still the goal – with only one minor exception: NVIDIA doesn’t want the source code of the overlay to leak out simply because of some potential patent/liability concerns. Instead, we are hoping to have ANOTHER application built to act as the overlay; it may be something that Beepa and the FRAPS team can help us with."

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

Hübie

2013-04-25, 13:35:49

Das beste wäre 120 Hz bei 120 fps. Das braucht eine engine die frei skalieren kann. Das ist jedoch Träumerei.

ndrs

2013-04-25, 14:05:39

Ich wär ja dafür, dass man das zweite System, welches das Bild mitschneidet ebenfalls die Eingaben übernimmt, sprich eine Tastatur und Maus emuliert, welche an den PC, welcher das Spiel hostet, die entsprechenden Befehle sendet.
Damit müsste sich der Inputlag doch messen lassen. Zwar nicht der, den nur die GPU verursacht, sondern nur der gesamte, aber wenn man außer der Graka nichts am System verändert, sollte sich zumindest ein Vergleich anstellen lassen.
Oder hab ich da einen Denkfehler drin?

Schaffe89

2013-04-25, 14:38:49

Und Schaffe89 versteht wieder gar nicht, worum es geht und packt deshalb die Fanboykeule aus, statt au f das Geschriebene einzugehen.

Sry, aber man dreht sich mit dir schon so lange im Kreis bei dem Thema und du bist ja auch grade bekannt dafür mir Falschaussagen zu unterstellen, ich hätte gesagt Framepacing von Nvidia sei nicht besser als keins im Mittel, mir fällt kein Grund ein deine Sichtweise zu verstehen. Du willst "konkrete" Beweise dann schaffe dir bitte selbst welche oder lies Tests da ist genügend Futter vorhanden, welches zeigt das FCAT Bullshit misst, was die Bewertung dessen anbelangt.
Es ist völlig egal ob es nun als Lag Ruckler oder sonstiges beschrieben wird.
Denn es ist kein vergleichbarer Lag wie bei vsync, sondern einer der Ingame vs. Display Time zeitlich auseinanderlaufen lässt und dies in unregelmäßigen Abständen, deswegen ruckelt auch SLI und FCAT erfasst das nicht, sondern beschönigt die Werte und beschönigt ziemlich sicher auch die Werte von AMD, gerade deshalb will AMD den shice viellecht optional anbieten.

NVIDIA doesn’t want the source code of the overlay to leak out simply because of some potential patent/liability concerns.

Warum sagt Lars Weinand dann man könne ihn haben, wenn man wolle und sich anmelde? Kapier ich nicht.
Ich kann zwar grundsätzlich diese Patentgeschichte verstehen, aber wen zum Teufel interessiert das bei dem Tool, welche Patente sollen denn da verletzt werden? Solange Nvidia nicht sich bemügt ein anderweitiges Tool mit Open Source zu veröffentlichen oder zu veranlassen, bleib ich dabei dass das Tool nicht besser als Fraps ist um die wirkliche Frameausgabe zu bewerten, was ich schon gesagt hab als das Tool rausgekommen ist, aber da wurde man ja nur von allen Seiten deswegen angepisst.

boxleitnerb

2013-04-25, 15:32:12

Sry, aber man dreht sich mit dir schon so lange im Kreis bei dem Thema und du bist ja auch grade bekannt dafür mir Falschaussagen zu unterstellen, ich hätte gesagt Framepacing von Nvidia sei nicht besser als keins im Mittel, mir fällt kein Grund ein deine Sichtweise zu verstehen. Du willst "konkrete" Beweise dann schaffe dir bitte selbst welche oder lies Tests da ist genügend Futter vorhanden, welches zeigt das FCAT Bullshit misst, was die Bewertung dessen anbelangt.
Es ist völlig egal ob es nun als Lag Ruckler oder sonstiges beschrieben wird.
Denn es ist kein vergleichbarer Lag wie bei vsync, sondern einer der Ingame vs. Display Time zeitlich auseinanderlaufen lässt und dies in unregelmäßigen Abständen, deswegen ruckelt auch SLI und FCAT erfasst das nicht, sondern beschönigt die Werte und beschönigt ziemlich sicher auch die Werte von AMD, gerade deshalb will AMD den shice viellecht optional anbieten.

Ich habe das, was ich von dir gesagt habe auch per Zitat belegt. Ich bin nicht auf einem Lag rumgeritten, also muss ich auch nichts beweisen, ganz einfach. FCAT ist mir völlig egal, falls das bei euch noch nicht angekommen ist. Und um Ruckeln geht es mir auch nicht. Hab ich aber auch mehrfach gesagt. EOD.

Godmode

2013-04-25, 16:08:31

Das beste wäre 120 Hz bei 120 fps. Das braucht eine engine die frei skalieren kann. Das ist jedoch Träumerei.

Spiele gerade wieder Dishonored und da gehen 120 Hz mit 120 fps mit 8xAA + 8xSGSAA @ FullHD. Dafür brauche ich nur zwei Titan zu aktivieren. Das Spiel läuft so wirklich flüssig. Wenn ich 3 oder 4 GPUs aktiviere und dann noch 1.5 DS dazu nehme, ist es allerdings gleich um einiges zäher, obwohl die FPS noch bei 80-90 sind. IMO steigt die CPU Last mit 3 oder 4 GPUs enorm an, daher kann ich mit 1.5 DS die 120 FPS nicht mehr halten.

Angiesan

2013-04-25, 16:50:43

Ja ja und die Erde ist doch eine Scheibe!
@Boxleitnerb verstehst du jetzt warum ich nicht mehr diskutieren wollte:freak: Das was ich dir per pn geschrieben hatte in einem anderen Forum, lass es es würde eh nix bringen und in dem neuen Beta ist es auch nicht mehr ansprechbar wurde wieder auf locked gesetzt.

Grüße

Marty98

2013-04-26, 04:28:42

Botcruscher

2013-04-26, 09:30:33

Der sollte aber unter idealen Bedingungen messbar und konstant sein. Damit kann man ihn in Tests raus rechnen. Nicht schön aber ausreichend.

ndrs

2013-04-26, 09:37:14

Jede Signalübertragung und auch die Aufzeichnung selbst erzeugt etwas lag.
Das ist richtig. Allerdings wäre der von dir genannte Lag bei jeder verbauten Grafikkarte gleich. Wenn ich also eine Single-GPU als Optimum annehme und diesen Lag X mit einer AMD Dual-GPU mit dem LAG Y und einer nVidia Dual-GPU mit dem Lag Z vergleiche, kann ich doch direkt den durch Frame Metering oder was auch immer verursachten LAG Z-X bzw. Z-Y bestimmen. Dann kann ich zumindest eine Aussage treffen um wievel nV besser/schlechter ist als AMD.

Hübie

2013-04-26, 09:58:45

Spiele gerade wieder Dishonored und da gehen 120 Hz mit 120 fps mit 8xAA + 8xSGSAA @ FullHD. Dafür brauche ich nur zwei Titan zu aktivieren. Das Spiel läuft so wirklich flüssig. Wenn ich 3 oder 4 GPUs aktiviere und dann noch 1.5 DS dazu nehme, ist es allerdings gleich um einiges zäher, obwohl die FPS noch bei 80-90 sind. IMO steigt die CPU Last mit 3 oder 4 GPUs enorm an, daher kann ich mit 1.5 DS die 120 FPS nicht mehr halten.

Mensch. Nur 2000 Euro statt 4000? ;D Mit frei skalierbar meinte ich das bei mangelnder Rechenleistung dynamisch Details abgeschaltet werden können um immer das frame per second target halten zu können. Das ist aber dermaßen schwierig zu implementieren, dass es wie gesagt Träumerei bleibt.

robbitop

2013-04-26, 10:08:53

Das menschliche Gehirn ist darauf getrimmt, schnell passierende Änderungen zu erkennen. Wenn sich ständig die Detailstufen hin und her ändern würden, wäre das äußerst irritierend.
Außerdem könnte das nur im Nachhinein passieren. Also nach dem die fps einbrechen. Das heißt, dass man ständig einen Nachlauf hätte und damit die FPS auch nicht konstant wären.

Um FPS konstant und hoch halten zu können, kann man leider nur mit deutlich überdimensionierter Leistung (im Verhältnis zum Leistungsbedarf des Spiels) agieren.

Godmode

2013-04-26, 11:33:02

Mensch. Nur 2000 Euro statt 4000? ;D Mit frei skalierbar meinte ich das bei mangelnder Rechenleistung dynamisch Details abgeschaltet werden können um immer das frame per second target halten zu können. Das ist aber dermaßen schwierig zu implementieren, dass es wie gesagt Träumerei bleibt.

Achso meintest du das. Ich glaube bei Rage wurde doch sowas in der Art versucht, oder?

Hübie

2013-04-26, 12:41:46

Na ja ausgehend von 120 fps hast du alle 8,333 Sekunden den Bildwechsel. Wenn intern mit 240 fps gerechnet wird hast du genug Zeit zum zu oder abschalten der Details. Aber wie du sagst bedarf dies einem enormen Überschuß an Leistung in jeder Kategorie (entrylevel, mainstream, performance und eben highend) und würde auch mal das inputlag deutlich vermiesen. Merkt man ja auch bei prerendered frame = >5
Aber so Sachen wie decals, LoD distance und Partikel kann man ja dynamisch verteilen. Wenn z.B. eine Explosion mit Anti-Aliasing geglättet wird gibts eben weniger Partikel als ohne AA (da mehr Leistungsreserven). So in der Art wäre es heute schon möglich.

@godmode: Bei Rage wurde das nicht in Hinsicht auf Effekte und Polygone gemacht, jedoch bei den Texturen. Das Ergebnis kennen wir alle :facepalm:

Godmode

2013-05-01, 13:41:38

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-High-End-GPUs-Benchmarked-4K-Resolutions

4k-Benchmarks mit allen möglichen HighEnd GPUs, Crossfire, SLI und 3-Way-SLI inkl. dem neuen Messverfahren.

aufkrawall

2013-05-01, 13:45:34

Nicht schlecht, wie sich die 2 GB halten.
Bei BF3 sieht man allerdings deutlich das Verhalten, dass mir mit 1 GB schon bei 1280x1024 aufgefallen ist: Stocker.
Offenbar ist die Engine dafür recht anfällig, was sehr schwach ist, da es im MP selbst mit genügend VRAM schon manchmal sichtbares Texturenstreaming gibt.

Edit: Wieso steht bei den Stichworten vom Thread eigentlich "Hetze"? :D

Hübie

2013-05-01, 14:03:04

Damit Leute wie du den Thread schneller finden ;D

Die Frostbite 2 ist imo eh schmutz. Viel geblende und nix dahinter. Vor allem die Physik ist eine mittelschwere Katastrophe. Das GI ebenso. In keinem Spiel blitzt Staub so stark wie dort :D

Skysnake

2013-05-01, 14:58:47

Das ist doch total fürn Poppes, so lange man sich nicht den grundlegenden Problemen von FCAT angenommen hat...

Das Einzige für was der "Test" taugt ist, das man sieht, das AMD mit ihrem Framepacing eben genau so wie nVidia die Unzulänglichkeit von FCAT ausnutzen kann zu ihrem Vorteil...

Total behämmert und Leutsverarsche... Mehr nicht.

Hübie

2013-05-01, 15:01:48

Worauf genau spielst du mit der Aussage "die Unzulänglichkeit von FCAT ausnutzen" an?

Skysnake

2013-05-01, 15:08:42

-.-

Verzöger ein Frame, der zu einem "rund" Frame führen würde, und alles ist "paletti"

Für den Nutzer hat sich NICHTS verbessert, nur die Zahlen sehen besser aus...

Das ist halt fürn Arsch und kann man sich eigentlich sparen.

aufkrawall

2013-05-01, 15:26:32

Natürlich ist es das.
Deshalb laufen Spiele im CPU-Limit ja auch absolut beschissen.

Knuddelbearli

2013-05-01, 16:16:41

Hübie

2013-05-01, 16:22:21

Aber das Bild sieht doch damit auch homogener aus. Zumindest ohne V-Sync und entsprechenden fps...
Ich habe nun seit etwas über einer Woche SLi und habe schon jetzt festgestellt dass du alles mit entsprechenden Einstellungen individuell in den Griff bekommst. Nervig halt dass man aber erst mal alles testen muss (prerender-limit, fps-limit, v-sync (30, 60 & 120 Hz), adaptive oder nicht und was der Geier. Schon echt anstrengend.
Andererseits: Gut das man dass alles bei nVidia einstellen kann. Ohne inspector sähe die Situation aber auch nicht rosig aus. Das Panel gibt ja nun wirklich nicht viel her.
Über AMD kann ich mir kein aktuelles Urteil erlauben, da ich mit der 6000er-Reihe aufgehört habe da einzukaufen.

LG Hübie

fondness

2013-05-03, 09:12:29

Wie ich vermutet habe ist das neue Speichermanagement in den aktuellen Treibern wohl schon enthalten:

AMD says frame pacing beta driver due in June/July timeframe (http://techreport.com/news/24748/amd-says-frame-pacing-beta-driver-due-in-june-july-timeframe)

Brolivia Wilde
@AMDRadeon when will the new prototype driver will be ready for the public to download? as in, the driver that is addressing frame metering

AMD Radeon Graphics
.@ILoveHitMarkers We're anticipating a beta release in the June/July timeframe. I should note that single-GPU pacing is already fixed. ^RH

Das erklärt auch warum es bei aktuellen Messungen mit Single-GPUs keine Auffälligkeiten mehr gibt.

aufkrawall

2013-05-03, 15:21:54

Da steht aber nirgends, der Fix wäre schon einem erhältlichen Treiber enthalten.
Reine Speku von dir.

Konami

2013-05-04, 12:39:33

Hatte eine Idee, hab gegooglet und diesen Thread gefunden: https://developer.oculusvr.com/forums/viewtopic.php?f=26&t=731 ... wo aber leider die meisten einen ziemlich ahnungslosen Eindruck machen.

Was ist eure Meinung dazu? Könnten VR-Brillen den Nutzen von SFR-SLI verbessern? Könnte man auch bei nur einem Bildschirm (wie bei der Rift) jede GPU eine Hälfte rendern lassen und die dann unabhängig vom anderen Frame direkt an die Brille schicken?
Ich stell mir das ideal vor. Jede Bildhälfte ist ein eigenständiges Bild. Nichts müsste in irgendeiner Form synchronisiert werden. Mikroruckler adé?

raumfahrer

2013-05-04, 15:18:22

Konami

2013-05-04, 15:53:34

Für Stereoskopie braucht man grundsätzlich erstmal zeitgleiche Aufnahmen (oder statische Objekte). Wie zeitgleich die dann im Endeffekt genau sein müssen ist dann wiederum eine andere Sache. Das hängt von der Geschwindigkeit ab, mit der sich Objekte bewegen.

E: Idealerweise muss der Zustand der Spielwelt in beiden Bildern also identisch sein, damit Stereo "perfekt" funktioniert.
Okay, ist natürlich wahr, dass unabhängige Frames bei schnellen Bewegungen zum Problem werden könnten. Dann müsste man sie halt doch synchronisieren. Aber auch dann gäbe es prinzipbedingt kein Mikroruckeln, und die übliche SFR-Kritik, dass man das Bild nicht einfach so aufteilen kann, entfällt auch.

Warum wird das dann nicht schon längst bei stereoskopischem 3D so gemacht? Ich hab das Gefühl, ich überseh irgendwas Großes. :D

Wake

2013-05-10, 07:22:10

Frame Rating and FCAT Explanation and Discussion with NVIDIA - PC Perspective (https://www.youtube.com/watch?feature=player_detailpage&v=2cH_ozvn0gA#t=1s)
90+min von PCPer und Nvidia über Frame Rating bzw. Skysnakes Lieblingsprogramm ;D

Hübie

2013-05-10, 16:40:22

Hm. Viel Blah wenig neues. Interessant wirds erst ab der Frage wie es mit einem framelimiter aussieht. Die bleibt aber unbeantwortet. Das ist imo nur dann sinnvoll wenn man aber das prerender-limit ebenfalls auf 2 senkt. Wenn die fps hoch genug sind kann man ja auch mal mit 3 herum experimentieren.
Hat einer Kontakt zu Tom Petersen?

aufkrawall

2013-07-10, 10:54:17

M4xw0lf

2013-07-10, 11:11:57

Ah ja? Bei Anno sehe ich persönlich mehrere große Spikes (Makroruckler sozusagen) bei der GTX770 und nur einen bei der 7970. Die Frametime-Varianz im 1ms-Bereich bei der 7970 kann man nicht ernsthaft ins Feld führen.

Sieht man bei CB übrigens genauso:
In der Tat, bei einer einzelnen Radeon-Grafikkarte lassen sich nicht nur keine störenden Ruckler im Spielverlauf fühlen, es lassen sich auch keine per FCAT messen. Mit am auffälligsten sind zwei ziemlich große „Aussetzer“ in Crysis 3 auf der GeForce GTX 770 sowie mehrere Unregelmäßigkeiten derselben Art bei der Radeon HD 7970 GHz Edition in Metro: Last Light, die man im Spielverlauf aber nicht bemerkt und die damit ignoriert werden können.

Anderweitige Probleme wie ausgelassene oder nur kurz angezeigte Frames gibt es bei einer einzelnen Grafikkarte ebenso wenig, weswegen die FRAPS-Ergebnisse bei Frameverlaufsdiagrammen mit denen aus FCAT übereinstimmen.

Raff

2013-07-10, 11:13:37

Neuer Test von CB, auch sGPU:
http://www.computerbase.de/artikel/grafikkarten/2013/mikroruckler-bei-grafikkarten/12/

Die 7970 ist definitiv bei einigen Spielen eher schlechter als die 770, nämlich bei Anno 2070, Battlefield 3, Bioshock Infinite (etwas) und Hitman: Absolution.
Was genau bringt dich zu dieser Aussage? Ich sehe direkt in der oberen Anno 2070-Grafik bei der GeForce die größeren Spikes. Man kann natürlich aus jeder Fliege einen Wal machen ... oder man sieht es wie das IMO realistische CB-Fazit (das tu ich beispielsweise):

Für Besitzer einer Single-GPU-Karte haben wir am Ende dieses Tests eine ausschließlich positive Nachricht: Nvidia und AMD nehmen sich nichts, Mikroruckler sind bei beiden kein Thema. [...]

Und selbst wenn FCAT irgendwelche Kuriositäten nachweisen kann: Niemand wird auf einer Radeon-GPU bei gleicher Bildrate irgendwas Störendes im Vergleich mit einer GeForce-GPU fühlen. Wir können heutzutage auch Giftstoffe nachweisen, die uns mit Gewissheit töten – aber erst, wenn wir ganze Ozeane davon trinken oder 3 Milliarden Schweine im Jahr vertilgen. ;)

€dit: Argh, der Maxwolf schon wieder. ;D Okay, unterstreicht meine Aussage (bzw. umgekehrt).

MfG,
Raff

aufkrawall

2013-07-10, 11:27:12

Natürlich merkt man die nicht. :tongue:
Trotzdem kurios, dass die Frametimes der Radeons etwas "variabler" sind. Mögliche Deutung: So ganz an der Wurzel hat man das Problem offenbar nicht gefixt.

Na ja, wenigstens ruckelt BF3 bei CB auf Geforces nicht. ;)

StefanV

2013-07-10, 13:26:18

Natürlich merkt man die nicht. :tongue:
Gut, wenn wir hier uns einig sind, warum versuchst du dann in diesem Punkt AMD zu bashen und wieder auf einen Missionierungsfeldzug zu gehen?!

Nur um deinen 'Glauben' unterstreichen zu können??

aufkrawall

2013-07-10, 13:31:31

Dann hätt ich was von dir zitierte wohl kaum gesagt.
Dein Post ist so nützlich wie ein Kropf, da ging wohl der Beschützerinstinkt wieder mit dir durch.

fondness

2013-07-10, 13:36:44

aufkrawall

2013-07-10, 13:39:23

Leider krieg ich da, nicht wie du, kein Geld für...

fondness

2013-07-10, 13:45:46

Leider krieg ich da, nicht wie du, kein Geld für...

Wie wärs mit Argumenten anstatt Geister zu sehen und Dinge zu behaupten welche die Fakten offenbar nicht her geben? :)
Anhand der Graphen kann man definitiv nicht behaupten das AMD mehr ruckelt, ganz im Gegenteil.

aufkrawall

2013-07-10, 14:01:19

Anhand der Graphen kann man definitiv nicht behaupten das AMD mehr ruckelt, ganz im Gegenteil.
Das ist dann wohl wieder die fondness-Exegese.

fondness

2013-07-10, 14:05:26

Das ist dann wohl wieder die fondness-Exegese.

Damit habe ich nicht gesagt das NV mehr ruckelt, um das klar zu stellen. Aber es lässt sich eben ganz im Gegenteil sagen, dass AMD NICHT mehr ruckelt als NV.

aufkrawall

2013-07-10, 14:09:10

Damit habe ich nicht gesagt das NV mehr ruckelt, um das klar zu stellen.

Hm, nicht?
Das Gegenteil von "AMD ruckelt mehr" wäre "AMD ruckelt weniger".

Eins muss man dir lassen, es wird nicht langweilig...

Hübie

2013-07-10, 14:24:36

Also sGPU ist diesbezüglich ja auch recht unspektakulär. Multi-Setups sind ja die Achillesferse bei AMD. Und daran ändert der Alpha-Treiber auch noch nicht soviel um sagen zu können es sei erledigt. Das sind (besonders gemessen an der Marktpräsens) desaströse Ergebnisse.
Bei Hitman versagen sogar beide... welche Engine ist das doch gleich?

aufkrawall

2013-07-10, 14:29:41

Bei Hitman versagen sogar beide... welche Engine ist das doch gleich?
Glacier 2 (http://en.wikipedia.org/wiki/Hitman:_Absolution).
Bei NV kannst du allerdings gegen etwas Leistung noch das AFR-Vsync einschalten.
Ich hatte bei dem Spiel aber mal mit Fraps mit SLI Frametimes gemessen und die waren an der Stelle sehr gut.

samm

2013-07-10, 14:40:27

Gut überlegtes, informatives Posting vom Guru3D-Forum über Stotter-Ursachen u.A. auch auf Engine-Ebene:

http://forums.guru3d.com/showpost.php?p=4634403&postcount=47

Was noch fehlt ist die Erwähnung des Windows-Timings, das für Game-Engines standardmässig äusserst suboptimal ist, wie afair Gipsel anhand der Gamebryo-Engine (Skyrim) gezeigt hat (danke an die erneute Erwähnung davon im BF3-Benchmark-Thread). Potentielles Mittel dagegen: http://www.lucashale.com/timer-resolution/

Kriton

2013-07-10, 15:37:10

Hm, nicht?
Das Gegenteil von "AMD ruckelt mehr" wäre "AMD ruckelt weniger".

Eins muss man dir lassen, es wird nicht langweilig...

OT: Ich wünschte, dass könnte man von Dir auch sagen.
Wenn man nicht die einzelnen Posts für sich betrachtet, sondern den Kontext des Threads betrachtet ist klar was er ausdrücken will. Deine ursprüngliche Aussage zu den Microrucklern bei Einzelkarten war ja auch mindestens "mißverständlich".

Mir ist echt egal welchen IHV Du bevorzugst, das ist Dein Ding (meiner Frau habe ich übrigens eine Nvidia eingebaut, nicht dass meine AMD-Karte gleich das Warnlicht herauf beschwört), aber die Art und Weise wie Du diesen "Kreuzzug" Nvidia gegen AMD befeuerst ist echt ermüdend geworden.

Sich mal auf die inhaltlichen/technischen Fragen OBJEKTIV zu beschränken wäre mal schön zu sehen.

Bei DX 11 spielt es ja keine Rolle, dass Nvidia nur die API unterstützt, nicht aber die für den kompletten Funktionsumfang notwendige HW bietet, weil Nvidia sagt, dass das eh egal ist (vielleicht wird es ja anhand der installierten Basis von Nvidia eine selbsterfüllende Prophezeiung), aber bei AMD ist es scheinbar wichtig wenn ein Graph ein Verhalten zeigt, dass in der Praxis nicht bemerkt wird. :rolleyes: Bias anyone?

Skysnake

2013-07-10, 17:59:35

Hm, nicht?
Das Gegenteil von "AMD ruckelt mehr" wäre "AMD ruckelt weniger".

Eins muss man dir lassen, es wird nicht langweilig...
Ja das Gegenteil, aber er hat eben NICHT "AMD ruckelt weniger" gesagt, sondern" AMD ruckelt nicht mehr"

Es "ruckeln" einfach! beide GAR NICHT!

Sprich Sie geben sich einfach nichts, und man kann das Thema komplett vergessen...

Hübie

2013-07-10, 19:27:13

samm

2013-07-10, 22:49:55

Mal als (Teil-)Zitate mit Link im quote-code:Hier uebrigens mal ein weiterer Beitrag zur Faktensuche am Beispiel von Skyrim (http://benchmark3d.com/microstutter-case-study-skyrim-diving-deeper). Bisher habe ich das nur ueberflogen, aber das viel mir dann doch auf:

Normal auf QuadCore:
http://benchmark3d.com/wp-content/uploads/2013/01/present-flip-skyrim-4-cores.jpg

Eingeschraenkt auf einen Kern:
http://benchmark3d.com/wp-content/uploads/2013/01/present-flip-skyrim-1-core.jpg

(...)
aber irgendwas scheint auch die Skyrim-Engine selber komisch zu machen.

PS:
Insgesamt kommt mir diese 10ms Granularitaet ziemlich verdaechtig vor. Man kann die Granularitaet des Thread-Schedulings von Windows naemlich von den standardmaessigen 10ms auf 1ms runterstellen (was man bei zeitkritischen Sachen auf jeden Fall tun sollte). Dies beeinflusst durchaus die Wartezeiten bei der Synchronisation von Threads, wenn man kein busy-waiting machen will.
Das kann eine Anwendung/Spiel per Windows-Systemaufruf anfordern. Dann wird wie von Grasso erwähnt, ein Zeitgeber (der den Timerinterrupt auslöst, dessen Behandlung den Windows-Thread-Scheduler aufruft) beschleunigt. von den standardmäßig 10 oder 15,6ms auf (typischerweise) 1 ms. Einige Browser und viele Audio-/Video-Plugins machen das zum Beispiel. Daher kann es durchaus Unterschiede geben, je nachdem, was auf dem System installiert ist bzw. im Hintergrund läuft.
Gehört habe ich davon, daß Einige sagen, sie merken einen Einfluß. Aber genau sagen kann ich das nicht.
Nicht wirklich. Bei B3D hat sich jemand dazu geäußert (http://forum.beyond3d.com/showthread.php?p=1715735#post1715735), daß die Nichtbeachtung der Scheduling-Granularität (wie von mir oben vermutet) durchaus negativen Einfluß auf die empfundenen µRuckler haben können. Aber wie weitverbreitet dieses (Teil-)Problem in typischen Games ist, da habe ich keine Ahnung.

Schaffe89

2013-07-10, 23:06:26

Trotzdem kurios, dass die Frametimes der Radeons etwas "variabler" sind. Mögliche Deutung: So ganz an der Wurzel hat man das Problem offenbar nicht gefixt.ngt

Ich finde nur deine Person kurios, welche schon wieder mit extrem dünner Substanz anfängt zu provozieren.

Die einzigen großen und regelmäßigen Spikes ( unregelmäßige liegen wohl hauptsächlich an der CPU oder am System oder an der Engine), hat Nvidia im Falle von Anno 2070.

Das Gesamtbild ist absolut vergleichbar, viel eher müsstest du aufgrund der regelmäßigen Spikes in Anno bei Nvidia darauf schließen das das Problem noch nicht am Schopf gepackt zu haben.

Bei Berückichtigung der SMT Problematik und x anderen Faktoren, werde ich mir aber sicherlich keinen solchen Schuh anziehen, viel zu dünn.

Und zu Crysis 3, hier treten die Ausreißer ja auch beiden Karten auf, also noch mehr ein Grund anzunehmen, dass solche Spikes gar nix mit der Karte selbst zu tun haben müssen, die Möglichkeit steht ach im Falle von Nvidias Anno offen, auch wenn es weniger wahrscheinlich scheint.

gnahr

2013-07-11, 00:11:18

Ich finde nur deine Person kurios, welche schon wieder mit extrem dünner Substanz anfängt zu provozieren.

Die einzigen großen und regelmäßigen Spikes ( unregelmäßige liegen wohl hauptsächlich an der CPU oder am System oder an der Engine), hat Nvidia im Falle von Anno 2070.
Glashaus?! Steine?!
und wo ist da denn bitte die kausale kette im fetten text. pure, instrumentalisierte spekulation.
dafür brauchst du nicht mal nen vorher-nachher-vergleich und nimmst sofort den alpha-treiber samt seinem angeblichen improvement in schutz.

Schaffe89

2013-07-11, 02:27:27

Glashaus?! Steine?!
und wo ist da denn bitte die kausale kette im fetten text. pure, instrumentalisierte spekulation.
dafür brauchst du nicht mal nen vorher-nachher-vergleich und nimmst sofort den alpha-treiber samt seinem angeblichen improvement in schutz.

Ich provoziere damit? Wen denn?
Es ist doch bekannt dass eine vielzahl von solchen Rucklern eben nicht von der Karte ausgelöst werden.
ICh nehme gar keinen alpha treiber in Schutz und von Multi Gpu rede ich schon gar nicht.

Mach mal einen Bljck zurück und schaue dir die graphen der radeon damals in hitman oder he witcher an, alles regelmässige schwankungen der Bildausgabe da konnte man mit Fug und Recht behaupten es gibt da ein Problem im Gegensatz zu dem was jetzt aufkrawall wieder macht.

Iruwen

2013-07-11, 10:16:08

Dem würde ich ausnahmsweise so zustimmen.

aufkrawall

2013-07-11, 10:44:05

Mach mal einen Bljck zurück und schaue dir die graphen der radeon damals in hitman oder he witcher an, alles regelmässige schwankungen der Bildausgabe da konnte man mit Fug und Recht behaupten es gibt da ein Problem im Gegensatz zu dem was jetzt aufkrawall wieder macht.
Zur Erinnerung: Der Pösewicht aufkrawall hat in Post #939 bereits eingestanden, dass da subjektiv so ziemlich kein Unterschied ist.

Aber hauptsache wir haben Spaß. :)

Knuddelbearli

2013-07-11, 10:47:50

nachdem du behauptet hast das NV besser ist ( bzw du mal wieder nur Spiele genannt hast wo NV besser ist und sogar da hast du mit Anno geschummelt ) was die Resultate von CB aber nicht hergaben ^^

naja eigentlich nix neues ^^

aufkrawall

2013-07-11, 11:23:10

nachdem du behauptet hast das NV besser ist ( bzw du mal wieder nur Spiele genannt hast wo NV besser ist und sogar da hast du mit Anno geschummelt )

Natürlich habe ich nur Spiele genannt, wo NV besser ist, weil es den gegenteiligen Fall beim CB-Test überhaupt nicht gibt.

Wegen den Rucklern bei Anno:
Kannst du dem Test entnehmen, dass die Messvorgänge drei Mal wiederholt wurden?
Wenn der Test nur einmal ausgeführt wurde, besteht die nicht unrealistische Chance, dass die Häufung der Spikes bei NV Zufall ist. Bei weiteren Wiederholungen könnte ja vielleicht rauskommen, dass beide gleich viele Spikes haben, AMD mehr, Nvidia ganz ganz viele etc. ;)

Das gilt aber nicht für den ausgeprägteren Sägezahn-Effekt bei Radeons, da dieser bei mehr als drei Spielen auftritt und somit die Chance einer zufälligen Anomalie gering ist.

Im Übrigen sind das alles sehr niedrige Frametimes. Interessant wäre ein Test mit niedrigeren Frameraten, also etwa 30 und noch niedriger.
Da wär es nicht auszuschließen, dass die variableren Frametimes von AMD nicht doch negativ empfunden werden können, weil die Schwankungen mitskalieren müssten.

boxleitnerb

2013-07-11, 11:25:38

Ich glaube bei 30fps oder weniger ist das das geringere Problem...und ich glaube auch, die Diskussion hier ist eher unnötig.

fondness

2013-07-11, 11:29:22

Fazit von aufkrawall: Bei NV ist es Zufall, bei AMD natürlich nicht. :freak:
Deshalb ist NV auch überall besser. So LOL. ;D

Die großen Spikes (welche mit Sicherheit deutlich störender sind) treten bei NV übrigens auch bei mindestens drei Spielen auf, aber egal. :freak:
Auch dass das jeder andere inkl. den Artikelautoren anders sieht, scheint ihn nicht weiter zu stören, klarer kann man seine Verblendung eigentlich nicht mehr zum Ausdruck bringen.

aufkrawall

2013-07-11, 11:30:57

Ich glaube bei 30fps oder weniger ist das das geringere Problem...
Meinst du.
Es gibt Leute, die drehen bei SP-Spielen die Grafik so weit auf wie es geht und denen reichen dann 30fps für ein Crysis oder Metro LL.

Bei sehr guten Frametimes geht die Maussteuerung dann noch in Ordnung.
Wenn die zu stark schwanken, weißt du als SLI-User ja, was passiert.
Ich sage nicht, dass AMD sGPU so schlecht wie AFR wäre. ;)
Trotzdem wären Messungen mit niedrigeren fps nicht uninteressant. Hat ja auch nicht jeder zwei Titanen.

maximus_hertus

2013-07-11, 11:31:05

Ihr habe jetzt über 1 Seite zugespamt OHNE vernünftigen Inhalt? Respekt!

Zusammengefasst: Wenn jemand einfach nur spielen will, macht bei SingleGPU keinen Fehler, egal ob AMD oder nV. So sollte es *immer* sein.

Multi-GPU: Wie schon lange bekannt, fehlt bei Crossfire das Frame-Pacing, ergo heißt es auf den 31.7. warten. Möge dann das Bashing / Trolling neu beginnen *g*

Ph0b0ss

2013-07-11, 14:28:15

Ist den dieses FCAT-System jetzt wirklich 100% zuverlässig? Ich meine, wenn jetzt wie im Link1 berechnet wird und der Frame der zweiten GPU immer per Metering verzögert wird, so dass es so aussieht wie im Link2. Dann kommen zwar am Ende perfekte Frametimes heraus, aber der Inhalt der Frames der zweiten GPU passt ja dann nicht mehr zum Ausgabezeitpunkt. Sollte also trotz perfekter Frametimes übel ruckeln. Wird das beim FCAT irgendwie mitberücksichtigt? Und wie löst Nvidia das Problem bei SLI?

Link1:
http://www.computerbase.de/bildstrecke/50553/47/

Link2:
http://www.computerbase.de/bildstrecke/50553/46/

Skysnake

2013-07-11, 14:38:29

Nein wird es nicht... nVidia berücksichtigt wahrscheinlich/womöglich bewusst/unbewusst durch die Iteration über die 16 fixen Farbwerte genau diesen Sachverhalt NICHT!

Aber schön, dass du das auch bemerkt hast ;) Mein Kritikpunkt seit Monaten...

boxleitnerb

2013-07-11, 14:40:00

Skysnake

2013-07-11, 15:05:05

Doch kann es... Das haben wir doch schon lang und breit durchgekaut, das es GANZ darauf ankommt, wie die Engine arbeitet....

Wenn die Engine selbst eine Analyse macht, welche Zeit zwischen den Frames vergeht, bzw welche Zeit zu erwarten ist für den nächsten Frame aufgrund von Heuristiken, dann verschlimmbesserst du mit Framemetering die Sache nur.

Deswegen ist Framemetering ja auch nur eine Notlösung! Man versucht die Symptome zu reduzieren/behandeln, statt am Kern des Problems an zu setzen. DARAUF sollten die GPU- und OS-Hersteller lieber ihre Energie bündeln, statt an den Symptomen rum zu doktoren.

Problem erkannt, Problem gebannt... Also gogogo ab und entweder API-Extensions verabschieden/entwickeln, die sich des Problems an der Wurzel annehmen, oder zumindest Libs für die APIs entwickeln, die den Developern zur Verfügung gestellt werden, und das Problem möglichst Hardwareunabhängig lösen, damit die Akzeptanz steigt, so was auch zu nutzen.

boxleitnerb

2013-07-11, 15:11:17

Wenn das Wörtchen Wenn nicht wär...
Das sind alles nur Vermutungen, Beweise hast du keine. Ich glaube kaum, dass die Entwickler so Rücksicht auf Multi-GPU nehmen, dazu ist die Verbreitung zu gering. Kannst aber gerne mal 100 Entwickler anschreiben und fragen und das Ergebnis dann hier posten. Bis dahin bleibt das dein ganz persönlicher Spekulatius.

Im Übrigen fehlt dir die Praxiserfahrung, da du wohl noch nie mit AFR gespielt hast. So kannst du gar nicht beurteilen, wie sich das Endresultat inklusive Metering im Spielealltag verhält, willst aber trotzdem mitreden können. Das klappt nicht.

Skysnake

2013-07-11, 15:30:04

Pong.

Das Gleiche gilt auch für deine "Aussagen"

Zudem solltest du bedenken, dass das prinzipiell kein reine mGPU Angelegenheit ist, sondern sich auch auf SGPU bezieht. Man hat ja doch teils sehr stark schwankende GPU-Last, und statische Timeframes zwischen Bildern sind eh nicht mehr zwangsläufig vorhanden in den Engindes.

Es ist halt ein Sammelsurium von Faktoren, die da reinspielen und keiner überblicken kann!

Und les bitte nochmal was ich und was du schreibst. Du stellst etwas als fakt hin

D.h. ohne Metering passt der Frameinhalt sowieso nicht (unbedingt) zum Ausgabezeitpunkt. Schlimmer kann es also wohl kaum werden, wenn Metering zum Einsatz kommt, eher im Gegenteil.

Ich sage immer AUSDRÜCKLICH! das wir es einfach NICHT WISSEN! und daher jedwede Aussage in diese Richtung einfach fürn Arsch ist...

boxleitnerb

2013-07-11, 15:47:07

Meine Aussagen sind vorsichtig formuliert, falls es dir nicht aufgefallen ist ("ich glaube", "wohl", "eher"...)...
Außerdem bin ich nicht der, der hier permanent gegen das Metering wettert. Wenn du schon zugibst, dass du nichts weißt, ist dein ganzes Wettern gegen das Metering für den Arsch. Schön, dass du das endlich selbst erkannt hast.
Bleibt zudem auch noch deine fehlende Praxiserfahrung. Du kannst so einfach nicht mitreden als Theoretiker. Denn die Theorie führt nur so weit, die Praxis ist aber Trumpf. Vielleicht solltest du dich also besser zurückhalten, wenn du davon keinen blassen Schimmer hast.

Ph0b0ss

2013-07-11, 15:50:41

Wenn du dir die Diagramme anschaust, siehst du doch schon die Antwort. Ohne Metering zeitlich sehr geringer Abstand zwischen den Inputs aber großer Abstand zwischen den Outputs. D.h. ohne Metering passt der Frameinhalt sowieso nicht (unbedingt) zum Ausgabezeitpunkt. Schlimmer kann es also wohl kaum werden, wenn Metering zum Einsatz kommt, eher im Gegenteil.

Ohne Metering wird der Frameinhalt zeitlich höchstwarscheinlich stimmen. Hier hast du aber das Problem, das quasi immer Frame-Frame-laaange Pause-Frame-Frame-laannge Pause... usw ausgegeben werden. Ruckelt oder zuckt regelmäßig. Wird jetzt die Ausgabe per Metering auf gleichmäßige Ausgabe gebogen, kommt zwar schön flüssig Frame-Frame-Frame... im gleichem Abstand, aber da jeder 2. Frame (bei 2xGPU-Sli) dann einen zeitlich falschen Inhalt hat, ruckelt es trotzdem. Ob das jetzt subjektiv flüssiger wirkt kann ich nicht sagen. Aber es wird sicher alles andere als gut aussehen!

Noch schlimmer wird es, wenn jetzt wie bei AMD??? auch bei Single-GPU Metering eingesetzt wird! Da werden dann einfach Probleme der Grafikkarte verschleiert anstatt gelöst. So hat man in Zukunft keine Chance mehr, eine sicher ruckelfreie Single-GPU-Karte zu kaufen.:mad: Es sei denn, es kommt etwas, dass die Zeitrichtigkeit der Frames mitmessen kann!

boxleitnerb

2013-07-11, 15:58:34

Ohne Metering wird der Frameinhalt zeitlich höchstwarscheinlich stimmen. Hier hast du aber das Problem, das quasi immer Frame-Frame-laaange Pause-Frame-Frame-laannge Pause... usw ausgegeben werden. Ruckelt oder zuckt regelmäßig. Wird jetzt die Ausgabe per Metering auf gleichmäßige Ausgabe gebogen, kommt zwar schön flüssig Frame-Frame-Frame... im gleichem Abstand, aber da jeder 2. Frame (bei 2xGPU-Sli) dann einen zeitlich falschen Inhalt hat, ruckelt es trotzdem. Ob das jetzt subjektiv flüssiger wirkt kann ich nicht sagen. Aber es wird sicher alles andere als gut aussehen!

Wie denn? Wenn du eine gleichmäßige Änderungsrate des Bildinhalts hast (z.B. bei konstanter Bewegung vorwärts), die Bildausgabe aber (regelmäßig) unregelmäßig kommt, ist evtl. jedes zweite Bild vom Inhalt her falsch, die übrigen richtig. Man kann hier nicht alle Frames in einen Topf werfen.
Und wie kommst du darauf, dass es alles andere als gut aussieht; hast du SLI? Ich schon. Ich habe eine Vielzahl von Spielen gespielt in den 3 Jahren, die ich AFR jetzt schon benutze. In den allermeisten Fällen ist es ab ca. 50 fps flüssig vom Gefühl her. Trotz Metering. Aus "falscher Bildinhalt", "richtiger Bildinhalt", "falscher Bildinhalt" wird dann u.U. eben "ein bisschen falscher Bildinhalt", "ein bisschen falscher Bildinhalt" usw. Wobei das ein Ruckeln implizieren würde, das in der Praxis wie gesagt praktisch nie auftaucht.

Noch schlimmer wird es, wenn jetzt wie bei AMD??? auch bei Single-GPU Metering eingesetzt wird! Da werden dann einfach Probleme der Grafikkarte verschleiert anstatt gelöst. So hat man in Zukunft keine Chance mehr, eine sicher ruckelfreie Single-GPU-Karte zu kaufen.:mad: Es sei denn, es kommt etwas, dass die Zeitrichtigkeit der Frames mitmessen kann!

Wie kommst du darauf, wo ruckelt noch etwas mit Single-GPU bei AMD oder Nvidia? Es ist auch gar nicht klar, ob das Metering von SLI bzw. später CF derselbe Mechanismus ist, der auch bei SGPU zum Einsatz kommt (falls überhaupt!).

Ph0b0ss

2013-07-11, 16:34:24

Wie denn? Wenn du N ms zwischen den Eingabeänderungen (z.B. während einer 90° Drehung) hast, die Renderzeit zwischen den aufeinanderfolgenden Bildern aber mindestens 4N ms beträgt, wie soll das bitte funktionieren?
Und wie kommst du darauf, dass es alles andere als gut aussieht; hast du SLI? Ich schon. Ich habe eine Vielzahl von Spielen gespielt in den 3 Jahren, die ich AFR jetzt schon benutze. In den allermeisten Fällen ist es ab ca. 50 fps flüssig vom Gefühl her. Trotz Metering.

Habe kein SLI. Muss ich hierfür auch nicht haben. Subjektive Einschätzungen beim Spielen helfen hier auch nicht viel weiter, da das Verhältnis CPU zu GPU Leistung je nach Spiele und Szene stark schwanken. Somit schwanken die Auswirkungen des Problems auch stark zwischen nicht vorhanden und extrem. Auch kommt es auf die Geschwindigkeit der Bewegungen im Spiel an, wie stark es sichtbar sein sollte. Und solange du nicht ohne Zeitverzögerung im AB-Vergleich zu eine fehlerfreien Referenz umschalten kannst, ist eine subjektive Einschätzung praktisch nicht möglich.

Hier nochmal das Problem. die CPU schafft z.B. 4x soviel FPS wie eine GPU. Jedes 4.CPU-Frame wird verwendet. Frames werden zeitrichtig und regelmäßig ausgegeben. Mit SLI nimmt GPU2 jetzt aber nicht das Frame genau in der Mitte von GPU1, sondern gleich das sofort folgende. Wird dieses Frame jetzt um genau 1 CPU-Frame per Metering verzögert, damit es genau in der Mitte von den GPU1-Frames ist, ist die Bildfolge zwar regelmäßig, aber der Inhalt stimmt nicht mehr. Der 1 Frame von GPU2 kommt hier also z.B. auf CPU Frame 2 hat aber den Inhalt des CPU Frames 1. Also passt der Inhalt nicht mehr zur Ausgabezeit. Dieses Problem schwankt natürlich mit der CPU-"Überlegenheit". Ist die CPU nur so schnell oder langsamer als 2 Karten, gibts kein Problem und je mehr die CPU überlgen ist, je schlimmer wirds.

CPU
0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0
GPU1
1-0-0-0-1-0-0-0-1-0-0-0-1-0-0-0-1-0-0-0-1
GPU2
0-1-0-0-0-1-0-0-0-1-0-0-0-1-0-0-0-1-0-0-0
GPU2-gemetert
0-0-1-0-0-0-1-0-0-0-1-0-0-0-1-0-0-0-1-0-0

Wie kommst du darauf, wo ruckelt noch etwas mit Single-GPU bei AMD oder Nvidia? Es ist auch gar nicht klar, ob das Metering von SLI bzw. später CF derselbe Mechanismus ist, der auch bei SGPU zum Einsatz kommt (falls überhaupt!).

Die HD 7970 hatte doch noch vor ca einem halben Jahr Mikroruckler im SGPU-Betrieb. Sind die Probleme jetzt wirklich behoben, oder einfach nur per Metering kaschiert?

boxleitnerb

2013-07-11, 16:53:03

Doch, man muss schon SLI selbst probiert haben. Denn es ist ja nicht so, dass nicht unzählige Situationen beim Spielen auftauchen, nämlich Best-Cases und Worst-Cases, das ganze Spektrum eben. Und wie gesagt, gäbe es Probleme mit dem Metering, müssten diese auch auffallen. Nicht immer, aber doch nicht vernachlässigbar häufig. Tun sie aber nicht, das ist der springende Punkt. Es ist hier irrelevant, ob man das Framemetering ausschalten kann oder nicht, denn flüssiger als flüssig geht nunmal nicht (bitte nicht verwechseln mit Inputlag, da geht natürlich bis zum Ende der Wahrnehmungsschwelle immer flüssiger). Es geht mir hier nur um die Abwesenheit von Unregelmäßigkeiten im Ablauf (=Ruckler).

Das Problem, was du in deinem Diagramm aufzeigst, ist mir schon bekannt. Aber du kannst nicht davon ausgehen, dass das permanent gemetert wird, sondern nur da wo nötig. Und du kannst immer noch nicht alle Bilder in einen Topf werfen. Es gibt nicht nur "falscher" und "richtiger" Bildinhalt - das ist keine binäre Frage, sondern da gibt es viele Grautöne dazwischen.

Zu AMD SGPU - weiß ich nicht. Ich glaube aber nicht, dass es ein Metering bei SGPU gibt. Ich schätze, da war etwas anderes im Argen, das gefixt wurde. Frühere Generationen waren davon ja auch nicht betroffen.

Skysnake

2013-07-11, 17:34:04

Meine Aussagen sind vorsichtig formuliert, falls es dir nicht aufgefallen ist ("ich glaube", "wohl", "eher"...)...
Außerdem bin ich nicht der, der hier permanent gegen das Metering wettert.

Stimmt, du belobhudelest es ständig trotz seiner offensichtlichen Unszulänglichkeiten...

Wenn du schon zugibst, dass du nichts weißt, ist dein ganzes Wettern gegen das Metering für den Arsch. Schön, dass du das endlich selbst erkannt hast.

... :facepalm:

Lesen und verstehen... Ich weiß, das ich keine Aussage über die quantitative Einordnung machen kann. Das bedeutet aber nicht, das ich nicht weiß, das es eben Probleme gibt. Man kann nur nicht sagen, wie stark Sie zu tragen kommen... Das ist ein FUNDAMENTALER! Unterschied!

Beim einen hab ich verloren, beim anderen müsste ich halt einfach nur genauer hinschauen, was einem ja aber verwährt wird...

Bleibt zudem auch noch deine fehlende Praxiserfahrung. Du kannst so einfach nicht mitreden als Theoretiker. Denn die Theorie führt nur so weit, die Praxis ist aber Trumpf. Vielleicht solltest du dich also besser zurückhalten, wenn du davon keinen blassen Schimmer hast.
Aha, du entscheidest jetzt wer mitreden darf/kann und wer nicht? Es wurde von mir ein OFFENSICHTLICHES! Problem schon sehr lange angesprochen, welches auch mit Indizien immer wieder untermauert wurde bisher. Stichwort "Was FCAT anzeigt, und unsere Betrachtung passen nicht zusammen."

Und wir grad dabei sind. Mach ich doch mal "Pong" und Spiele den Ball zurück.

"Du als "Theoretiker" ohne ein eigenes FCAT System kannst doch darüber gar nicht mitreden, also überlasse das doch bitte den Leuten, die ein FCAT-System da stehen haben"

Ich hoffe du merkst was ;)

Ohne Metering wird der Frameinhalt zeitlich höchstwarscheinlich stimmen.

Kann muss aber nicht. Das ist GENAU! das Gleiche Problem wie mit Framemetering. Man weiß es halt nicht, und macht einfach etwas, ohne Kenntnis darüber, was eigentlich das Optimum ist, das man erreichen will/sollte

Noch schlimmer wird es, wenn jetzt wie bei AMD??? auch bei Single-GPU Metering eingesetzt wird! Da werden dann einfach Probleme der Grafikkarte verschleiert anstatt gelöst. So hat man in Zukunft keine Chance mehr, eine sicher ruckelfreie Single-GPU-Karte zu kaufen.:mad: Es sei denn, es kommt etwas, dass die Zeitrichtigkeit der Frames mitmessen kann!
Die Gefahr besteht durchaus, und es wäre durchaus zu wünschen, das man den Punkt auch! bei SGPU untersucht, wenn man schon bei MGPU dabei wäre.

Aktuell gibt es aber keine Indizien dafür, bzw selbst wenn es so wäre, funktioniert die Lösung aktuell scheinbar so gut, das es unterhalb der Wahrnehmungsschwelle des Menschen liegt. Das Problem ist halt, ist das beim nächsten Game auch so?

Fragen über Fragen...

Habe kein SLI. Muss ich hierfür auch nicht haben. Subjektive Einschätzungen beim Spielen helfen hier auch nicht viel weiter, da das Verhältnis CPU zu GPU Leistung je nach Spiele und Szene stark schwanken. Somit schwanken die Auswirkungen des Problems auch stark zwischen nicht vorhanden und extrem. Auch kommt es auf die Geschwindigkeit der Bewegungen im Spiel an, wie stark es sichtbar sein sollte. Und solange du nicht ohne Zeitverzögerung im AB-Vergleich zu eine fehlerfreien Referenz umschalten kannst, ist eine subjektive Einschätzung praktisch nicht möglich.

100% /sign

Die HD 7970 hatte doch noch vor ca einem halben Jahr Mikroruckler im SGPU-Betrieb. Sind die Probleme jetzt wirklich behoben, oder einfach nur per Metering kaschiert?
Können wir nicht sagen. Dazu müsste man halt mal FCAT so erweitern, wie von mir vor Monaten schon vorgeschlagen...

Doch, man muss schon SLI selbst probiert haben.

Weil?

Denn es ist ja nicht so, dass nicht unzählige Situationen beim Spielen auftauchen, nämlich Best-Cases und Worst-Cases, das ganze Spektrum eben.

Ach nein?

Und warum äußern Redaktionen, die FCAT benutzen, sich dahingehend, dass die Ergebnisse von FCAT teilweise überhaupt nicht mit dem zusammenpassen, was Sie am Bildschirm wahrnehmen?

Und wie gesagt, gäbe es Probleme mit dem Metering, müssten diese auch auffallen. Nicht immer, aber doch nicht vernachlässigbar häufig.

Tut es doch auch!

Es wird nur immer klein geredet, und als "falsche" subjektive Wahrnehmung dargestellt. Und wenn man dann erklärt, warum das durchaus richtig sein kann, man es halt nur nicht mit Gewissheit sagen kann, dann kommt von Leuten wie dir nur mal wieder Abwiegelung...

Tun sie aber nicht, das ist der springende Punkt.

OH DOCH TUN SIE!

Und dazu gibt es hier im Thread auch verlinkte Tests dazu.. Ich glaub der eine war von THG und ein Fall auch von CB. Und nein, ich werde jetzt nicht den Topic durchforsten, um den Link zu suchen... Das wäre nämlich vergeudete Zeit, weil du und andere das eh wieder abstreiten und relativieren werdet...

Es ist hier irrelevant, ob man das Framemetering ausschalten kann oder nicht, denn flüssiger als flüssig geht nunmal nicht (bitte nicht verwechseln mit Inputlag, da geht natürlich bis zum Ende der Wahrnehmungsschwelle immer flüssiger). Es geht mir hier nur um die Abwesenheit von Unregelmäßigkeiten im Ablauf (=Ruckler).

Tja, wenns denn nur wirklich so wäre wie von dir beschrieben....

Leider ist auch SLI mit Framemetering nicht Fehlerfrei und verursacht "Ruckler" irgendwelcher Art.

Das Problem, was du in deinem Diagramm aufzeigst, ist mir schon bekannt. Aber du kannst nicht davon ausgehen, dass das permanent gemetert wird, sondern nur da wo nötig.

Und genau so wenig kannst du auch nicht davon ausgehen, das NICHT ständig gemetert wird... Wir wissen es einfach nicht, und jedwede Aussage darüber ist reines unfundiertes Gelaber und Spekulieren...

Und du kannst immer noch nicht alle Bilder in einen Topf werfen. Es gibt nicht nur "falscher" und "richtiger" Bildinhalt - das ist keine binäre Frage, sondern da gibt es viele Grautöne dazwischen.

Na, es gibt schon eine ein "Falsch" "Richtig", aber es gibt dazu auch noch eine Varianz, innerhalb der ein "Falsch" nicht "schlimm" ist, also nicht auffällt. Das Problem dabei ist nur:

1. Wir wissen nicht wie groß diese "Varianz" sein darf
2. Wir wissen noch nicht mal wie groß die reale "Varianz" überhaupt ist -.-

Zu AMD SGPU - weiß ich nicht. Ich glaube aber nicht, dass es ein Metering bei SGPU gibt.

Glauben heist aber nicht wissen, und das gilt für nVidia genauso, und ich persönlich gehe nach dem Mott: "Glauben tut man in der Kirche..."

Ich schätze, da war etwas anderes im Argen, das gefixt wurde. Frühere Generationen waren davon ja auch nicht betroffen.
Reine Spekulation, auch wenn ich diese Einschätzung durchaus teile.

boxleitnerb

2013-07-11, 18:12:11

Schaffe89

2013-07-11, 19:30:49

Und wieder geht das Gezanke in eine neue Episode.

Für mich ist nur eins klar:

Framemetering ist keine Lösung sondern eine insgesamt deutlich merkbare Verbesserung der Bildausgabe bei Multi GPu Systemen, Aunahmen bestätigen die Regel.

( Siehe Crossfire in Metro Last Light bei Computerbase)
Problem bei diesem Verfahren ist wie so oft die Diskrepanz zwischen Ingame und Displaytime, welche bei FCAT nicht gemessen wird, vielleicht auch nicht gemessen werden kann.

Das heißt es gibt kein Verfahren, welches die AFR Probleme Lösen kann, sondern lediglich minimieren.

In meiner langjährigen Erfahrung mit SLI ist es aber fast immer ruckelfrei ab besagter Schwelle, und das zeigt für mich, dass kein grundlegendes Problem besteht,

Das war es mit Crossfire ab einer "bestimmten Schwelle" genauso. Lies dazu mal die Tests von Computerbase vor 2 oder 3 Jahren quer.
Das Problem besteht nach wie vor, es wird mit Framepacing lediglich abgeschwächt, was ja auch gut ist.

Für mich als Außenbetrachter stellt sich die Situation so dar:

Du lässt keine Kritik am Framepacing zu, während Skysnake kläglich versucht dir zu vermitteln, dass Framepacing unzulänglichkeiten besitzt, was wohl in der Theorie völlig klar sein muss.

Ich zitiere mal CB´s Aussage dazu:

"Auf die Frage, warum AMD im Gegensatz zu Nvidia wortwörtlich Jahre gebraucht hat, um die Mikroruckler zu verbessern, hört man die Antwort, dass der bisherige Mechanismus Vorteile bei der Framelatenz bringt, da die Frames nicht verzögert, sondern gleich auf Anhieb an den Monitor weitergegeben werden.

Unserer Erfahrung nach kann man dieses Argument aber getrost wieder vergessen, da die Mikroruckler meistens derart intensiv sind, dass selbst eine theoretische Verzögerung der Steuerungseingaben vor lauter Ruckler völlig nebensächlich ist."

Diese Aussage lässt sich sicherlich Diskutieren, sowie auch die Erklärung von Nvidia:

"Nvidia argumentiert gar, dass der Eingabeinput bei durchgeführtem Frame Metering und abgeschaltetem Vsync gar eine geringere Latenz aufweisen kann als ohne Metering. Denn wenn zum Beispiel zwei Eingabebefehle schnell hintereinander stattfinden, der zweite Befehl aber nicht beim erstmöglichen Frame (von GPU 1) umgesetzt werden kann (da das Rendering bereits angefangen hat), folgt der zweite Frame (von GPU 2) mit dem zweiten Eingabeinput noch vor dem dritten Frame (von GPU 1), da der zweite Frame verzögert wird und dadurch weitere Eingabebefehle angenommen werden können. Frame zwei wird in dem Fall genau mittig zwischen Frame 1 und Frame 3 ausgegeben."

Mich würde interessieren wie ihr das seht?
Ist es möglich dass Framepacing die Eingabeverarbeitung also Input bzw. Outputlag von der Hardware zum Monitor verbessert?
AMD sagt wie zu lesen ist scheinbar das Gegenteil.

aufkrawall

2013-07-11, 19:32:38

Das heißt es gibt kein Verfahren, welches die AFR Probleme Lösen kann, sondern lediglich minimieren.

Die AFR-Probleme sind auf Kosten von etwas Skalierung mit Nvidias AFR-Vsync gelöst.
Proven by reality.

Schaffe89

2013-07-11, 19:37:20

Die AFR-Probleme sind auf Kosten von etwas Skalierung mit Nvidias AFR-Vsync gelöst.
Proven by reality.

Was ist AFR-Vsync? Adaptives Vsync?

Godmode

2013-07-11, 19:41:05

Was ist AFR-Vsync? Adaptives Vsync?

Ein spezielles Flag das man mit dem Inspector setzen kann. Das hilft öfter ganz gut.

Schaffe89

2013-07-11, 19:43:04

Also betrachtest du Probleme durch dieses Verfahren auch als "gelöst"?

aufkrawall

2013-07-11, 19:43:21

Ein spezielles Flag das man mit dem Inspector setzen kann. Das hilft öfter ganz gut.
Kann man mittlerweile auch offiziell im CP einstellen. Für gleichzeitig adaptiv brauchts aber trotzdem den Inspector.

Schaffe89

2013-07-11, 19:50:16

aufkrawall

2013-07-11, 20:09:12

Ist dann µruckeln auch durch einen gut gesetzen Framelimiter "gelöst", schließlich leidet ja nur die Skalierung.
Ich hätt mir von dir schon ein bisschen mehr Kompetenz gewünscht, anstatt wieder den üblichen Feldzug weiter durchzuziehen, ich bin hier raus.
Wo lebst du?
Dass AFR nie mit 100% mikroruckelfrei skalieren kann, ist seit Jahren bekannt und es wurden hier von Ail und Coda auch schon die Alternativen angesprochen.

Ist vielleicht wirklich besser, wenn du raus bist. Bitte nicht über mGPU/AFR äußern, wenn man es nie wirklich benutzt hat. Danke.

Schaffe89

2013-07-11, 20:56:15

Dass AFR nie mit 100% mikroruckelfrei skalieren kann, ist seit Jahren bekannt und es wurden hier von Ail und Coda auch schon die Alternativen angesprochen.

Und was soll dann deine klägliche Rethorikdiskussion, mit deinem obigen Einwand?
Spar dir doch einfach sowas, dann kann man vielleicht auf vernünftig diskutieren. Dass man das Problem selbst nicht wegen der "AFR" Methode an sich "lösen" oder behaben kann, steht außer Frage und hat auch nicht wirklich was mit der Framemetering Geschichte zu tun.

Du pickst dir eine einzige Aussage heraus und sagst dann plakativ das Problem sei gelöst.
Du scheinst an keiner Diskussion interessiert zu sein.

Ist vielleicht wirklich besser, wenn du raus bist. Bitte nicht über mGPU/AFR äußern, wenn man es nie wirklich benutzt hat. Danke.

Du meinst wohl eher die von einer Diskussion auszuschließen, welche dir in den Kram passen.

Die Problematik, dass man Ingame vs. Displaytime nicht messen kann und dies Nvidia und auch die Redaktionen mit der Aussage übergehen, dass es sich ja mit Framemetering besser ist als ohne und sich die weitere Untersuchung diesen Zusammenhanges aufgrund dessen erübrigt, kann ich nicht nachvollziehen.

aufkrawall

2013-07-11, 21:01:54

Du pickst dir eine einzige Aussage heraus und sagst dann plakativ das Problem sei gelöst.
Du scheinst an keiner Diskussion interessiert zu sein.

Was willst du bei AFR noch diskutieren?
Du kannst Ruckler nur bekämpfen, indem du Leistung opferst (zeigen ja auch die Tests mit dem AMD Alphatreiber).

Außerdem verringert Nvidias AFR-Vsync auch noch den Input Lag.
Nachteile gegenüber sGPU = 0, aber deutlich mehr Leistung. Mehr kannst du von AFR nicht erwarten.
Und du hast recht: Ich bin nicht daran interessiert, diesen klaren Sachverhalt in irgendeiner Art zu diskutieren, ist mir zu dämlich. Tschö.

Schaffe89

2013-07-11, 21:13:43

Um den Sachverhalt ging es auch nicht ( den hast ja du durch deinen Diskussionbremser Einwand eingeführt), sondern um die Funktionsweise von Framepacing.
Und spätestens wenn AMD mit ihrem Treiber draussen ist, lohnt es sich sicherlich das Thema Ingame vs. Displayzeit mal anzugehen.

Solange als einziger Nvidia diese Funktion anbietet, wird das Thema von dir blockiert, gibt es dann zwei Frame Pacing Lösungen kommst du aus der Höhle gekrochen und suchst dann Gründe welche die AMD Lösung als schlechter betitelt und ich möchte nicht ausschließen dass du dann das Ingame vs. Display Thema wieder hervorholst.

Spar dir deine Rethorikdiskussionen. Wer mit solchen Mitteln hier Diskussionen führen will, der sollte mal überlegen, ob er sich mit seinem Verhalten, andere User mit fadenscheinigen Begründungen von der Diskussion auszuschließen zu wollen, nicht doppelt lächerlich macht.

Godmode

2013-07-11, 21:17:37

Also betrachtest du Probleme durch dieses Verfahren auch als "gelöst"?

Ein spezielles Flag das man mit dem Inspector setzen kann. Das hilft öfter ganz gut.

Öfter heißt nicht immer, somit ist das Problem nicht gelöst.

boxleitnerb

2013-07-11, 21:43:07

Framemetering ist keine Lösung sondern eine insgesamt deutlich merkbare Verbesserung der Bildausgabe bei Multi GPu Systemen, Aunahmen bestätigen die Regel.

Wenigstens einer, der es versteht.
Framemetering/Framepacing ist kein Wundermittel, das das Problem komplett aus der Welt schafft. Das habe ich nie behauptet bzw. gemeint, das sollte klar sein. Aber dass es das Spielgefühl maßgeblich verbessert in den meisten Fällen, zeigen ja die Erfahrungen mit dem Alpha-Treiber von AMD. So gesehen ist es egal, was die Theorie sagt - der subjektive Eindruck bestätigt den positiven Effekt, und darauf kommt es letztendlich an.

Das war es mit Crossfire ab einer "bestimmten Schwelle" genauso. Lies dazu mal die Tests von Computerbase vor 2 oder 3 Jahren quer.
Das Problem besteht nach wie vor, es wird mit Framepacing lediglich abgeschwächt, was ja auch gut ist.

Für mich als Außenbetrachter stellt sich die Situation so dar:

Du lässt keine Kritik am Framepacing zu, während Skysnake kläglich versucht dir zu vermitteln, dass Framepacing unzulänglichkeiten besitzt, was wohl in der Theorie völlig klar sein muss.

Zur Schwelle:
Dass AFR mit und ohne Framemetering unterhalb einer gewissen Bildrate versagt, ist für mich selbstverständlich. Aber oberhalb dieser Bildrate habe ich in meinen 3 Jahren mit SLI eben größtenteils keine Ruckler oder Unregelmäßigkeiten festgestellt, was im Widerspruch zu den angeführten (vereinzelten) gegenteiligen Beispielen steht. Mit "größtenteils" meine wirklich fast nie. Zumal man auch dazusagen muss, dass Nvidia nur soviel selbst tun kann. Man kann eine Engine auch ziemlich AFR-feindlich schreiben (ich glaube Remedy hatte mit Alan Wake da ziemliche Probleme), da kann das Framemetering dann nicht unbedingt was ausrichten. Die Ursache automatisch dort zu suchen, wenn doch mal was stockt, ist nicht zielführend.

Kritik ist ok. Aber Skysnake kritisiert nicht nur, sondern er betrachtet das Thema vorrangig theoretisch und ignoriert die Praxis völlig bzw. die Praxiserfahrung, die ihm nicht in den Kram passt.

Obendrein will er uns Enthusiasten, zu denen er nichtmal gehört, diese Lösung wegnehmen, weil sie ihm nicht in sein idealistisches Weltbild passt. Und auf so eine Einstellung reagiere ich EXTREM sauer, denn für mich grenzt das schon an Fanatismus.

aufkrawall

2013-07-11, 22:17:34

Öfter heißt nicht immer, somit ist das Problem nicht gelöst.
Das Problem der allgemeinen Mikrorucklerproblematik und des höheren Inputlags ist damit definitiv "gelöst".
Wenn es trotzdem irgendwie ruckelt, funktioniert was anderes nicht richtig.

Wo hat es deiner Erfahrung nach versagt?

Godmode

2013-07-11, 22:24:25

Das Problem der allgemeinen Mikrorucklerproblematik und des höheren Inputlags ist damit definitiv "gelöst".
Wenn es trotzdem irgendwie ruckelt, funktioniert was anderes nicht richtig.

Wo hat es deiner Erfahrung nach versagt?

Meine Erfahrung ist nicht ganz aktuell, da ich jetzt die letzten Wochen nicht wirklich viel gespielt hab. Vor ein paar Wochen hat das Feature eben noch nicht in jedem Spiel perfekt funktioniert. In TR 2013 war ich nicht so zufrieden damit, IIRC.

aufkrawall

2013-07-11, 23:00:53

Meine Erfahrung ist nicht ganz aktuell, da ich jetzt die letzten Wochen nicht wirklich viel gespielt hab. Vor ein paar Wochen hat das Feature eben noch nicht in jedem Spiel perfekt funktioniert. In TR 2013 war ich nicht so zufrieden damit, IIRC.
Gerade getestet: Tatsache, bei TR werden die fps merkwürdig schlecht. :(
Ok, bleibt festzuhalten, dass es wirklich nicht immer geht.
Bei BF3, Crysis 3, Metro LL etc. hier aber bisher keine Probleme damit.

Skysnake

2013-07-12, 02:10:07

Ich habe nie behauptet, dass SLI+Metering IMMER ruckelfrei ist ab einer gewissen fps-Schwelle. Es gibt durchaus mal den Fall, dass man mit Bits nachhelfen muss. In meiner langjährigen Erfahrung mit SLI ist es aber fast immer ruckelfrei ab besagter Schwelle, und das zeigt für mich, dass kein grundlegendes Problem besteht,
Und genau da versagt eben leider dein Verständnis bzgl. visueller Wahrnehmung, biologisch/evolutionären Limitierungen der Menschlichen Wahrnehmung und eben ein bischen Statistik + Fehlerrechnung.

Das es ab "einer gewissen" FPS Grenze eben "gar nicht" mehr zu dem Problem kommt ist absolut typisch für Effekte, die jeweils eine Gewisse Varianz haben und sowohl additiv als auch substraktiv miteinander interferrieren können. Besser gesagt, man hat eine Superposition mehrerer sich überlagernder Effekte.

sonst müsste man die Szenen, in denen Ruckler auftreten, nicht mit der Lupe suchen.
Da haben aber genug Leute sehr wenig Probleme damit, Mycroruckler zu sehen.

Wenn ich jetzt auf deine Argumentationsstruktur zurückgreifen würde, würde ich jetzt einfach sagen: "Wenn du das nicht siehst, bist du halt kein richtiger Enthusiast."

So was ist aber komplett fürn ARSCH, denn das Thema hat so viele Seiteneffekte, und auch allein deine Wahrnehmung unterliegt starken Schwankungen. Schon allein deine emotionale Einstellung zu etwas beeinflusst die. Es wäre wirklich schön, wenn du dir das mal klar machen würdest. Das würde nämlich auch so manche Diskussion versachlichen.

Ich spreche hier wohlgemerkt von 2-way SLI, 3- und 4-GPU-Gespanne habe ich nicht und kann dazu nichts sagen.
Klar kannst du was dazu sagen. Die Probleme werden generell größer. Mehr kann man allgemein eh nicht dazu sagen.

Das Problem was ich mit dir habe ist nicht, dass du grundlegende Probleme aufzeigst, sondern dass du es aufbauschst und aufgrund einer Theorie und einer sehr sehr dünnen "Beweis"lage so tust, als ob Framemetering gleich böse und unbrauchbar wäre.
Nein, da liegst du mal wieder leider total falsch.

Ich sage weder! das Framemetering "böse" noch "unbrauchbar" ist. Das ist eine unhaltbare Unterstellung deinerseits. Framemetering ist nur ein rumgedoktore an den Symptomen, und das sollte man sich einfach mal eingestehen. Daher wird man auch nie wirklich glücklich werden, und es ist auch definitiv nicht zielführend da noch viel mehr Geld rein zu investieren.

Das bedeutet aber nicht, dass die Lösung "unbrauchbar" ist. Sie ist im Schnitt! besser als eben gar nichts zu tun, aber eben nicht immer. Man kann die Probleme wie gesagt sogar verschlimmbessern. Das ändert aber nichts daran, das es im Schnitt besser ist. Ein "besser" ist in meinen Augen aber nicht akzeptabel. Da bin ich dann wohl einfach der wahre Enthusiast, der sich auch mit 90% Lösungen schlicht nicht zufrieden gibt.

Das ist aber gar nicht der Punkt. Eigentlich ist mir das Thema ziemlich scheis egal, da es eh nur eine Randgruppe betrifft (SLI/Crossfire Besitzer), und selbst bei diesen wiederum nur eine kleine Gruppe derjenigen, die es eben bewusst wahrnehmen UND sich daran stören. So what eigentlich. Es gibt wichtigers auf der Welt. Wie dir aufgefallen ist, habe ich den Topic auch ziemlich lange bewusst links liegen gelassen, weil ich mir den Mist gar nicht erst geben wollte. Durch nVidias auf die Scheise gehaue mit FCAT, wurde ich aber mehr oder weniger dazu genötigt, doch etwas darüber zu lesen, und das was ich gelesen habe war halt einfach bullshit. nVidia hat einfach den Bogen für mich überspannt mit einigen Aussagen, und Darstellungen, was dann dazu geführt hat, das einige Redaktionen noch einen drauf gesetz haben, was dann einfach zu viel war. Das in der Branche gedehnt und getrickst wird noch und nöcher muss man akzeptieren und sich immer wieder vor Augen führen. Das ist meist auch legitim. Man darf den Bogen nur nicht überspannen, denn wenn man als "Kunde" das Gefühl bekommt verschaukelt/verarscht zu werden auf eine ziemlich offensichtliche Art und Weise, dann muss man sich nicht wundern wenn "Kunden" pissed reagieren. Niemand lässt sich gerne für Dumm verkaufen, und genau das versucht(e) nVidia mit FCAT.

Bei mir dauert es echt lange, bis ich wirklich richtig pissed bin, aber für dumm verkaufen lasse ich mich nicht... Das mag jetzt hart klingen, aber bei mir gilt folgende Regel: Wenn du mir ans Bein pisst, dann SCHEIS ich dir in den Hals, bis du daran elendig verreckst.

Wie gesagt, es dauert lange, bis ich das Gefühl habe, da ich wirklich gutmütig bin, aber nVidia hat da den Bogen einfach überspannt, und das löst dann in mir eben auch den Anreiz aus, meine wertvolle Zeit für so einen Mist zu opfern. Deswegen wirst du auch nicht erleben, das ich bei dem Thema klein bei geben werde, so lange die den Mist nicht klar stellen, oder mir einen wirklich wirklich gut bezahlten Job anbieten, werden Sie sich damit abfinden müssen, dass FCAT und die Aussagen dazu ins rechte Licht gerückt werden inkl aller systematischen Unzulänglichkeiten.

Und das alles nur, weil Sie und THG richtig auf die Kacke hauen mussten bei dem Thema...

Extrem vereinzelte Hinweise auf Ruckler werden dann von allen Seiten beleuchtet und hervorgehoben, aber die Stimmen von Leuten, die den Kram fast täglich jahrelang benutzen und andere Erfahrungen haben, werden ignoriert.

Also Raff, dem ich jetzt mal mehr "Erfahrung" in dem Thema zumesse als dir, ignorierst du ja auch geflissentlich. Also komm mir nicht mit derartig scheinheiligen Argumentationen.

Das geht einfach nicht. Ich belobhudele nichts, ich weigere mich nur, dein übertriebenes Schlechtreden so stehenzulassen und führe dazu meine ausgeprägten Praxiserfahrungen an,
Und damit begehst du eben einen kapitalen Fehler. Du stellst dich und deine sehr beschränkte Wahrnehmung über die rationale Betrachtung. So was beraubt dich der Möglichkeit zur Selbstreflektion, und die wäre bitterlich nötig. Wer sich schon mal intensiver damit auseinander gesetzt hat, wie man Sachen/Dinge misst, der weiß, das man den menschlichen Sinnesorganen keinen Millimeter über den Weg trauen kann. Wir können Verhältnisse relativ gut einschätzen, aber bei absoluten Werten sind wir die reinsten Flachpfeifen. Wenn man sich das nicht immer und immer und immer wieder vor Augen führt, dann ist man bereits auf einem Auge blind, wenn man Probleme betrachtet.

die imo mehr zählen als wenn sich ein Redakteur mal ein, zwei Tage mit SLI hinsetzt.

Aha..

Also wie gesagt, Raff messe ich da mehr Erfahrung zu als dir, oder sonst irgend einem "normalen" Nutzer. Er ist ein echter Enthusiast und hat durch seinen Job eben ein derart breiten Überblick, den kann man gar normal gar nicht haben.

Nicht weil ich wichtiger bin, sondern weil ich mich einfach viel länger und mit einem breiteren Spektrum aus Spielen und Settings damit beschäftigt habe als er.
Selbstbeweihräucherung at it's best. Sorry, aber die Sichtweise ist destruktiv.

Mich würde interessieren wie ihr das seht?
Ist es möglich dass Framepacing die Eingabeverarbeitung also Input bzw. Outputlag von der Hardware zum Monitor verbessert?
AMD sagt wie zu lesen ist scheinbar das Gegenteil.
Es kann sein, das nVidias Framepacingmethode dazu in der Lage ist, den Inputlag leicht zu reduzieren, aber nach dem, was Sie sonst sagen, als das Sie den Present-Call "einfach" verzögern, ist es nach meinem Verständnis nach eigentlich nicht möglich.

Sie verzögern ja nicht den Start des Zeitpunktes, an dem die CPU ihren Timestomp nimmt. Wenn dem denn so wäre, wäre es praktisch die Lösung, die ich mir wünsche. Das dem so ist, ist aber äußerst unwahrscheinlich. Es gibt nichmal den geringsten Funken eines Hinweises darauf. Zudem wäre der Eingriff ziemlich fundamental, und eben ohne Rückkoppelung in die Engine vorhanden, was dann auch wieder zu ziemlich hässlichen Effekten führen kann...

Also kurz gesagt, nein, die aktuellen Framepacings sollten das eigentlich nicht ermöglichen. Zumindest fällt mir im Moment keine Konstallation ein, wo sich das so verhalten würde.

Die AFR-Probleme sind auf Kosten von etwas Skalierung mit Nvidias AFR-Vsync gelöst.

Nein sind Sie nicht...

Proven by reality.
Die "aufkrawall"-"realitiy"???

So eine "reality" wie hier?
Gerade getestet: Tatsache, bei TR werden die fps merkwürdig schlecht. :(
Ok, bleibt festzuhalten, dass es wirklich nicht immer geht.
Bei BF3, Crysis 3, Metro LL etc. hier aber bisher keine Probleme damit.
Sorry, aber du haust IMMER WIEDER! irgendwelche Plattitüden raus, und musst dich wenig später revidieren... Das ist doch einfach nur stumpf...

Öfter heißt nicht immer, somit ist das Problem nicht gelöst.
Erklär das mal Herrn/Frau von und zu aufkrawall...

bloxleitnerb kannste ruhig auch nochmal auf den Punkt hinweisen, auch wenns bei ihm nur zur Sicherheit ist ;)

Wenigstens einer, der es versteht.
Framemetering/Framepacing ist kein Wundermittel, das das Problem komplett aus der Welt schafft. Das habe ich nie behauptet bzw. gemeint, das sollte klar sein. Aber dass es das Spielgefühl maßgeblich verbessert in den meisten Fällen, zeigen ja die Erfahrungen mit dem Alpha-Treiber von AMD. So gesehen ist es egal, was die Theorie sagt - der subjektive Eindruck bestätigt den positiven Effekt, und darauf kommt es letztendlich an.

Ja, die "richtigen" Enthusiasten (OMG wat ein Bullshitbingo...) sehen das aber durchaus anders, und sehen weder Corssfire noch SLI als Vergleichbar mit SGPU und als prinzipiell ungeeignet an. Vor allem unter Berücksichtigung Preis/Leistung.

Framepacing ist daher nur ein Notnagel, den man nimmt, so lange nichts besseres da ist. Von genug Leuten wird dies aber eben als völlig ausreichende und "perfekte" Lösung propagiert, was einfach ... ist. Damit provoziert man nur, das sich sowohl nVidia als auch AMD auf ihren Lorbeeren ausruhen und "Finger im Po - Mexiko" singen, anstatt sich mal ENDLICH der Grundproblematik an zu nehmen...

Zur Schwelle:
Dass AFR mit und ohne Framemetering unterhalb einer gewissen Bildrate versagt, ist für mich selbstverständlich. Aber oberhalb dieser Bildrate habe ich in meinen 3 Jahren mit SLI eben größtenteils keine Ruckler oder Unregelmäßigkeiten festgestellt, was im Widerspruch zu den angeführten (vereinzelten) gegenteiligen Beispielen steht. Mit "größtenteils" meine wirklich fast nie. Zumal man auch dazusagen muss, dass Nvidia nur soviel selbst tun kann.[/quote]
Nein steht es nicht. Siehe oben.

Man kann eine Engine auch ziemlich AFR-feindlich schreiben (ich glaube Remedy hatte mit Alan Wake da ziemliche Probleme), da kann das Framemetering dann nicht unbedingt was ausrichten. Die Ursache automatisch dort zu suchen, wenn doch mal was stockt, ist nicht zielführend.

Absolut richtig, aber es zeigt eben das fundamentale Problem von Framemetering/pacing auf. Es geht das Problem NICHT an der Wurzel an, sondern doktort nur! an den Sympthomen rum. Das funktioniert halt NIE! 100%.... Deswegen ist es auch absolut falsch sich damit zu begnügen, und nVidia oder AMD groß dafür zu danken. Sie gehen halt den Weg des geringsten Widerstandes, anstatt sich mal ernsthaft um das PRoblem zu kümmern. So etwas erfährt von mir absolut keine Unterstützung, denn MÖGLICH! wäre eine Vernünftige Lösung durchaus... Man müsste halt nur mal endlich den Arsch hoch bekommen, und das politische Klein Klein beiseite schieben. Ohne fundamentale Integration einer Möglichkeit zur Rückkoppelung der Bildausgabe über die APIs in die Engines, die auch eine Vielzahl von Steuermöglichkeiten der Grafikkarten zulässt, wird man keine wirklich zufriedenstellende Lösung erhalten....

Kritik ist ok. Aber Skysnake kritisiert nicht nur, sondern er betrachtet das Thema vorrangig theoretisch und ignoriert die Praxis völlig

Ich ignoriere die "Praxis" nicht, ich nehm Sie nur so wie Sie ist. Eben ziemlich mängelbehaftet und ungenügend....

bzw. die Praxiserfahrung, die ihm nicht in den Kram passt.

Tu ich nicht, aber nehmen wir mal an, dem wäre so. Dann mach ich mal ein "Pong" und freu mich über die gute Gesellschaft in der ich mich hiermit befände :rolleyes:

Obendrein will er uns Enthusiasten, zu denen er nichtmal gehört,
Aha, versuchen wir jetzt wieder jemanden zu diffamieren? Du solltest inzwischen gelernt haben, das ich derartige mehr oder weniger unterschwelligen und subtilen Manöver nicht tolleriere und kommentarlos durchgehen lasse.

diese Lösung wegnehmen, weil sie ihm nicht in sein idealistisches Weltbild passt.

Ich will dir/euch gar nichts "wegnehmen". Dafür müsste man ja erstmal etwas haben, und da macht es absolut keinen Sinn, denn etwas ist besser als gar nichts.

Wenn es aber darum geht, ob Geld und Ressourcen in etwas gesteckt werden sollen, was einfach von grund auf schon mit fundamentalen Mängeln behaftet ist, dann ja, dann bin ich gegen so etwas. Das ist aber kein "wegnehmen", sondern ein "vorenthalten", wenn schon denn schon.

Dies ist aber mal wieder auch NUR! die halbe Wahrheit, da ich eben nicht das "Nichtstun" propagiere, sondern das angehen einer echten fundamentalen Lösung propagiere, welche das Problem an der Wurzel angeht, und damit erst wirklich zu einer grundlegend brauchbaren Lösung führen kann.

Und auf so eine Einstellung reagiere ich EXTREM sauer, denn für mich grenzt das schon an Fanatismus.
Siehst du, und ich reagiere EXTREM sauer, wenn einfach Unwahrheiten verbreitet werden, und wenn eine winzig kleine Randgruppe meint, die ganze Welt müsse sich um Sie drehen, und dann auch noch fordert, das kostbare Ressourcen in Projekte gesteckt werden, die Probleme nur kaschieren, statt Sie wirklich zu lösen. Das ist einfach nur Verschwendung.... Wenn man schon für eine Randgruppe Ressourcen frei schaufelt, dann sollte es wenigstens eine wirklich brauchbare Lösung sein, an der man arbeitet, und kein rumgedoktore...

Das Problem der allgemeinen Mikrorucklerproblematik und des höheren Inputlags ist damit definitiv "gelöst".
Wenn es trotzdem irgendwie ruckelt, funktioniert was anderes nicht richtig.

....

Ohne Worte.... OHNE WORTE!....

Wie kann man nur derart verblendet sein...