Test Mikroruckler bei Grafikkarten

[PuppetMaster]

Die Mikroruckler sind der horizontale Versatz bei schneller Drehung des Avatars, meist in der Nähe des Übergangs vom oberen Bildschirmdrittel zum Darunterliegenden.

Das ist Tearing und hat nichts mit Mikrorucklern zu tun. SLI und Crossfire rechnen abwechselnd immer ganze Bilder: AFR.

Finde den Zeitpunkt auch nicht optimal. Wenn zeitnah zum Erscheinen des Treibers ein Test kommt, ist aber alles in Butter. Wenn nicht, wärs sehr bedenklich.

Siehe hier:

Ja, damit sind es nur noch drei Wochen bis zum versprochenen Treiberupdate seitens AMD, wir haben uns aber dagegen entschieden noch weitere drei Wochen zu warten, weil wir mit diesem Artikel eine Grundlage legen wollten.
[...]
Damit haben wir eine Basis, von der aus ein Blick auf den finalen Treiber ohne viel Drumherum in drei Wochen möglich sein wird.

 

[CD]

@Miuwa: ich würde eine gleichmäßige Berechnung des Bildinhalts bevorzugen. Die Ausgabe kann dann glaub schon unregelmäßig erfolgen, solang die Bewegungen gleichmäßig ablaufen/dargestellt werden ist es denke ich ok. Einzig der alternierende Input-Lag könnte bei geringen FPS spürbar werden, also wenn die FPs zwischen zb 20 und 40 hin und her springen, dann hat man immer zwei fps wo die Eingaben gleich verarbeitet werden, gefolgt von einem fps-paar bei dem die eingaben vergleichsweise viel delay haben.

 

[exuser0815]

@Miuwa: ich würde eine gleichmäßige Berechnung des Bildinhalts bevorzugen.

FULL ACK.
Die gleichmaessigste Ausgabe (gemessen mit FCAT) hilft NICHTS, wenn der Bildinhalt ungleichmaessig berechnet wurde!
Allerdings scheint man das zu ignorieren.

 

[DaBzzz]

SLI und Crossfire rechnen abwechselnd immer ganze Bilder: AFR.

Nvidia-SLI, "Scalable Link Interface". Das originale SLI ("Scanline Interleaving") macht das zeilenweise.

Genug kluggeschissen für heute

 

[Laggy.NET]

Wirklich toller artikel, gute arbeit. Danke. Dennoch muss ich mich der Kritik anschließen.

Abgesehen davon finde ich es aber irgendwie wiedersprüchlich, dass Microruckeln bis ins kleinste Detail analysiert wird und und man ein riesen Fass auf macht, aber das Tearing am Monitor akzeptiert und sogar als Berechnungsgrundlage nimmt.

Die ganze Messung der Frametimes basiert ja darauf, dass auf einem ausgegebenen Bild mehrere Frames gleichzeitig zu sehen sind. Klar geht es hier mehr um die analyse des Zeitabstands zwischen den Frames. Aber gleichzeitig zeigt das auch wieder, dass die Grundlage dieser Microruckler u.a auch das Tearing darstellt. Ohne Tearing würde es schließlich gar nicht zu "runt" frames bzw. wertlosen Frames kommen, da eben nur vollständige Bilder angezeigt werden und nicht zwei oder mehrere gleichzeitig.

Tearing führt selbst bei absolut perfekten Frametimes dazu, dass ein Monitorframe aus mehreren frames zusammengesetzt sein kann, welche dann logischerweise eine zeitliche differenz im Bildinhalt aufweisen.

Wenn sich nun z.B. ein objekt über den Bildschirm bewegt, aber die dargestellten Frames mal früher mal später erstellt worden sind, kommt es unweigerlich zu "rucklern" bzw. das Objekt kann sich unmöglich gleichmäßig über das Display bewegen. Beispiel: eine kugel bewegt sich von unten nach oben übers display. Nun werden zwei Frames gleichzeitig dargestellt, sagen wir zu 50% oben und zu 50% unten, so dass die grenze zwischen den Frames genau in der Mitte horizontal verläuft. Die kugel befindet sich nun genau in der Mitte des Monitors, während sie in einer Aufwärtsbewegung ist. Nun ist das obere Frame aber älter, als das untere Frame. Folglich entsteht ein ruckler in der Bewegung der kugel, da der obere Teil des Bildes zu spät aktualisiert wurde und eben noch aus dem alten Frame, als die kugel noch ein paar pixel weiter unten war besteht. Es entsteht unweigerlich ein versatz, der bei ner Bewegung, wie gesagt zu nem µRuckler führt.

Für mich ist daher nach wie vor vsync absolut unverzichtbar für ein klares, ruckelfreies Bild. (ausser ich erreiche 150+ FPS, dann sind die störungen durch Tearing weniger sichtbar)


Eine Messung mit Vsync wäre daher IMHO sinnvoll, wenn man eh schon so pingelig in der ganzen sache bzgl. den rucklern ist. Theoretisch dürfte es ja dann höchstens nur noch zu dropped Frames kommen.

Ich kann eben wie gesagt nicht verstehen, warum man Microruckler so harsch kritisiert, aber Tearing nicht bzw. komplett ignoriert, obwohl es nahezu den selben visuellen Effekt auslöst.

 

[CD]

FULL ACK.
Die gleichmaessigste Ausgabe (gemessen mit FCAT) hilft NICHTS, wenn der Bildinhalt ungleichmaessig berechnet wurde!
Allerdings scheint man das zu ignorieren.

Wenn man's ganz genau haben will müsste man bei FCAT eigetnlcih auch noch irgend ne einfache geometrische Form einblenden und mit konstanter Geschwindigkeit* ständig durchs Bild bewegen (zB ein lila Kreis von links nach rechts) und nach der Capture-Karte dann mit ner Software die Bewegung auswerten, also so ne art "zurückgelegte Pixel pro ms"-Diagramm erstellen. Das würde einen Messwert für die "Gleichmäßigkeit" der wahrgenommenen Bewegungen ergeben.


*konstant bezieht sich dabei auf die Geschwindigkeit in der Engine, sprich bevor dann alles (Ingame-Grafik und Overlay) an die Render-Engine und die ganzen Delay-Sachen übergeben wird.



Die verzögerte Ausgabe allein ist also sicher auch nicht das Wundermittel. Man muss vorab eigentlich schon wissen wie lange die Berechnung des nächsten Frames in etwa dauert und dann den Beginn der Berechnung entsprechend verzögern, damit das Frame dann passend zur nächsten Ausgabe fertig ist und nicht noch 16 ms (oder mehr, je nach eingestelltem Limit) in irgend nem Buffer vorgehalten werden muss.


@Laggy.NET: Tearing braucht man nicht kritisieren, dagegen hilft einfach VSYNC Ok und gegen Mikroruckler helfen ebenfalls VSYNC bzw. Framelimiter. Wobei ich bisher einzig für FC3 einen brauche, der Rest läuft ziemlich rund.

 

[Binothep]

Ein eigentlich sehr schöner Artikel.
Was mich aber doch stört ist die sehr deutliche Aussage am Ende ohne auf einen der "Hauptsponsoren" und den
(rein zufällig?) passenden Zeitpunkt am Ende hinzuweisen.
Was meiner Meinung nach zwingend nötig wäre, um den zumidest bei mir doch sehr starken Beigeschmak, zu entfernen.

Gruß Binothep

 

[Teiby]

Huch, 10 Minuten und noch kein Kommentar?

Weil man 10 Seiten auch in 10 Minuten lesen und verstehen kann und dann auch noch ein Kommentar bilden und schreiben...das kann keiner in 10 Minuten.

Okay ich hab auch nur die erste und letzte Seite gelesen und mir fällt auf: Ein Tool von Nvidia und Nvidia hat dann am Ende das bessere Ergebnis...man programmiert ja kein Tool mit dem man nachher schlechter dastehen könne...

 

[Haldi]

Es wäre mal interessant den Frame-Lag zu testen. Es kann doch nich wahr sein. Erst werden die FPS geschönt, um bei den Benches besser auszusehen... dann fliegt es auf und man gibt die Bilder gleichmäßiger aus, wobei aber ganz sicher der "Input-Lag" höher wird.

Man sollte unbedingt mal ein Interview mit John Carmack führen, der hat dies schon vor langer Zeit kritisiert.
Dass das Messtool von Nvidia stammt, stimmt mich auch ein wenig skeptisch.
.....

Nun ja direkt nach der Engine werden die Bilder mit einem Farbcode bestückt und anschließend wird mit einer externen Karte gemessen, welches Bild wie lange angezeigt wird bzw. wie viel % eines Bildes tatsächlich dargestellt werden bevor das nächste Bild kommt. Ich seh da nicht so viele Möglichkeiten zu cheaten. Dass die FRAPS-Messungen mit ihren ingame-FPS nur die halbe Wahrheit sagen ist schon länger bekannt. Wobei man sich durch das ganze Frame-Metering und irgendwelche künstlichen Delays natürlich wieder einen ganz anderen Satz an Problemen schafft: evtl. mehr input-lag, und es bringt ja auch nix wenn zwei Bilder nahezu gleichzeitig fertig sind mit der Berechnung, daher fast den gleichen Inhalt zeigen, aber eines der Bilder halt stark verzögert ausgegeben wird. Das wird dann auch als ruckeln empfunden, trotz der regelmäßigen Ausgabe. Um das zu quantifizieren, müsste man zB ein Objekt mit einer konstanten Geschwindigkeit über den Bildschirm bewegen und dann mit einer Capture-Karte die tatsächliche Bewegung messen, die auf dem Bildschirm ausgegeben wird.

Prima Antwort FCAT macht lediglichdas Farboverlay! Dies wird durch eine Neutrale methode (DVI Capture card) aufgenommen, und dann via Python script (was ja öffentlich einsehbar ist!) ausgewertet! Du kannst also selbst ein Script erstellen das nach deinen Wünschen die Farbcodes auswertet. Und das Nvidia nun beim Farbcode einbetten bei AMD noch absichtlich Frameversätze einbaue.... kann ich mir nur schwer vorstellen, das Risiko gehen sie wohl nicht ein.

Also ich habe über jahre einen Quad Sli system und Microruckler habe ich noch nie gemerkt .

Naja, mit QuadSLI hat man wohl konstant über 60 FPS egal was man macht oder ?

Wirklich toller artikel, gute arbeit. Danke. Dennoch muss ich mich der Kritik anschließen.

Abgesehen davon finde ich es aber irgendwie wiedersprüchlich, dass Microruckeln bis ins kleinste Detail analysiert wird und und man ein riesen Fass auf macht, aber das Tearing am Monitor akzeptiert und sogar als Berechnungsgrundlage nimmt.

Die ganze Messung der Frametimes basiert ja darauf, dass auf einem ausgegebenen Bild mehrere Frames gleichzeitig zu sehen sind. Klar geht es hier mehr um die analyse des Zeitabstands zwischen den Frames. Aber gleichzeitig zeigt das auch wieder, dass die Grundlage dieser Microruckler u.a auch das Tearing darstellt. Ohne Tearing würde es schließlich gar nicht zu "runt" frames bzw. wertlosen Frames kommen, da eben nur vollständige Bilder angezeigt werden und nicht zwei oder mehrere gleichzeitig.

Tearing führt selbst bei absolut perfekten Frametimes dazu, dass ein Monitorframe aus mehreren frames zusammengesetzt sein kann, welche dann logischerweise eine zeitliche differenz im Bildinhalt aufweisen.

Wenn sich nun z.B. ein objekt über den Bildschirm bewegt, aber die dargestellten Frames mal früher mal später erstellt worden sind, kommt es unweigerlich zu "rucklern" bzw. das Objekt kann sich unmöglich gleichmäßig über das Display bewegen. Beispiel: eine kugel bewegt sich von unten nach oben übers display. Nun werden zwei Frames gleichzeitig dargestellt, sagen wir zu 50% oben und zu 50% unten, so dass die grenze zwischen den Frames genau in der Mitte horizontal verläuft. Die kugel befindet sich nun genau in der Mitte des Monitors, während sie in einer Aufwärtsbewegung ist. Nun ist das obere Frame aber älter, als das untere Frame. Folglich entsteht ein ruckler in der Bewegung der kugel, da der obere Teil des Bildes zu spät aktualisiert wurde und eben noch aus dem alten Frame, als die kugel noch ein paar pixel weiter unten war besteht. Es entsteht unweigerlich ein versatz, der bei ner Bewegung, wie gesagt zu nem µRuckler führt.

Für mich ist daher nach wie vor vsync absolut unverzichtbar für ein klares, ruckelfreies Bild. (ausser ich erreiche 150+ FPS, dann sind die störungen durch Tearing weniger sichtbar)


Eine Messung mit Vsync wäre daher IMHO sinnvoll, wenn man eh schon so pingelig in der ganzen sache bzgl. den rucklern ist. Theoretisch dürfte es ja dann höchstens nur noch zu dropped Frames kommen.

Ich kann eben wie gesagt nicht verstehen, warum man Microruckler so harsch kritisiert, aber Tearing nicht bzw. komplett ignoriert, obwohl es nahezu den selben visuellen Effekt auslöst.

Was du hier beschreibst ist der Frameversatz und NICHT Tearing! Tearing entsteht NUR auf dem Bildschirm, NICHT in der Engine selbst! Zbsp bei Multimonitor (Eyefinity/Surround) taucht Tearing auf wenn du schlechte Adapter oder Bildschirme hast un die einen Linienversatz verursachen. (AFAIK) (Und übrigens nicht mal verhinderbar^^ Sonst wäre das Bild ja starr)

Multimonitor-Benchmarks wären natürlich nice - denn mal ehrlich für Full-HD muss man sich keine zwei High-End-Karten in den Rechner packen, außer man will aus irgendwelchen Gründen 500 fps haben (die dann eh nicht angezeigt werden können). So richtig "notwendig" wird MultiGPU erst bei Multimonitor-Gaming wo einer einzelnen Karte ziemlich schnell die Firepower ausgeht.

Es sei denn jemand will 144hz auf 27" 2560x1660(1400) Pixel

Wenn man's ganz genau haben will müsste man bei FCAT eigetnlcih auch noch irgend ne einfache geometrische Form einblenden und mit konstanter Geschwindigkeit* ständig durchs Bild bewegen (zB ein lila Kreis von links nach rechts) und nach der Capture-Karte dann mit ner Software die Bewegung auswerten, also so ne art "zurückgelegte Pixel pro ms"-Diagramm erstellen. Das würde einen Messwert für die "Gleichmäßigkeit" der wahrgenommenen Bewegungen ergeben.


*konstant bezieht sich dabei auf die Geschwindigkeit in der Engine, sprich bevor dann alles (Ingame-Grafik und Overlay) an die Render-Engine und die ganzen Delay-Sachen übergeben wird.

(dazu brauchst du kein FCAT, zumal das sowieso Engine Abhängig ist! Aber hier Bitteschön http://frames-per-second.appspot.com/ )

Schön das du es erwähnst. Um auf die 144hz Monitore zurück zu kommen, kennst du diese Seite ? http://www.blurbusters.com/

Es geht zwar hier nicht um die Enginemässige "flüssigkeit" sondern um die des Bildschirmes, aber je mehr FPS du hast destö flüssiger das Bild, so einfach, und mehr als 60 FPS bringen nur bei Vertikalen Bewegungen etwas.
Interessante Frage hier wäre wie oft in einem Refresh das Bild wechseln kann, also kann ich während dem Refresh 1089 Neue Bilder errechnen und diese an den Bildschirm senden das er diese anzeigt, oder wie lange braucht der Monitor bis er das signal bekommt? (auch besser bekannt unter dem namen Input Lag) Da dieser aber meistens bei 10-30ms liegt dürfte dies einzig und alleine bei Starren szene etwas bringen (also auch keine Kamera bewegungen!)


Btw um wieder auf 144hz zu kommen, Nvidias Lightboos Technologie ermöglicht es (War ja ursprunglich für 3D shutter brillen gedacht) 2D so zu hinterleuchten das ein Motionblur effekt wie bei einem Röhrenmonitor erscheint Meine nächsten Monitore (wenn nicht Projektoren xD ) werden bestimmt 144/120hz mit Lightboost, Leider gibt es die nicht in IPS, nur TN.

60HZ

120hz

120hz mit Lightboost!

@Teiby.... doch ? Das einzig wichtige war im Anhang die Diagramme und evtl noch die Äusserungen des Autors. Wer heute das erste mal von Mikrorucklern und Fcat gehört hat wohl vermutlich nicht....

 

[SaarL]

Hab mir das original Video (550MB) heruntergeladen und per VLC-Player angeschaut.
AMD und Nvidia sind "grausig" - wieso sollte da eine besser sein?
Beide gleich schlecht.

Und was sagt uns das:
Diagramme sind alle für den Mülleimer. Es ist alles subjektiv.

Bei der pcgh gabs mal nen Video von FC3 und µRucklern bei CF/SLI.
Der Test besagte, dass AMD graupenhaft war.
Im Video war es dann genau andersrum für mich(!) SLI war schlechter.

Da kann ein Diagramm sagen was es will, wenn meine Augen sagen: nö nix schlecht, dann ist das so^^
Respektive Diagramm sagt: keine Mikroruckler, aber Auge sagt: boah ist das schlecht, dann ist das auch so

 

[Thanok]

@Die ganzen AMD Fanboys die CB für den Releasezeitpunkt flamen:
Lest ihr eigentlich was ihr da von euch gebt? Es wurde im Test zig mal erwähnt dass AMD einen Treiber bringen wird um das Problem zu mindern, die Alpha-Version dieses Treibers wurde getestet und positiv bewertet und wir können wohl davon ausgehen dass CB die Finale Version nochmal durch FCAT jagen wird.
Dann wird noch die Geschichte mit den SGPU Rucklern von AMD wiederlegt, aber der ganze Artikel ist Pro NV?
Ich weiß ja dass AMD allgemein hin immer die "Guten" sind und nie etwas falsch machen, aber wenn man sagt dass sie etwas richtig machen dann ist das auch falsch weil man ja nicht noch 3 Wochen gewartet hat? Wieso lest ihr dann eigentlich Tests wenn AMD euch eh heilig ist und euch keine "Böse" Firma ins Haus kommt?

Mal eine blöde Frage: Wieso setzten sowohl AMD als auch NV eigentlich immer noch auf dieses bescheidene AFR? Ok, es skaliert am besten, aber die Möglichkeit im Treiber einen anderen Modus auszuwählen wäre doch imho in der heutigen Zeit nicht zu viel verlangt. So kann man dann halt auswählen ob man lieber maximale Frames und dafür eventuelle µRuckler haben möchte, oder lieber ein paar fps opfert um dafür ein flüssiges Bild zu haben.
Gerade "Super Tiling" hat da doch richtig Potenzial (Für die die es nicht wissen: Dabei wird das Bild quasi in ein Schachbrettmuster aufgeteilt. Eine GraKa rendert dann alle Schwarzen und die andere alle Weißen Felder). Wobei ich mich immer noch frage wieso die Hersteller nicht mal auf die Idee kommen eine Karte oben Links, die andere unten Rechts ansetzen und aufeinander zu rendern zu lassen. So rechnen beide GraKas fast genau gleich lang da sich die Karten ja einfach irgendwann bei der Berechnung treffen.

 

[entropie88]

Mal eine blöde Frage: Wieso setzten sowohl AMD als auch NV eigentlich immer noch auf dieses bescheidene AFR?

Nvidia supportet AFR / SFR / AA / AFRofAA / Mosaic klick (unter Option "SLI" "string"). Ist doch klar das sie das nicht auf Windows freigeben, weil sie dann nicht auf FPS gehen sondern auf Qualität und mit dem Monitor syncen.

 

[Thanok]

Wäre doch eine Gute Werbung. Man könnte da doch schöne Graphen machen und zeigen dass man maximale Qualität und maximale Performance (AFR) liefert. Man braucht in den Bildchen ja nicht zu erwähnen dass das nur das beste der Unterschiedlichen Methoden ist. Sonst wird das doch auch überall gemacht damit möglichst alle Balken ganz lang sind.
Schade eigentlich dass das unter Windows nicht geht.

 

[mmic29]

Ob es ein guter Zeitpunkt war, jetzt über MR bei AMD zu berichten, möchte ich nicht beurteilen.

Ich möchte nur eine persönliche Einschätzung geben. Bin gestern von meiner "geliebten" GTX690 auf die Gainward GTX780 Phantom GLH umgestiegen. Was soll ich sagen? Neben den Lautstärkevorteilen habe ich in der ersten Metro LL-Session gestern Abend ein deutlich flüssigeres Spielgefühl erlebt, welches ich so nicht erwartet hatte. Ich habe durchaus einige Erfahrung mit Multi-GPU sammeln können (HD3870X2, GTX295, GTX590, GTX680@SLI, GTX690), aber das der direkte Vergleich immer noch so krass ausfällt, hätte ich nicht gedacht. Ist natürlich wie immer subjektives Empfinden.

Mfg mmic29

 

[Herdware]

@Miuwa: ich würde eine gleichmäßige Berechnung des Bildinhalts bevorzugen. Die Ausgabe kann dann glaub schon unregelmäßig erfolgen, solang die Bewegungen gleichmäßig ablaufen/dargestellt werden ist es denke ich ok.

Das ist ein interessanter Punkt.

Auch wenn die Frames gleichmäßig dargestellt werden, kann natürlich ein sich ungleichmäßig ändernder Bildinhalt immer noch für einen ruckelnden Eindruck sorgen und ein Tool wie FCAT bemerkt davon gar nichts.

Diesen Effekt müsste man z.B. mit einer Kombination aus FRAPS und FCAT messen können. Aber die Auswertung wird natürlich extrem kompliziert, denn auch wenn man weiß welche Frames das Spiel rendert und welche letztendlich auf dem Monitor dargestellt werden, muss man das immer noch unter einen Hut bringen (welche Frames kommen letztendlich auf dem Display an und welche nicht und wie viel hat sich in denen jeweils geändert usw.). Ich wüsste auch nicht, wie man das Ergebnis dann einigermaßen anschaulich z.B. in einem Diagram darstellen könnte.

Auswertung und Darstellung sind nämlich ein Problem für sich.

Es gibt von Microsoft ein mächtiges Entwicklertool namens GPUView, das extrem detailiert auswertet, wie die Frames durch die diversen Stufen der Renderpipeline von Direct3D wandern. Es wird z.B. von Treiberentwicklern benutzt. Es wäre (eventuell in Kombination mit sowas wie FCAT) nahezu perfekt, um den Mikrorucklern und Framelatenzen usw. auf den Grund zu gehen.
Aber die Datenwüsten und komplexen Diagramme, die bei GPUView heraus kommen, sind leider selbst für Experten schwer zu verstehen und für interessierte Laien wie uns bömische Dörfer.



Vielleicht müssen wir uns damit abfinden, dass man sinnvoll immer nur Teilaspekte des Problems beleuchten kann.

Wobei man in diesem speziellen Fall ja durchaus ein paar Annahmen treffen kann. Würde das Spiel selbst schon extrem ungleichmäßig Frames produzieren, dann würde das SingleGPU und SLI/Crossfire gleichermaßen betreffen. Das entspricht aber nicht wirklich den praktischen Erfahrungen bzw. der subjektiven Wahrnehmung. Offenbar entsteht der wesentliche Anteil der Mikroruckler doch erst zwischen Renderer und Display.

 

[CD]

Ja ich glaub das mit dem bewegten Objekt könnte sogar überflüssig sein. Wenn man hier:

Zugriff hat auf T_present und T_render (indem man zB bei jedem dieser Schritte einen Timestamp ins Overlay einfügt) hat, und mit FCAT dann noch T_Display misst (dazu müssten auf dem Gaming- und Capture-PC synchronisierte Timer laufen), dann hat man eigentlich alles was man braucht:

man weiß wann ein Frame von der Engine in Auftrag gegeben wurde (T_present), man weiß wann es gerendert wurde (T_rendered), und man weiß wann es auf dem Display ankam (T_display). T_display - T_present (falls Vsync oder Limiter verwendet werden) oder T_rendered - T_display (kein Vsync, Engine und Karte hauen so viele Bilder raus wie maximal möglich) sollten dann ein Maß dafür sein, wie stark sich die Bildinhalte zeitlich unterscheiden.

Greift ein Limiter bzw. Frame Metering bei T_present ein, sprich es verzögert den Zeitpunkt, zu dem die Engine der Grafkkarte sagt "hey render mir mal ein Bild", dann werden die Bilder mit äquidistanten zeitlichen Inhalten gerendert. Vorausgesetzt natürlich, man weiß schon im Voraus, wie lang das rendern dauern wird. Wobei man dies wahrscheinlich ganz gut aus den letzten X Frames abschätzen kann.

Greift der Limiter bzw. Frame Metering dagegen erst bei T_render, sprich die Frames werden so schnell wie möglcih gerendert aber dann künstlich zurückgehalten nur um meinetwegen konstant 60 fps zu erzeugen, dann sehe ich genau das gleiche Problem wieder: Beide Karten sind u. U. fast gleichzeitig fertig, die Bilder zeigen fast identische Inhalte, eins wird sofort dargestellt während das andere minimum 16 ms (ausgehend von 60 Hz und Vsync) zurückgehalten wird obwohl sein Bildinhalt sich lediglich um wenige ms vom vorherigen Bild unterscheidet.

 

[domidragon]

Bin ich denn blind? Der einzige Unterschied, der für mich im Video zu sehen ist, ist, dass er sich manchmal schneller und manchmal langsamer dreht... Ich sehe keine Microruckler...

Nein bist du nicht. Einige sind anfälliger auf diese andere weniger...
Auch sind MR eher Messbar, spürbar in selteren Fällen und Sehbar nur wenns extreme wird wie bei AMD.

 

[Genicksalto]

Ich sehe die Microruckler kaum vor lauter Tearing.

 

[RayKrebs]

Ich sehe die Microruckler kaum vor lauter Tearing.

Das wollte ich auch schon sagen. Ich bin was Ruckler angeht schon empfindlich. Aber dieses Tearing und 30 bis
40fps ohne v-sync, da sind diese Microruckler wirklich micro im Vergleich zum Rest. Aber im Ernst, hier sind gute Ansätze.

Vollzustimm: nicht nur die Ausgabezeit eines Frames ist entscheidend sondern auch der Zeitpunkt wann es
berechnet wurde. Den Frame nur zu verzögern bringt absolut nix fürs Auge, außer der besseren Konstanz für FCAT.

Außerdem stinkt der Fisch vom Kopf, d.h. wenn die Game engine es schon nicht schaft ordentlich zu rendern,
kann der Rest auch nix mehr machen. Kenne viele Spiele die ruckeln vor sich hin und schaffen es selbst nicht
auf einer Single GPU konstante Frametimes zu rendern.

 

[Iscaran]

Greift der Limiter bzw. Frame Metering dagegen erst bei T_render, sprich die Frames werden so schnell wie möglcih gerendert aber dann künstlich zurückgehalten nur um meinetwegen konstant 60 fps zu erzeugen, dann sehe ich genau das gleiche Problem wieder: Beide Karten sind u. U. fast gleichzeitig fertig, die Bilder zeigen fast identische Inhalte, eins wird sofort dargestellt während das andere minimum 16 ms (ausgehend von 60 Hz und Vsync) zurückgehalten wird obwohl sein Bildinhalt sich lediglich um wenige ms vom vorherigen Bild unterscheidet.

Schöne Erklärung !
AFAIK greift frame metering bei T_render ein, ebenso frame pacing und der effekt von V-Sync via Radeon Pro auch...

Ergo für das Auge ist wohl nur die gleichmäßige Wiedergabe der Bilder KOMBINIERT mit der Tearing freien V-Sync Wiedergabe "ruckelfrei" egal wieviele echte ms zwischen den Bildern liegen. Unsere Augen sind eben keine Hochgeschwindigkeitskameras.

Zudem frage ich mich WIE MISST FCAT eigentlich die Zeit ?!? Wenn der windows zeitgeber nur eine genauigkeit von ~15 ms hat...wie kann FCAT dann die Zeiten genauer messen etc...(oder auch der GPU Treiber oder die GPU "hardware" selbst)....