Oculus und AMD sprechen über Asynchronous Time Warp

Don

[printed]-Redakteur, Tweety
Thread Starter
Mitglied seit
15.11.2002
Beiträge
27.060
<p><img src="/images/stories/logos-2013/AMD_Logo_2013.jpg" alt="AMD Logo 2013" style="margin: 10px; float: left;" />AMD 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. <a href="http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/vr" target="_blank">AMD wählt mit LiquidVR</a> eine etwas offenere Position, während man bei <a...<br /><br /><a href="/index.php/news/hardware/grafikkarten/38632-oculus-und-amd-sprechen-ueber-asynchronous-time-warp.html" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wäre es nicht besser, sicherzustellen, dass der Frame korrekt berechnet werden kann, anstatt mit dieser... ähm... Patchworklösung die Fehlberechnung auszugleichen?

Ich denke da an sowas wie Polygonlimitierung (Tesselation) oder auch dem Auslassen von gewissen Details um den Frame halt noch rechtzeitig zu rendern. Im Hinblick darauf, dass man zum Beispiel bei Grafikdeteils von "ultra vs high" kaum noch Unterschiede erkennt, würde ich eher daran ansetzen (grob gesagt: Das mp3 fürs Auge hinsichtlich der Grafikqualität)

Das kann aber der Treiber nicht oder nur noch teilweise machen und benötigt eher die Aufmerksamkeit der Anwendungsentwickler um sicherzustellen, dass sie ihre Rendering-Szenen optimieren (Pipeline, saubere 3D Objekte, weniger überlappende und somit obsolete Lichtquellen usw)
 
Beim Asynchronous Time Warp geht es nur darum ein Sicherheitsnetz zu spannen, falls etwas schiefgeht. Nur wenige Frames sollten per ATW abgefangen werden – das sollte nur alle paar Sekunden notwendig sein, wenn überhaupt. Darauf verlassen sollten sich die Entwickler schon gar nicht.

Von daher ja, die Optimierungen müssen stattfinden, aber schon bevor ATW überhaupt eingreifen muss.
 
G-Sync / Free-Sync würde da nicht helfen? Ist sowas bei VR nicht vorgesehen oder warum steckt man nicht lieber hier ein paar Ressourcen rein? Gerade bei VR kann ich mir den Nutzen noch am ehesten vorstellen, zumal die Hardwarelandschaft ja recht überschaubar ist und man daher nicht so viele verschiedenen Hardwarekonfigurationen berücksichtigen muss, wie am Desktop.
 
G-Sync / Free-Sync würde da nicht helfen? Ist sowas bei VR nicht vorgesehen oder warum steckt man nicht lieber hier ein paar Ressourcen rein? Gerade bei VR kann ich mir den Nutzen noch am ehesten vorstellen, zumal die Hardwarelandschaft ja recht überschaubar ist und man daher nicht so viele verschiedenen Hardwarekonfigurationen berücksichtigen muss, wie am Desktop.
Freesync und Gsync sind für einen Monitor, würde aber nichts bringen wenn die Ausgabe schon hakelt.
Da wäre "Frame Pacing" für jedes Auge schon effektiver, da unabhängig vom Monitor. ;)
 
Da wäre "Frame Pacing" für jedes Auge schon effektiver, da unabhängig vom Monitor. ;)

Kannst du den Satz irgendwie erklären? Den versteh ich irgendwie nicht.

Frame Pacing ist meines Wissens nach nen Begriff hauptsächlich aus der Multi-GPU Rendering Welt und bezeichnet letztlich das Verhältnis der Renderzeiten aufeinander folgender Frames, welches beim Rendern der Frames auf unterschiedlichen GPUs durchaus unterschiedlich lange dauern kann (bei AFR zum Beispiel; etwa durch Abhängigkeiten zwischen den Frames). Dachte ich zumindest immer?!
Wie kann also jetzt eine Metrik an sich für einen bestimmten Sachverhalt "besser" sein und vor allem besser als was?

Mit G-Sync / Freesync kann man erreichen, das das Frame Pacing homogener, gleichmäßiger wird, was bei VR insbesondere den flüssigen Eindruck, die Immersion erhalten hilft. Sicher wird man hier irgendwie algorithmisch eingreifen müssen um die Frameraten möglichst gleichmäßig zu halten und starke Sprünge und damit den Eindruck von Ruckeln zu vermeiden, aber letztlich erscheint es mir durchaus als probates Mittel.

Ich vermute eher das Problem wird Input-Lag (oder die Reduzierung dessen) sein, bei VR nen riesen Thema.
 
Zuletzt bearbeitet:
Freesync und Gsync sind für einen Monitor, würde aber nichts bringen wenn die Ausgabe schon hakelt.
Da wäre "Frame Pacing" für jedes Auge schon effektiver, da unabhängig vom Monitor. ;)

Nein, gesyncte Bildausgabe wäre genau das richtige. Im Unterschied zu einem Single Screen muss nur der langsamste Part in der Kette dynamisch den Speed vorgeben. Also müssen die Frames auf beiden Augen so lange angezeigt werden, wie die folgenden zwei Bilder in der Berechnung dauern und unmittelbar nach der Berechnung muss die Ausgabe erfolgen. Können die Displays dann ein Sync Feature, lässt sich das bewerkstelligen. Da genau damit seitens der Grafikkarte der Refresh mit neuem Bildinhalt erfolgen kann ohne zum nächsten Refreshzyklus der Displays warten zu müssen.

Frame Pacing respektive Frame Metering hilft da nicht wirklich. Denn es wird damit die Ausgabe verzögert oder der Start der Berechnung nach hinten verschoben. Aber anhand welcher Basis? -> Berechnungen der Vergangenheit... Das hilft Frametimes zu glätten, aber nicht das Problem, was hier benannt ist, zu beheben. Denn es sind nicht unterschiedlich hohe und ungleichmäßige Frametimes das Problem, sondern ein Problem ist die absolute Latenz. Wenn ein Frame doppelt so lange (weil unmittelbar nach dem Display Refresh erst fertig) dargestellt wird, halbiert sich für dieses Frame die Leistung. Deswegen will man das letzte Bild mit einem Vorsatz anhand von Eingabedaten berechnen, ähnlich der Zwischenbildberechnung bei TVs. Das ist aber eher der/ein dirty Workaround als eine Problemlösung...

Ideal für VR wären auch exakt zwei GPUs, oder ein vielfaches von zwei, wenn man SFR nutzt. Denn jegliche Anzahl von ungeraden GPUs würde bedeuten, dass entweder Leerlauf entsteht oder Frames nacheinander berechnet werden müssen. Beides ist bei VR eher kontraproduktiv.

Für gesyncte Displays bei VR Brillen scheint es wohl aber an der Displayhardware zu scheitern... ;) deswegen erst dirty Workaround, dann ggf. mal der richtige Ansatz. Lässt sich dann auch schön als Weltneuheit vermarkten und die Masse rennt in die Läden und kauft. ;)

PS: bitte nicht wieder in deine pseudotechnischen Erklärungsversuche verfallen. ;) das geht wieder nach hinten los...
 
Kannst du den Satz irgendwie erklären? Den versteh ich irgendwie nicht.

Frame Pacing ist meines Wissens nach nen Begriff hauptsächlich aus der Multi-GPU Rendering Welt und bezeichnet letztlich das Verhältnis der Renderzeiten aufeinander folgender Frames, welches beim Rendern der Frames auf unterschiedlichen GPUs durchaus unterschiedlich lange dauern kann (bei AFR zum Beispiel; etwa durch Abhängigkeiten zwischen den Frames). Dachte ich zumindest immer?!
Wie kann also jetzt eine Metrik an sich für einen bestimmten Sachverhalt "besser" sein und vor allem besser als was?

Mit G-Sync / Freesync kann man erreichen, das das Frame Pacing homogener, gleichmäßiger wird, was bei VR insbesondere den flüssigen Eindruck, die Immersion erhalten hilft. Sicher wird man hier irgendwie algorithmisch eingreifen müssen um die Frameraten möglichst gleichmäßig zu halten und starke Sprünge und damit den Eindruck von Ruckeln zu vermeiden, aber letztlich erscheint es mir durchaus als probates Mittel.

Ich vermute eher das Problem wird Input-Lag (oder die Reduzierung dessen) sein, bei VR nen riesen Thema.
Hier haben sie Frame Pacing mit dem Crimson Treiber getestet: AMD Radeon Software Crimson Improves FreeSync and Frame Pacing Support | PC Perspective

@fdsonne
Für einigermaßen stabile 90FPS brauchst mindestens 2x HD 7970, von daher macht Frame Pacing schon Sinn. (siehe Frametime Vergleich bei pcper)
 
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.
 
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:
amd-asynchronous-time-warp-rs.png

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. ;)
 
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.
 
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...
 
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.
 
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...
 
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.
 
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...

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...
 
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.
 
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.
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
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. :)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh