MR@tri-fire

[eliciel]

hallo,

ich spiele schon eine weile mit dem gedanken, mir eine 6990 zu meiner bestehenden freigeschalteten 6950 dazuzukaufen. grund: ich hink schon seit ich denken kann immer mit meinen midrange-karten den fluessigen fps hinterher. das muss auch mal ein ende haben.

wie sieht das in 3x crossfire mit mikrorucklern aus? also mein wissensstand ueber crossfire und mikroruckler begrenzt sich auf Alternate frame rendering - Wikipedia, the free encyclopedia und damals dieses fake-MR programm. kann ich das so verstehen, dass bei 3x crossfire dann 3 frames alternierend gerechnet werden und die wahrscheinlichkeit, dass diese sehr kurz (so wie bei 2 karten 2 frames direkt) hintereinander gerendert werden, sinkt? hat es ueberhaupt etwas mit wahrscheinlichkeit zu tun? am besten fuer mich waere, wenn jemand mit einem tri-fire system mal eine detail-analyse der framezeiten machen koennte in verschiedenen spielen. ein verweis zu einem solchen review, falls es existiert, waere natuerlich auch klasse.

mir hat sich noch eine frage aufgetan: laufen die beiden karten ueberhaupt zusammen auf einem board mit x8/x8?

 

[boxleitnerb]

Soweit ich weiß, entstehen Mikroruckler dadurch, dass die GPUs länger an einem Bild rechnen, als die CPU braucht, um es vorzubereiten bzw. den Auftrag für die Berechnung rauszugeben.

CPU braucht z.B. 10ms, GPUs für 2 Bilder 50ms (also 40fps). Die Kadenz, die daraus folgt, ist in diesem Fall 10-40-10-40

Bei 3 GPUs und 40fps wäre es 10-10-30-10-10-30

Wie sich das subjektiv anfühlen würde, kann ich nicht sagen, da müssen andere her.
Was ich dir aber sagen kann ist, dass du mit einem fps-Limiter die Bildaufträge zeitlich verlangsamen kannst, und zwar so, dass GPU 2 anfängt, wenn GPU 1 ein Drittel ihres Bildes gerechnet hat und GPU 3, wenn GPU 2 ihrerseits ein Drittel fertig hat. Dann kommen die Bilder gleichmäßig heraus und du hast (idealerweise) keine Mikroruckler.

In der Praxis funktioniert das meistens hervorragend. Tools wie Tommtis SSAA-Tool (kostenlos aber nicht so zuverlässig) oder Dxtory (32 Euro, funzt aber 1A) könntest du dir mal anschauen. Von Dxtory gibt es selbstverständlich eine kostenlose Testversion. Ein Kumpel hat das mit 4-way SLI probiert und damit ist es butterweich, wo er vorher starke MR hatte.

 

[fdsonne]

Soweit ich weiß, entstehen Mikroruckler dadurch, dass die GPUs länger an einem Bild rechnen, als die CPU braucht, um es vorzubereiten bzw. den Auftrag für die Berechnung rauszugeben.

CPU braucht z.B. 10ms, GPUs für 2 Bilder 50ms (also 40fps). Die Kadenz, die daraus folgt, ist in diesem Fall 10-40-10-40

Bei 3 GPUs und 40fps wäre es 10-10-30-10-10-30

Woher hast du das?
Weil das klingt reichlich unlogisch... Denn die CPU hat damit wohl sogut wie nix am Hut. Denn der Thread, der die Daten vorbereitet läuft nicht sequenziel nach der GPU Berechnung. Wenn die CPU also die Daten vorbereitet hat, gehts weiter mit den nächsten. Da wird nicht erst gewartet, bis die GPUs fertig sind.
Vor allem, der überwiegend verwendete Rendermodus ist AFR. Im AFR Modus berechnen alle GPUs im Gespann zur gleichen Zeit jeweils ein Bild. Das heist, es wird im Vorraus berechnet.

Die CPU bereitet also drei Bilder (sequenziel) vor, dann fängt GPU 1 an, dann GPU 2 und GPU 3 in dem Fall. Das Problem ist einfach, durch die gleichzeitige Berechnung und der Tatsache, das nicht sichergestellt ist, wie lange ein Bild zum berechnen braucht, kommen diese unterschiedlich schnell hinten raus. Diese Ausgabezeit schwankt also teils sehr stark. Und genau das sind MR. Es bezieht sich nicht auf die Berechnungsdauer vor der GPU Berechnung, sondern auf die Ausgabezeit dahinter.

NV hat sich nun dazu entschlossen wohl mit minimalen Leistungsverlust die Bildausgabe zu syncronisieren, das heist, je nach aktueller FPS wartet die jeweilige GPU in der Reihenfolge mit der Ausgabe so lange, das die Frametimes am Ende möglichst syncron sind.
Laut Aussage NVs klappt das überwiegend sehr gut. In einigen Games aber auf Grund der Datenmenge nicht (was für mich ebenso unlogisch erscheint, Crysis ist so ein Beispiel)

Ein Framelimiter macht quasi nix anderes... Aber das ist irgendwie total endgegen dem Sinn von SLI/CF. Gerade wenn man mit drei GPUs zockt.

 

[boxleitnerb]

Das ist die Erklärung von tombman aus dem 3DC - einer der ersten, der die MR "entdeckt" hat.

Die CPU bereitet also drei Bilder (sequenziel) vor, dann fängt GPU 1 an, dann GPU 2 und GPU 3 in dem Fall. Das Problem ist einfach, durch die gleichzeitige Berechnung und der Tatsache, das nicht sichergestellt ist, wie lange ein Bild zum berechnen braucht, kommen diese unterschiedlich schnell hinten raus. Diese Ausgabezeit schwankt also teils sehr stark. Und genau das sind MR. Es bezieht sich nicht auf die Berechnungsdauer vor der GPU Berechnung, sondern auf die Ausgabezeit dahinter.

Zum Fettgedruckten:
Du meinst also, die CPU bereitet die drei Bilder vor und erst DANN fangen die GPUs an? Und weiterhin soll dann zwischen den einzelnen Renderaufgaben nochmal ein Versatz liegen:

dann fängt GPU 1 an, dann GPU 2 und (dann?) GPU 3 in dem Fall

Wozu die Sache nochmal verzögern?

Später schreibst du:

Im AFR Modus berechnen alle GPUs im Gespann zur gleichen Zeit jeweils ein Bild

Das widerspricht deiner vorherigen Aussage. Fangen die GPUs jetzt exakt zum gleichen Zeitpunkt an zu rendern oder nicht? Und wenn ersteres, wieso? Warum nicht gleich anfangen zu rendern, wenn der Auftrag fertig ist?

Hier nochmal die Erklärung von tombman ausführlich in eigenen Worten:

CPU bereitet Daten vor, braucht dafür z.B. 10ms. Nach 10ms beginnt GPU 1.
Nach 20ms vergibt die CPU das nächste Bild und GPU 2 beginnt. Jetzt sind erstmal beide GPUs beschäftigt, und obwohl nach weiteren 10ms schon Bild 3 berechnet werden könnte, ist noch keine GPU "frei". Genau diese Wartezeit, bis GPU 1 wieder einen Auftrag annehmen kann, führt zu den bekannten MR - dem Hin- und Herspringen zwischen zwei (in einem kleinen Intervall) nahezu fixen Frametimes. So wie man es auch in den Messungen meist erkennen kann, z.B. bei Computerbase:

http://www.computerbase.de/artikel/...00-sli/20/#abschnitt_das_problem_mikroruckler

Ich glaube nicht, dass die GPUs exakt gleichzeitig anfangen zu rechnen. Wenn das der Fall wäre, warum hast du dann so eine Regelmäßigkeit? Es ist höchst unrealistisch, dass sich zwei aufeinanderfolgende Bilder IMMER um z.B. 30ms in der Berechnungszeit unterscheiden.

Woher hast du das?
Weil das klingt reichlich unlogisch... Denn die CPU hat damit wohl sogut wie nix am Hut. Denn der Thread, der die Daten vorbereitet läuft nicht sequenziel nach der GPU Berechnung. Wenn die CPU also die Daten vorbereitet hat, gehts weiter mit den nächsten. Da wird nicht erst gewartet, bis die GPUs fertig sind.
Vor allem, der überwiegend verwendete Rendermodus ist AFR. Im AFR Modus berechnen alle GPUs im Gespann zur gleichen Zeit jeweils ein Bild. Das heist, es wird im Vorraus berechnet.

Ich würde auch darauf tippen, dass zwei oder gar drei direkt hintereinander berechnete Bilder fast dieselbe Berechnungsdauer erfordern, denn so schnell ändert sich in einer Szene idR nichts. Das kann die Mikroruckler nicht erklären.

Edit:

Ob der Framelimiter vor oder nach dem Rendern eingreift, weiß ich nicht. Es ist wohl wahrscheinlicher, dass er danach die Bilder zeitlich sortiert ausgibt. Das ändert jedoch nichts an meiner Annahme, dass die unterschiedlichen "Takte" von Renderbefehlen und dem eigentlichen Rendern das Problem sind.

 

[eliciel]

erstmal danke soweit fuer die antworten. schade, dass bisher noch keiner mit erfahrung mit 3-gpu-system geantwortet hat, aber der post hier gibt schon relativ gute informationen.

Soweit ich weiß, entstehen Mikroruckler dadurch, dass die GPUs länger an einem Bild rechnen, als die CPU braucht, um es vorzubereiten bzw. den Auftrag für die Berechnung rauszugeben.

CPU braucht z.B. 10ms, GPUs für 2 Bilder 50ms (also 40fps). Die Kadenz, die daraus folgt, ist in diesem Fall 10-40-10-40

Bei 3 GPUs und 40fps wäre es 10-10-30-10-10-30

Wie sich das subjektiv anfühlen würde, kann ich nicht sagen, da müssen andere her.
Was ich dir aber sagen kann ist, dass du mit einem fps-Limiter die Bildaufträge zeitlich verlangsamen kannst, und zwar so, dass GPU 2 anfängt, wenn GPU 1 ein Drittel ihres Bildes gerechnet hat und GPU 3, wenn GPU 2 ihrerseits ein Drittel fertig hat. Dann kommen die Bilder gleichmäßig heraus und du hast (idealerweise) keine Mikroruckler.

In der Praxis funktioniert das meistens hervorragend. Tools wie Tommtis SSAA-Tool (kostenlos aber nicht so zuverlässig) oder Dxtory (32 Euro, funzt aber 1A) könntest du dir mal anschauen. Von Dxtory gibt es selbstverständlich eine kostenlose Testversion. Ein Kumpel hat das mit 4-way SLI probiert und damit ist es butterweich, wo er vorher starke MR hatte.

wie real ist das szenario, dass die cpu 5 mal so schnell "vorbereiten" kann wie die karten rechnen? was bedeutet vorbereiten? woher weiss die cpu, was im naechsten frame passieren wuerde? das klingt als haette ich die bekannten vsync probleme mit multi-gpu wie inputlag.

wieso brauchte dein kumpel den framelimiter mit 4-way-sli? ich haette gedacht, dass die tatsache, dass schon 4 karten im system sind, die frames relativ gut glaetten.

wenn noch jemand mit detailanalysen der framezeiten @3-gpu kommen wuerde, waere nach wie vor dankbar.

@boxleitnerb der computerbase-test hat ja leider auch kein 3kartensystem analysiert.

 

[boxleitnerb]

Du stellst ja eine fixe Framerate ein, d.h. die Aufträge (wenn der Limiter dort eingreift - das weiß ich nicht genau) würden entsprechend synchron rausgegeben. Die CPU kann nicht in die Zukunft sehen

Ja ich hab das mal durchgerechnet - je mehr GPUs, desto glatter müsste die Verteilung sein. Ich frag mal den Kumpel, ob er ein paar frametimes messen kann.

 

[Phantomias88]

wenn noch jemand mit detailanalysen der framezeiten @3-gpu kommen wuerde, waere nach wie vor dankbar.

HD6990 + HD6970 im Tri-Fire Verbund vs 3-Way SLI GTX580:
Gameplay Performance - NVIDIA GeForce 3-Way SLI and Radeon Tri-Fire Review | [H]ard|OCP

MfG

 

[Bytexivex]

MR die vierhundertundsiebenundzwanzigste

 

[boxleitnerb]

MR die vierhundertundsiebenundzwanzigste

Top Post, sehr informativ!
Wenn man nichts zu sagen hat...bitte vervollständigen Sie diesen Satz

Der Test bei Hardocp gibt keine Auskunft über Mikroruckler. Die Leute dort haben generell einen Scheuklappenblick und schauen nur auf die fps. Kann man so fast in die Tonne treten so einen Test. Kein Wort zu MR, zu Inputlag, zu Profilen...

 

[eliciel]

Top Post, sehr informativ!
Wenn man nichts zu sagen hat...bitte vervollständigen Sie diesen Satz

Der Test bei Hardocp gibt keine Auskunft über Mikroruckler. Die Leute dort haben generell einen Scheuklappenblick und schauen nur auf die fps. Kann man so fast in die Tonne treten so einen Test. Kein Wort zu MR, zu Inputlag, zu Profilen...

jo, den test hatte ich auch schon gesehen. solche tests verfuehren zwar dazu, ne 6990 einzubinden, aber ich wuerde schon gerne wissen zu welchem preis der performancegewinn dann kommt.

@boxleibnerb waere bombe, wenn dein kollege ein paar sessions aufzeichnen koennte.

@Bytexivex wenn ich zu meinem speziellen thema irgendwo im forum antworten gefunden haette, haette ich keinen neuen thread aufgemacht.

 

[Chilon]

zu Performance eines Tri-CF kanst bei tomshardware nachlesen
AUf MR geht der Test aber so weit ich das noch weis nicht ein

 

[LD]

Ich habe 3 6950@6970 laufen, generell werden mikroruckler unter etwa 35fps auffällig, dadrüber läuft das Spiel flüssig.

 

[fdsonne]

Zum Fettgedruckten:
Du meinst also, die CPU bereitet die drei Bilder vor und erst DANN fangen die GPUs an? Und weiterhin soll dann zwischen den einzelnen Renderaufgaben nochmal ein Versatz liegen:


Wozu die Sache nochmal verzögern?

Später schreibst du:


Das widerspricht deiner vorherigen Aussage. Fangen die GPUs jetzt exakt zum gleichen Zeitpunkt an zu rendern oder nicht? Und wenn ersteres, wieso? Warum nicht gleich anfangen zu rendern, wenn der Auftrag fertig ist?

OK, ich gebe zu, das war etwas unverständlich ausgedrückt...

Die CPU berechnet wohl das erste Bild in Life (wenn man wirklich vom ersten ausgeht) dann wird eine vorrausberechnung des möglichen Bildes für GPU 2 angestellt, das gleiche gilt danach für das Bild von GPU 3.
Nach der Berechnung von Bild 1 durch die CPU kann mit diesen Daten GPU 1 gefüttert werden und loslegen. Nach durchführung der Vorrausberechnung für Bild 2 beginnt GPU 2 usw.
Die GPUs fangen somit nicht zur gleichen Zeit an, sondern immer im Versatz, solange wie die CPU halt braucht.
Aber dann macht die CPU ja trotzdem weiter. Man wartet nicht bis die GPUs fertig sind, sondern berechnet das nächste Bild wohl sofort. Sonst hätte man eine unnötige Verzögerung drin und würde im AFR Modus wohl nur unwesentlich mehr Leistung bekommen.


Die große Unbekannte bei der Betrachtung ist aber, wie wird die Berechnung des AFR Modus genau angestellt?
Denn eine Vorrausberechnung muss nicht zwingend richtig sein, das heist, unter Umständen muss mehrfach das eine Bild im vorraus erzeugt werden und wird dann immernoch verworfen.
Bei funktionierender Unterstützung gibts aber ne Skalierung von 90%+ bei CF/SLI. Das wäre ein Wiederspruch.
Ich könnte mir vorstellen, das eben im AFR Modus ein etwas größeres Bild als die Auflösung berechnet wird. Und dann anhand der größeren Datenmenge mögliche Blickwinkeländerungen oder Objektbewegungen schon zu einem Großteil mit abgegolten sind. Des weiteren werden da wohl weitere Algorithmen intelligent die Vorrausberechnung anstellen.
Und an dem Punkt unterscheidet sich die Aussage von mir zu der von dir... Das vorrausberechnete Bild wird wohl in 99% der Fälle länger brauchen um den CPU Teil zu durchlaufen, als das andere... Um so weiter vorraus die Berechnung geschehen muss, desto länger dauert auch die Zeit, weil die Warscheinlichkeit abnimmt, das die Berechnung passt.

Hier nochmal die Erklärung von tombman ausführlich in eigenen Worten:

CPU bereitet Daten vor, braucht dafür z.B. 10ms. Nach 10ms beginnt GPU 1.
Nach 20ms vergibt die CPU das nächste Bild und GPU 2 beginnt. Jetzt sind erstmal beide GPUs beschäftigt, und obwohl nach weiteren 10ms schon Bild 3 berechnet werden könnte, ist noch keine GPU "frei". Genau diese Wartezeit, bis GPU 1 wieder einen Auftrag annehmen kann, führt zu den bekannten MR - dem Hin- und Herspringen zwischen zwei (in einem kleinen Intervall) nahezu fixen Frametimes. So wie man es auch in den Messungen meist erkennen kann, z.B. bei Computerbase:

Test: Radeon HD 6900 CF vs. GeForce GTX 500 SLI (Seite 20) - 24.01.2011 - ComputerBase

Das Problem bei der Theorie ist doch, das hier in dem Fall in einem MGPU Setup eine Verzögerung auftritt, zwischen jedem Durchlauf über alle GPUs.
Denn in der Theorie (damit das von oben mit 10-10-30 eingehalten werden könnte) darf die CPU erst mit der Berechnung der Daten für Bild 4 beginnen, wenn GPU 3 fertig ist. Und das macht eben keinen Sinn aus meiner Sicht.
Denn in allen anderen Fällen wäre der Übergang zwischen den Bildern eben nahtlos.
Des weiteren ist die Frage, wie die Theorie eben auf mehr wie drei GPUs ausweitbar ist. Bzw. was passiert wenn nur zwei GPUs rendern?
Problem zwei, du sprichst im Beispiel zwei Bilder mit 50ms an (was 40FPS entspricht) Das wiederum heist, ein Bild braucht 25ms. Aber du rechnest trotzdem auf 50 hochaddiert. Warum? Rechnest du mit 25ms pro einzel Bild, kommt nämlich was ganz anderes raus

Bekanntlich und messtechnisch nachweisbar werden MR schlimmer mit steigender GPU Anzahl im AFR Modus und stärker auffällig um so niedriger die FPS.
Kleines Beispiel, laut der Theorie müssten drei GPUs bei groben 33FPS gänzlich ohne MR auskommen. Denn bei 10ms von der CPU und in Summe 30ms pro Bild würde sich ein humanes 10-10-10-10-10-10-xxx ergeben...
In der Praxis gibts das nahezu nicht.
Auch ist der Zeitversatz nicht überall identisch, wäre die CPU für den Frametimeunterschied verantwortlich, müsste bei gleicher FPS Rate der Versatz durch die CPU immer identisch sein. Das ist er aber nicht... Mal ist er größer, mal ist er kleiner, je nach Game und Lust und Laune
Das hat auch nen einfachen Grund, bleibt die FPS Rate gleich, so ist der absolute Frametime Abstand immer identisch. (also bei 30 FPS strich, sinds eben 33,33ms zwischen den Frames) Wäre die CPU für den Spaß verantwortlich, müsste diese bei gleicher FPS Rate immer den gleichen Frametimeunterschied sichtbar machen. Denn die GPU Berechnung läuft immer exakt gleich schnell ab. (wäre diese schneller, wären auch mehr FPS und somit kürzere Frametimes zu sehen)


Was noch interessant wäre, die Fraps Messungen messen ja absolute Abstände zwischen Bild 1 und Bild n. Und man errechnet daraus die Zwischenzeiten. Die Frage ist, wie viel Zeit pro Durchlauf hat hier die CPU davon belegt!?

 

[Powerplay]

Angeblich soll doch laut dem neustem Test grade bei 3AMD karten kaum noch microruckler auftreten!
AMD mit 3 Karten ist echt der burner!!
Klick

 

[carlo33]

Ich hatte drei HD5870 und das war Horror und nie wieder.

 

[Powerplay]

Ja aber ich hatte auch eine HD5970 und das war auch zum kotzen mit den treibern aber nun hat AMD echt gut was aus den treibern gemacht weil meine beiden HD6970 sind einfach super geil!

 

[LD]

Ich hatte drei HD5870 und das war Horror und nie wieder.

Ja ab etwa 10.11c wurde die Crossfire Skalierung und MR anfälligkeit stark verbessert.

 

[eliciel]

Ich habe 3 6950@6970 laufen, generell werden mikroruckler unter etwa 35fps auffällig, dadrüber läuft das Spiel flüssig.

eine detailbetrachtung waere natuerlich schon nuetzlicher als eine subjektive einschaetzung. aber danke.

Angeblich soll doch laut dem neustem Test grade bei 3AMD karten kaum noch microruckler auftreten!
AMD mit 3 Karten ist echt der burner!!
Klick

das sieht natuerlich sehr geil aus. danke fuer den link.

ich denke, ich werde es einfach mal versuchen. jetzt muss nur noch die verfuegbarkeit besser werden oder es taucht eine im forum auf

edit: es wurde noch garnichts dazu gesagt, wie das aussieht mit ner dualgpu auf x8/x8, wird das problemlos funktionieren? ich hab nur 2 pcie x16 slots.

 

[boxleitnerb]

OK, ich gebe zu, das war etwas unverständlich ausgedrückt...

Die CPU berechnet wohl das erste Bild in Life (wenn man wirklich vom ersten ausgeht) dann wird eine vorrausberechnung des möglichen Bildes für GPU 2 angestellt, das gleiche gilt danach für das Bild von GPU 3.
Nach der Berechnung von Bild 1 durch die CPU kann mit diesen Daten GPU 1 gefüttert werden und loslegen. Nach durchführung der Vorrausberechnung für Bild 2 beginnt GPU 2 usw.
Die GPUs fangen somit nicht zur gleichen Zeit an, sondern immer im Versatz, solange wie die CPU halt braucht.
Aber dann macht die CPU ja trotzdem weiter. Man wartet nicht bis die GPUs fertig sind, sondern berechnet das nächste Bild wohl sofort. Sonst hätte man eine unnötige Verzögerung drin und würde im AFR Modus wohl nur unwesentlich mehr Leistung bekommen.

Bis hierhin sind wir uns ja einig

Die große Unbekannte bei der Betrachtung ist aber, wie wird die Berechnung des AFR Modus genau angestellt?
Denn eine Vorrausberechnung muss nicht zwingend richtig sein, das heist, unter Umständen muss mehrfach das eine Bild im vorraus erzeugt werden und wird dann immernoch verworfen.
Bei funktionierender Unterstützung gibts aber ne Skalierung von 90%+ bei CF/SLI. Das wäre ein Wiederspruch.
Ich könnte mir vorstellen, das eben im AFR Modus ein etwas größeres Bild als die Auflösung berechnet wird. Und dann anhand der größeren Datenmenge mögliche Blickwinkeländerungen oder Objektbewegungen schon zu einem Großteil mit abgegolten sind. Des weiteren werden da wohl weitere Algorithmen intelligent die Vorrausberechnung anstellen.

Hast du da irgendeine Quelle? Klingt jetzt nicht unbedingt unlogisch, aber ohne es zu belegen, ist mir das etwas zu dünn. Dass Bildaufträge verworfen werden, kann ich mir nicht so recht vorstellen. Es könnte ja nun theoretisch sein, dass durch so eine Verwerfung ein Versatz reinkommt, weil reinzufällig mal der Bildauftrag grad rausgeht, wenn eine GPU auch wirklich Zeit hat.

Und an dem Punkt unterscheidet sich die Aussage von mir zu der von dir... Das vorrausberechnete Bild wird wohl in 99% der Fälle länger brauchen um den CPU Teil zu durchlaufen, als das andere... Um so weiter vorraus die Berechnung geschehen muss, desto länger dauert auch die Zeit, weil die Warscheinlichkeit abnimmt, das die Berechnung passt.

Dass die Vorberechnungen immer die gleiche Zeit brauchen ist natürlich Unsinn. Ich frag mich nur, woher dann die Regelmäßigkeit über längere Zeiträume (in Crysis hab ich z.B. bis zu 700ms gemessen wo man 8-40-8-40 durchgehend hat) kommt. Dazu muss ich aber noch sagen, dass das mit VSync (und damit mit Triple Buffering) war. Das macht das nochmal viel komplizierter. Ohne VSync waren die Frametimes deutlich glatter.

Das Problem bei der Theorie ist doch, das hier in dem Fall in einem MGPU Setup eine Verzögerung auftritt, zwischen jedem Durchlauf über alle GPUs.
Denn in der Theorie (damit das von oben mit 10-10-30 eingehalten werden könnte) darf die CPU erst mit der Berechnung der Daten für Bild 4 beginnen, wenn GPU 3 fertig ist. Und das macht eben keinen Sinn aus meiner Sicht.
Denn in allen anderen Fällen wäre der Übergang zwischen den Bildern eben nahtlos.

Das wäre aber auch bei Single-GPU ein Problem. Wenn die Berechnungen auf der CPU pro Bild flotter sind als das Rendering, würden die zugehörigen "Blöcke" mit der Zeit ewig weit auseinandergerissen, wenn die CPU nicht wartet. Von den Fluktuationen mal abgesehen würde bei jedem Frame ein bisschen dazukommen und am Ende rechnet die CPU und das zugehörige Bild wird erst 20 Sekunden später gerendert - das geht ja nicht.

Irgendwas muss die CPU bremsen. Und ich nehme mal stark an, das ist eine Art "Frei"Signal der GPU, die sagt "ich bin fertig, gib mir das nächste Bild zum Bearbeiten". Die CPU rechnet wohl wirklich begrenzt vor, denn erst dann anzufangen mit der Vorbereitung, wenn die Grafikkarte wieder bereit ist, ist irgendwie unsinnig.

Des weiteren ist die Frage, wie die Theorie eben auf mehr wie drei GPUs ausweitbar ist. Bzw. was passiert wenn nur zwei GPUs rendern?
Problem zwei, du sprichst im Beispiel zwei Bilder mit 50ms an (was 40FPS entspricht) Das wiederum heist, ein Bild braucht 25ms. Aber du rechnest trotzdem auf 50 hochaddiert. Warum? Rechnest du mit 25ms pro einzel Bild, kommt nämlich was ganz anderes raus

Nein, ein Bild braucht 50ms auf einer GPU. Die GPUs rechnen ja nicht am selben Bild, das geht nicht schneller als Single-GPU. Nur zusammen schaffen sie zwei Bilder in 25ms. Das passt schon

Bekanntlich und messtechnisch nachweisbar werden MR schlimmer mit steigender GPU Anzahl im AFR Modus und stärker auffällig um so niedriger die FPS.
Kleines Beispiel, laut der Theorie müssten drei GPUs bei groben 33FPS gänzlich ohne MR auskommen. Denn bei 10ms von der CPU und in Summe 30ms pro Bild würde sich ein humanes 10-10-10-10-10-10-xxx ergeben...
In der Praxis gibts das nahezu nicht.

Ne, du rechnest falsch:

33fps sind 30ms pro Frame. 60ms pro 2 Frames. Eine GPU braucht 60ms für die Bearbeitung ihres jeweiligen Bildes.

Die GPUs starten mit 10ms Abstand ihre Berechnungen. Das von GPU 1 gerenderte Bild 1 wird ausgegeben. Nach 10ms kommt Bild 2, nach weiteren 10ms Bild 3. GPU 1 rechnet zu diesem Zeitpunkt seit 20ms an Bild 4 (sie hat sofort nach Bild 1 weitergemacht), braucht aber noch 40ms, bis sie fertig ist.

Es sind also 10-10-40-10-10-40...

Dass MR stärker mit niedriger werdenden FPS werden ist logisch. Der CPU-Anteil bleibt weitestgehend konstant, aber die GPUs sind länger beschäftigt. Damit wird die Lücke in der fps-Kadenz größer.

Bei 60fps und drei GPUs hast du z.B. 10-10-13, was natürlich viel besser ist als 10-10-40. Je höher die fps, desto eher nähert sich die Abfolge 10-10-10 an. Ab einem Grenzwert bremst dann die CPU und alles ist in Ordnung, weil die Bilder nun gleichmäßig ausgegeben werden.

Was ich jetzt nicht kapiere ist Folgendes:

Je mehr GPUs man einsetzt, desto eher puffert man über die Renderzeit eines Bildes. Im obigen Beispiel mit 10-10-40 könnte man die 40ms mit weiteren Bildern von weiteren GPUs überbrücken. D.h. rein theoretisch sollte bei gleichen fps die Mikroruckler mit steigender GPU-Anzahl weniger/besser werden.
Ich kenne keinen Test, der die MR mit 2-4 GPUs in diesem Szenario vergleicht.

Auch ist der Zeitversatz nicht überall identisch, wäre die CPU für den Frametimeunterschied verantwortlich, müsste bei gleicher FPS Rate der Versatz durch die CPU immer identisch sein. Das ist er aber nicht... Mal ist er größer, mal ist er kleiner, je nach Game und Lust und Laune
Das hat auch nen einfachen Grund, bleibt die FPS Rate gleich, so ist der absolute Frametime Abstand immer identisch. (also bei 30 FPS strich, sinds eben 33,33ms zwischen den Frames) Wäre die CPU für den Spaß verantwortlich, müsste diese bei gleicher FPS Rate immer den gleichen Frametimeunterschied sichtbar machen. Denn die GPU Berechnung läuft immer exakt gleich schnell ab. (wäre diese schneller, wären auch mehr FPS und somit kürzere Frametimes zu sehen)

Die FPS-Rate sagt erstmal nix über die Frameverteilung, weil durch die Mittelwertbildung Informationen verlorengehen. 30fps kann alles mögliche sein außer 33-33-33...es sind immer noch gemittelt 30fps.
Weiterhin weiß man nicht, was bei 30fps limitiert. Ist grade die KI am Start und man spielt nicht grad mit 8xSGSSAA könnte die CPU gleichlang oder gar länger beschäftigt sein als die GPU.
Ist man allerdings im GPU-Limit, so wie du es vermutlich meinst, beachte folgendes:

Die FPS-Rate ist eben nicht immer gleich. Diese und die Lastverteilung zwischen GPU und CPU schwankt natürlich. Man muss schon einen ausreichend kleinen Intervall beobachten. In Crysis 2 hab ich z.B. dieselbe Kadenz von 8-41-8-41 (natürlich mit minimalen Abweichungen) für satte 700ms gemessen - aber eben nicht länger. Danach kommt was anderes, weil die Szene, die fps und die Lastverteilung sich geändert haben. Computerbase misst ja auch nicht ewig lang sondern nur so für eine Dauer von 20 Bildern. Das ist nur ein Snapshot und nicht länger gültig.

Was noch interessant wäre, die Fraps Messungen messen ja absolute Abstände zwischen Bild 1 und Bild n. Und man errechnet daraus die Zwischenzeiten. Die Frage ist, wie viel Zeit pro Durchlauf hat hier die CPU davon belegt!?

Ich glaube nicht, dass man das herausfinden kann. Wäre toll, aber ich wüsste nicht wie. Ich hab mal Benchmarks mit 2,3 und 4,3 GHz gemacht, um zu sehen ob die Mikroruckler bei schwächerer CPU schwächer werden, aber ich hab noch Probleme mit der Reproduzierbarkeit.

 

[Powerplay]

edit: es wurde noch garnichts dazu gesagt, wie das aussieht mit ner dualgpu auf x8/x8, wird das problemlos funktionieren? ich hab nur 2 pcie x16 slots.

Das sollte kein problem darstellen!

 

[fdsonne]

Hast du da irgendeine Quelle? Klingt jetzt nicht unbedingt unlogisch, aber ohne es zu belegen, ist mir das etwas zu dünn. Dass Bildaufträge verworfen werden, kann ich mir nicht so recht vorstellen. Es könnte ja nun theoretisch sein, dass durch so eine Verwerfung ein Versatz reinkommt, weil reinzufällig mal der Bildauftrag grad rausgeht, wenn eine GPU auch wirklich Zeit hat.

Ne, alles Spekulatius meinerseits... Es gibt da aktuell wohl keine Quelle, wie das wirklich sauber von statten geht.
Aber, in einer der letzten CTs war ein Artikel, wie sich das Bild beim Berechnen zusammen setzt. Soweit ich das überflogen habe, besteht die Aufgabe nicht nur in einem CPU gefolgt von einem GPU Teil, sondern das ganze switcht hin und her. Erst kommt statischer Inhalt, dann kommen Objekte hinzu usw. zum Schluss dann halt Post Prozessing usw.

Dass die Vorberechnungen immer die gleiche Zeit brauchen ist natürlich Unsinn. Ich frag mich nur, woher dann die Regelmäßigkeit über längere Zeiträume (in Crysis hab ich z.B. bis zu 700ms gemessen wo man 8-40-8-40 durchgehend hat) kommt. Dazu muss ich aber noch sagen, dass das mit VSync (und damit mit Triple Buffering) war. Das macht das nochmal viel komplizierter. Ohne VSync waren die Frametimes deutlich glatter.

Das ist halt die große Preisfrage... Die Regelmäßigkeit ist bei gleich bleibenden FPS recht gut sichtbar. Aber auch in anderen FPS Regionen nachfollziehbar. Nur eben dann mit anderen Abständen. Kurrioser weise aber eben nicht von Game zu Game übertragbar. Was irgendwie gegen die Theorie spricht.

Das wäre aber auch bei Single-GPU ein Problem. Wenn die Berechnungen auf der CPU pro Bild flotter sind als das Rendering, würden die zugehörigen "Blöcke" mit der Zeit ewig weit auseinandergerissen, wenn die CPU nicht wartet. Von den Fluktuationen mal abgesehen würde bei jedem Frame ein bisschen dazukommen und am Ende rechnet die CPU und das zugehörige Bild wird erst 20 Sekunden später gerendert - das geht ja nicht.

Irgendwas muss die CPU bremsen. Und ich nehme mal stark an, das ist eine Art "Frei"Signal der GPU, die sagt "ich bin fertig, gib mir das nächste Bild zum Bearbeiten". Die CPU rechnet wohl wirklich begrenzt vor, denn erst dann anzufangen mit der Vorbereitung, wenn die Grafikkarte wieder bereit ist, ist irgendwie unsinnig.

Die Bremse ist die GPU selbst. Die Berechnungen sind aufeinander aufbauend. Bei drei GPUs müssen zwei im Vorraus berechnet werden. Aber das vierte (was dann wieder GPU 1 bekommt) kann ja erst vorbereitet werden, wenn klar ist, wie Bild 3 ausschaut. Das heist, die CPU kann nie vorne weg laufen, wenn die Berechnungen aufeinander aufbauen.

Nein, ein Bild braucht 50ms auf einer GPU. Die GPUs rechnen ja nicht am selben Bild, das geht nicht schneller als Single-GPU. Nur zusammen schaffen sie zwei Bilder in 25ms. Das passt schon

Das versteh ich nicht...
Wenn ein Bild auf einer GPU 50ms braucht, dann brauchen zwei Bilder auf zwei GPUs auch 50ms... Wieso zwei in 25?

Ne, du rechnest falsch:

33fps sind 30ms pro Frame. 60ms pro 2 Frames. Eine GPU braucht 60ms für die Bearbeitung ihres jeweiligen Bildes.

Die GPUs starten mit 10ms Abstand ihre Berechnungen. Das von GPU 1 gerenderte Bild 1 wird ausgegeben. Nach 10ms kommt Bild 2, nach weiteren 10ms Bild 3. GPU 1 rechnet zu diesem Zeitpunkt seit 20ms an Bild 4 (sie hat sofort nach Bild 1 weitergemacht), braucht aber noch 40ms, bis sie fertig ist.

Es sind also 10-10-40-10-10-40...

Auch hier komm ich nicht ganz mit...

Nochmal von Anfang. Wir definieren:
- konstante 33FPS (entspricht ner Frametime im Mittel von 30ms)
- keine sinnfrei Betrachtung ala 39 Bilder in einer ms Abstand und das 40. nach 961ms.
- drei GPUs
- CPU Zeitanteil von 10ms.

Bedeutet ausgehend vom 0. Bild. CPU rechnet 10ms lang, dann kommt GPU mit 20ms (macht in Summe 30ms für das komplette Frame)
Ergibt eine Bildausgabe von 0-30-
Nach den ersten 10ms berechnet die CPU das zweite Frame folgend von GPU 2 mit ihren 20ms Anteil.
Ergibt 0-30-10 (also besagte 10ms Versatz zum Vorbild, soweit klar)
Beim dritten Frame das gleiche, gleiches Spiel mit 10ms Versatz.
Ergibt 0-30-10-10 (also wieder 10ms Versatz zum Vorbild, auch klar)
Aber jetzt wiederum nach dem CPU Teil kann die CPU schon Bild vier vorberechnen, denn die Daten hat sie für Bild drei fertig und GPU 1 ist ja auch schon fertig (da der GPU Anteil bei 30ms Frametime inkl. 10ms CPU Anteil nur noch 20ms beträgt)
Das heist, das nächste Frame würde wiederum nach 10ms auftauchen.
Also 0-30-10-10-10

Hier das ganze mal bildlich in drei verschiedenen Versionen. Einmal mit 30ms pro Bild, also 33FPS, einmal mit 40ms pro Bild also 25FPS und einmal mit 50ms pro Bild also 20FPS bei jeweils konstaten 10ms für den CPU Part:



Einzig beim vollständigen GPU Limit hast du den besagten Versatz, aber auch nur dann, wenn eben der GPU Teil so viel mehr länger dauert im Verhältnis zur Anzahl der zu rechnenden GPUs.
Und genau das wirkt der Theorie entgegen... Denn man schaue mal auf die dann übrig bleibende FPS Rate... Die MR sind aber auch bei deutlich höheren FPS (eben jenen bei um die 30-40FPS) mit dem Versatz so sichtbar. Das heist, die CPU allein kann durch ihren Versatz beim Berechnen nicht allein dafür verantwortlich sein... das muss noch andere Gründe haben...

Was ich jetzt nicht kapiere ist Folgendes:

Je mehr GPUs man einsetzt, desto eher puffert man über die Renderzeit eines Bildes. Im obigen Beispiel mit 10-10-40 könnte man die 40ms mit weiteren Bildern von weiteren GPUs überbrücken. D.h. rein theoretisch sollte bei gleichen fps die Mikroruckler mit steigender GPU-Anzahl weniger/besser werden.
Ich kenne keinen Test, der die MR mit 2-4 GPUs in diesem Szenario vergleicht.

Genau eben an der Stelle bin ich auch stuzig gewurden... Da nämlich in dem Fall eigentlich mehr GPUs dem Thema entgegen wirken müssten, anstatt es zu verschlimmern...
Leider sind Frametimeanalysen sowieso recht selten... Sinnvolle Analysen gibts sogut wie gar keine. Vor allem keine vergleichbaren...

Die FPS-Rate sagt erstmal nix über die Frameverteilung, weil durch die Mittelwertbildung Informationen verlorengehen. 30fps kann alles mögliche sein außer 33-33-33...es sind immer noch gemittelt 30fps.
Weiterhin weiß man nicht, was bei 30fps limitiert. Ist grade die KI am Start und man spielt nicht grad mit 8xSGSSAA könnte die CPU gleichlang oder gar länger beschäftigt sein als die GPU.
Ist man allerdings im GPU-Limit, so wie du es vermutlich meinst, beachte folgendes:

Die FPS-Rate ist eben nicht immer gleich. Diese und die Lastverteilung zwischen GPU und CPU schwankt natürlich. Man muss schon einen ausreichend kleinen Intervall beobachten. In Crysis 2 hab ich z.B. dieselbe Kadenz von 8-41-8-41 (natürlich mit minimalen Abweichungen) für satte 700ms gemessen - aber eben nicht länger. Danach kommt was anderes, weil die Szene, die fps und die Lastverteilung sich geändert haben. Computerbase misst ja auch nicht ewig lang sondern nur so für eine Dauer von 20 Bildern. Das ist nur ein Snapshot und nicht länger gültig.

Das ist schon klar... Ich denke aber wir sollten das erstmal so als Grundlage nehmen... Schwankende Frametimes (also auch zwangsläufig schwankende FPS) sind eben nicht sonderlich förderlich für das Aufstellen einer trivialen Begründung/Theorie zu dem Thema...
Ich denke deswegen, man sollte möglichst vom optimal Fall ausgehen. Das heist, man sucht ne Szene, die laut FPS Messungen sogut wie keinen FPS Schwankungen unterliegt. Das sollte zumindest ansatzweise konstante Werte liefern zum Vergleich.

Ich glaube nicht, dass man das herausfinden kann. Wäre toll, aber ich wüsste nicht wie. Ich hab mal Benchmarks mit 2,3 und 4,3 GHz gemacht, um zu sehen ob die Mikroruckler bei schwächerer CPU schwächer werden, aber ich hab noch Probleme mit der Reproduzierbarkeit.

Normal müsste das der Fall sein, wenn die Theorie von dir aufgeht. Aber ich denke, das problem wird sein, das eben bei zu viel Absänkung der CPU eben die FPS durch andere Sachen stark limitiert werden. Was eben der Aussage voll entgegen wirkt.
Das Problem der nicht möglichen Nachstellung der beiden Teile kommt denke ich von der derzeit nicht sichtbaren Trennung zwischen Spiel selbst und dem Teil, der grundsätzlich nötig ist, damit die GPUs rendern können.
Das ist der gleiche Part, den man beim Thema Skallierung für CF/SLI untersucht, denn das Game skallierst selbst unter Umständen nicht mit Takt und Cores. Aber der eigentliche GPU-Vorberechnungs-Teil wohl teils stark (je nach Spiel) Was wiederum eben FPS erzeugt und hohe Auslastungen in Sachen CF/SLI.
Und genau dieser Teil ist der Übeltäter bei der ganzen Geschichte...

Laut Aussage von NV macht man es dort recht clever, denn man schickt die Bilder vor der Ausgabe in nen Puffer, der dann gemittelt nach dem Zufluss in den Puffer die Bilder hinten nahezu konstanten Frametimes ausspuckt. Aber das ganze erhöht das Inputlag etwas und wirkt wohl auch den FPS etwas entgegen. Eine Methodik, die aber besser als nix ist

 

[boxleitnerb]

Das ist halt die große Preisfrage... Die Regelmäßigkeit ist bei gleich bleibenden FPS recht gut sichtbar. Aber auch in anderen FPS Regionen nachfollziehbar. Nur eben dann mit anderen Abständen. Kurrioser weise aber eben nicht von Game zu Game übertragbar. Was irgendwie gegen die Theorie spricht.

Wieso? Die anfallenden Arbeiten für CPU und GPU sind ja von Spiel zu Spiel unterschiedlich. Sogar von Szene zu Szene, von Sekunde zu Sekunde. Mikroskopisch betrachtet hast du Gleichmäßigkeit, makroskopisch dann eher "Chaos".

Die Bremse ist die GPU selbst. Die Berechnungen sind aufeinander aufbauend. Bei drei GPUs müssen zwei im Vorraus berechnet werden. Aber das vierte (was dann wieder GPU 1 bekommt) kann ja erst vorbereitet werden, wenn klar ist, wie Bild 3 ausschaut. Das heist, die CPU kann nie vorne weg laufen, wenn die Berechnungen aufeinander aufbauen.

Ist die Frage - was genau baut aufeinander auf? Rein beim Rendering kann ich mir das nicht vorstellen. Ich würde eher sagen, es kommt auf die Interaktionen des Spielers mit der Spielwelt an. Bewegt er sich, schießt oder macht sonstwas, beeinflusst das natürlich, was gerendert werden muss. Diese Informationen kommen kontinuierlich rein. Ob in einem langsameren oder schnelleren Rhythmus als gerendert wird, weiß ich nicht. Wenn ich geradeaus laufe, wie oft wird die Eingabe dann abgefragt? Alle 10ms, alle 5?

Das versteh ich nicht...
Wenn ein Bild auf einer GPU 50ms braucht, dann brauchen zwei Bilder auf zwei GPUs auch 50ms... Wieso zwei in 25?

Ja da hab ich natürlich Quatsch geschrieben
Ich meinte, eine GPU braucht 50ms für ein Bild, zwei GPUs brauchen 50ms für zwei Bilder. Der kleinste (parallele) Block ist aber weiterhin 50ms, nicht die aus den schlussendlich angezeigten 40fps errechneten 25ms.

Auch hier komm ich nicht ganz mit...

Nochmal von Anfang. Wir definieren:
- konstante 33FPS (entspricht ner Frametime im Mittel von 30ms)
- keine sinnfrei Betrachtung ala 39 Bilder in einer ms Abstand und das 40. nach 961ms.
- drei GPUs
- CPU Zeitanteil von 10ms.

Bedeutet ausgehend vom 0. Bild. CPU rechnet 10ms lang, dann kommt GPU mit 20ms (macht in Summe 30ms für das komplette Frame)

Halt mal. Hier machst du einen essentiellen Denkfehler. Laut deinen Diagrammen rendert das System jetzt viel schneller wie du es eigentlich angibst. Alle 10ms wird ein Frame rausgehauen - das sind 100fps! Nicht 33 oder 25. Das Diagramm im GPU-Limit ist auch deutlich näher an 100fps als an 20. Und damit ist deine ganze Rechnung leider für die Katz.

Hier mal das GPU-Limit nochmal von mir (3 GPUs, 33fps, 10ms für CPU):


Das Rote oben ist die CPU. Denke, das Bild ist selbsterklärend. Das einzige, was ich nicht gemacht hab, ist die CPU-Zeit in die Zeit für ein Frame zu packen. Macht aber nur 10ms aus und ändert an der Grundaussage nichts.
Die CPU-Blöcke 4 und 7 sind doppelt, weil hier irgendwo eine Bremsung stattfinden muss. Würden die Blöcke ohne Pause aneinandergereiht, würde ja das passieren, was ich oben schon geschrieben habe - die zeitliche Differenz zwischen Vorarbeit_n und n-tem Bild würde immer größer werden. Irgendwo zwischen den beiden Blöcken mit "4" muss die CPU also Bild 4 vorbereiten. Vorher kann sie nicht, da ist sie mit 3 beschäftigt. Später als der zweite Block "4" ist auch ungeschickt, weil dann zu den 70ms Versatz nochmal 10ms dazukommen würden.

Problem hierbei: Die CPU weiß nicht, wie lange GPU 1 rendern wird. Eigentlich müsste sie die Daten so schnell wie möglich bereithalten, denn statt 90ms könnte GPU 1 ja vielleicht auch nur 30 brauchen und die neuen Daten sofort benötigen ohne Pause.

Nochmal: Deine GPUs rendern zu schnell
Eine GPU wird für ihr zugewiesenes Bild immer 3x (bei perfekter Skalierung) so lang brauchen wie 3 GPUs zusammen, die ja die (gemittelte) Framerate letztendlich angeben.
Deine Diagramme sind aber sonst durchaus schlüssig, nur sind die Render-/Rechenzeiten für die angegebenen fps falsch.

Genau eben an der Stelle bin ich auch stuzig gewurden... Da nämlich in dem Fall eigentlich mehr GPUs dem Thema entgegen wirken müssten, anstatt es zu verschlimmern...
Leider sind Frametimeanalysen sowieso recht selten... Sinnvolle Analysen gibts sogut wie gar keine. Vor allem keine vergleichbaren...


Das ist schon klar... Ich denke aber wir sollten das erstmal so als Grundlage nehmen... Schwankende Frametimes (also auch zwangsläufig schwankende FPS) sind eben nicht sonderlich förderlich für das Aufstellen einer trivialen Begründung/Theorie zu dem Thema...
Ich denke deswegen, man sollte möglichst vom optimal Fall ausgehen. Das heist, man sucht ne Szene, die laut FPS Messungen sogut wie keinen FPS Schwankungen unterliegt. Das sollte zumindest ansatzweise konstante Werte liefern zum Vergleich.

Da bin ich grad dran. Ist schwierig, eine zu finden, weil immer ist irgendwas los. Vegetation bewegt sich, Schnee fällt, Feuer, Rauch...und wenn es mal ne ruhige Szene ist, komm ich nicht unter 50-60fps ...
Dazu suche ich noch ein Programm, was Tastatureingaben simuliert. Ich kann das natürlich auch ohne Bewegung messen, aber mit ist irgendwie realistischer. Da muss es dann halt ganz genau sein. Aber vielleicht erstmal ohne Bewegung der Spielfigur.

Laut Aussage von NV macht man es dort recht clever, denn man schickt die Bilder vor der Ausgabe in nen Puffer, der dann gemittelt nach dem Zufluss in den Puffer die Bilder hinten nahezu konstanten Frametimes ausspuckt. Aber das ganze erhöht das Inputlag etwas und wirkt wohl auch den FPS etwas entgegen. Eine Methodik, die aber besser als nix ist

Es heißt Skalierung bitte
Dass NV was macht, glaub ich denen schon, nur bringen tut es nichts. Ich spüre die Mikroruckler ganz deutlich. Ohne Limiter mag ich da nicht spielen.

 

[LD]

Aber generell kann man doch ganz einfach mit Fraps nachmessen ob man wirklich solche Sprünge in den Frametimes erkennt oder nicht.

 

[boxleitnerb]

Die Sprünge zu erkennen ist ja nicht das Problem. Ihre Herkunft genau zu erklären, das interessiert fdsonne und mich. Gut, ist "etwas" OT

y33H@ hat mir angeboten, ein paar Fragen an Nvidia weiterzuschicken diesbezüglich, er hat da Kontakte. Vielleicht kommen ja ein paar Erleuchtungen bei raus. Ich setz mich mal am Wochenende dran und formulier was aus.

 

[LD]

Naja es ist zur Zeit auch fraglich ob Mikrorucker tatsächlich von diese Sprünge kommen, denn dann müsste bei 3gpu-s z.B. immer jede 3. Frametime besonders groß sein.

 

[fdsonne]

Wieso? Die anfallenden Arbeiten für CPU und GPU sind ja von Spiel zu Spiel unterschiedlich. Sogar von Szene zu Szene, von Sekunde zu Sekunde. Mikroskopisch betrachtet hast du Gleichmäßigkeit, makroskopisch dann eher "Chaos".

Ne so mein ich das nicht...
Betrachten wir ein Frame als ein Ganzes, so hast du bei 33FPS eben eine Zeitspanne von gemittelten 30ms.
Der Zeitanteil der CPU muss in diesen 30ms mit drin sein...

Nach der Theorie von dir oben ist die CPU durch ihre vorherige Berechnungen für den MR Versatz zuständig.
Da aber jedes Games bei den zu vergleichenden möglichst konstanten 33FPS immer besagte 30ms pro Frame zur Verfügung haben, bedeutet das, das in so manchem Game die GPU deutlich eher mit dem Bild fertig wird, und der CPU Anteil dieser 30ms deutlich höher ist als in anderen Games. Denn der Versatz variiert bei um die 30FPS teils sehr stark. Mal sinds nur paar wenige ms, mal 10, mal 15 usw. (das ganze kannst du natürlich auf mehrere GPUs hochrechnen, genau so auf mehr als nur ein Frame)
Das ist halt der Punkt... Das der CPU Zeitanteil schwanken kann, ist klar, aber der GPU Anteil kann nicht in Spiel A für 33FPS 20ms brauchen und für Spiel B eben nur sagen wir 15ms. Wäre das der Fall, würde die Leistung in FPS deutlich ansteigen müssen.
Auch wäre dann die Szene im Vergleich unpassend. Denn die Leistung steigt.

Ist die Frage - was genau baut aufeinander auf? Rein beim Rendering kann ich mir das nicht vorstellen. Ich würde eher sagen, es kommt auf die Interaktionen des Spielers mit der Spielwelt an. Bewegt er sich, schießt oder macht sonstwas, beeinflusst das natürlich, was gerendert werden muss. Diese Informationen kommen kontinuierlich rein. Ob in einem langsameren oder schnelleren Rhythmus als gerendert wird, weiß ich nicht. Wenn ich geradeaus laufe, wie oft wird die Eingabe dann abgefragt? Alle 10ms, alle 5?

Die Eingabe wird denke ich doch nicht abgefragt, sondern die Eingabe kommt wie sie kommt. Bewegst du die Maus, so wird ein stetiger Strom an Daten (mit leichter Verzögerung durch USB) an den PC geliefert. Ich denke nicht, das es dort ein hartes Zeitintervall Fenster gibt. Denn dann wären Mausbewegungen rucklig.
Dazu kommt, es hängt ja nicht nur an der Interaktion des Menschen...
Es können ja auch andere Ereignisse interagieren. Beispielsweise wenn ein NPC über einen bestimmten Punkt raus geht, passiert irgendwas.

Normal arbeitet man soweit mir bekannt mit Offsets von Werten. Das heist, ich bewege beispielsweise Körper A in der X Achse um 10 Einheiten usw.
Aber für diese Bewegung muss vorher klar sein, wo war das Teil vorher. Das heist, ich brauch die Daten des Vorframes.
Hart positionieren in dem Fall gestaltet sich auch recht schwer, da wiederum klar sein muss, was sieht der Betrachter überhaupt...

Ja da hab ich natürlich Quatsch geschrieben
Ich meinte, eine GPU braucht 50ms für ein Bild, zwei GPUs brauchen 50ms für zwei Bilder. Der kleinste (parallele) Block ist aber weiterhin 50ms, nicht die aus den schlussendlich angezeigten 40fps errechneten 25ms.

Aber aber dennoch bleibts doch bei 40FPS und 25ms pro Bild... Das mindestens zwei Bilder kommen müssen, ist logisch. Sonst geht das nicht auf. Aber das ist ja beim Gamen der Fall...

Halt mal. Hier machst du einen essentiellen Denkfehler. Laut deinen Diagrammen rendert das System jetzt viel schneller wie du es eigentlich angibst. Alle 10ms wird ein Frame rausgehauen - das sind 100fps! Nicht 33, 25 oder 20. Und damit ist deine ganze Rechnung leider für die Katz. Die 100fps hast du übrigens in allen drei Diagrammen, was ja nicht wirklich sein kann

Mhh OK, ich seh grad die Erklärung über den Bildern ging nach hinten los, aber schau nochmal genauer... Oben die 10ms Abstände sollen nur als Skala dienen um zu verdeutlichen, das pro Kasten eben 10ms Abstand gemeint sind.
- Im ersten Bild schmeiße ich 3 Bilder nach 50ms raus (aber 6 nach 80ms raus). Weitergerechnet auf 1000ms wären das 75 Bilder. Also 75 FPS. Hier limitiert der 10ms CPU Teil die schnellere GPU Berechnung, weil GPU 1 mit Frame 4 erst nach 10ms Leerlauf beginnen kann.
- Im zweiten Bild kommen die 6 Bilder nach 90ms raus. Also 66,66FPS.
- Im dritten Bild kommen die 6 Bilder nach 110ms raus. Also 54,54FPS...

Das ganze kannst du nun weiter hoch ziehen. Um so länger der GPU Teil, bei gleichem CPU Teil, desto niedriger die FPS im Beispiel.

Ich stelle mir das eher so vor:
http://www.abload.de/img/mrvm1d.png

Das Rote oben ist die CPU. Denke, das Bild ist selbsterklärend. Das einzige, was ich nicht gemacht hab, ist die CPU-Zeit in die Zeit für ein Frame zu packen. Macht aber nur 10ms aus und ändert an der Grundaussage nichts.
Die CPU-Blöcke 4 und 7 sind doppelt, weil hier irgendwo eine Bremsung stattfinden muss. Würden die Blöcke ohne Pause aneinandergereiht, würde ja das passieren, was ich oben schon geschrieben habe - die zeitliche Differenz zwischen Vorarbeit_n und n-tem Bild würde immer größer werden. Irgendwo zwischen den beiden Blöcken mit "4" muss die CPU also Bild 4 vorbereiten. Vorher kann sie nicht, da ist sie mit 3 beschäftigt. Später als der zweite Block "4" ist auch ungeschickt, weil dann zu den 70ms Versatz nochmal 10ms dazukommen würden.

Problem hierbei: Die CPU weiß nicht, wie lange GPU 1 rendern wird. Eigentlich müsste sie die Daten so schnell wie möglich bereithalten, denn statt 90ms könnte GPU 1 ja vielleicht auch nur 30 brauchen und die neuen Daten sofort benötigen ohne Pause.

Nochmal: Deine GPUs rendern zu schnell
Eine GPU wird für ihr zugewiesenes Bild immer 3x (bei perfekter Skalierung) so lang brauchen wie 3 GPUs zusammen, die ja die (gemittelte) Framerate letztendlich angeben.

Neja mein drittes Bild im GPU Limit entspricht ja quasi deinem. Nur das ich die CPU Zeit noch mit im Frame habe. Und ja, du hast recht, die CPU weis nicht, wann GPU 1 in dem Fall fertig ist, und weis logisch auch nicht, wann sie mit dem Vorberechnen von Frame vier beginnen muss... Ich denke ich verstehe was du mit bremsen meinst... Vllt gibts hier dann wirklich was von wegen Treiber Queue gibt den Speed vor oder irgendwie anhand des Framebuffers oder sowas wird abgezählt.
Bei DX9 scheints hier ja vllt auch einfach zu sein, denn dort geht AFR nur mit zwei vorgerenderten Bildern. Das heist, mehr wie drei in Summe sind ja nicht drin. Ich könnt mir zum Beispiel vorstellen, die CPU berechnet Bild vier vor, sobald ein Frame aus dem Framebuffer raus fliegt, so wäre immer ne konstante Anzahl an Frames im Umlauf. Bei größer DX9 klappt das aber so nicht. Wobei man dann hier sicher auch anhand der GPU Anzahl ein viertes in dem Fall vorbereiten könnte, das fünfte aber erst beginnt, wenn das erste hinten rausgespuckt wurde.


Aber OK, mein Problem bei der Betrachtungsweise ist immernoch, das ich nicht den CPU Zeitanteil für den Versatz verantwortlich machen will. Vergleiche mal ein paar Fraps Messungen... Das schwankt mal mehr mal weniger. Wie oben schon angesprochen müsste aber gleich identischer FPS Rate der GPU Anteil, also die Zeit, die die GPU hat um die Berechnung anzustellen identisch sein bei gleicher FPS Rate. Oder steh ich da völlig auf dem Schlauch?

Ich hab grad mal Heaven 2.5 bei mir laufen gehabt. Mit den beiden OCed 470ern komme ich mit angehaltener Cam. beim Tess Drachen auf um die 30 FPS. Die Anzeige schwankt nicht. Vllt wäre das eine gute Stelle um mal die Frametime Unterschiede bei massiver Taktänderung der CPU zu prüfen. Vorteil ist, die Stelle kann man komplett einfrieren. Durch anhalten der Cam.
Werd ich mal probieren... Einfach unter Windows den Multi runter drehen müsste ja gehen und das Bild bleibt kommt auch sauber wieder beim zurück "tabben"...

Es heißt Skalierung bitte
Dass NV was macht, glaub ich denen schon, nur bringen tut es nichts. Ich spüre die Mikroruckler ganz deutlich. Ohne Limiter mag ich da nicht spielen.

Wie auch immer, ich denke du weist was gemeint ist
Skalierung mit einem "l" sieht irgendwie mies aus

Naja es ist zur Zeit auch fraglich ob Mikrorucker tatsächlich von diese Sprünge kommen, denn dann müsste bei 3gpu-s z.B. immer jede 3. Frametime besonders groß sein.

In der Theorie ja. Aber die Unbekannte ist eben die Zeit, welche die CPU braucht. Kommts allein von der CPU, so müsste eben durch massive Taktsänkung der CPU Zeitanteil größer werden. Und somit die Frametimes in Summe länger bzw. der Versatz im gleißen Maße eben steigen.

 

[boxleitnerb]

Hm, wie kann ich den Multi in Windows verändern? Weißt du da ein Programm?

Ich glaub VSync sollte man bei solchen Tests weglassen, das macht es zu kompliziert.

Edit:

Windows Powermanagement. Ist nicht linear, aber ich krieg Taktraten von 1600 bis 4300 mit ein paar Zwischenschritten hin. Machst du mit und machen wir einen Thread auf?

 

[fdsonne]

Je nachdem was du für ein Board hast... Bei meinem Asus kann ich über die Software den Turbo Multi der Sandy beliebig verstellen... Da ja nicht überhalb des eigentlichen OC gegen werden muss, kann denke ich auch alles andere außer acht gelassen werden inkl. der Spannung...

Ansonsten klar, eigener Thread macht Sinn, ich kann aber erst heut abend wieder an den PC Zuhause