Frage Welche zusätzliche Rechenleistung ist "grundsätzlich" notwendig um 2 Perspektiven für VR zu berechnen?

Kreiseltower

Neuling
Mitglied seit
Sep 2, 2020
Beiträge
6
Bewertungspunkte
1
Punkte
1
Hallo und guten Morgen,

Ich bin neu hier in der Community. Bin absolut begeistert von Igors Fachkenntnis und möchte daher eine Frage stellen über die ich mir schon länger Gedanken mache. Falls es dazu schon einen Artikel/Bericht/Video gibt habe ich ihn nicht gefunden.

Es geht darum (könnte auch ein theoretischer Ansatz sein, abseits davon wie es tatsächlich derzeit praktikabel implementiert wird).. wie viel zusätzliche Rechenleistung von einem Computer benötigt wird um z.B. aus einem "normalen" Spiel ein VR Spiel zu machen. Nach meiner Vorstellung muss die Grafikkarte eigentlich "nur" 2 Perspektiven der gleichen Szene berechnen. Die Texturen usw. im VRAM müssten doch eigentlich die gleichen sein usw.

Frage: Funktioniert das tatsächlich so oder müssen mehr Dinge quasi unnötigerweise doppelt berechnet werden? Wie funktioniert es überhaupt? Ich versuche es mal bildhaft darzustellen wie ich es mir vorstelle und einen Vergleich zu verwenden wie ich mir das von Igor vorstellen könnte :sneaky:

Es soll ein VR Familienbild gemalt werden. Die CPU legt fest, wo Tante Hilde, Onkel Gerd, Cousine Jutta usw. stehen. Die CPU legt auch fest, dass im Hintergrund der Weihnachtsbaum steht und wo der Maler mit seinem Pinsel steht.

Reicht es jetzt dem Maler zu sagen: Mal 2 Bilder, eines von deinem linken und eins von deinem rechten Auge oder muss die CPU für das zweite Bild dem Maler wieder erklären wo Tante Hilde, Onkel Gerd usw. stehen ;-)

Für jede Info oder Quellen wie dies Funktionsweise vereinfacht erklärt wird wäre ich dankbar.
 
In Prinzip hast Du es schon richtig beschrieben. Die GPU berechnet die Szene aus zwei Blickwinkeln und tatsächlich müssen dazu die Texturen nur einmal im Speicher sein.

Dennoch wird in der GPU normalerweise jedes Frame unabhängig voneinander berechnet (temporale Effekte wie MotionBlur, TAA und DLSS mal außen vor gelassen), und das gilt auch für die beiden Bilder in einer VR Brille.

Man kann also grob sagen, dass sich die Anforderungen an die Leistung (nicht den Speicher!) einer GPU durch VR verdoppeln. Allerdings sind auch die Auflösungen der VR Brillen i.d.R. niedriger als HighEnd Monitore.
 
Hallo,
habe gerade erst entdeckt, dass es hier auch einen VR-Bereich gibt. Schade, dass hier so wenig los ist.

Um die Frage oben zu beantworten und das Beispiel weiter zu führen: Dem Maler (nicht dem Onkel, der die Familie arrangiert) muss AFAIK bei dem 2.Bild nicht nur erneut beigebracht werden, wo Tante Hilda steht, sondern auch wer Tante Hilda eigentlich ist, bzw wie sie aussieht.
Es handelt sich nicht um eine theoretische Vektorgrafik auf einem theoretische 3D Bildschirm, die perspektivisch einfach leicht verschoben wird, sondern bei jedem neuen Renderdurchgang muss jeder einzelne Bildpunkt/Pixel für die beiden 2D Bildschirme neu berechnet werden.
Zwar gibt es verschiedene Tricks, wie man dies intern vereinfachen kann, aber theoretisch könnte man das, glaube ich, so stehen lassen. Daher steigt auch uA die Rechenlast bei höheren Auflösungen.

Hierbei muss man zwischen "echter" höherer Auflösung und einfachem Hochskalieren unterscheiden. Die reine Bildberechnung beim reinen Hochskalieren ist deutlich vereinfacht und kann auch zB von dedizierter Hardware in manchen HMDs übernommen werden (zB Pimax), trotzdem muss berechnet werden, dass bei einem zB doppelt so großem Bildausschnitt an zB Tante Hildas obersten Blusenknopf 4 weiße Pixel statt einem gezeigt wird. Dies findet (neben dem erwähnten Pimax HMD usw) zB beim Supersampling Anwendung. Damit kann man die Bildqualität noch einmal etwas steigern. Obwohl es sich dabei um eine relativ einfache Berechnung handelt, wissen wir alle, dass es ganz schön viel Performance kostet, den Regler nach rechts zu verschieben.

Dazu kommt noch, zusätzlich zu dem was Grestorn ja schon geschrieben hat, die berechnete Bildkorrektur um die Linsenverzerrung auszugleichen und weitere Korrekturberechnungen (zB sogar teilweise Farbverzerrungs-Ausgleich). Sonst würden wir das Bild, etwas vereinfacht, wie zB durch einen Türspion sehen.

Lange Rede, kurzer Sinn: Bisher habe ich noch nirgendwo einen allgemein anerkannten Berechnungsschlüssel gefunden, mit dem man die VR-HMD-Auflösungen mit normaler Bildschirmauflösung vergleichen könnte.
Einige Berechnungen sind in VR vereinfacht, es müssen nicht so viele und große Texturen in den VRAM geladen werden, VRSpiele sind oft auch Grafisch weniger anspruchsvoll, usw. Dafür kosten einige andere Berechnungen mehr Zeit, durch die Kopfbewegung finden sehr viele Perspektivenänderungen statt und wir brauchen konstant hohe Bildwiederholungsfrequenzen/FPS um nicht Seekrank zu werden. Im Groben wird daher zumeist die addierte Auflösung beider Bildschirme als Bezugswert herangenommen. Vor einigen Tagen bestätigte der Entwickler des "VR-Benchmarks" noch einmal deutlich, dass "selbst eine Valve Index bereits mehr als 4k" anzeigt.
 
Hallo

Ein Game durchläuft bei jedem Frame der erstellt wird die gleichen Abläufe.
- Zuerst werden Eingaben der Tastatur und Maus abgefragt. (und Server bei Onlinegames)
- Dann wird der Spielverlauf berechnet, Objekte verschoben und dabei Kollisionen festgestellt.
- Wenn nötig werden neue Objekte nachgeladen und generiert
- dann erzeugt der Prozessor den Programmcode, der für das erstellen des neuen Bildes nötig ist
- Ein Teil dieses Programmcodes wird auf der Grafikkarte ausgeführt. Was die Grafikkarte nicht übernehmen kann, wird auf dem Prozessor ausgeführt.
- Sound wird ausgegeben und der Server über den Ablauf informiert
Dann beginnt das ganze von vorne.

Bei VR bleiben die ersten Schritte unverändert. Der Prozessor muss aber Programmcode für 2 Bilder erstellen. Danach berechnen die Grafikkarte und der Prozessor die beiden Bilder. Bei unveränderten Einstellungen und 2 x FHD statt einmal FHD verdoppelt sich somit der Aufwand dieser beiden Arbeitsschritte. Das Game selbst wird nicht komplexer. Es werden gleich viele Objekte generiert und bewegt. Es müssen auch nich mehr Texturen geladen werden, da man normalerweise mit beiden Augen die selben Objekte sieht.

Nun verwendet man bei VR häufig eine tiefere Auflösung und kann die Qualitätseinstellungen etwas senken.

Wenn man die Menge Objekte im Game reduziert, entlastet das den Prozessor etwas beim generieren und verschieben dieser Objekte.

Wenn man die Bildqualität, Antialiasing, Supersampling und so verändert, wird die Berechnungsart der Bildpixel verändert. Dadurch sinkt oder steigt der Aufwand die CPU und GPU mit der Bildberechnung haben.

Es bleibt aber dabei, dass der Prozessor den Programmcode für 2 Bilder generieren muss. Gerade ältere, mittelmässig programmierte Games sind genau dadurch Prozessorlimitiert und kommen nur auf ungefähr halb so viele FPS wie man bei der selben Objektdichte ohne VR hätte.

Ein ähnliches Verhalten kann man bei älteren Flugsimulatoren wie dem FSX feststellen. Wenn man zusätzliche Sichtfenster öffnet, kann man die Anzahl FPS praktisch durch die Anzahl Sichten teilen. Wenn man beispielsweise zur Cockpitsicht die mit 50 FPS auf dem Hauptbildschirm läuft noch eine Aussenansicht von der Seite dazu nimmt, sinken die FPS ungefähr auf 25. Öffnet man dann noch eine Aussenansicht von hinten, fallen die FPS auf unter 20, so dass es kaum mehr spielbar ist. Dabei spielt es kaum eine Rolle, wie gross die neu geöffneten Fenster sind.
 
Kann man diese Schritte nicht geradezu optimal parallelisieren, also in zwei Threads ausführen? Damit dürften doch moderne Mehrkern-CPUs ein leichtes Spiel haben...
 
Kann man diese Schritte nicht geradezu optimal parallelisieren, also in zwei Threads ausführen? Damit dürften doch moderne Mehrkern-CPUs ein leichtes Spiel haben...
Können: Ja.
Machen: Na, ja.

Bei der Neuentwicklung eines Games entscheiden sich die Programmierer für eine geeignete Programmiersprache und Programmierumgebung. Dadurch sind die Möglichkeiten der Programmierer auf die Möglichkeiten der Programmierumgebung beschränkt. Gewisse Aufgaben können einige Programmierumgebungen automatisch paralellisieren. Für eine weitgehende Parallellisierung braucht es aber einen Grundlegenden Aufbau im Programm, den die Programmierer umsetzen müssen.

Beim Erstellern neuer Games muss man also "nur" eine aktuelle Programmierumgebung verwenden und den Programmierern erklären, worauf sie beim Programmieren achten müssen.

Die meisten heutigen Games bauen aber auf älteren Versionen auf, die mit älteren Programmierumgebungen erstellt wurden. Später mit einer neuen Programmierumgebung eine stärkere Parallellisierung in eine alte Software zu bringen ist extrem aufwändig. So tiefgreifende Veränderungen benötigen Anpassungen an allen möglichen Programmteilen, von denen dann wieder die nächsten abhängig sind.

Wie weit es überhaupt schon Programmierumgebungen gibt, mit denen man VR sinnvoll paralellisieren kann, ist mir nicht bekannt. Für die meisten Entwickler ist VR eine hübsche Option, die von ein paar Fans genutzt wird. Darum steht es auf der Prioritätenliste meist recht weit unten nach all den Verbesserungen die man für die grosse Masse der Gamer verwirklichen möchte.
 
Ich weiss zufällig, dass zB neuere Versionen von Unity relativ gut die vorhandenen Kerne in VR auslasten können. Ältere Versionen könen das zB nicht sonderlich gut und die Portierung eines älteren VR-Games ist zumeist unwirtschaftlich. Unity hat (wie andere auch) bereits seit längerem direkte SteamVR Unterstützung. Wie Martin schon geschrieben hat, hängt es also immer davon ab, wie und womit das Spiel entwickelt wurde... Ich würde noch "wann" ergänzen.

Von grauenhaft unoptimiert in VR portierte Spiele wie Fallout und Skyrim brauchen wir garnicht reden. Schade, da diese mit Alyx noch immer meine Lieblingstitel sind.
 
Huch, der Thread wurde ja nochmal richtig aktiv. Ganz verpasst :)
@Martin Gut : Danke für die ausführliche Erklärung

Auch alle anderen. Echt Schade, dass es sich kaum lohnt "alte" Programme auf die Möglichkeiten der neuen Technik umzuschreiben. Hier wird sicher viel Potential verschenkt.
 
Wenn ich mal assetto corsa als Vergleich nehme, dann ist das schon ganz ordentlich was du da an Mehrleistung brauchst. Ich denke das Spiel ist auch ein gutes Beispiel, da es normal und mit VR spielbar ist.

Mit nem 9900k und ner 2080 hab ich bei dem Spiel auf dem Fernseher mit 4k und allen Reglern nach oben, inkl. Sol mod etc. Um die 100-120 Bilder/sekunde.

Mit der HP reverb, welche ja mit der Auflösung etwas über 4k liegt, komme ich nicht ansatzweise auf die benötigten 90 Bilder. Da muss ich einiges runter schrauben. Schlimm ist das nicht bei diesem Spiel, die Optik ist noch ausreichend.

Bei HL alyx hingegen merkt man Das das Spiel für VR gemacht ist. Ich müsste nochmal nachschauen, mir dünkt aber das ich die regler alle irgendwo zwischen hoch und sehr hoch stehen hätte.
 
Danke für eure Antworten.

Ich habe seit 1,5 Wochen nun auch eine Reverb G2 und beim Racing-Sims schafft meine RTX 3080 das nicht "vernünftig". Da muss man gewaltige Abstriche machen für 90 HZ und immer noch hohe Abstriche für 45 FPS mit ein bisschen höheren Settings.. Half Life Alyx läuft auch bei mir mit hohen Super Sampling und Ultra Einstellungen in Game ohne Probleme mit 90 HZ.

Mir war nicht so wirklich bewusst gewesen, dass man eine Renderauflösung von ~140-150% der nativen Auflösung wählen muss/sollte um das volle Potential auszuschöpfen. Und da die native Auflösung schon 2160x2160 pro Auge ist, landet man da bei mehr als dem doppelten von 4K.
 
Falls du von R3E redest, dann liegt das am Spiel. Das nutzt wohl nur einen CPU Kern... da bringt die also der beste Rechner nichts. Hab da auch schon alles mögliche probiert. Guck dir mal die CPU/GPU auslastung an...

Ansonsten denke ich das die 3080 doch genug Leistung hasben sollte.0

SS nutze ich nicht, ich habe die normale Auflösung der Brille eingestellt, mehr schafft der Rechner sowieso nicht. Aber das sieht schon ganz gut aus verglichen mit anderen Brillen die eine weniger gute Auflösung haben.
 
Können: Ja.
Machen: Na, ja.

Bei der Neuentwicklung eines Games entscheiden sich die Programmierer für eine geeignete Programmiersprache und Programmierumgebung. Dadurch sind die Möglichkeiten der Programmierer auf die Möglichkeiten der Programmierumgebung beschränkt. Gewisse Aufgaben können einige Programmierumgebungen automatisch paralellisieren. Für eine weitgehende Parallellisierung braucht es aber einen Grundlegenden Aufbau im Programm, den die Programmierer umsetzen müssen.

Beim Erstellern neuer Games muss man also "nur" eine aktuelle Programmierumgebung verwenden und den Programmierern erklären, worauf sie beim Programmieren achten müssen.

Die meisten heutigen Games bauen aber auf älteren Versionen auf, die mit älteren Programmierumgebungen erstellt wurden. Später mit einer neuen Programmierumgebung eine stärkere Parallellisierung in eine alte Software zu bringen ist extrem aufwändig. So tiefgreifende Veränderungen benötigen Anpassungen an allen möglichen Programmteilen, von denen dann wieder die nächsten abhängig sind.

Wie weit es überhaupt schon Programmierumgebungen gibt, mit denen man VR sinnvoll paralellisieren kann, ist mir nicht bekannt. Für die meisten Entwickler ist VR eine hübsche Option, die von ein paar Fans genutzt wird. Darum steht es auf der Prioritätenliste meist recht weit unten nach all den Verbesserungen die man für die grosse Masse der Gamer verwirklichen möchte.

Bei AMD reicht wohl eine R9 390 für LiquidVR.

Ich habe die Tage mal den VR Test von Steam laufen lassen: https://abload.de/img/steamvrtest_stocknpj8n.jpg
 

Bei AMD reicht wohl eine R9 390 für LiquidVR.

Ich habe die Tage mal den VR Test von Steam laufen lassen: https://abload.de/img/steamvrtest_stocknpj8n.jpg
Der Steam VR Test ist... wie sage ich es mal höflich... schon etwas überholt. Der stammt noch von dem ersten "VR-Ready" Tool, welches schon bei einer GTX 970 auf grün sprang. Ich behaupte mal, ohne dafür natürlich einen Beleg zu haben, als Grundlage dient da noch die Mindestantforderung der HTC Vive von 2015/2016. Schlimm ist das nicht, da sehr viele VR Games der letzten Jahre diese Mindestanforderungen als Maßstab genutzt haben. D.h. Halflife Alyx läuft heutzutage auch auf Einsteigerkarten... mit der Auflösung der HTC Vive. Auch auf einer Vive Pro, oder Valve Index, etc..., läuft es noch sehr OK. Die "neuen" HMDs mit sehr hochauflösenden Displays, wurden da nicht berücksichtigt. Valve meinte dazu mal, dass eine höhere Auflösung als die der Index nicht gewünscht sei, da zu performancehungrig und daher schlecht für die möglichst weiter Verbreitung von VR. Stattdessen solle man lieber andere Baustellen angehen. Das war auch meine Meinung, bis ich mal die Vergeleichsbilder bei MRTV gesehen habe. ;-)
Leider sind die wirklich großen VR-Spiele auch oft die wirklich teuren und somit meist nicht exklusiv für VR entworfen. So gut programmiert/optimiert wie Halflife Alyx sind, behaupte ich mal, kaum andere umfangreiche Spiele für VR.

Lange Rede, kurzer Sinn: Durch die neue Hardware, welche jetzt in den Köpfen der Fans einen neuen Standard gesetzt hat, und wenig optimierte Spiele, ist die Messlatte mittlerweile deutlich höher gerutscht; vor Allem bei Simulationen. Den absoluten Großteil der sonstigen VR-Experiences und Spielchen, konnte ich auch auf meiner alten 980ti völlig problemlos spielen.
 
Der Steam VR Test ist... wie sage ich es mal höflich... schon etwas überholt. Der stammt noch von dem ersten "VR-Ready" Tool, welches schon bei einer GTX 970 auf grün sprang. Ich behaupte mal, ohne dafür natürlich einen Beleg zu haben, als Grundlage dient da noch die Mindestantforderung der HTC Vive von 2015/2016. Schlimm ist das nicht, da sehr viele VR Games der letzten Jahre diese Mindestanforderungen als Maßstab genutzt haben. D.h. Halflife Alyx läuft heutzutage auch auf Einsteigerkarten... mit der Auflösung der HTC Vive. Auch auf einer Vive Pro, oder Valve Index, etc..., läuft es noch sehr OK. Die "neuen" HMDs mit sehr hochauflösenden Displays, wurden da nicht berücksichtigt. Valve meinte dazu mal, dass eine höhere Auflösung als die der Index nicht gewünscht sei, da zu performancehungrig und daher schlecht für die möglichst weiter Verbreitung von VR. Stattdessen solle man lieber andere Baustellen angehen. Das war auch meine Meinung, bis ich mal die Vergeleichsbilder bei MRTV gesehen habe. ;-)
Leider sind die wirklich großen VR-Spiele auch oft die wirklich teuren und somit meist nicht exklusiv für VR entworfen. So gut programmiert/optimiert wie Halflife Alyx sind, behaupte ich mal, kaum andere umfangreiche Spiele für VR.

Lange Rede, kurzer Sinn: Durch die neue Hardware, welche jetzt in den Köpfen der Fans einen neuen Standard gesetzt hat, und wenig optimierte Spiele, ist die Messlatte mittlerweile deutlich höher gerutscht; vor Allem bei Simulationen. Den absoluten Großteil der sonstigen VR-Experiences und Spielchen, konnte ich auch auf meiner alten 980ti völlig problemlos spielen.

Da hat Steam auch Vollkommen recht, höhere Auflösungen sind zu Rechenaufwendig.
Es sei denn man hat die Bandbreite von HBM2 VRAM.

Hier nochmal LiquidVR Zitiert:

The LiquidVR™ run-time is automatically installed by the current AMD drivers. All that is needed for usage in an application is the LiquidVR.h header file, which is included in the LiquidVR™ SDK on GitHub. Download the White Paper to read a quick start guide which describes how to integrate LiquidVR™ into an application.

Es lääst sich Grundsätzlich in jede Applikation integrieren welche die APIs DX11, DX12 oder Vulkan nutzen.
Mit allen Vorteilen der Multi-GPU Technik.

;)
 
Da hat Steam auch Vollkommen recht, höhere Auflösungen sind zu Rechenaufwendig.
Es sei denn man hat die Bandbreite von HBM2 VRAM.

Hier nochmal LiquidVR Zitiert:



Es lääst sich Grundsätzlich in jede Applikation integrieren welche die APIs DX11, DX12 oder Vulkan nutzen.
Mit allen Vorteilen der Multi-GPU Technik.

;)
Gut, dass Du mich da mit der Nase draufstößt, ich bin erst seit etwa einer Woche AMD-Grafikkartenbesitzer und habe mich mit dem Begriff "LiquidVR" noch nicht wirklich beschäftigt. Ich hätte Deinen Post besser lesen sollen. Dachte es ging allgemein um den Steam VR-Test.
Mit der Auflösung gebe ich Dir Recht. Sieht zwar auf Screenshots klasse aus, aber wirklich "nötig" ist die nicht und der Kosten/Nutzen Aufwand ist sehr unausgewogen. Auch bei meiner Index kann ich so gut wie kein Fliegengitter mehr erkennen, und so viel schlechter schneidet die bei den Vergleichsbildern auch nicht ab. Da schlägt bei mir hauptsächlich der "Will haben"-Faktor durch. Da Foveated Rendering ja offensichtlich doch eine größere technische Herausforderung darstellt, als wir noch vor 5 Jahren dachten, geht die hohe Auflösung voll zu Lasten der PC-Performance, und solange ich VR nicht mit jedem Mittelklasse-Laptop betreiben kann, wird es auch immer ein Nischenprodukt bleiben. Oder wir stagnieren bei technisch anspruchsloseren Spielen und/oder Stand-Alone, was der Sache IMHO auch nicht hilfreich ist.
Ich fürchte allerdings, die Reverb G2 Auflösung hat sich bereits als neuer Standard in den Köpfen der Kunden durchgesetzt, da muss sich jetzt jedes neue HMD dran messen lassen.
 
Oben Unten