Die Vulkan Extension übergibt ja eben entsprechende RT- Befehle an die Treiberabteilung von AMD.
Ich habe selten so einen Tünüff gelesen. Die
Procedures and Conventions liegen jedem Hersteller als Mitglied der Khronos Group vor (abrufbar, letztlich ist das eine freie Bibliothek), die haben ständig Zugriff und da wird nichts übergeben. Die API Referenzen werden auch nicht auf Github zur Verfügung gestellt, sondern können speziell abgerufen werden und dürfen beliebig erweitert werden. Das KHR Extensions brauch also Anpassungen und das nicht nur beim Renderpass.
Was ist denn daran neu? Nix um ehrlich zu sein. Nvidia setzen doch wie immer auf ihr eigenes Ding (was Vulkan auch erlaubt) und warum sollte AMD eine Optimierung für RTX unterstützen?
Wenn das reiner Shader Betrieb ist, warum ist dann Pascal so langsam und Vega kann es garnicht?
Weil der Treiber Kaka ist! oder es nicht gewollt ist. Wer hätte dann noch Turing oder würde Ampere kaufen, oder RDNA2.
Was Minecraft RTX angeht, verschießt Nvidia zur Simulation (PBR) gezielt Godrays inlusive Irradiance (die Secundärrays werden gezielt durch bestimmte Geometrieanteile geblockt, um die gesamte Raymenge zu minimieren und damit die Renderzeit nicht all zu sehr abfallen zu lassen = ist also absolut auf RTX und damit Nvidia optimiert), wenn AMD das komplette Bild (1Ray pro Pixel) berechnet, braucht man sich also nicht wundern das sie abfallen. In Minecraft wird nicht alles per Rays simuliert. Ist ist also kein Fullsize Pathtracing, da Nvidias Variante Probleme mit der Simulation von Wasser und Nebel (Partikelsimulation) hat. Diese werden rasteriziert.
Das hat rein gar nichts damit zu tun, wie AMD intern (llvl) den In- oder Output berechnen würde, das ginge genauso parallel. Sie optimieren eher auf dXU (DXR1.1).
Der 20.11.2 unterstützt Vulkan RT auf Vega und Vega2, darüber habt ihr doch selbst berichtet.