Du schreibst wirres Zeug; etwas mehr Fokus würde dem Verständnis deines Posts zugute kommen.
Trotzdem enthält diese Extension (SDK) den llv Loader und bestimmte Layer, das Windows auch unterstützt wird. Sie ist somit die Schnittstelle und nicht dx.
Ändert nichts daran, dass Vulkan selbst derzeit keine Raytracing-Unterstützung bietet. nVidia kann diese Funktionalität derzeit nur aufgrund der für Erweiterungen offenen Struktur von Vulkan selbst beisteuern und genau das machen sie hier mit VK_NV_ray_tracing.
Was sollte also dx mit proprietärer Hardwareunterstützung zu tun haben [...]
Das weiß ich nicht, das hast Du geschrieben. DirectX geht hier den genau entgegengesetzten Weg und stellt ein von der Hardware abstrahierendes API zur Verfügung. In Bezug auf Raytracing hat es ein paar Datenstrukturen und API-Funktionsaufrufe definiert, die die Treiberentwickler von nVidia/AMD/Intel erfüllen müssen, sodass deren Hardware mit DXR zusammenarbeitet.
Nur weil Microsoft keine offizielle Vulkan-API-Unterstützung liefert, heißt das nicht das es keinerlei Hardware gäbe die es könnte. Es gibt sie, nur nicht unter Windows.
Noch kryptischer geht es nicht? a) Was hat Microsoft mit Vulkan zu tun? Das ist so als wenn man sagen würde "Nur weil Mercedes keine BMWs baut ...". b) Und was haben 3D-APIs wie Vulkan oder DirectX mit konkreter Hardware zu tun? Auch relativ wenig, denn auch Vulkan verfolgt wie DirectX und OpenGL das Ziel von der Hardware zu abstrahieren. c) Und in welchem Kontext sollte jetzt irgendwelche Hardware stehen, die was können soll oder auch nicht? Weder Microsoft noch die Khronos Group fertigen Hardware.
Wie ich schon schrieb, selbst mein i486er konnte Raytracing, jedoch ist das für das was hier im PCGH-Forum wohl die meisten interessieren dürfte, irrelevant, da es hier um (hybrides) Echtzeitraytracing geht und da kommt man erst mit dedizierter Hardware (sinnvoll) hin. Insbesondere, wenn man sich das Haupteinsatzgebiet Gaming ansieht, das unvorteilhafterweise das Ganze auch noch gleich mit hohen Bildraten und Auflösungen kombiniert, sodass einmal mehr reguläre Hardware (wie bspw. eine einfache Berechnungn über die Shader-Prozessoren) nur zu ungenügenden Ergebnissen führen. *)
Auf einem Mac lief doch Radeon Ray mit einer W9000.
Was hat das mit PCGH und Games zu tun, oder mit Windows und DirectX? Wie schon zuvor gesagt, du kannst auch Raytracing mittels einer alten Kepler-GPU via CUDA berechnen lassen, nur hat das nichts mit Echtzeitraytracing zu tun.
Abseits dessen weist AMD sein Radeon Rays SDK nur als für Windows und Linux verfügbar aus.
*) Entsprechend verwendet man mit der Einführung der Technologie auch keine reinen Raytracing-Engines sondern ein Hybridrenderingverfahren, denn für vollständiges Raytracing reicht die Rechenleistung noch längst nicht aus und daran wird sich auch in den kommenden Jahren nichts ändern.
Pascal bricht nicht umsonst ein, sobald zu viel Raytracing-Rechenlast im Sichtbereich anfällt (gut zu testen in BF5) wohingegen Metro Exodus mit seiner GI-Implementation eine gleichmäßig hohe Raytracing-Last pro Frame erzeugt, sodass das Spiel hier auf Pascal in FullHD mit aktiviertem Raytracing grundsätzlich unspielbar ist.
Die im März'18 vorgestellte Star Wars Elevator-Demo lieft nicht umsonst auf einer DGX mit vier Volta-Karten, da hier noch die regulären Shader herhalten mussten, jedoch kann man ein 20.000+ US$-System nicht wirklich als mainstreamtauglich bezeichnen.
Ergänzend dazu der Hinweis, dass viele fälschlicherweise immer gerne dazu neigen nVidia's "RTX"-Begriff mit Raytracing gleichzusetzen, was schlichtweg falsch ist. Ersteres ist ein Produktname für nVidia's LowLevel-Raytracing-Softwarestack, der auch für die Neubenennung der aktuellen Grafikkartengeneration ausgeschlachtet wurde, letzteres ist ein bereits im letzten Jahrtausend entwickeltes mathematisches Verfahren zur Berechnung dreidimensionaler Bilder. (Und genaugenommen kann man den Begriff sogar auch nur als Oberbegriff für mittlerweile eine Vielzahl differenzierter, noch viel komplexerer Methoden für noch realistischere, physikalisch korrekte Bilder verstehen.)
Schlussendlich ist das, was nVidia derzeit als "RTX" vermarktet, nur eine mögliche, technisch Implementation. AMD wird in diesem Zuge seine RDNA2-Architektur in den Markt bringen, die die notwendigen Funktionalitäten anscheinend etwas anders als nVidia implementieren wird und wer weiß, welche Art der Implementation Intel sich vorbehält. Solange sich aber bspw. alle an die zusammen mit Microsoft definierten API-Spezifikationen halten, werden diese unterschiedlichen GPUs alle Raytracing unter DirectX 12 bieten.
Der Vollständigkeit halber: Natürlich brauch man nicht unbedingt eine Turing-GPU für Raytracing, denn am Ende gibt es hier nur zwei einfache Operationen die ausgeführt und auch in Hardware unterstützt werden: a) Die Intersection-Berechnung alias Strahlverfolgung/Schnittberechnung und das Traversieren der Szenen-Datenstruktur (BVH), d. h. man muss in einer großen Datenmenge von Polygonen/Dreiecken möglichst schnell diejenigen finden, die für den Intersection-Test sinnvoll infrage kommen.
Entsprechende Verarbeitungsschritte kann man bei Bedarf auch komplett in Software erledigen. Beispielsweise das DX12 SDK enthält einen kompletten Software-/CPU-basierten Renderpfad für das Debugging von Raytracing, der aber natürlich extreeem langsam rendert.
Intels Embree Raytracing-Kernels sind da weitaus leistungsfähiger, die eine vollständige Raytracing-Engine über viele CPU-Kerne verteilen und selbst AVX-512 für ein beträchtliches Leistungsplus ausnutzen können. Die Leistung ist immens taugt aber immer noch nur für bspw. einen interaktiven Viewport-Renderer für das Modelling, nicht jedoch für Games.
Der nächstschnellere Weg ist die Ausnutzung der universellen Rechenleistung der GPUs über die Shader-Prozessoren, die seit Jahren unentwegt zunimmt. nVidia's RTX-Entwicklung begann auf diese Weise, indem man den RTX-Softwarestack entwickelte, der die Raytracing-basierten Funktionsaufrufe bündelte und hinten heraus auf die Shader-Prozessoren der Volta-GPUs verteilte. **)
Entsprechenes sah man dann auch Anfang 2019, als nVidia die Verwendung der Shader-Prozessoren für Raytracing in die Pascal-Treiber rückportierte, sodass auch Pascal nun als RTX-fähige GPU genutzt werden kann, natürlich mit geringerer Leistung, aber immerhin.
Und einen ähnlichen Weg geht Crytek mit ihrer neuen Engine-Version 5.6/5.7 die u. a. ebenfalls die universell verfügbaren Shader für einige Raytracing-Effekte bemühen, wahrs. in Verbindung mit FP16-Berechnungen. (Hier wird es zweifelsfrei aber auch einen Upgrade-Pfad für eine entsprechende Hardwareunterstützung geben, so anscheinend über DX12 und ggf. auch Vulkan.)
Unterm Strich werden umfangreiche, Raytracing-basierte Berechnungen jedoch erst sinnvoll mittels dedizierter Hardware möglich sein. Das sieht man sowohl beim Vergleich Volta zu Turing in Games als auch in der aktuellen Blender-Entwicklung, die gerade als zusätzliche Alternative zu CUDA nVidia's OptiX in Verbindung mit den "RT-Cores" implementiert. Die letztgenannte Variante erreicht teilweise bis zur doppelten Performance der CUDA-Variante. Und wenn man jetzt noch den Schrei vieler leidender Gamer berücksichtigt, die ohne 4K nicht mehr leben können, kann man sich leicht ausmalen, dass Emulationen (bzw. Berechnungen über general purpose Funktionseinheiten) bestenfalls nur eine kurze Übergangslösung darstellen können.
**) In Verbindung mit der demonstrierten Star Wars Elevator Demo verteilt auf die über 20.400 Shader-Prozessoren der vier Volta-GPUs in der DGX. In Verbindung mit Turing hat man die betreffende RTX-Funktionalität herausgelöst und in den Turing-Treiber übertragen und den Stack so umgeschrieben, dass er statt der Shader-Prozessoren die hierbei leistungsfähigeren "RT-Cores" von Turing verwendet.