Ich wunder mich irgendwie immer noch wie du immer "Frame Pacing" verwendest als wäre es eine Technologie, die man einfach nur implementieren müsste und damit alle Probleme beseitigen würde. Nachdem ich den Artikel den du gelinkt hast, nochmal angeschaut habe, ist mir allerdings auch klar warum du das machst: In den AMD Treibern gibt es eine Option "Frame Pacing On/Off" und in den Grafiken dort gibt es auch sowas wie "Frame Pacing enabled driver". Das ist leider etwas irreführend und so auch nicht ganz korrekt ausgedrückt. Was damit aber eigentlich gemeint ist, ist, das der Treiber das Frame Pacing berücksichtigt (also letztlich die Varianz der Zeitintervalle, in denen aufeinanderfolgende Frames fertig berechnet sind) und versucht dies möglichst konstant zu halten (vermutlich durch verzögern von Frames, falls diese zu schnell aufeinanderfolgend berechnet werden zwischen mehreren GPUs).
Theoretisch ist es sogar eine Technologie. Bei AMD schimpft es sich Frame Pacing. Bei NV heist es Frame Metering. Beide verwenden effektiv das gleiche Prinzip imdem die Ausgabe im MGPU AFR Modus verzögert wird, damit nicht zwei Bilder unmittelbar aufeinander ausgespuckt werden und dann eine längere Pause (hohe Frametime) bis zum nächsten Pärchen von Bildern zu sehen ist. Denn das erhöht zwar auf die Sekunde gemittelt die FPS Rate, visuel nimmt man das ggf. aber als ruckeln war. Um so niedriger die FPS, desto höher dabei die Frametimes, desto höher auch dieses empfundene Ruckeln.
Mit dem Problem hier in der News hat das effektiv aber nix zu tun... Hier gehts eher um die quasi fixe Bildausgabe der Displays von VR Brillen -> mit dem Nachteil, ist ein Frame fertig unmittelbar nach dem Display Refresh, muss es lange bis zum nächsten Refresh warten. So lange, dass es ggf. sogar verworfen wird.
Siehe dazu das Bild in der News:
Das rote Frame wird verworfen. Und es würde in dem Fall das vorhergehende grüne Frame über mindestens zwei Display Refreshs dargestellt. -> was soviel heißt, dass die Zeit sich verdoppelt und damit die FPS Rate halbiert. Das merkt man schlagartig. Um dem entgegenzuwirken, will man den dirty Workarround nutzen, dass es eine Art Zwischenbildberechnung gibt, dessen Ergebnis man in so einem Fall anzeigen will. Wohl wird das Bild dann anhand der Tracking Daten in eine Richtung verschoben, damit es nicht ganz so abgehackt wirkt.
Möglicherweise kann das vom OP angesprochene Asynchronous Time Warp ne Möglichkeit sein das Frame Pacing zu glätten und zusätzlich die FPS oben zu halten, auch wenn das heißt Quasi-Bilder auszugeben.
Frame Pacing kann man nicht glätten
Frame Pacing ist das verfahren um Frametimes zu glätten... Und glätten meint dabei, dass aufeinanderfolgende Frames möglichst wenig absoluten Unterschied zwischen der Ausgabe haben. Einfach weil ein permanentes hoch und runter in den Frametimes nach Ruckeln ausschaut. Neudeutsch, Microruckler...
@fdsonne
Für einigermaßen stabile 90FPS brauchst mindestens 2x HD 7970, von daher macht Frame Pacing schon Sinn. (siehe Frametime Vergleich bei pcper)
Du brauchst effektiv aber 2x xxFPS. Das können ggf. dank der eher noch niedrigen Displayauflösung zwei HD7970 liefern... Aber da zwei GPUs sich perfekt dafür eignen, dass jede GPU je ein Display bedient, ist Frame Pacing/Frame Metering da eher wenig bis gar nicht von Belang... Zumal es, wie nun schon 3x gesagt, nix mit dem Problem aus der News zu tun hat. Perfekte Frametimes, also welche, die syncron zur Displayrefreshrate sind, erreichst du nur mit FreeSync/G-Sync stand heute. Und das scheinen die VR-Brillen atm nicht zu können.
Nimmt man es genau, dann wäre das Verhalten, was MGPU im AFR Mode bei nem Single Screen OHNE Frame Pacing/Frame Metering erzeugt, nämlich zwei Frames unmittelbar nacheinander und dann länger nix bis zum nächsten Doppelpack, sogar wünschenswert für VR Brillen. Warum? Weil es zwei Bilder bedarf. Und diese zwei Bilder sollten sich möglichst so ähneln, dass daraus verschiedene Perspektiven für den 3D Effekt entstehen... Man will doch dort gerade, dass beide Displays zur gleichen Zeit refreshen. Und nicht, dass erst links, dann rechts, dann links, dann rechts usw. in möglichst kleinem Abstand dargestellt wird -> letzteres würde arg zum Flimmern neigen. Wie es bspw. 3D Shutterbrillen normal verursache, da dort genau das passiert.
Und nutze diese auch zum Teil aktiv. Den einen primär zum Filme schauen, den anderen primär zum Spielen. Wenn sich bei mir dann irgendwann mal eine HDMI 2.0 fähige Grafikkarte, respektive so ein DP auf HDMI2.0 Adapter einfinden wird, kann ich auch mal in der Stube auf der 55" Glotze testen, ob echtes FHD 3D in Games geht 
Rein filmtechnisch macht der zumindest echtes UHD 3D im SBS Verfahren. Sprich 8k in der Breite und 2k in der Höhe... Hatte das anfangs mal mit ner simpel groß skalierten half-SBS Quelle von ner USB Platte probiert. -> das geht. Wie schon auf dem anderen TV mit echten FHD 3D, wenn es von USB kommt oder gestreamt wird. 8x2k wird aber wohl nicht durch den HDMI 2 Port gehen geschweige denn, dass es via 3D TV Play ausgebbar wäre...