AW: Raytracing für PC, PS5 und Xbox Series X: AMD sieht gemeinsame Architektur als Vorteil
Für DX12 ist das korrekt, denn dieses wurde als hardwareagnostisches API konzipiert und die jeweilige Hardware passt sich mittels einer entsprechenden Auslegung ihres Treibers daran an um kompatibel zu sein.
Nichts anderes macht auch gerade nVidia mit Turing und Pascal. Erfolgt ein entsprechender DXR-Aufruf in Richtung der Hardware, ergo des Treibers, setzt dieser die Anfrage und Datenstrukturen um. Auf Turing steuert der Treiber hierzu die RT Cores an und kann die Berechnungen entsprechend schneller vornehmen. Auf den größeren Pascal-Karten, auf denen nVidia die Unterstützung ebenfalls freigeschaltet hat, leitet der Treiber die Berechnung über die normalen Shader Prozessoren und muss hier manuell unterstützen, was deutlich langsamer vonstatten geht. DXR ist das am Ende jedoch egal, das zurückgelieferte Ergebnis ist das gleiche, nur dass ersteres deutlich schneller zur Verfügung steht, was sich in signifikant besseren Frametimes niederschlägt.
Entsprechend wird auch AMD für DX12/DXR einen passenden Treiber bereitstellen, der die API-Aufrufe entgegen nimmt und in passender Art auf ihre Hardware weiterleitet, die möglicherweise auf dem Silizium eine völlig andere Implementation nutzt. (Bei AMD werden Raytracing-Berechnungen möglicherweise nahe der oder in den TMUs verarbeitet.)
Für Vulkan trifft das jedoch nicht zu. Auch die aktuellste Version v1.2 vom Januar 2020 unterstützt kein Raytracing. Die Raytracing-Funktionalität kann man hier nur nutzen, indem man die proprietäre Vulkan-Erweiterung von nVdiai verwendet (VK_NV_ray_tracing). Die Khronos Group hat Raytracing auf der Roadmap, sieht eine Implementation jedoch erst für ein späteres Release vor.
Ob AMD hier eine eigene Erweiterung bereitstellen wird, bleibt abzuwarten, wäre aber nur eine temporäre Lösung bis Vulkan selbst Raytracing unterstützen wird und zudem würde es Entwickler nur verschrecken, die dann, wenn sie auf Vulkan setzen wollten, zwei komplett unterschiedliche, proprietäre Erweiterungen unterstützen müssten. Selbst wenn AMD eine solche Erweiterung übergangsweise anbieten würde, würden Entwickler den Mehraufwand voraussichtlich scheuen oder aber im Zweifelsfall eher auf die breitere Installationsbasis setzen, d. h. sich für VK_NV_ray_tracing entscheiden.
Letzten Endes wird alles, was ein Computer macht, softwareseitig umgesetzt, von daher ist die einleitende Aussage unsinnig. Du kannst bspw. AES komplett in Software oder per AES-NI berechnen, aber selbst hochgradig optimierter Code kommt nicht ansatzweise an die hardwareunterstützten Varianten heran, die Faktor 2x bis 3x erreicht und bei parallelisierbaren Entschlüsselungsaufgaben bis zu Faktor 10x erreichen können. Nichts anderes ist auch das Ziel der Raytracing-Hardwareunterstützung in modernen GPUs.
Und natürlich kann eine RX 5700 (XT) auch Raytracing berechnen wie auch alles andere erdenkliche, was man über die Shader Prozessoren berechnen kann, bspw. mittels OpenCL ... man muss sich nur die Mühe machen und das manuell implementieren. Aber ebenso natürlich wird die RTX 2060 Super bzgl. dieser speziellen Aufgabenstellung schneller sein, da ihre Hardware hier eine direkte Unterstützung dieser Operationen bietet, was ein deutliches Leistungsplus gewährt.
Ich denke es wird schon seinen Grund haben, dass Sebastian Vettel nicht auf seinen F1-Boliden verzichtet und stattdessen einfach mit einem Opel Corsa antritt. Mit letzterem wird er zweifelsfrei auch die Ziellinie überqueren, die Frage ist nur wann ...
Unsinn. RTX ist das Raytracing-Backend bei nVidia. Der kompatible Output erfolgt schon jetzt per DirectX Raytracing (DX12) oder per Vulkan (Wolfenstein Youngblood + Quake II RTX). [...]
Für DX12 ist das korrekt, denn dieses wurde als hardwareagnostisches API konzipiert und die jeweilige Hardware passt sich mittels einer entsprechenden Auslegung ihres Treibers daran an um kompatibel zu sein.
Nichts anderes macht auch gerade nVidia mit Turing und Pascal. Erfolgt ein entsprechender DXR-Aufruf in Richtung der Hardware, ergo des Treibers, setzt dieser die Anfrage und Datenstrukturen um. Auf Turing steuert der Treiber hierzu die RT Cores an und kann die Berechnungen entsprechend schneller vornehmen. Auf den größeren Pascal-Karten, auf denen nVidia die Unterstützung ebenfalls freigeschaltet hat, leitet der Treiber die Berechnung über die normalen Shader Prozessoren und muss hier manuell unterstützen, was deutlich langsamer vonstatten geht. DXR ist das am Ende jedoch egal, das zurückgelieferte Ergebnis ist das gleiche, nur dass ersteres deutlich schneller zur Verfügung steht, was sich in signifikant besseren Frametimes niederschlägt.
Entsprechend wird auch AMD für DX12/DXR einen passenden Treiber bereitstellen, der die API-Aufrufe entgegen nimmt und in passender Art auf ihre Hardware weiterleitet, die möglicherweise auf dem Silizium eine völlig andere Implementation nutzt. (Bei AMD werden Raytracing-Berechnungen möglicherweise nahe der oder in den TMUs verarbeitet.)
Für Vulkan trifft das jedoch nicht zu. Auch die aktuellste Version v1.2 vom Januar 2020 unterstützt kein Raytracing. Die Raytracing-Funktionalität kann man hier nur nutzen, indem man die proprietäre Vulkan-Erweiterung von nVdiai verwendet (VK_NV_ray_tracing). Die Khronos Group hat Raytracing auf der Roadmap, sieht eine Implementation jedoch erst für ein späteres Release vor.
Ob AMD hier eine eigene Erweiterung bereitstellen wird, bleibt abzuwarten, wäre aber nur eine temporäre Lösung bis Vulkan selbst Raytracing unterstützen wird und zudem würde es Entwickler nur verschrecken, die dann, wenn sie auf Vulkan setzen wollten, zwei komplett unterschiedliche, proprietäre Erweiterungen unterstützen müssten. Selbst wenn AMD eine solche Erweiterung übergangsweise anbieten würde, würden Entwickler den Mehraufwand voraussichtlich scheuen oder aber im Zweifelsfall eher auf die breitere Installationsbasis setzen, d. h. sich für VK_NV_ray_tracing entscheiden.
RT wird softwarelastig umgesetzt, dafür braucht es keine spezielle Hardware und keine magische RT Architektur auf den Grafikkarten, wer das glaubt ist halt auch bei anderen Sachfragen eher geistig seicht veranlagt.
Meine 2060 super kann RT, obwohl ich das nicht nutze, und so schnell wohl auch nicht brauche. Dann kann das eine 5700 und eine 5700 XT auch schon. Eine Vega 64 mit Sicherheit und eine V2 auch.[...]
Letzten Endes wird alles, was ein Computer macht, softwareseitig umgesetzt, von daher ist die einleitende Aussage unsinnig. Du kannst bspw. AES komplett in Software oder per AES-NI berechnen, aber selbst hochgradig optimierter Code kommt nicht ansatzweise an die hardwareunterstützten Varianten heran, die Faktor 2x bis 3x erreicht und bei parallelisierbaren Entschlüsselungsaufgaben bis zu Faktor 10x erreichen können. Nichts anderes ist auch das Ziel der Raytracing-Hardwareunterstützung in modernen GPUs.
Und natürlich kann eine RX 5700 (XT) auch Raytracing berechnen wie auch alles andere erdenkliche, was man über die Shader Prozessoren berechnen kann, bspw. mittels OpenCL ... man muss sich nur die Mühe machen und das manuell implementieren. Aber ebenso natürlich wird die RTX 2060 Super bzgl. dieser speziellen Aufgabenstellung schneller sein, da ihre Hardware hier eine direkte Unterstützung dieser Operationen bietet, was ein deutliches Leistungsplus gewährt.
Ich denke es wird schon seinen Grund haben, dass Sebastian Vettel nicht auf seinen F1-Boliden verzichtet und stattdessen einfach mit einem Opel Corsa antritt. Mit letzterem wird er zweifelsfrei auch die Ziellinie überqueren, die Frage ist nur wann ...

Siehe im Übrigen Detroid welches auf vergleichbaren Karten wie die PS4 sie nutzt wie Arsch läuft und das in Low UND 900p
und das mit wohlgemerkt vieeel stärkeren CPUs wie sie die PS4 hat. Da läuft gar nix. Nullinger. Die Konsoleneffizienz ist bewiesen. Jetzt hoffen wir beide noch das wirklich HZD für den PC erscheint dann Nagel ich dir die Kiste endgültig zu ...
. Ich dachte die wären bei Vulkan schon bei der vollen hardwareagnostischen RT-API Implementierung angekommen.

