AW: Nvidia zeigt Minecraft RTX erneut und kündigt sechs weitere Spiele mit Raytracing an
Durch schlaue Köpfe ist es den Entwicklern möglich Dinge zu zaubern, die sich bezüglich programmierbarer Shader beim Entlassen in die Wildnis niemand hätte träumen lassen.
Lasst die Entwickler halt mal noch ein wenig Erfahrung sammeln im Hybriden Ansatz, der da ja lauten sollte, jeder Strahl, der nicht verschossen werden muss, ist ein guter Strahl, da anderweitig dann Qualität hinzugewonnen werden kann.
RTRT steht am Anfang... -und funktioniert dafür entgegen vieler anderer Techniken schon wirklich gut in einigen Teilbereichen.
Das war aber nie das Thema.
Das Thema ist, dass man durch die spezialisierten und asynchron arbeitenden Einheiten einfach deutlich Geschwindigkeit rausholen kann.
nvidia schlüsselt das ja selbst transparent schön auf, was in der Praxis mit einem Frame passiert (einmal pascal, dann turing, dann turing inkl. RTX):
https://www.nvidia.com/content/dam/...eforce-rtx-gtx-dxr-one-metro-exodus-frame.png
Das Beispiel im Link ist übrigens kein Marketingmist oder geschönt (wie ich es erst einmal vermutet hatte)- Ich habe das mittels nsight nachgeprüft und die Grafen entsprechen der Wahrheit. - Kann also auch jeder selbst nachprüfen.
Bei Voxeln musst du mit Gradienten an Präzision/Fehlern je nach Voxelauflösung leben.
nvidia sind diejenigen, die sich wie die anderen Hersteller auch diesem Standard unterwerfen.
Wie das ganze dann unter der Haube genannt wird, ob RTX oder bei AMD dann Radeon Rays oder was weiss ich auch immer, macht dort keinen Unterschied.
Wenn man die Patente von AMD in Sachen RT ansieht, dann werden die zwar auch einen hardwarebeschleunigten Weg gehen, der aber wiederum einen leicht anderen Ansatz verfolgt.
Der Treiber wird dann dafür sorgen, dass die DXR Aufrufe richtig von der Karte verarbeitet werden können.
Aber dafür ist eine Weiterentwicklung ja da. Und wenn man nicht mal irgeneinen Weg einschlägt und das in die freie Wildbahn entlässt (wie jetzt bei RT), dann kann sich da einfach nichts entwickeln.
Allein durch Programmiertechnik ist sowas heute auf einem C64 möglich.
YouTube
Da hätte zu seiner Blütezeit keiner auch nur einen Gedanken drauf verschwendet, etwas ähnliches zu versuchen. Das Wissen, die Technik und die Optimierungen waren einfach nicht vorhanden.
Ansonsten ein sehr schöner Beitrag, der ein Wenig von den Bemühungen zeigt, die hier aufgewandt werden um diversen Problemen aus dem Weg zu gehen und der zeigt, dass wir noch ziemlich am Anfang der Entwicklung stehen.
In diesem Sinne, noch ein atmosphärischer Screenshot von dem, was RT ganz unaufgeregt und unspektakulär beiträgt:
https://static.fore.4pcdn.de/premium/Screenshots/59/3b/92603183-vollbild.jpg
LG
Zero
Aber das ist es doch grundsätzlich immer, wenn man eine Technik mal in die Freiheit entlassen hat. Schau Dir mal an, wie sich die Programmierung in Sachen Engine und Shader geändert hat. Der vermehrte Wandel zum stochastischem Rendern.Das ist aber nicht Nvidia zu verdanken - sondern den Spieleentwicklern.
Durch schlaue Köpfe ist es den Entwicklern möglich Dinge zu zaubern, die sich bezüglich programmierbarer Shader beim Entlassen in die Wildnis niemand hätte träumen lassen.
Lasst die Entwickler halt mal noch ein wenig Erfahrung sammeln im Hybriden Ansatz, der da ja lauten sollte, jeder Strahl, der nicht verschossen werden muss, ist ein guter Strahl, da anderweitig dann Qualität hinzugewonnen werden kann.
RTRT steht am Anfang... -und funktioniert dafür entgegen vieler anderer Techniken schon wirklich gut in einigen Teilbereichen.
RT ist dann rekursiv, wenn es nicht der physikalischen Marschrichtung der Photonen richtung Auge entspricht. Sobald also irgendetwas von der virtuellen Kamera aus abgeschossen wird, ist es bereits rekursiv. Wobei da auch eine Nachschärfung der Definition helfen kann.Metro ist ein gutes Bsp. Und nein - es ist in dem Fall kein rekursives RT in Echtzeit.
Die Next- Gen- Konsolen besitzen aber in Hardware gegossene Beschleunigungseinheiten. Zudem stimmt das - Auch das BVH- Traversal lässt sich per Compute lösen. Macht ja nvidia unter anderem dadurch, dass sie RT auch für die non RTX- Karten freigegeben haben. Somit wäre auch widerlegt, dass nvidias Raytracing proprietär etwas mit deren RT Einheiten zu tun hätte (wird ihnen immer wieder unterstellt).Die Engine braucht also nicht zwingend dedizierte Rechenkerne was Absicht war - weil sie hauptsächlich auf Next-Gen-Konsolen ausgelegt wurde und genau das ist die Zukunft.
Das war aber nie das Thema.
Das Thema ist, dass man durch die spezialisierten und asynchron arbeitenden Einheiten einfach deutlich Geschwindigkeit rausholen kann.
nvidia schlüsselt das ja selbst transparent schön auf, was in der Praxis mit einem Frame passiert (einmal pascal, dann turing, dann turing inkl. RTX):
https://www.nvidia.com/content/dam/...eforce-rtx-gtx-dxr-one-metro-exodus-frame.png
Das Beispiel im Link ist übrigens kein Marketingmist oder geschönt (wie ich es erst einmal vermutet hatte)- Ich habe das mittels nsight nachgeprüft und die Grafen entsprechen der Wahrheit. - Kann also auch jeder selbst nachprüfen.
Genau so ist es - Ohne diese halbe Wahrheit wäre es aber nicht möglich (und das unterscheidet das Verfahren der SVxGI der Cryengine), in entsprechender Geschwindigkeit Schnittpunkte mit hoher Präzision abzutasten.Also ist Turings Architektur und dessen dedizierte RT Rechenkerne für Kreuzungstest's nur die halbe Wahrheit - was die Effizienz von RTX angeht und Entwickler wollen vor allem vom Effizienzgewinn in Zeit und Arbeitswand profitieren - der auf directX12-Hardware auch unter DXR möglich ist.
Bei Voxeln musst du mit Gradienten an Präzision/Fehlern je nach Voxelauflösung leben.
Umgekehrt wird ein Schuh draus. Deshalb wurde zum Beispiel mit DXR ein Standard mit allen großen Herstellern an Bord geschaffen, der die Marschrichtung vorgibt und die Kompatibilität sicherstellen soll.Den Entwicklern ist wichtig das sie auf LowLevel-Ressourcen frei zugreifen können - damit man das Optimum herausholen kann. Nvidia ist dabei nur wichtig das ihr eigener Ansatz unterstützt wird.
nvidia sind diejenigen, die sich wie die anderen Hersteller auch diesem Standard unterwerfen.
Wie das ganze dann unter der Haube genannt wird, ob RTX oder bei AMD dann Radeon Rays oder was weiss ich auch immer, macht dort keinen Unterschied.
Wenn man die Patente von AMD in Sachen RT ansieht, dann werden die zwar auch einen hardwarebeschleunigten Weg gehen, der aber wiederum einen leicht anderen Ansatz verfolgt.
Der Treiber wird dann dafür sorgen, dass die DXR Aufrufe richtig von der Karte verarbeitet werden können.
Genau- Wer sollte denn auch in der Wirtschaft etwas verschenken wollen?Die machen für andere keinen Finger krum. Offene Standards sind denen ein Fremdwort - wenn nicht sogar ein Dorn im Auge. Damit läßt sich kein Gewinn generieren.
Selbes Spiel wie bei den Shadern/Rastern- Da recyclest Du ja auch so viele Daten, wie nur möglich fürs Folgeframe und versuchst durch intelligente Algorithmen nur das notwendigste an Kostenintensiven Berechnungen durchzuführen.Im DLC hat 4A das Verfahren optimiert und konnte so allein die Latenzen für RT - von 6-8 ms pro Frame auf niedrigere Werte drücken. In so einem Schlauchlevel wie dunklen Gängen - fällt copy&paste der Beschleunigungsstrukturen und Sphärendaten weniger auf. Siehe zgl. Lightprobes.
Aber dafür ist eine Weiterentwicklung ja da. Und wenn man nicht mal irgeneinen Weg einschlägt und das in die freie Wildbahn entlässt (wie jetzt bei RT), dann kann sich da einfach nichts entwickeln.
Allein durch Programmiertechnik ist sowas heute auf einem C64 möglich.
YouTube
Da hätte zu seiner Blütezeit keiner auch nur einen Gedanken drauf verschwendet, etwas ähnliches zu versuchen. Das Wissen, die Technik und die Optimierungen waren einfach nicht vorhanden.
Ansonsten ein sehr schöner Beitrag, der ein Wenig von den Bemühungen zeigt, die hier aufgewandt werden um diversen Problemen aus dem Weg zu gehen und der zeigt, dass wir noch ziemlich am Anfang der Entwicklung stehen.
In diesem Sinne, noch ein atmosphärischer Screenshot von dem, was RT ganz unaufgeregt und unspektakulär beiträgt:
https://static.fore.4pcdn.de/premium/Screenshots/59/3b/92603183-vollbild.jpg
LG
Zero
Zuletzt bearbeitet:


