Microruckler für alle : Testprogramm für SingleGPU Nutzer

Ja, abhängig von der Anwendung.

Die frames werden entweder einfach zwischengespeichert und passend ausgegeben um eine gute Frametime anzuzeigen oder aber später berechnet.

Das dies kein flüssigeres bild ermöglicht, weil die Informationen auf dem Bild dann veraltet sind sollte klar sein.


Auch wenn viele das glauben, ein Grafikkartentreiber kann die MR-AFR-Problematik nicht verbessern.

Das liegt ganz einfach daran, das die cpu die Frameberechnung nur in Auftrag gibt, wenn sie das tut aber längst feststeht was auf dem Bild landet.

Die grafikkarte kann nun entweder das bild berechnen und ausgeben oder nicht, aber der Inhalt kann nicht mehr verändert werden.


Das Einzige was man mit einem treiber erreichen könnte wäre die angezeigten fps auf das Niveau der gefühlten fps zu senken. Aber wer will das schon, damit sieht sieht man in Benchmarks doch viel schlechter aus.



Hier sieht man das recht gut : https://www.computerbase.de/2009-01...95/21/#abschnitt_mikroruckler_auf_der_gtx_295

- COJ : keine cheats, das spiel weißt durchgehend mikroruckler auf. Die angezeigte Framerate sind 35-40fps, die gefühlte sind 30.

- bei crysis klappt der Fake-algorithmus noch nicht perfekt. Gefühlte <25fps bei mehr als 30 angezeigten fps lassen sich auch hier noch nachweisen.

- bei stalker ist der nachweis nicht mehr möglich. Das liegt aber mit Sicherheit nicht daran das hier keine MR existieren(siehe ende, hier kommen sie durch), sondern ist eher äquivalent zum hinteren Abschnitt des Crysis verlaufs : die Verarsche klappt.


Keine Ahnung ob das bei ati auch so ist, da weitläufig behauptet wird nur nvidia hätte was "verbessert" bezweifle ich es.
 
Realsmasher schrieb:
Ja, abhängig von der Anwendung.

Die frames werden entweder einfach zwischengespeichert und passend ausgegeben um eine gute Frametime anzuzeigen oder aber später berechnet.

Aber das ist doch genau der Punkt wie man Microruckler wirkungsvoll bekämpfen kann.
Der Treiber reagiert auf das vorherige Frame und passt das nächste Frame an.
Zwar kann man dadurch die MR nicht völlig beseitigen aber man kann aktiv etwas dagegen tun.

Das dies kein flüssigeres bild ermöglicht, weil die Informationen auf dem Bild dann veraltet sind sollte klar sein.

Warum das ?
Das Bild wird halt nicht gleich nach seiner Berechnung dargestellt sondern die Ausgabezeit dem vorherigen Frame angepasst. Das nächste Frame wird wieder dem Vorherigen angepasst und schon gibt es ein deutlich flüssigeres Ergebnis.


Zitat: CB
Wir verlassen uns dabei aber nicht nur auf die Zahlen, sondern achten mit unseren eigenen Augen auf die Mikrorucklern. Wir starten Fraps erst dann, wenn wir der Meinung sind, dass das Spiel „unrund“ läuft beziehungsweise nach Angaben der FPS unrund laufen müsste. Damit schließen wir eine Fehlmessung von Fraps aus und kontrollieren mit zwei voneinander unabhängigen „Systemen“ den Spielfluss. Wir es dem Leser etwas leichter machen und stellen die Frametimes in mehreren Verlaufsdiagrammen dar und nicht mehr nur als nackte Zahlen. Die Diagramme stellen die Zeit dar, die die Grafikkarte benötigt, um von Frame A nach Frame B und anschließend nach Frame C bis hin zum 30. Frame zu schalten.

Wir hatten es beim Probespielen im Gefühl und die Diagramme der GeForce GTX 295 bestätigen unsere Vermutung: In der Tat
Zitat Ende:

- bei stalker ist der nachweis nicht mehr möglich. Das liegt aber mit Sicherheit nicht daran das hier keine MR existieren(siehe ende, hier kommen sie durch), sondern ist eher äquivalent zum hinteren Abschnitt des Crysis verlaufs : die Verarsche klappt.

Der Test auf CB wurde nicht nur mittels der Frameangabe von Fraps vorgenommen.
Es wurde auch visuell auf die MR geachtet und eben diese als deutlich gemindert wahrgenommen.
Und genau das ist es doch worauf es ankommt oder ?
Wie der Hersteller des Treiber es macht ist doch egal.

Ich sehe das alles nicht als Verarsch sondern als aktive Maßnahme zur Bekämpfung der MR.
 
Zuletzt bearbeitet:
Tja, hier kann ich leider cb nicht zustimmen, die verläufe zeigen klar deutlich unter 25 gefühlte fps bei crysis, dennoch wird das als

ohne Probleme möglich, auf der Multi-GPU-Karte ein flüssiges Spielerlebnis zu haben.

bezeichnet. wer das auch so sieht sollte sich glücklich schätzen.

Ich halte 25-50% performanceverlust nicht für akzeptabel. Da kann ich ja fast bei single gpu bleiben.


Der Treiber reagiert auf das vorherige Frame und passt das nächste Frame an.
Zwar kann man dadurch die MR nicht völlig beseitigen aber man kann aktiv etwas dagegen tun.


nein kann man nicht. Etwas tun kann nur der Programmierer des Spiels. Tut der es nicht ist alles von Seiten des Treibers nur Tricksen um die Wirklichkeit zu verschleiern.


Das Bild wird halt nicht gleich nach seiner Berechnung dargestellt sondern die Ausgabezeit dem vorherigen Frame angepasst. Das nächste Frame wird wieder dem Vorherigen angepasst und schon gibt es ein deutlich flüssigeres Ergebnis.

Wenn du ein gerendertes bild zurückhälst dann bringt das für den Eindruck garnichts.

Warum ? Nun stellen wir das mal in Zeitangeben dar.
Nehmen wir an die cpu braucht 10ms für ein Bild und eine gpu 30ms.

0ms : Inhalt von Bild 1 wird berechnet
10ms : Bild 1 wird berechnet, Inhalt bild 2 wird berechnet
20ms : Bild 2 wird berechnet
40ms : Bild 1 ausgegeben
50ms : bild 2 fertig, aber zurückgehalten
70ms : bild 2 ausgegeben


so, nun habe wir eine saubere bildausgabe alle 30ms. Man beachte aber von wann der Bildinhalt stammt : von Zeitpunkt 0 und Zeitpunkt 10.

D.h. das was auf den Bilden erscheint ist nur 10ms auseinander, die Bilder liegen aber 30ms auseinander.

Ergebnis : keine fließende Bewegung.

Man stelle sich das anhand einer Bewegung mit 1 meter pro 10ms vor. dann hat man zwar gleiche bildabstande, aber der inhalt bewegt sich in den ersten 30ms um 1 meter, in den nächsten um 3 meter, dann wieder um 1 meter.

Fazit : Frames im richtigen Abstand, aber der Inhalt der Frames springt. Der Eindruck beim Betrachter ist dadurch nicht verbessert worden.


Funktionieren tut es nur wenn das Spiel die realen FPS auswertet und die Bewegungsgeschwindigkeit im Spiel dazu anpasst indem die cpu künstlich gebremst wird.

Das macht z.b. mein programm hier im single gpu modus, im dual gpu modus ist diese Bremse je nach Einstellung abgeschaltet.



Der treiber kann hier jedoch garnichts machen. Zu dem zeitpunkt an dem er greift ist das Kind längst in den Brunnen gefallen.


Klar könnte der Treiber VOR der Berechnung des nächsten Bildes die cpu bremsen. Ergebnis : viel schlechteres Abschneiden in Benchmarks -> unerwünscht. (zudem Bastellösung, bei plötzlich cpu intensiven Szenen führt es zu massiven slowdowns)
 
Realsmasher schrieb:
Ich halte 25-50% performanceverlust nicht für akzeptabel. Da kann ich ja fast bei single gpu bleiben.

In diesen Punkt stimme ich 100% zu.
Das ist ja auch der Grund warum ich von MultiGPU weg bin dazu noch die MR-Probleme.
Lieber eine starke Singel-Karte die man noch übertaktet.

Wenn du ein gerendertes bild zurückhälst dann bringt das für den Eindruck garnichts.

Warum ? Nun stellen wir das mal in Zeitangeben dar.
Nehmen wir an die cpu braucht 10ms für ein Bild und eine gpu 30ms.

0ms : Inhalt von Bild 1 wird berechnet
10ms : Bild 1 wird berechnet, Inhalt bild 2 wird berechnet
20ms : Bild 2 wird berechnet
40ms : Bild 1 ausgegeben
50ms : bild 2 fertig, aber zurückgehalten
70ms : bild 2 ausgegeben


so, nun habe wir eine saubere bildausgabe alle 30ms. Man beachte aber von wann der Bildinhalt stammt : von Zeitpunkt 0 und Zeitpunkt 10.

D.h. das was auf den Bilden erscheint ist nur 10ms auseinander, die Bilder liegen aber 30ms auseinander.

Ergebnis : keine fließende Bewegung.

Das ist ebenfalls sehr einleuchtend.
Die Zeitverschiebungen sind also das Resultat der Glättung des Frameverlaufes von Bild2.

Die Frage ist eben nur ob das menschliche Auge/Bewusstsein diese Verschiebung im Millisekundenbereich wahrnehmen kann bzw. unser Verstand diese Zeitdifferenz nicht selber korrigiert.
Sprich: Den Einen stört es den Anderen nicht.

Klar könnte der Treiber VOR der Berechnung des nächsten Bildes die cpu bremsen. Ergebnis : viel schlechteres Abschneiden in Benchmarks -> unerwünscht. (zudem Bastellösung, bei plötzlich cpu intensiven Szenen führt es zu massiven slowdowns)

Und genau da sollte der Treiber eine mögliche Einstellung diesbezüglich gewähren.
Zwar verliert man dann Leistung. Aber bei genügend Rechenpower hat man dann ein besseres Spiel-Erlebniss.
Ähnlich der V-Sync. Die ebenfalls durch das Warten auf das Monitorsignal die Leistung ausbremst aber man eben dann keine Verzerrungen mehr im Bild hat.
Allerdings müßten dann beide Hersteller absolut offen mit diesem Problem umgehen. Was sie aber wohl aus Presstischgründen nicht tun werden. :(

Fazit ist wohl leider daraus das MultiGPU einfach nicht zu gebrauchen ist.
 
Zuletzt bearbeitet:
Solange in den tests allein die durchschnittlichen FPS gewertet werden kann sich ja eigentlich garnicht viel tun.

Es würde ja schon reichen die min-fps anhand der frametimes anzugeben, das würde für AFR häufig das Aus bedeuten und die Hersteller wären im Zugzwang.

Aber solange man es ihnen SO einfach macht und ggf sogar für die Zwischenspeicherung aus Verschleierunggründen lobt...
 
Bleibt die Frage, wieviele SLI-User sich wirklich an den Rucklern stören...gibts da ne grobe Prozentzahl?
 
Jeder der es nicht tut braucht auch kein Sli.

Defacto verringern doch Mikroruckler nur die real empfundene Performance. Wenn also jemand sagt ihn stört das nicht, wozu braucht er dann überhaupt sli ?

Ohne sli wäre die Auswirkung von der selben Art (wenn auch nicht genauso groß) : weniger gefühlte fps.


Das Problem ist wohl das sich viele was völlig falsches unter der Thematik vorstellen.
Ich selbst zähle mich auch dazu. Ich habe lange Zeit auch nicht verstanden wie die tatsächlichen Auswirkungen aussehen.

Das liegt wohl an dem völlig irreführenden Begriff an sich.

Würde es "performanceverringernde Schwankungen" heißen, dann könnten sich viele wohl mehr darunter vorstellen.
 
Ich bin ja sehr gespannt auf Lucids Hydra-Chip. Das wird vielleicht die erste Lösung seit dem Scan Line Interleave von 3dfx sein, die Multi-GPU wieder effektiv macht. Die ganze AFR-Problematik wäre damit komplett vom Tisch und es gäbe wieder regelmäßige Frametimes, die auch auf einer regelmäßigen CPU-Berechnung basieren würden.

Interessante Lebenszeichen gibt es ja bereits und ein erstes Mainboard aus dem Hause MSI steht auch schon in den Startlöchern.
 
Zuletzt bearbeitet:
Hallo Realsmasher!
Danke für dein Tool, ich wollte es gerne testen. Leider kommt bei mir nur ein schwarzer Bildschirm zum Vorschein, oben links steht Free Test Mode 1 und darunter Quiz Mode 2. Was mache ich falsch? Falls das schon geklärt wurde, könnte ich dir empfehlen vielleicht ein ganz kleines Readme zu deinem Programm beizufügen.

Danke übrigens dass du dich dem Problem Microruckler und auch SSAA mit Ati-Grafikkarten annimmst. Das sind genau die beiden Probleme die mich im Moment am meisten interessieren! Super!
Leider geht DXTweaker ja nicht mit Steam und auch bei einem non-Steam-Spiel (Flatout2) hab ich nicht viel AA gesehen, aber danke für die Anleitung (auch wenn da keine Bilder mehr angezeigt werden). Ok, das ist jetzt OT, deswegen lieber nochmal: "danke für dein MR-Testprogramm". Hoffentlich kriege ich es noch zum laufen.
-Alex

EDIT:
Sorry, durch diesen Post hab ich mich als absoluter Volldepp geoutet. Natürlich läuft das Microruckler-Programm. Asche auf mein Haupt, das müssen die 9h sein, die ich jetzt ohne Pause am PC sitze. Scheiß Uni. :)
 
Zuletzt bearbeitet:
Danke für das Lob.

Leider hatte ich kaum Zeit in den letzten Monaten, deswegen konnte ich mich mit beiden Themen nicht intensiver beschäftigen.

Aber gut das du das Problem lösen konntest, ich wüsste auf Anhieb garnicht mehr worum es ging :p


Das mit SSAA hat sich mit der 5000er Serie ja glücklicherweise erledigt. Ansonsten stimme ich dir zu, es läuft mit viel zu wenig Spielen und selbst wenn ist es nur selten flüssig.

Ich nutze es(da noch 4k nutzer) eigentlich so gut wie nur noch bei Spielen mit 2D Elementen oder massivem shader-einsatz.
 
Hab diesen Thread gerade zufällig gefunden und durchgeackert, find das sehr interessant! Werd das Programm auch bei Gelegenheit testen, würd mich interessiern wie die MR in Natura aussehn bzw sich anfühlen. Auf jeden Fall ein fettes DANKE an Realsmasher für die Mühe, auch wenn der Thread schon Jahre alt ist!
mfg
 
@Cloud: Warum brauchst Du das denn? Falls Du eine AMD-Grafikkarte hast, dann beachte, dass sich in der Zwischenzeit im AMD-Treiber einiges weiterentwickelt hat. Seit 2013/14 haben sie in mehreren Iterationen ein Frame-Pacing eingebaut, das genau diesen Effekt, um den es hier geht, eindämmen soll.
 
Zurück
Oben