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
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:
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:
Nvidia - Mikro Ruckler - Die Erklärung - Patrick fragt! - 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:
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
Die Testversion hat nur eine (meiner Ansicht nach verschmerzbare) Einschränkung:
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
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
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:
Nvidia - Mikro Ruckler - Die Erklärung - Patrick fragt! - 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:
Zuletzt bearbeitet:
...deswegen hatte ich es dran gegeben und konnte nicht verstehen wie man darüber so begeistert sein konnte^^
- auf hd7770 warten ist angesagt. 
Da war ATI selbst noch nicht so weit)
