Was bedeuten die amd crossfire modus afr freundlich

Soweit so gut...
XP scheint dann doch ein wenig kooperationsfreudiger zu sein.
Denn dort funzt die Anzeige des "Freien Grafikspeichers" zumindest erstmal, in wie weit die Werte stimmen, kann ich aber leider nicht sagen.
Des weiteren ist noch anzumerken, das ich nicht weis ob nebenbei noch Daten ausgelagert wurden, gehe aber mal stark davon aus, das das nicht passiert ist.

Hab vorerst mal Gothic 3 und CoD4 getestet.
Bei G3 hab ich aber AA nicht zum laufen gebracht, ich erinner mich dunkel, das das auch nicht ging anfangs, aber dann irgendwann mal mittels Treiber erzwungen werden konnte (hat aber bei mir net geklappt)

Auf jedenfall hier CoD4 640x480, max. Details ohne AA/AF
FVM: 171MB --> 341MB Verbrauch

CoD4 640x480, max. Details + 4xAA inGame
FVM: 170MB --> 342MB Verbrauch

CoD4 640x480, max. Details + 24xAA/16xAF im CCC
FVM: 171MB --> 341MB Verbrauch

CoD4 1680x050, max. Details ohne AA/AF
FVM: 136MB --> 376MB Verbrauch

CoD4 1680x1050, max. Details + 4xAA inGame
FVM: 128MB --> 384MB Verbrauch

CoD4 1680x1050, max. Details + 24xAA/16xAF im CCC
FVM: 136MB --> 376MB Verbrauch (kann ich aber leider nicht im Screen festhalten, beim Screenshot schießen aus mir unerklärlichen Gründen die FPS und die VRam Anzeige nicht mit eingeblendet wird, muss wohl am ATT liegen denk ich)

Gothic 3 800x600, max. Details, HDR+Tiefenunschärfe, 16xAF
FVM: 339MB --> 173MB Verbrauch

Gothic 3 1680x1050, max. Details, HDR+Tiefenunschärfe, 16xAF
FVM: 288MB --> 224MB Verbrauch

Im Beispiel von CoD4 werden bei 640x480 341MB verbraucht, bei 1680x1050 sinds 376MB. Bedeutet ein Verbrauchsanstieg von 10,26% bei 574,22% mehr Pixeln...
Anhand der Screens mit AA sieht man auch das AA nahezu kein Speicher verbraucht.

Anmerkung:
Den einen 1680x1050 Screen mit 24xAA muss ich noch mal machen, da ist irgendwie die Verbrauchsanzeige nich mit drauf. Wird aber gleich nachgereicht...

So und jetzt kommt ihr doch bitte mit den Gegenbeweisen und nicht wieder bloß mit leeren Behauptungen. Weitere Games werden folgen, aber ich denke ich habe meine Schuldigkeit vorerst getan...
Was ich noch komisch finde, bei G3 ist die GPU Aktivitätsanzeige so drastisch niedrig, warum auch immer, bei CoD4 ist die immer bei fast 100%.

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.