> > > > Oculus und AMD sprechen über Asynchronous Time Warp

Oculus und AMD sprechen über Asynchronous Time Warp

DruckenE-Mail
Erstellt am: von

AMD Logo 2013AMD und NVIDIA sind in den vergangenen Monaten bemüht zu zeigen, dass sie jeweils in der Lage sind, an den neuen Entwicklungen bei den Grafik-APIs zu partizipieren. Die höhere Leistung spielt dabei natürlich die Hauptrolle und zwar unabhängig davon, ob eine Darstellung auf dem Monitor erfolgt oder in einem VR-Headset. Sowohl AMD als auch NVIDIA haben dazu eigene Schnittstellen entwickelt, die es Entwicklern einfacher machen sollen, für VR-Headsets das Maximum an Leistung herauszuholen. AMD wählt mit LiquidVR eine etwas offenere Position, während man bei NVIDIA auf GameWorks VR vertraut.

In vielen Punkten sind sich die verwendeten Technologien aber sehr ähnlich und dies trifft auch auf Asynchronous Time Warp zu, dessen Implementierung und Funktionsweise Oculus und AMD jeweils in einem Developer-Blog veröffentlicht haben. NVIDIA sprach auf der GPU Technology Conference im vergangenen Jahr bereits darüber und auch AMD ließ in Vorträgen immer wieder einige Worte dazu fallen, die nun konkret aufgefertigt wurden.

Der aktuell größte Störfaktor beim Rendering für ein VR-Headset ist ein Frame, der gedroppt werden muss – also nicht dargestellt wird. Es gibt verschiedene Gründe warum dies passiert. Eventuell reicht die Leistung des Systems nicht aus und die Frames erreichen die Brille zu langsam oder das Timing stimmt nicht und die Frames werden immer erst kurz nach dem Refresh des Displays ausgeliefert. Es gibt allerdings einige Methoden, um dies zu verhindern, doch auch diese können fehlschlagen und dann kommt es zu einem Effekt, der sehr störend beim Tragen einer solchen Brille ist.

Funktion des Asynchronous Time Warp in der Rendering-Pipeline
Funktion des Asynchronous Time Warp in der Rendering-Pipeline

Beim Asynchronous Time Warp wird der letzte fertig gerenderte Frame beibehalten und ersetzt letztendlich den nicht rechtzeitig berechneten Folgeframe. Damit bei der Darstellung aber nicht der gleiche Frame noch einmal angezeigt wird, was einem Stottern des Bildes nahekommt, wird dieser Frame leicht um die inzwischen getätigten Bewegungen des Kopfes bzw. des Nutzers angepasst. Die Anpassung der Berechnung wird auf der GPU ausgeführt, auf den Shadern. Der dazugehörige Prozess kann asynchron durchgeführt werden, ein Vorteil, der auch im Rahmen der Quick Response Queue und bei den Asynchronous Shaders insgesamt bereits eine Rolle spielt.

Letztendlich kann sichergestellt werden, dass immer ein fertig gerenderter Frame zur Verfügung steht – egal ob dieser in Echtzeit gerendert wurde oder nur bei Asynchronous Time Warp als Backup vorgehalten wird. In der Praxis ist die Umsetzung aber ungleich schwieriger, denn die Berechnung des Asynchronous Time Warp sollte so spät wie möglich im Rendering-Prozess des aktuellen Frames erfolgen, es muss aber noch genügend Zeit vorhanden sein, um die Berechnung vollständig auszuführen. Wird die Berechnung für den Asynchronous Time Warp zu früh angestoßen, könnte es bis zur Ausgabe noch größere Bewegungen beim Headtracking oder dem der Controller gegeben haben, die nicht mehr einbezogen werden können.

Daher werden die Berechnungen des Asynchronous Time Warp in die Quick Response Queue eingeführt. Somit kann sichergestellt werden, dass die Berechnungen selbst zu einem späten Zeitpunkt noch rechtzeitig und vollständig durchgeführt werden können.

AMD arbeitet bereits an weiteren Technologien, die von den Asynchronous Shaders und der Quick Response Queue Gebrauch machen. Als Beispiel wird die Berechnung von Audioinhalten genannt, die nun ebenfalls besser und positionsgenau erfolgen sollen, wenn sich der Nutzer im virtuellen Raum bewegt. Details dazu will man aber erst zu einem späteren Zeitpunkt veröffentlichen.

Social Links

Kommentare (17)

#8
Registriert seit: 02.06.2015

Matrose
Beiträge: 19
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).

Also nochmal: Frame Pacing meint nichts weiter, als das Zeitverhalten aufeinander folgender Frames. Was man also braucht ist eine Technologie um das Frame Pacing homogener zu bekommen und nicht andersrum.

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.
#9
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31933
Zitat Breit;24462907
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.

Zitat Breit;24462907
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...

Zitat Phantomias88;24462441
@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. ;)
#10
Registriert seit: 02.06.2015

Matrose
Beiträge: 19
Für mich klingt das trotzdem alles so, als ob hier ein (wie auch immer geartetes) Verfahren zur adaptiven Refreshrate durchaus helfen würde. Die Technologie ist mit G-Sync/Free-Sync da und überall verfügbar. Da verstehe ich nicht wieso so ein riesen Aufwand betrieben wird, wenn man (zumindest ein Stück weit) mit vorhandenen Technologien kommen würde?!
Die Displays in den VR-Brillen selbst sind ja sicher nicht das Problem, eher die eingesetzten Ansteuerungen. Bei der langen Entwicklungszeit und den horrenden Preisen hätte man ja durchaus die 2€ für nen Scaler-Chip übrighaben können, der variable Refreshraten kann.

Sicher ist das kein Allheilmittel für VR, aber für speziell die Fälle, wo eben ein Frame gerade so nicht rechtzeitig fertig wird, wäre es durchaus ne Lösung. Bei größeren Abweichungen von der Target-Framerate muss man sicher andere Sachen überlegen, klar.
#11
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31933
Das sehe ich auch so ;) Einzige Unbekannte ist, aktuelle Sync Verfahren setzen auf ein Display. Bei VR müssen es aber halt zwei syncrone Displays sein, damit das Sinn ergibt. Ob man das aus Adaptive Sync rausholen kann? Keine Ahnung... Ggf. muss man einfach den Standard dahingehend anpassen. Bei G-Sync, ist so oder so propritär, kann ich mir das aber schon eher vorstellen.

Allerdings, wie oben schon versucht zu erwähnen -> warum den Alleskönner schon im ersten Anlauf bringen? Rein für das Geschäft wäre das eher unsinn. Denn die Kunden kaufen heute VR, damit sie es testen. Dann finden die das geil und werden mit aller höchster Warscheinlichkeit auch eine bessere, gesyncte Displayversion nachkaufen. Vielleicht gleich kombiniert mit höher auflösenden Displays ;)

Was halt als weiteres Problem oben drauf kommt -> AMD kann FreeSync, NV kann G-Sync. Aber NV kann kein FreeSync und AMD kein G-Sync. Wenn sich die Hersteller der VR Brillen also auf einen der Themen einschießen, bleibt der andere im Regen. Für einen Markt, der erst zeigen muss, ob er überhaupt aufgeht? Wohl ein viel zu großes Risiko. Zumal, FreeSync, der eigentliche Ansatz aufbauend auf dem Standard, ja vom kleineren der beiden Parteien beherscht wird. Würde man also FreeSync einbauen, schließt man gut 50% des Marktes aus und sogar noch mehr, beim dGPU Markt. Nutzt man G-Sync, wird das "G-Sync Modul" fällig, die Logik muss halt irgendwo hin...
Wirklich schön für den Kunden wird das definitiv nicht werden ;) Zumindest nicht solange beide GPU Hersteller nicht am selben Strang ziehen. Intel ist aus meiner Sicht da kein Treiber -> kann zwar prinzipiell FreeSync, aber die Intel IGPs sollten für VR eher zu schwach sein. Auch Kommende...
#12
Registriert seit: 05.11.2007
Neckar-Odenwald Kreis
Fregattenkapitän
Beiträge: 2896
Zitat fdsonne;24463052
Das sehe ich auch so ;) Einzige Unbekannte ist, aktuelle Sync Verfahren setzen auf ein Display. Bei VR müssen es aber halt zwei syncrone Displays sein, damit das Sinn ergibt. Ob man das aus Adaptive Sync rausholen kann? Keine Ahnung... Ggf. muss man einfach den Standard dahingehend anpassen. Bei G-Sync, ist so oder so propritär, kann ich mir das aber schon eher vorstellen.


Die Brillen werden aber doch wie ein einzelner Monitor behandelt, sonst müssten die auch 2 HDMI Anschlüsse besitzen, die Oculus Rift hat AFAIK nur 1 HDMI und 1 DVI Anschluss.
#13
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31933
Das macht doch effektiv keinen Unterschied? Oder steh ich gerade auf dem Schlauch?

Im Grunde ist es doch ein "Bild" in der Basis (man schaut ja in eine virtuelle Welt und sieht auf beiden Augen das gleiche aus unterschiedlicher Perspektive), aus diesem "Bild" wird jeweils ein Frame für das linke und ein Frame für das rechte Auge erzeugt. Am Ende wird aus diesen beiden Frames entweder ein doppeltes Frame (pro Auge, nebeneinander) oder als zwei Bilder an die Brille verschickt. Egal wie man es dreht, wenn die GPU (sofern es nur eine ist), nur ein Frame zur gleichen Zeit berechnen kann (und das scheint ja der Fall zu sein), dann hat es entweder bei einem der beiden "Augen-Frames" einen Versatz in xxms oder es gibt eine Verzögerung (bei Ausgabe als ganzes Frame nebeneinander) vom gesamten Bild.

In beiden Fällen wäre der Sync nicht mit dem eines nativem Single Screens vergleichbar. Denn dort ist es doch eine 1:1 Beziehung. GPU berechnet Bild -> gibt es aus und der Monitor macht nen Refresh. Um so schneller die GPU, desto schneller kann refresht werden usw.
Hier wären es, egal ob als ein Frame nebeneinander oder als zwei Bilder im Wechsel links/rechts aber doch notwendig, dass der Refresh/Sync über die Berechnung beider Bilder auf der GPU erfolgt...
Oder berechnet die GPU das in einem Rutsch? Wäre mir zumindest so bis dato nicht geläufig...
#14
Registriert seit: 02.06.2015

Matrose
Beiträge: 19
NV kann schon Freesync, die wollen nur nicht. ;)
Meines Wissens nach sind die VR-Displays aber tatsächlich logisch nur ein Display, eins was eben aufgeteilt wird. Aber selbst wenn das nicht so wäre, 2 Display-Elektroniken zu synchronisieren ist eher nicht so nen riesen Problem.

Ich glaube ja eher VR ist eh nichts für den Massenmarkt, auch wenn das alle immer gerne so hätten. Den allermeisten Leuten wird dabei eh nach kurzer Zeit schlecht und wenn man sich jetzt auch noch Features, die helfen können diesen Effekt zu verringern bewusst erst in der zweiten/dritten Generation verbaut werden um "größeren Profit zu machen", na dann Prost. Der Grat zwischen Scheitern und finanziellem Erfolg scheint mir recht schmal zu sein. :)

Das Ganze wird vermutlich so ne Luftnummer wie 3D-Fernsehen. Alles ganz toll, aber eigentlich will das kaum jemand wirklich haben und mittlerweile gibts auch immer weniger Geräte die das überhaupt können. Spätestens mit 4K isses dann ganz tot, weil es nicht mal ne Spezifikation für 4k-3D-BluRays gibt und auch nicht angedacht ist eine zu verabschieden.
#15
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 31933
Zitat Breit;24463351
NV kann schon Freesync, die wollen nur nicht. ;)
Meines Wissens nach sind die VR-Displays aber tatsächlich logisch nur ein Display, eins was eben aufgeteilt wird. Aber selbst wenn das nicht so wäre, 2 Display-Elektroniken zu synchronisieren ist eher nicht so nen riesen Problem.


Logisch wollen die nicht ;)
Man hat doch bei NV auf Biegen und Brechen VOR der FreeSync Vorstellung G-Sync rausgehauen. Und AMD konnte effektiv auch nicht sooo viel schneller, da es ja erstmal zum Standard gemacht werden musste. Das Prinzip ist eigentlich das gleiche. NV wird wie so oft aber nen Teufel tun, da was dran zu ändern. Gibt auch nen 1A Kopierschutz, dieses G-Sync Modul.

Ansonsten, wie angesprochen, ich sehe nicht primär das Problem auf der Seite der VR Brille. Ob das nun als ein Bild oder als zwei Bilder an die Brille geht, ist doch theoretisch nebensächlich. Denn im Endeffekt unterteilt die Brille oder die GPU die Bildinformation ja nach links und rechts. Wer es macht ist wurscht. Mir gings eher um die Erzeugung des Bildes... Und die ist nicht von Beginn an ersichtlich. Sprich es steht nicht VOR dem Berechnen fest, wie lange die Berechnung dauert.
Deswegen (wie in der News zu lesen) kann es da zu ungünstigen Konstellationen kommen. Die man mit diesem dirty Workaround angehen will. Das Sync Feature wäre hingegen eigentlich der interessante Part... Nur sehe ich das nicht mit dem adaptive Sync nach aktuellem Standard, weil es von der Berechnung meiner Ansicht nach nicht ein Bild mit zwei Perspektiven nebeneinander sondern zwei dieser Bilder sind, die dann wohlweise zusammen gelegt oder nacheinander ausgegeben werden. Man müsste also über die Zeit der Berechnung von zwei Bildern in Summe die Ausgabe syncen. Ob das mit adaptive Sync nach aktueller Implementierung und ohne Anpassung des Standards geht? Wäre zumindest nicht gesichert...

Zitat Breit;24463351
Ich glaube ja eher VR ist eh nichts für den Massenmarkt, auch wenn das alle immer gerne so hätten. Den allermeisten Leuten wird dabei eh nach kurzer Zeit schlecht und wenn man sich jetzt auch noch Features, die helfen können diesen Effekt zu verringern bewusst erst in der zweiten/dritten Generation verbaut werden um "größeren Profit zu machen", na dann Prost. Der Grat zwischen Scheitern und finanziellem Erfolg scheint mir recht schmal zu sein. :)

Das Ganze wird vermutlich so ne Luftnummer wie 3D-Fernsehen. Alles ganz toll, aber eigentlich will das kaum jemand wirklich haben und mittlerweile gibts auch immer weniger Geräte die das überhaupt können. Spätestens mit 4K isses dann ganz tot, weil es nicht mal ne Spezifikation für 4k-3D-BluRays gibt und auch nicht angedacht ist eine zu verabschieden.


Bei ersterem stimme ich dir zu ;) Weswegen ich wohl auch im ersten Anlauf keine VR Brille besorgen werde. Dazu noch das Herstellerproblem... Sollte sich das ansatzweise etablieren, dann wird sich eine der Brillen wohl am Ende durchsetzen. Dann wird der Part für mich interessant(er), sofern es dann auch nutzbar ist/wird.

Zum 3D TV -> also ich mag meine 3D TVs :D 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 :fresse: 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...
#16
Registriert seit: 05.11.2007
Neckar-Odenwald Kreis
Fregattenkapitän
Beiträge: 2896
Zitat fdsonne;24463345
Das macht doch effektiv keinen Unterschied? Oder steh ich gerade auf dem Schlauch?

Im Grunde ist es doch ein "Bild" in der Basis (man schaut ja in eine virtuelle Welt und sieht auf beiden Augen das gleiche aus unterschiedlicher Perspektive), aus diesem "Bild" wird jeweils ein Frame für das linke und ein Frame für das rechte Auge erzeugt. Am Ende wird aus diesen beiden Frames entweder ein doppeltes Frame (pro Auge, nebeneinander) oder als zwei Bilder an die Brille verschickt. Egal wie man es dreht, wenn die GPU (sofern es nur eine ist), nur ein Frame zur gleichen Zeit berechnen kann (und das scheint ja der Fall zu sein), dann hat es entweder bei einem der beiden "Augen-Frames" einen Versatz in xxms oder es gibt eine Verzögerung (bei Ausgabe als ganzes Frame nebeneinander) vom gesamten Bild.

In beiden Fällen wäre der Sync nicht mit dem eines nativem Single Screens vergleichbar. Denn dort ist es doch eine 1:1 Beziehung. GPU berechnet Bild -> gibt es aus und der Monitor macht nen Refresh. Um so schneller die GPU, desto schneller kann refresht werden usw.
Hier wären es, egal ob als ein Frame nebeneinander oder als zwei Bilder im Wechsel links/rechts aber doch notwendig, dass der Refresh/Sync über die Berechnung beider Bilder auf der GPU erfolgt...
Oder berechnet die GPU das in einem Rutsch? Wäre mir zumindest so bis dato nicht geläufig...


Du stehst auf dem Schlauch, da es sich für die GPU bei der Ausgabe um nur ein Bild handelt, kann man es genauso synchen wie eben auch bei einem Monitor. In der Brille (oder ist das ein Headset?) wird dann halt ab Pixel X auf dem zweiten Display ausgegeben. Wieso sollte man denn das Bild im Wechsel ausgeben? macht doch gar keinen Sinn.
#17
customavatars/avatar89889_1.gif
Registriert seit: 19.04.2008
PorscheTown
Flottillenadmiral
Beiträge: 5142
Zitat Breit;24462907

Also nochmal: Frame Pacing meint nichts weiter, als das Zeitverhalten aufeinander folgender Frames. Was man also braucht ist eine Technologie um das Frame Pacing homogener zu bekommen und nicht andersrum.

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.

Zitat
Der aktuell größte Störfaktor beim Rendering für ein VR-Headset ist ein Frame, der gedroppt werden muss – also nicht dargestellt wird.


Radeon Software 16.3.2 mit VR-Unterstützung und Quick Response Queue - Hardwareluxx
Zitat
Bestimmte Rechenaufgaben sollten gerade im Zusammenspiel mit VR-Headsets priorisiert behandelt werden. Eben diese werden in die Quick Response Queue eingebracht.


Da muss man schon Entwickler sein um die Zusammenhänge zu erkennen, ich kann es nicht. :)
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Roundup: 5x GeForce GTX 1070 mit Custom-Design im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/5X-GTX1070/GTX1070_CUSTOM_ROUNDUP-TEASER

Nachdem wir bereits eine Reihe von Boardpartner-Karten der NVIDIA GeForce GTX 1080 ausführlich getestet haben, holen wir gleiches nun für das kleinere Schwestermodell nach, denn auch von der NVIDIA GeForce GTX 1070 gibt es viele Custom-Modelle mit höheren Taktraten, eigenen Kühlsystemen und... [mehr]

Drei Custom-Modelle der GeForce GTX 1060 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/3X-GTX1060/GTX1060_ROUNDUP_TEST-TEASER

Anders als bei der GeForce GTX 1080 und GeForce GTX 1070 trudelten wenige Stunden nach unserem Test zur Founders Edition der NVIDIA GeForce GTX 1060 schon die ersten Boardpartner-Karten mit teils höheren Taktraten, eigenem Kühlsystem und überarbeitetem Platinenlayout ein. Sie dürften... [mehr]

NVIDIA GeForce GTX 1080 mit Pascal-Architektur im XXL-Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Heute ist es soweit: NVIDIA läutet mit der GeForce GTX 1080 und GTX 1070 auf Basis der Pascal-Architektur den diesjährigen Neustart bei den Grafikkarten ein. In Kürze wird wohl auch AMD seinen Beitrag zu diesem Thema leisten. Vor zehn Tagen lud NVIDIA die gesammelte Fachpresse nach Austin ein... [mehr]

Roundup: 5x GeForce GTX 1080 im Custom-Design im Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Nachdem wir uns die Founders Edition der GeForce GTX 1080 und GeForce GTX 1070 bereits angeschaut haben, folgen nun fünf Retail-Modelle, die wir in aller Ausführlichkeit unter die Lupe nehmen wollen. Aus den vielen Boardpartnern und unterschiedlichen Modellen haben wir uns solche von ASUS, EVGA,... [mehr]

AMD Radeon RX 480 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/RADEON-RX480/RADEON-RX480-REFERENCE-LOGO

Es ist also soweit: AMD startet die großangelegte Zurückeroberung des Grafikkartenmarktes mit der Radeon RX 480, die als erste Grafikkarte der Polaris-Generation mit gleichnamiger Architektur erscheint und die wir uns genauer anschauen können. Dabei versucht sich AMD an einem anderen Ansatz im... [mehr]

PowerColor Radeon RX 480 Red Devil im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/POWERCOLOR-RX480/POWERCOLOR-RX480REDDEVIL-LOGO

Mit der Radeon RX 480 will AMD zurück zu alter Stärke und hat daher über Monate hinweg die PR-Trommel geschlagen. Letztendlich dabei herausgekommen ist eine sehr gute Karte für einen niedrigen Preis, die aber nicht in allen Bereichen zu überzeugen weiß. Wohl größtes Manko der Karte sollte... [mehr]