Ich habe mir das aber folgendermaßen erklären lassen:
Input1 kommt, GPU0 beginnt das Rendering von Frame n und gibt diesen gemeinsam mit Input1 aus.
Input2 kommt, reicht nicht mehr für Frame n und kommt daher auf GPU1 bei Frame n+1 drauf. Frame n+1 wird aber schon berechnet, während Frame n gerade ausgegeben wird. In einem Single-GPU-System wäre Frame n+1 von GPU0 erst ausgegeben worden, wenn Frame n fertig ist, was bei gleichen Settings (theoretisch doppelten FPS) bei einem Mulit-GPU-System 50 Prozent früher ist.
Erstmal vorweg, es könnte durchaus sein, ich hab nen Denkfehler, also immer rausdamit
Aber aus meiner Sicht kann man das nicht so in direktem Zusammenhang sehen...
Denn die Inputs erfolgen ja völlig unabhängig der Berechnung.
Sprich wenn Input1 kommt, heist das nicht zwingend, das GPU0 mit der Berechnung beginnen kann, es könnte genau so sein, das GPU0 gerade eben 1ms vorher angefangen hat mit berechnen, somit liegt der Input bis zur nächsten freien GPU in der Pipeline...
Desweiten dürfte rein theoretisch betrachtet völlig egal sein, wann eine GPU anfängt mit dem Bild zu berechnen. Solange eben in der Abfolge keine "Luft" ist, wo eine (oder mehrere) GPUs warten müssen...
Bildlich sollte das ganze dann so ausschauen:
Ich hab mal versucht drei Szenen darzustellen. Einmal SGPU oben, zweimal MGPU. Letztere unterscheiden sich in der für das Beispiel exakt doppelten FPS Rate. (also halbe Framelänge) Erste MGPU und SGPU haben absichtlich gleich lange Frames... Wie angesprochen soll dies aufzeigen, was beim direkten verblasen der MGPU Leistung in BQ passiert.
Auch die Inputs erfolgen zur Darstellung an der selben Stelle für alle drei Szenen.
Schön zu erkennen ist, das die Outputs der SGPU in etwa gleichmäßig nach dem Input sind, wärend beim ersten MGPU große! Lücken zwischen klaffen.
Doppelte FPS Rate macht diesen Umstand etwas wett, denn die Zeiten verkürzen sich drastisch zum ersten MGPU Beispiel.
Das ganze soll dazu aufzeigen, das ein Input eben häufig einen Frame warten muss. Eben die Berechnungszeit wenn beide GPUs voll ackern. Beim SGPU kann man davon ausgehen, dass eben der Input auch im nächsten Frame mit drin ist. Bei MGPU muss dies nicht der Fall sein. Denn im Extremfall heist es hier fast zwei ganze Frames auf die Ausgabe warten.
Praktisch wird sich das ganze statistisch irgendwo im Mittel einsortieren... Denn ein Input erfolgt ja nicht immer direkt vor der Frameberechnung und auch nicht direkt am Ende einer Frameberechnung. Sondern zeitlich irgendwo...
Die NV Methode setzt nun an und glättet die Frameausgabe. Heist im Fall von zwei und drei, die Ausgabe erfolgt möglichst gleichbleibend. Da eine Ausgabe nie nach vorn verschoben werden kann, rückt die Ausgabe immer ein Stück weit nach hinten... Somit erhöht sich auch die Zeit zwischen Eingabe und Ausgabe ein Stück weit. Ob man das merkt oder nicht!? Keine Ahnung...
Im Fall von Multiplayer Shootern beispielsweise heist das in Summe dann, bei ner Single GPU hat man im Extremfall den Gegner nach der Frametime x auf dem Schirm und kann einen Input abgeben.
Bei MGPU im gleichen Spiel hat man aber Extremfall den Gegner erst nach Frametime x*2 auf dem Schirm und der Input erfolgt somit auch erst nach Frametime x*2. Bei 60 FPS wären das 16,67ms später, als bei 60 FPS und SGPU.
Bei doppelter FPS wären es dann (x/2)*2... Also bestenfalls gleich der SGPU Lösung...
Soweit mein Gedankengang dazu.
Das Thema, was FCAT an der Stelle noch mit aufgreift, sprich das "vergessen" von ganzen Frames oder das nur wenige Zeilen ausgeben von Frames, kommt dem Umstand übrigens theoretisch noch mit oben drauf. Dürfte praktisch in dem Fall aber keine Bewandniss haben. Denn man sieht auf dem Schirm davon ja nichts... Rein logisch müsste das sogar dem Inputlag in den Karten spielen und dieses wiederum verkürzen.
