Mikroruckler/AFR - Frage zur Entstehung

[boxleitnerb]

Weit verbreitet ist ja die Erklärung, dass die CPU deutlich fixer mit der Vorbereitung eines Bildes ist als eine GPU dieses Bild rendern kann.

Die gängige Annahme ist, dass die CPU nach 2 (2 GPUs) bzw. 3 (3 GPUs) Bildern auf die GPUs warten muss, obwohl schon das 3. bzw. 4. Bild berechnet werden könnte, und diese Wartezeit dann die Mikroruckler erzeugt. Die GPUs rechnen hier leicht versetzt, wobei dieser Versatz der Zeit enspricht, die die CPU jeweils zur Vorbereitung eines Renderauftrags benötigt.

Jetzt gibt es aber auch die Meinung, dass die CPU bei AFR 2 bzw. 3 Bilder vorbereitet und die Aufträge gleichzeitig raushaut und die GPUs erst dann gleichzeitig zu rechnen beginnen.

Könnte da ein Guru bitte nochmal Licht ins Dunkel bringen? Inzwischen bin ich mir nämlich nicht mehr völlig sicher.
Außerdem noch eine Frage zu Frame Limitern:

Beeinflussen diese das Timing der Renderaufträge, so dass die GPUs erst dann anfangen, wenn das vorherige Bild zu 50% (2 GPUs) bzw. 33% (3 GPUs) fertig ist oder ändern sie das Ausgabetiming der schon fertigen Bilder nach dem Rendern?

Edit:
Sollten Mikroruckler mit 4 GPUs nicht besser sein als nur mit 2? Bei einer fixen Framerate von 40fps und angenommenen 10ms CPU-Zeit pro Frame hat man

bei 2 GPUs: 10-40-10-40 -> fps springen zwischen 100fps und 25fps. Im Mittel 40fps
bei 3 GPUs: 10-10-30-10-10-30 -> fps springen zwischen 100fps und 33fps. Im Mittel 40fps
bei 4 GPUs: 10-10-10-20-10-10-10-20 -> fps springen zwischen 100 und 50fps. Im Mittel 40 fps

[xxMuahdibxx]

Grob gesagt müsste es besser sein mit mehr GPU´s aber es erfordert schon mehr aufwand die Bilder auch zu verteilen ... und auch die PCI Express Lanes werden dann knapp .

4 x GPU a 16 Lanes frag mich nicht ob das wirklich geht .

Problem ist aber auch das jede Szene eine unterschiedliche Grafiklast darstellt man kann sich halt drehen und schwups muss die Graka unmengen neue Daten berechnen und die CPu halt auch .

Wohl wäre es möglich mit gewissen Delays zu hantieren aber das würde ja die "Perfomance" beschneiden die man erreichen will statistische hohe FPS werte .

[boxleitnerb]

Sollten direkt aufeinanderfolgende Frames nicht von der Rechenlast sehr ähnlich sein, weil Veränderungen in den Szenen im Vergleich dann doch eher langsam sind?

Weiterhin:

Wie ist es denn in der Praxis? Da sind die Mikroruckler mit mehr GPUs doch schlechter. Widerspricht das nicht der Theorie?

Wie spielt die Übertragungszeit von der Sekundär- auf die Primärkarte (die die Bilder ausgibt) rein? Wie wird das getimed?

Fragen über Fragen :)

[InsaneDruid]

Edit:
Sollten Mikroruckler mit 4 GPUs nicht besser sein als nur mit 2? Bei einer fixen Framerate von 40fps und angenommenen 10ms CPU-Zeit pro Frame hat man

bei 2 GPUs: 10-40-10-40 -> fps springen zwischen 100fps und 25fps. Im Mittel 40fps
bei 3 GPUs: 10-10-30-10-10-30 -> fps springen zwischen 100fps und 33fps. Im Mittel 40fps
bei 4 GPUs: 10-10-10-20-10-10-10-20 -> fps springen zwischen 100 und 50fps. Im Mittel 40 fps

Bei deiner Rechnung beachtest du nicht, dass auch mit 10000 GPUs die Renderzeiten pro Frame exakt gleich bleiben, da nachwievor jeweils nur eine GPU einen Frame rendert, egal wie viele GPUs im System sind. Das ist ja bei AFR der extreme Unterschied zu, zb Scanline Interlaving, wobei die Renderzeiten pro Frame sich bei 2 GPUs halbierten.

EDIT: Außerdem ist es ja grade das Problem, dass die CPU sofort mit den Vorbereitungen zum 2ten Frame beginnt, sobald das erste an die erste GPU abgesetzt ist. Damit knallt die 2te GPU sehr zeitnah zum ersten Bild ihr Bild raus (nämlich im Abstand der Zeitdauer die die CPU benötigt), was auch noch inhaltlich sehr nah am ersten ist, obwohl es besser wäre selbst mit den vorbereitungen (CPU Last) zu warten, um nicht nur den Anzeigezeitpunkt des 2ten Bildes weiter nach hinten zu schieben, sondern auch den Bildinhalt zeitlich weiter in der Bewegung nach hinten zu stellen.

[Captain Future]

Das wirkliche Problem ist aber, dass die fertigen Bilder erstmal wieder zurück in den Framebuffer der Grafikkarte transferiert werden müssen, an die der Monitor angeschlossen ist.

Hier könnte der Grafiktreiber zwar eingreifen, aber das werden die IHVs schön bleiben lassen, weil es Balkenlänge kostet.

[boxleitnerb]

Bei deiner Rechnung beachtest du nicht, dass auch mit 10000 GPUs die Renderzeiten pro Frame exakt gleich bleiben, da nachwievor jeweils nur eine GPU einen Frame rendert, egal wie viele GPUs im System sind. Das ist ja bei AFR der extreme Unterschied zu, zb Scanline Interlaving, wobei die Renderzeiten pro Frame sich bei 2 GPUs halbierten.

EDIT: Außerdem ist es ja grade das Problem, dass die CPU sofort mit den Vorbereitungen zum 2ten Frame beginnt, sobald das erste an die erste GPU abgesetzt ist. Damit knallt die 2te GPU sehr zeitnah zum ersten Bild ihr Bild raus (nämlich im Abstand der Zeitdauer die die CPU benötigt), was auch noch inhaltlich sehr nah am ersten ist, obwohl es besser wäre selbst mit den vorbereitungen (CPU Last) zu warten, um nicht nur den Anzeigezeitpunkt des 2ten Bildes weiter nach hinten zu schieben, sondern auch den Bildinhalt zeitlich weiter in der Bewegung nach hinten zu stellen.

Du hast natürlich vollkommen Recht. Ich hab das inzwischen auch näher mit zwei, drei Leuten untersucht, und die geistigen Ergüsse daraus sind hier zu finden:
http://www.hardwareluxx.de/community/f14/mikroruckler-entstehung-benches-einfluss-von-gpu-anzahl-und-cpu-loesungsansatz-824152.html

Soll ich den Thread hier auch aufmachen oder ist das nicht nötig?

Das wirkliche Problem ist aber, dass die fertigen Bilder erstmal wieder zurück in den Framebuffer der Grafikkarte transferiert werden müssen, an die der Monitor angeschlossen ist.

Hier könnte der Grafiktreiber zwar eingreifen, aber das werden die IHVs schön bleiben lassen, weil es Balkenlänge kostet.

Das ist doch auch bei SFR der Fall, oder? Hier zwar nur ein halbes Frame (salopp gesagt), aber an der grundlegenden Problematik ändert das imo nichts.

[Captain Future]

Bei SFR muss sowieso immer solange gewartet werden, bis die Daten von beiden GPUs auf einmal da sind, da tritt das Problem nicht (oder zumindest wesentlich weniger stark) auf.