Notiz RDNA 2 Technology Demo: Hangar 21 mit DXR erscheint am 19. November

Die Vulkan Portierung mit Path Tracing existierte vorher. Darauf aufbauend hat man Raytracing hinzugefügt. Wieso hätten sie das ganze auf DX portieren sollen? Das wäre völlig sinnlos. abgesehen davon ist alles OSS und Dokumentiert. AMD hätte ihre Karten bzw. deren Vulkan API auch kompatibel machen können.
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_NV_ray_tracing.html
AMD hat hier sogar mit contributed.

Wadenbeisser schrieb:
Zum Thema Minecraft RTX @ Radeon, hast du mal nen Link zu entsprechenden Tests? Ich habe keine gefunden.
1605871281333.png


(Quelle: https://www.pcgameshardware.de/Rade...6000-Raytracing-Kompatibilitaet-Test-1362034/)
 
  • Gefällt mir
Reaktionen: Wadenbeisser
Beispielsweise weil es um GPU Beschleunigung und nicht um Berechnung über die CPU geht, des weiteren nutzte das ursprüngliche Spiel eine uralte Variante der OpenCL API und ich glaube kaum das die ganzen anderen Neuerungen der asbach uralt Engine beigebracht wurden. Tauschst du die Engine aus oder mußt sie massiv umschreiben dann kannst du fast das gesammte Spiel nochmal neu aufbauen und die einfache Portierung ist so oder so vom Tisch.

Im übrigen habe ich gerade bei Golem Testergebnisse für Minecraft RTX gefunden, scheint also prinzipiell zu laufen.
 
Nicht zu vergessen, dass Quake 2 RTX auch unter Linux läuft. Das wäre mit DXR sicherlich nicht so einfach - zumindest habe ich noch nichts davon gehört, dass Wine bzw. Valves Proton schon so weit sind.
 
  • Gefällt mir
Reaktionen: foo_1337
Ja das hatte ich in #95 und #99 schon vergeblich versucht zu sagen :)

Spaß machen wird Minecraft RTX jedoch auf den AMD Karten, bis ein DLSS Äquivalent kommt, nicht:

1605874677818.png
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: benneq
Also ich freu mich auch schon total auf solche Spiele wie Minecraft RTX. Da möchte ich selbstverständlich nicht mit wenigen fps herumkrebsen, während ich mit NVidia die 3 bis 8 fache Leistung herausbekomme. Von daher verstehe ich auch solche Aussagen in den Testberichten nicht, wenn es heißt: "Nvidia kann in diesem Duell nur noch mit Raytracing sowie DLSS punkten."

Das als "nur" zu bezeichnen ist schon etwas kurzsichtig.
 
Zuletzt bearbeitet:
Wadenbeisser schrieb:
Im Übrigen habe ich gerade bei Golem Testergebnisse für Minecraft RTX gefunden, scheint also prinzipiell zu laufen.
Ja, ist schlicht DXR - nur Quake 2 RTX und Wolfenstein Youngblood nutzen Nvidias proprietäre Vulkan Extension ... da muss halt die Khronos Version rein gepatcht werden.
 
y33H@ schrieb:
Nvidias proprietäre Vulkan Extension ...
Bloß weil Extensions von bestimmten Entwicklern in Vulkan eingebracht wurden sind die aber noch lange nicht proprietär. Das ist ein völlig normaler Prozess, dass die Extensions so benannt werden bis die Funktionen eventuell oder eventuell auch nicht in Vulkan übernommen werden.

Das heißt aber nicht, dass bis dahin die Extensions nicht auch von anderen Herstellern genutzt oder weiterentwickelt werden können. Du siehst ja, dass an VK_NV_ray_tracing auch Entwickler von AMD und Intel arbeiten.
 
  • Gefällt mir
Reaktionen: foo_1337
Naja, wenn AMD wollte, könnten sie. Daher ist das nicht wirklich proprietär. Aber auch nachvollziehbar, dass sie da jetzt keine Aufwände mehr reinstecken wollen, da es ja mittlerweile einen Standard für RT in Vulkan gibt, welcher in den letzten Zügen ist. Dieser Standard wurde Anfang 2018 durch eine Task Force* begonnen und ist bis heute eben nicht ganz fertig. Irgendwie verständlich, dass Nvidia da kurzerhand was eigenes (zu dem eben auch Intel und AMD Contributed haben) gemacht hat, oder?

*Mitglieder der Task Force:
Daniel Koch, NVIDIA, Vulkan Ray Tracing TSG Chair
Tobias Hector, AMD,
Joshua Barczak, Intel
Eric Werness, NVIDIA

Ich glaube nicht, dass man nvidia hier für fehlende Offenheit blamen kann, insbesondere wenn man sich anschaut, von welchen der 3 Firmen die meisten commits kamen ;)
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: noxon
y33H@ schrieb:
Ich verstehe unter proprietär in diesem Fall, dass die Extension (bisher) nur mit Nvidia Karten läuft.
Dafür ist eine API ja da. Sie ist hardwareunabhängig. Die Treiber sind anschließend dafür verantwortlich die API Aufrufe auf der entsprechenden Hardware umzusetzen. Bei Nvidia auf die RT Kerne und bei AMD auf den externen Texturprozessor und die Shaderkerne.
In der Vulkan Extension stecken selbst aber keine Aufrufe die spezielle Nvidia Hardware voraussetzen. Das sind alles ganz allgemeine Aufrufe, so wie du sie auch in DXR vorfindest.

BTW: Hier zeigt sich übrigens mal wieder der Vorteil von DirectX gegenüber Vulkan und warum ich das als Entwickler DirectX mal wieder den Vorzug geben würde.
Die DXR Doku ist mal wieder tausend mal besser als der Mist, den Khronos da bereitstellt. Mit DXR könnte ich jetzt sofort was anfangen und ich verstehe auch sofort was los ist. Die Vulkan Doku andererseits habe ich immer noch nicht verstanden, obwohl ich mich schon doppelt so lange damit befasst habe.

So viel zur Frage. Warum nutzen Entwickler eigentlich immer DirectX obwohl Vulkan doch plattformübergreifend ist.
 
Zuletzt bearbeitet:
Äpfel, Birnen und so. Du verlinkst eine Manpage und vergleichst das mit einer richtigen Doku. Soll ich dir die Vulkan Doku zu Raytracing raussuchen?
 
noxon schrieb:
Bei Nvidia auf die RT Kerne und bei AMD auf den externen Texturprozessor und die Shaderkerne.
Was bitte sind externe Texturprozessoren? AMD hat pro CU einen Ray Accelerator, der macht die Box Intersections und die Triangle Intersection.
 
foo_1337 schrieb:
Äpfel, Birnen und so. Du verlinkst eine Manpage und vergleichst das mit einer richtigen Doku. Soll ich dir die Vulkan Doku zu Raytracing raussuchen?
Ja, das wäre wirklich nett, denn ich kann nichts finden außer der Spec. Eine Spec ist für mich keine Doku.
Das nervt mich genau so an der Java "Doku". Auch da ist die .NET Doku hunter mal besser.

Beachte bitte, dass ich den Link auf die Manpage der Extension mittlerweile durch einen Link auf die gesamte Spec ausgetauscht habe. Das ändert aber nichts an der Tatsache, dass die genau so schlecht dokumentiert ist wie die Manpage. Der Inhalt ist identisch.
Ansonsten hab ich nur noch den absoluten Flickenteppich aus Developerresourcen gefunden aus denen man anscheinend irgendwie schlau werden soll.

y33H@ schrieb:
Was bitte sind externe Texturprozessoren? AMD hat pro CU einen Ray Accelerator, der macht die Box Intersections und die Triangle Intersection.
Ray Accelerator ist nichts anderes als Marketing Speech für den Texturprozessor über den AMD seine RT-Hardwarebeschleunigung implementiert hat.
https://www.freepatentsonline.com/20190197761.pdf
 
Ja, das stimmt - manch einer fabuliert ja Zeug zusammen, du nicht :)
 
Ich verstehe es nach wie vor so, dass die TMUs die Ray/Box-Intersections übernehmen (4 pro Clock pro CU) und der Ray Accelerator die Ray/Triangle-Intersections (1 pro Clock pro CU). Leider sind die aktuellsten Unterlagen von AMD nicht so präzise wie das Patent, wobei letzteres die Sache so beschreibt wie ich.
 
Zurück
Oben