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

scanline sagt es doch eigentlich schon : jede gpu eine zeile.


Zombie79 schrieb:
Um die Ruckler zu vermeiden, müsste der Treiber wissen, wann GPU1 zu 50% mit der Berechnung des Frames fertig ist und dann den nächsten Frame an GPU2 schicken.

Das ist so leider völlig unmöglich.

Das was auf dem frame passiert steht schon fest, in dem moment wo die cpu zu gpu sagt :"ich bin fertig"

fängt die gpu jetzt nicht sofort mit dem rechnen an, sondern wartet, dann wird sie auch später fertig.

Das Ergebnis ist, das der Spielverlauf selbst nicht mehr gleichmäßig ist, weil die Ausgabe zu später passiert als die cpu es vorgesehen hat.

Kann auch ein Rechenbeispiel dazu aufschreiben bei Interesse.

Das fazit ist jedenfalls das MR nicht durch die Graka(s) alleine unterbunden werden können*, es muss immer die cpu mitspielen.

* außer durch andere modi als AFR

Fairy Ultra schrieb:
kannst du mal erklären wie du die Frameszeit(Zeit bis zur ausgabe) errechnest (im Programm)?

Also Beispielhaft

Frame 1 - x ms
Frame 2 - x ms
Frame 3 - x ms

avg frames usw.


Die formeln dafür :

gpu = 1 -> zeit = ((1000/fps)*2)-delay
gpu = 2 -> zeit = delay


Im Programm läuft das dann etwa so ab :

busywaitung für gpu1-zeit
auftrag an gpu
busywaitung für delay-zeit
auftrag an gpu
... und wieder von vorne


Ok, ein bischen anders läuft es schon ab, die wartezeiten müssen kürzer sein, weil durch den rendervorgang noch etwas zeit verbraucht wird(<1ms je frame).

Deswegen braucht das Programm auch immer ein paar Sekunden um sich anzupassen, je nachdem ob man nun gerade eine 5 jahre alte onboardkarte oder eine 280gtx nutzt ;)




edit : mit einem ähnlichen(umgedrehten) Algorithmus könnte man übrigens jedes Spiel programmiertechnisch von MR befreien. Die Programmierer müssten es nur einbauen.

Nachteil : ein paar % performanceverluste, vorallem bei hohen fps.
 
Zuletzt bearbeitet:
jusaca schrieb:
[...] Mein TFT läuft mit Nvidia Treibern standartmäßig auf 75Hz....

Ist das jetzt gut oder schlecht?
Wahrscheinlich eher schlecht, denn die meisten TFTs haben einen Framebuffer mit festem Takt. Das bedeutet, dass er immer nur 60Hz anzeigt. Wenn du jetzt ein analoges Signal mit 75Hz zur Ansteuerung benutzt, sorgst du für noch mehr ungewollte Effekte, als ohnehin schon vorhanden sind.

Du kannst das mit dem JudderTest-Tool ausprobieren. Wenn auch dein TFT einen 60Hz Framebuffer hat, müssten die Streifen bei 75Hz Ansteuerung etwas zappeln.

Realsmasher schrieb:
[...] Das was auf dem frame passiert steht schon fest, in dem moment wo die cpu zu gpu sagt :"ich bin fertig"

fängt die gpu jetzt nicht sofort mit dem rechnen an, sondern wartet, dann wird sie auch später fertig.

Das Ergebnis ist, das der Spielverlauf selbst nicht mehr gleichmäßig ist, weil die Ausgabe zu später passiert als die cpu es vorgesehen hat.[...]
Die Ausgabe kommt immer später, als die CPU es vorsieht, denn die GPU muss den Frame ja erst berechnen. Und die GPU soll ja nicht warten, bevor die Berechnung gestartet wird - das wäre totaler Käse. Die CPU muss warten, bevor sie den Frame für die 2. GPU auf die Reise schickt. Das darf nicht gleich 5ms nach dem 1. Frame passieren, nur weil der Treiber meint, da noch eine freie GPU anbieten zu müssen.

Wenn die CPU weiß, dass 2 GPUs vorhanden sind und wie lange die Berechnung des letzten Frame gedauert hat, dann kann sie (theoretisch) beide GPUs immer zur richtigen Zeit bedienen. Das Ganze kommt nur dann aus dem Takt, wenn sich die Komplexität der Szene ändert. Diese Effekte sind aber normal und auch bei SingleGPU-Systemen unvermeidbar. µRuckler wären dann passé.

Auf die Performanceverluste bei hohen FPS kann man getrost <zensiert> ;), denn mehr als <Monitorwiederholfrequenz>FPS kann man ohnehin nicht sehen. Ich sehe das Problem auch nicht bei den Herstellern der Grafikkarten, sondern bei den Programmierern der 3D-Engines, die MultiGPU-Systeme bisher nicht vernünftig unterstützen.
 
Hm das hier irgendwie einigen immer noch die Augen vor MR effekten verschließen wundert mich ...

Habt ihr schon mal auf die wahrgenommene Drehrichtung von Autofelgen geachtet bei steigender Geschwindigkeit ?

Finde ich das beste Beispiel [ als Veranschaulichung ]für das "Phänomen" das auf einer Optischen Täuschung des Auges beruht.

Und da jeder andere Augen hat nimmt auch jeder diesen Effekt anders wahr ...
[von Overdrive Inputlag und Prerendered Frames Vsync u.s.w. mal abgesehen]

Das ganze sind sich überlagernde Frequentzmuster die [lach] freakwaves produzieren.

So long ... hail to the freaks ...
 
Realsmasher schrieb:
gpu = 1 -> zeit = ((1000/fps)*2)-delay
gpu = 2 -> zeit = delay

müsste das nicht einfacher

gpu = 1 -> zeit = (1000/fps)
gpu = 2 -> zeit = (1000/fps)+Delay sein

bzw.

gpu = 1 -> zeit = (1000/fps)
gpu = 2 -> zeit = (1000/fps)
gpu = 1 -> zeit = Delay + (1000/fps)
gpu = 2 -> zeit = Delay + (1000/fps)
usw
 
Zuletzt bearbeitet:
ZerHaKKeR schrieb:
Habt ihr schon mal auf die wahrgenommene Drehrichtung von Autofelgen geachtet bei steigender Geschwindigkeit ?

Finde ich das beste Beispiel [ als Veranschaulichung ]für das "Phänomen" das auf einer Optischen Täuschung des Auges beruht.
Das Phänomen nennt man Alias-Effekt und ist ein unpassendes Beispiel, da alle Menschen mit +-5% gleicher Abtastrate mit ihren Augen ihre Umgebung interpretieren. µRuckler sind keine optische Täuschung.

Bei den µRucklern geht es eher darum, wie sehr man darauf achtet und einfach das persönliche Empfinden. Den Alias-Effekt bei den drehenden Felgen sieht jeder gezwungenermaßen - wenn man speziell darauf achtet; in einem Spiel ist man von dem Geschehen jedoch so stark abgelenkt, dass man die Ruckler nicht unbedingt wahrnimmt - je nachdem wie empfindlich man da ist und welche framerates man gewohnt ist.

Deshalb sind einige MultiGPU User hier so entrüstet, da sie in dem Programm von Realsmasher praktisch "gezwungen" werden, darauf zu achten (von welcher grafischen Pracht sollten sie auch abgelenkt sein ;) ) und dann den Effekt auch sehen, den sie im Spielgeschehen nicht bemerken. Wenn ich mich an den Rand einer Schnellstraße stelle, müsste ja auch jeder 2. Autoreifen rückwärts laufen, aber da ich selten auf Autoreifen achte, habe ich den Eindruck, die Reifen drehen so wie sichs gehört nach vorne.
 
gpu = 1 -> zeit = (1000/fps)
gpu = 2 -> zeit = (1000/fps)
gpu = 1 -> zeit = Delay + (1000/fps)
gpu = 2 -> zeit = Delay + (1000/fps)

ich rechne mal fix für 30fps und 15er delay durch :

zeit1 = 33.3 (richtig, ist das oben erwähnte erste frame, was ich bei mir aber weglasse)
zeit2 = nochmal 33.3, das wird schon falsch, dann hätten beide den gleichen abstand
zeit3 = 15+33.3 = 48.3
zeit 4 = 48.4

keine ahnung wie das bei dir dann weitergeht, aber so funktioniert es nicht.

einfach :

gpu = 1 -> zeit = (1000/fps)
gpu = 2 -> zeit = (1000/fps)+Delay sein

geht logischerweise auch nicht, dann hätte man 33,3 ms und 48.3 ms, was zusammen 81.6ms ergibt und nurnoch (ausgegebenen, also was fraps anzeigt) 24.5fps entspricht.



Die Ausgabe kommt immer später, als die CPU es vorsieht, denn die GPU muss den Frame ja erst berechnen

richtig, aber dafür braucht sie idr immer gleich lange.

mal ein Beispiel das dem entspricht aber nicht im millisekundenbereich spielt :

Eine Kamera fotografiert jede volle Stunde einen Garten und fügt das ganze zu einem Zeittrafferfilm zusammen.

Das Foto entspricht hierbei dem zeitpunkt an dem die CPU fertig ist und der Film nachher dem Ausgabestrom der Grafikkarte.

Weil die Kamera aber ne Macke hat nimmt sie das ganze so auf :
0.00 : Bild 1
0.15 : Bild 2
2.00 : Bild 3
2.15 : Bild 4
usw

Das zweite Bild also immer 45minuten zu früh.


Bei dem zeittrafferfilm muss nun entsprechend das zweite Bild auch schon kurz nach dem ersten gezeigt werden, denn es ist kurz danach passiert.

Würde man jedes Bild gleich lang zeigen, indem man jedes zweite Bild für 45minuten puffert, dann stimmt der Verlauf einfach nicht mehr.

Der EINZIGE ausweg ist, das die Kamera erst um 1:00 das bild macht. Und wie geht das ?

du hast es bereits erwähnt :

Wenn die CPU weiß, dass 2 GPUs vorhanden sind und wie lange die Berechnung des letzten Frame gedauert hat, dann kann sie (theoretisch) beide GPUs immer zur richtigen Zeit bedienen. Das Ganze kommt nur dann aus dem Takt, wenn sich die Komplexität der Szene ändert. Diese Effekte sind aber normal und auch bei SingleGPU-Systemen unvermeidbar. µRuckler wären dann passé.

Und das geht nur in JEDEM Spiel einzeln, da hilft kein Grafiktreiber und auch kein externes Tool, die können alle das Problem nur verschieben.

Scheinbar passiert das ja sogar schon, wenn Fraps z.b. in Crysis jetzt völlig gleichmäßige Frametimes ausgibt.
 
Realsmasher schrieb:
[...] Und das geht nur in JEDEM Spiel einzeln, da hilft kein Grafiktreiber und auch kein externes Tool, die können alle das Problem nur verschieben.[...]
Richtig.

Realsmasher schrieb:
[...] Scheinbar passiert das ja sogar schon, wenn Fraps z.b. in Crysis jetzt völlig gleichmäßige Frametimes ausgibt.
Das wusste ich noch nicht. Klingt sehr interessant. Und vor allen gibt es Hoffnung. ;)
 
Danke für die Klarstellung Realsmasher.

Also dein Prog nutzt als Delay nicht den Abstand zum Mittelwert sondern direkt den "kurzen" Abstand zwischen 2 frames (bei einer beliebigen Folge von 4 frames). Dann ist es natürlich nur logisch das der "kurze" Delay in Wahrheit der schlimmere ist. Hatte mich da nur gewundert eben beim testen das es eigentlich hätte anders sein müssen.

Ich dachte der angegebene Delay bezöge ich auf den Mittelwert (da du ja z.B. 30 FPS mittelwert einstellst).

Ich würde wirklich die Formeln direkt im Programm ausgeben...führt sonst nur zu mißverständnisse.

Also Bsp:

1. Stelle Mittlere FPS (bzw. FPS einer single-GPU ein) (tasten "9" "0")
2. Stelle nun den "Delay" zwischen Frame1 und Frame2 ein...Abstand Frame2 zu Frame3 ergbit sich dann aus den Formeln. (Tasten "1" und "2")
Frame1 = 1000/FPS (ms)
Frame2 = Frame (n) + Delay
Frame3 = (1000/ FPS) - Delay
Frame4 = Frame (n+1) + Delay (eigentlich redundant in dem Fall)

Oder Evtl. einfach die Zahlenfolge der ms-Abstände angeben:

Frame1-2-3-4-5-6
20ms-40ms-20ms-40ms-20ms-40ms

Ich würde dann auch nicht von FPS "Goal" sprechen sondern von simulierten mittleren FPS.

Das sollte dann wesentlich selbsterklärender sein als das bisherige.

Btw. Danke nochmal für das wirklich tolle tool !
 
naja goal soll nur angeben was das ziel des nutzers ist.

ob diese FPS zum jeweiligen zeitpunkt anliegen muss man kucken.

so einfach lässt sich das alles nicht machen, da eben die rechenzeit der grafikkarte immer etwas schwankt und auch im hintergrund programme laufen etc...



Das mit der Zahlenfolge merke ich mir vor , das ist eine gute idee die auch leicht verständlich sein sollte.
 
Bei 2 Karten gibts ja bekanntlich Mikroruckler ok soviel ist derweil klar.
Wie siehts aber bei Triple SLI aus?
 
Bei 3 GPUs gibt es das Problem auch. Wahrscheinlich in Extremsituationen noch schlimmer als bei 2 GPUs.

Dann sehen die Zeiten bei 30FPS (10FPS pro GPU) im schlimmsten Fall so aus:

Frame 1: 100ms GPU1
Frame 2: 105ms GPU2
Frame 3: 110ms GPU3
Frame 4: 200ms GPU1
Frame 5: 205ms GPU2
Frame 6: 210ms GPU3

Dabei kommen dann gefühlte 10FPS heraus, obwohl 30FPS berechnet werden.
 
Mal ein extremes Beispiel für 1,2,3 und 4 Karten :

Fps=25, Minimum-delay zwischen den frames 10ms.

Mit einer Karte, klar 25 fps echt und gefühlt

mit 2 Karten : Verlauf 10-70-10-70-10 -> gefühlt im extremfall nur 14,3 fps

mit 3 Karten : Verlauf 10-10-100-10-10-100 -> gefühlt im extremfall nur 10 fps

mit 4 Karten :: Verlauf 10-10-10-130 -> gefühlt im extremfall nur 7,7 fps


selbst 60fps würden sich in manchen Spielen nur wie 27fps anfühlen mit 4 GPUs.


edit : ja ich bin langsam :(
 
Realsmasher schrieb:
ich rechne mal fix für 30fps und 15er delay durch :

hast recht war ein Denkfehler von mir:

das hier stimmt:

Frame 1: (1000/ fps) - Delay
Frame 2: (1000/ fps ) + Delay

Beispielhaft: 40 fps , 10 ms Delay (bzw. Abstand insgesamt 20ms)
ohne Delay:
Frame 1: 25 ms
Frame 2: 25 ms...

40 * 25 = 1000ms -> passt

mit Delay:

Frame 1: 1000/40 - 15 = 25-10 = 15 ms
Frame 2: 1000/40 + 15 = 25 +10 = 35 ms

Abstand: 20 ms (2*Delay)
2 Frames = 50 ms

40 Frames = 1000ms -> passt

in deiner Rechenformel werden die Abstände zu groß.

Deine Formel:
Frame1: (1000/40)*2-10 = 50-10 = 40
Frame2: 10

auch im Schnitt 40 fps aber effektiv eine Verzögerung von 30 ms (ruckelt zu stark)

nun ist die Frage was bei dir unter Delay verstanden wird?
Die Mikroruckler sind ja bedingt durch den Abstand von Frame1&Frame2

somit musstest die Verzögerung gerade von der Differenz davon abhängen.
Du solltest also die gesamte Verzögerungszeit einstellen:
z.b. 20ms -> Delay = 20ms / 2 = 10ms

könntest du das Programm eventuell auch so programmieren das man FPS (krumme FPS) angibt
Vorteil:
man kann die Panelfrequenz des monitors damit bestimmen.

viele monitore arbeiten nicht mit genau 60hz, aber es werden grafikkarten seitig 60 eingestellt -> führt zu regelmäßigen Rucklern. (wegen der asyncronität)
wenn man diese Frequenz einiger maßen genau ermitteln könnte,(das ginge sogar mit deinem Programm wenn mans entsprechend genau einstellen kann)
könnte man die Frequenz in der Grafikkarte anpassen.

(Viele TFTs haben leider nur eine feste Panelupdatefrequenz)

Spürbar wenn man bei deinem Programm etwa eben gerade im FPS bereich 50-60 wandert. (das ist kein ruckeln weil es zu wenig fps sind)
Letztendlich sind deswegen auch erst ~ 60 hz ( 60 fps ruckelfrei)

(und das ist gerade ein Problem für die Beurteilung von microrucklern, eigentlich müsste man die Microruckler auf einem CRT überprüfen, an einem TFT ist das sehr problematisch)
 
Zuletzt bearbeitet:
Fairy Ultra schrieb:
nun ist die Frage was bei dir unter Delay verstanden wird?
Die Mikroruckler sind ja bedingt durch den Abstand von Frame1&Frame2

und genau das ist das delay bei mir. der abstand von frame 1 zu 2


es ist damit NICHT der abstand zur Framedauer einer singlekarte gemeint, wie du es vorgerechnet hast.

siehe auch was iscaran schreibt :

Also dein Prog nutzt als Delay nicht den Abstand zum Mittelwert sondern direkt den "kurzen" Abstand zwischen 2 frames (bei einer beliebigen Folge von 4 frames). Dann ist es natürlich nur logisch das der "kurze" Delay in Wahrheit der schlimmere ist.
 
ich zitier mich mal selbst von weiter oben im Thread :

da hilft kein Grafiktreiber und auch kein externes Tool, die können alle das Problem nur verschieben

schön das dann die ausgabe gleichmäßig verläuft, dafür aber der sichtbare inhalt nichtmehr.


nehmen wir an ein Auto bewegt sich um 1 meter pro ms und frame 1 ist nach 45ms da, frame 2 nach 15ms.

dann hat sich das auto in frame 1 um 45meter bewegt und in frame 2 um 15 meter.

hält man nun frame 2 auf, sodass er erst nach 30ms kommt, dann hat sich auto trotzdem nur 15meter bewegt.

Demzufolge würde der Bildinhalt ungleichmäßig laufen anstatt der Frameausgabe, der effekt wäre aber ähnlich.

Die einzige lösung ist es, die cpu aufzuhalten BEVOR sie mit der berechnung beginnt, nicht aber die gpu aufzuhalten wenn die cpu schon längst die relevanten Daten für das Bild erstellt hat.


Die einzige wirkliche Änderung ist, das wir weiterhin MR haben, sie aber nichtmehr anhand von frametimes nachweisen können.
 
Zuletzt bearbeitet:
Nettes Programm. Nun kann ich mir endlich was unter Microrucklern vorstellen.

Eine Anregung hätte ich noch:
Anstelle der RAR Kompression lieber LZMA (7zip) verwenden. Das mit dem Ultra Preset erstellte Archiv ist um 1 MB kleiner, was bei 3 MB schon recht viel ist. (Liegt unter anderem an der besseren BMP Kompression.)
 
Zurück
Oben