Mikroruckler - Entstehung, Benches, Einfluss von GPU-Anzahl und CPU, Lösungsansatz

[boxleitnerb]

1. Einleitung

Da hier im Forum das Thema Mikroruckler immer mal wieder vorkommt, die wenigsten aber genau wissen, was das ist, woher es kommt und wie man damit umgeht, eröffne ich diesen Thread.

Das soll nun aber kein Monolog werden, sondern auch euer Wissen und eure Erfahrungen sind gefragt. Vieles ist auch mir noch unklar, und wenn ich irgendwo Quatsch schreibe, wäre ich für eine Richtigstellung (aber bitte mit Erklärung und evtl. Beleg) sehr dankbar. Wer gar ein paar Benchmarks beisteuern möchte, ist herzlich willkommen, dies zu tun.

Abkürzungen

Spoiler: Anzeigen

MR: Mikroruckler
SGPU: Single-GPU, Rendering auf einer GPU
MGPU: Multi-GPU, Rendering auf mehreren GPUs (Crossfire/SLI)
SFR: Split Frame Rendering, mehrere GPUs rechnen immer an einem Bild
AFR: Alternate Frame Rendering, mehrere GPUs rechnen allein an aufeinanderfolgenden Bildern

2. Mikroruckler und ihre Entstehung

Normale Ruckler (oder auch Makroruckler) enstehen, weil man zu wenig fps hat. Für einen flüssigen Bildaufbau fehlen dann Einzelbilder. Diese Ruckler können sowohl bei Single-GPU als auch bei CF/SLI auftreten.

Mikroruckler treten auf, wenn man genügend Bilder in einer Sekunde hat, diese aber nicht gleichmäßig über dieses Zeitintervall verteilt sind. Das folgende Diagramm stellt dies anschaulich dar.
Von oben nach unten: SGPU, MPUG (AFR), MGPU (SFR) - Bild von Spasstiger aus dem 3DC



MR sind ein inhärentes Problem der AFR-Rendermethode. Wird gleichzeitig immer nur ein Bild bearbeitet, wie es bei SGPU und SFR der Fall ist, werden die Bilder einfach ausgegeben, wenn sie fertig sind (ohne VSync oder Triple Buffering). Bei AFR hingegen ist Synchronisationsarbeit nötig, wie das folgende Diagramme zeigen sollen:

50fps


40fps, 33fps:


Annahmen:

• Es dauert 10 ms, bis die Daten für ein Bild bereit sind
• Eine GPU rechnet deutlich länger an einem Bild (GPU-Limit)
• Die Bildaufträge werden sequentiell abgearbeitet und herausgegeben, nicht auf einmal
• Wir betrachten nur ein kleines Zeitintervall (< 1 Sekunde)

Alle zwei Bilder (bei zwei GPUs) tritt eine größere Verzögerung ein, weil die GPUs zu schnell hintereinander angefangen haben zu rendern. Dem Rendering voran geht die Datenverwaltung der Spieleengine, Berechnungen auf der CPU, Transfers zum RAM und per PCIe zur Hauptgrafikkarte.

Die Engine weiß nicht, wie lange dies alles dauert und wie lange die GPU(s) rendern werden. Sie kann also in der Regel die Geschwindigkeit, mit der sie die Daten rausgibt, nicht passend timen.
Hierzu auch Lars Weinand von Nvidia:

&#x202a;Nvidia - Mikro Ruckler - Die Erklärung - Patrick fragt!&#x202c;&rlm; - YouTube

Einen wichtigen Einfluss hat die CPU, die wohl maßgeblich die Vorbereitungszeit für ein Bild bestimmt.

Allerdings muss irgendeine Synchronisation stattfinden, denn wenn man das Diagramm weiterführen würde, würde der zeitliche Abstand zwischen vorausberechneten Daten und zugehörigem Bild immer größer werden (solange man im GPU-Limit bleibt).

Man misst MR mit Frametimeabständen, also der Zeit, die zwischen der Ausgabe der einzelnen Bilder liegt. In einem Graphen sieht das dann so aus:


Quelle: PCGH

3. Einfluss der CPU

Wie schon erwähnt, liegt die Ursache der MR wohl daran, dass die Bildaufträge an die Grafikkarten zu schnell herausgegeben werden. Als Lösungsansatz sei vorweggenommen, dass man nun entweder die Aufträge vor dem Rendering oder die Bildausgabe nach dem Rendering besser timen kann.

Im Optimalfall wartet keine Komponente auf die andere:



Braucht die CPU noch länger, befinden wir uns im "CPU-Limit":



Das Rechenzeitverhältnis CPU/GPU an einem Bild ist hier wichtig, weil es darauf ankommt wie stark die o.g. Bremsung ist, was die Wartezeit und damit die Mikroruckler beeinflusst. An obigem Beispiel (selbe Framerate, immer noch 33fps) sehen wir also:

• Braucht die CPU/Engine nur 10 ms, mikroruckelt es
• Braucht die CPU/Engine 30 ms, mikroruckelt es nicht

Die These ist also:
Eine langsamere CPU vermindert je nach Engine/Spiel Mikroruckeln (im GPU-Limit!!!)

fdsonne und ich haben hierzu ein paar vorläufige Benchmarks gemacht. Erst möchte ich seine Werte präsentieren, da bei meinen Messungen wohl irgendwas schiefgelaufen ist und die Ergebnisse keinen Sinn ergeben (obwohl wir dasselbe gemessen haben).

Unigine Heaven, VSync aus. Linksk 4,5 GHz, rechts 2,2 GHz


Man sieht zumindest in diesem Beispiel:
Mit sinkender CPU-Leistung (Annäherung das optimale Lastverhältnis) nehmen die Mikroruckler ab!

Hier eine eigene Messung mit GTA 4. System ist ein 2600K und zwei GTX580 3GB im SLI.
Das Ergebnis ist überdeutlich. Nicht vergessen: Wir befinden uns hier trotz nur 1600 MHz aufgrund der hohen Bildqualitätseinstellungen (Auflösung!) im GPU-Limit! Die fps ändern sich nicht/kaum.



Und hier Mafia 2:


3. Einfluss der GPU-Anzahl

Bei gleichen fps sollte ein Gespann mit mehr GPUs auch stärkere Mikroruckler produzieren:



Hier ein Benchmark aus Unigine Heaven, immer mit denselben fps und anderselben Stelle:



Es ist schwierig, hier einen Trend herauszulesen. Ich schau mal, ob mein Kumpel das noch mit Mafia 2 testen kann, da sieht man es glaub deutlicher.

4. Lösungsansatz

Dass bei höheren fps die Frametimes gleichmäßiger werden, ist kein Geheimnis. Zwar hat man je nach Spiel manchmal auch noch bei 60+ fps ein unrundes Spielerlebnis, aber in der Regel ist man ab ca. 50 fps gut dabei.

Jetzt gibt es aber auch solche Leute wie mich, die sich ein Multi-GPU-System anschaffen, um möglichst maximale Einstellungen zu fahren. Also SGSSAA, Downsampling, 3DVision, Eyefinity und was es noch alles gibt. Selbst mit den stärksten Systemen kann es vorkommen, dass man deutlich unter 60 fps fällt. Dann trüben Mikroruckler massivst das Spielerlebnis. Ein halbwegs aktuelles Worst-Case Beispiel ist Mafia 2, das unter 50 fps praktisch unspielbar ist mit mehr als einer GPU.

Aber es gibt Abhilfe, und zwar in Form eines Framelimiters. Die genaue Funktionsweise kenne ich leider nicht, jedoch vermute ich stark, dass neben der Begrenzung der Framerate die x Bilder pro Sekunde gepuffert und gleichmäßig ausgegeben werden. Sehr anschaulich sieht man das auch wieder bei Mafia 2:



Ohne Limiter bewegen wir uns bei 33fps und es ist alles andere als flüssig. Mit auf 30 fps gesetztem Limiter werden sämtliche Mikroruckler eliminiert - das Spiel ist komplett flüssig. Frametimes sagen nicht die ganze Wahrheit. Manchmal kann die Verteilung derselbigen sehr gleichmäßig aussehen und doch ist es "unrund". In ausnahmslos allen Spielen, die ich getestet habe, sorgt ein fps-Limiter für ein absolut flüssiges Spielerlebnis (in meinem Rahmen von 30-40 fps, in dem ich mich auch mit einer GPU bewegen würde). Es gab sehr positives Feedback auch von anderen Leuten, die mit einem Limiter experimentiert haben.

Welche Software ist also hier zu empfehlen?
Ich kenne mehrere Programme, aber nur eines funktioniert (soweit ich es bisher ausprobiert habe) in allen APIs, in 32 und 64bit und ist in der Testversion kostenlos: Dxtory 2.0

Dxtory.com | Home

Dxtory ist eigentlich ein Captureprogramm für Video/Audio/Screenshots in Spielen, doch es hat auch einen Limiter integriert, der einwandfrei funktioniert:



Zwei sehr angenehme Eigenschaften dieser Software sind, dass man

• das Limit völlig frei einstellen kann und nicht an 30 oder 60 fps gebunden ist
• das Limit nur einmal pro Spiel einstellen muss, weil es eine Profilverwaltung gibt

Die Testversion hat nur eine (meiner Ansicht nach verschmerzbare) Einschränkung:

A license purchase site is displayed, when a program is terminated.

[Powerplay]

Problem ist halt das man auch eine gewissen leistung braucht um eine gewissen FPS zu erreichen!
Bei AMD kann man ja drei karten verbauen und schon hat man kaum noch microruckler!!

Ich glaube am besten wäre es aber mit nem 120HZ TFT und V-Sync

[Pumpi74]

1.) Klasse Sache, danke.

2.) Deine letzten zwei Bilder sind falsch beschriftet, eins ist mit 2200Mhz gemessen.

3.) Das mit dem CPU drosseln funktioniert nur synthetisch in kurzen Benchmarks. Die CPU Anforderung über die Zeit ist sicherlich zu schwankend, als das man sie genau eindrosseln könnte.

4.) Baut man sich ein SLI braucht man halt erstmal stabile 60fps, weil der Vsync limiter funzt immer, im Gegensatz zu einigen anderen.

Das ist doch aber auch nicht schlimm, visuell ist es dann glatt wie bei 40 fps auf single GPU, aber man hat noch den Vorteil des dann flüssigeren gameplays.

Ergo: Beim SLI macht kleckern keinen Sinn, nur klotzen bringt es wirklich. Das soll jetzt nicht überheblich sein, das ist einfach so. Entweder richtig oder eine GTX 580 @1,1 Ghz

[boxleitnerb]

1.) Klasse Sache, danke.

2.) Deine letzten zwei Bilder sind falsch beschriftet, eins ist mit 2200Mhz gemessen.

3.) Das mit dem CPU drosseln funktioniert nur synthetisch in kurzen Benchmarks. Die CPU Anforderung über die Zeit ist sicherlich zu schwankend, als das man sie genau eindrosseln könnte.

4.) Baut man sich ein SLI braucht man halt erstmal stabile 60fps, weil der Vsync limiter funzt immer, im Gegensatz zu einigen anderen.

Das ist doch aber auch nicht schlimm, visuell ist es dann glatt wie bei 40 fps auf single GPU, aber man hat noch den Vorteil des dann flüssigeren gameplays.

Ergo: Beim SLI macht kleckern keinen Sinn, nur klotzen bringt es wirklich. Das soll jetzt nicht überheblich sein, das ist einfach so. Entweder richtig oder eine GTX 580 @1,1 Ghz

1. No problem

2. Fixed

3. Deshalb hab ich nur 3 Sekunden aufgenommen und da auch nur die ersten 30 Frames aufgetragen. Ich schrieb explizit dazu, dass ein kleiner Zeitintervall betrachtet wird. Sonst ist die Reproduzierbarkeit natürlich im Eimer.

4. Selbst bei 60fps sind je nach Engine und Lastverteilung Mikroruckler nicht völlig ausgeschlossen. VSync hilft soweit ich weiß nicht gegen Mikroruckler. Ein richtiger fps-Limiter wie nthusim oder Dxtory dagegen hilft sehr wohl (kommt später noch).

Ganz wichtig!

Das Problem der zu schnellen CPU tritt sicherlich nicht in jedem Spiel auf. Es kommt auf die Engine an und man muss (tief) im GPU-Limit stecken.

Problem ist halt das man auch eine gewissen leistung braucht um eine gewissen FPS zu erreichen!
Bei AMD kann man ja drei karten verbauen und schon hat man kaum noch microruckler!!

Ich glaube am besten wäre es aber mit nem 120HZ TFT und V-Sync

Das musst du differenzierter sehen. Willst du/hast du sowieso immer mehr als sagen wir 50-60fps, ist das Problem nicht so gravierend. Wenn du aber im GPU-Limit steckst, ist die CPU für die fps egal, und genau in diesem Bereich trifft man auf die beschriebene Problematik.

Dass man auch mit hohen fps nicht vor Mikroruckler gefeit ist, zeigt laryllan aus dem Forum von Computerbase:
http://www.computerbase.de/forum/sho...&postcount=213

D.h. je nach Spiel bringt dir da ein 120Hz TFT mit VSync auch nix.
Außerdem: Woher weißt du, dass du keine Mikroruckler hast? Hast du die Frametimes auch wirklich gemessen? In laryllans erstem Beispiel hast du trotz 120fps Mikroruckler, nur nimmst du sie nicht als klassisch spürbare Ruckler (unterhalb deines Flüssigkeitsempfindens) wahr. Was aber passiert: Die 120fps fühlen sich nicht so flüssig an, wie sie es auf einer einzelnen Karte wären. Er sagt ja, 60fps mit Limiter fühlen sich in etwa gleichwertig wenn nicht besser wie die 120fps ohne Limiter an.

[Hogge]

dazu gabs erst nen schönen test mit den microrucklern bei tomshardware in verbindung mit sli/crossfire
AMD Crossfire vs. Nvidia SLI - Mikroruckler, Kernskalierung und Nutzen : Einführung und Übersicht

[Pumpi74]

VSync hilft soweit ich weiß nicht gegen Mikroruckler

Da scheiden sich wohl klar die Geister.

Ich hab auch schon das ein oder andere Zitat vernommen das glauben machen möchte das Vsync nichts im Kampf gegen die MR ausrichtet.

Nur Fakt ist doch auch mal das es zig Leute gibt die mit Vsync @ 60fps von allen Ruckelproblemen befreit sind, zumindest nehmen sie diese nicht mehr war.

Genauso bei mir, Unigine Heaven ist mit Average 60 fps ohne Vsync absolut ungenießbar. Mit vsync ist es trotz Drops auf 30fps runter immerhin schonmal erträglich. Mit 60fps im Vsync ohne Drops runter läuft es dann Butterweich. Mit der Beobachtung bin ich sicher nicht alleine.

Letzteres Setting kostet natürlich richtig Leistung, nur das muß es einem Wert sein.

Wenn die großen Konsolen und ihre Software am Start sind wird man vermutlich zwei Grafikkarten brauchen nur um Games bei 60 Fps im klaren Vsync zu halten und nur eine dritte Karte könnte die BQ verbessern und das @ FullHD.

Eine Umfrage zum Thema "Hilft Vsync gegen MR" und das unterteilt in "Vsync : Hauptsache an" und "Vsync @ immer 60fps" wäre genau das richtige zur Unterstützung dieses Threads

[boxleitnerb]

dazu gabs erst nen schönen test mit den microrucklern bei tomshardware in verbindung mit sli/crossfire
AMD Crossfire vs. Nvidia SLI - Mikroruckler, Kernskalierung und Nutzen : Einführung und Übersicht

Ich frage mich, warum es bei mehr GPUs bei denen weniger MR gibt. Laut der Theorie werden die Sprünge größer (33fps, 10ms CPU):

10-30-10-30... bei 2 GPUs
10-10-10-90... bei 4 GPUs

[Powerplay]

Vsync bringt was! Allerdings sollte man dann auch die Vsync FPS als min haben!
bei vsync wird doch die bildausgabe zeitlich beschränkt!
FPS limiter kann auch was bringen!

[boxleitnerb]

Dann ist doch die Frage, woher die Verbesserung maßgeblich kommt:

Durch die höhere Framerate an sich oder durch VSync? Wenn schon, sollte man Äpfel mit Äpfeln vergleichen und die Framerate für solche Tests gleich lassen. Dazu werde ich heute noch einen Test nachreichen.

[LD]

Ich frage mich, warum es bei mehr GPUs bei denen weniger MR gibt. Laut der Theorie werden die Sprünge größer (33fps, 10ms CPU):

10-30-10-30... bei 2 GPUs
10-10-10-90... bei 4 GPUs

Vllt solltet ihr auch mal eine Messung mit 3 oder 4 GPU-s machen um die Theorie mit der auf GPU warten zu belegen, denn bei 2 GPU-s ist es nicht überraschend dass die Frames abwechselnd in langen und kurzen Abständen kommen, das ist ja genau die Ursache von MR.

[boxleitnerb]

Ja ich kenne jemanden, der 4 GTX480 hat, vielleicht hat der das Wochenende mal Zeit, ein oder zwei Benchmarks zu fahren.

Oder hat hier noch jemand 4 GPUs?

[LD]

Ich habe nur noch 3.

[boxleitnerb]

Ich habe nur noch 3.

Das ist doch mal ein Anfang. Hast du ein Spiel, das leicht mikroruckelt, z.B. GTA4, Metro 2033, Call of Juarez oder sowas? Kannst mir gern auch ne PN schreiben, damit wir den Thread eher mit Ergebnissen, nicht mit sowas füllen.

[Powerplay]

also wenn LD wirklich 3amd gpus hat kann man wirklich mal testen ob da wirklich keine oder kaum MR auftreten

[ulukay]

Ja ich kenne jemanden, der 4 GTX480 hat, vielleicht hat der das Wochenende mal Zeit, ein oder zwei Benchmarks zu fahren.

Oder hat hier noch jemand 4 GPUs?

hatte ich mal.
absolut hirnrissig in sachen stromaufnahme und hitzeentwicklung. nicht wirklich besser in sachen spielbarkeit. einzig der vpenis wird laenger
eventuell find ich noch meine frametimes aufnamen mit fraps von damals

[Powerplay]

hatte ich mal.
absolut hirnrissig in sachen stromaufnahme und hitzeentwicklung. nicht wirklich besser in sachen spielbarkeit. einzig der vpenis wird laenger
eventuell find ich noch meine frametimes aufnamen mit fraps von damals

4gpus lohnt wohl nur bei 3 monitore mit jeweil 2560x1440er auflösung das vermute ich aber nur

[LD]

4gpus lohnt wohl nur bei 3 monitore mit jeweil 2560x1440er auflösung das vermute ich aber nur

Oder wenn man überall Downsampling benutzen will.

[ulukay]

4gpus lohnt wohl nur bei 3 monitore mit jeweil 2560x1440er auflösung das vermute ich aber nur

supersampling reicht da schon

[Powerplay]

ja nur geht das bei amd nur per tool und bei nv wirds unscharf weil man keinen negativen lod bekommt!
Aber ds ist schon echt geil! würde mich interessieren wie deine drei gpus scallieren...

[LD]

Ich werde bald auch ein paar Frametimes posten.

[ulukay]

ein weiterer nachteil wurde hier im uebrigen noch garnicht gelistet. SLI und CF setzen auf AFR. sprich abwechselt rendert eine gpu ein frame. damit da aber auch ein geschwindigkeitsvorteil rauskommt, muss man mindestens 1 frame vorrausrendern. sprich wenn man z.b. einen gegner sieht und reagiert, ist man immer 1 frame hintennach. ebenso "zieht" die maus leicht nach/bzw reagiert nicht so flott wie komplett ohne prerendering.
der inputlag ist bei 30fps und 0 vorgerenderten frames gleich hoch wie bei sli mit 60fps. irgendwie idiotisch

[fdsonne]

ein weiterer nachteil wurde hier im uebrigen noch garnicht gelistet. SLI und CF setzen auf AFR. sprich abwechselt rendert eine gpu ein frame. damit da aber auch ein geschwindigkeitsvorteil rauskommt, muss man mindestens 1 frame vorrausrendern. sprich wenn man z.b. einen gegner sieht und reagiert, ist man immer 1 frame hintennach. ebenso "zieht" die maus leicht nach/bzw reagiert nicht so flott wie komplett ohne prerendering.
der inputlag ist bei 30fps und 0 vorgerenderten frames gleich hoch wie bei sli mit 60fps. irgendwie idiotisch

Grundsätzlich richtig... Aber man sollte bei allen Nachteilen von MGPU Systemen nicht vergessen, das es sowieso Verzögerungen zwischen Eingabe und Ergebnis am Schirm gibt. Oft ist da auch ein schlechtes Eingabegerät viel mehr auffällig wie ein MGPU System.
Das es grundsätzlich ein gesteigertes InputLag bei MGPU Systemen gibt, ist aber erstmal richtig Und um so mehr GPUs im AFR mitrendern, desto schlimmer wird der Spaß.

[carlo33]

ja nur geht das bei amd nur per tool und bei nv wirds unscharf weil man keinen negativen lod bekommt!

Laber keinen Quatsch da ist garnichts unscharf und LOD wird bei OGSSAA aka DS automatisch erzeugt. War nicht böse gemeint, sondern nur als Aufklärung dienen.

[boxleitnerb]

Bitte gleitet nicht vom Thema ab

[scully1234]

Interessante These aber um daraus für den "Otto Normalo" einen Vorteil zu gewinnen bräuchte man für jedes Spiel mit jeglicher Art von GPU/CPU Setup eine Berechnung des Lastzustandes CPU/GPU Limit und ein daraus resultierendes Lastprofil im Treiber oder extern was daraufhin das System austariert im Takt

Edit: was ich aber auch noch annehme ist das die Anbindung des Vram und die aufkommende Datenflut mit zunehmenden CPU Takt ebenso einen negativen Einfluss auf die MR haben könnte. Wenn es die ersten PCIe 3.0x16 Boards gibt müsste man mit selber Hardware bei hoher CPU Taktrate das ganze nochmal laufen lassen

Vielleicht verhilft der veringerte Takt der CPU nur dem Bus dazu nicht für Bruchteile von Sekunden an seine Grenzen zu stoßen