AW: AMD Radeon: "Big Navi" angeblich in Südkorea gesichtet
Kann sein, dass ich mit meiner Idee ...
Du willst zusätzliche, spezialisierte Funktionalitäten unterbringen und so etwas gibt es nun mal nicht "für Lau". Diese zusätzliche Funktionalität benötigt zusätzliche Logikschaltungen, ergo zusätzliche Transistoren auf dem Die also zusätzliche Chipfläche, so oder so.
Für die BVH brauchst Du zudem eine angepasste Cachestruktur, da das jeweils erneute Traversieren derselbigen für jeden einzelnen Strahl sehr mühselig und speicherbandbreitenlastig wird. Und für die Intersection-Berechnung brauchst Du Fließkommaleistung. Zudem möchtest Du die sehr aufwändigen Raytracing-Berechnungen möglichst parallel zu den sonstigen Tasks der GPU berechnen lassen, weil Du ansonsten noch unverhältnismäßig mehr Leistung und damit Transistorfläche für die Funktionalität bereitstellen müsstest, um Leistung xy zu erreichen.
Abgesehen davon sind nVidia's "RT-Cores" Bestandteil der CUDA-Kerne bzw. des Shader-Blocks. Schlussendlich hat nVidia aber nach wie vor nicht offen gelegt, wie genau diese implementiert sind und es ist durchaus möglich, dass es DEN "RT-Core" als eine eigenständige, in sich abgeschlossene Funktionseinheit gar nicht gibt, sondern dass dieser eher einen Marketing-Begriff darstellt unter dem nVidia alle architektonischen Anpassungen zusammenfasst, die den Turing-Karten die Raytracing-Berechnungen ermöglichen. (Beispielsweise ist unklar, ob diese "RT-Cores" über eigene FP-Einheiten verfügen oder ob die FP-Einheiten der SMs mitverwendet werden. Klar ist jedenfalls, dass diese "RT-Cores" in einigen Fällen nicht parallel zu den SMs arbeiten können, d. h. es scheint geteilte Ressourcen zu geben. *)
Beispielsweise von AMD gibt es ein Patent, dass die Raytracing-Berechnungen in die TMUs verlagert und hier gleichzeitig in effizienter Art deren große Caches mitnutzen kann. Vielleicht handelt es sich dabei um die Art der Implementation, die AMD bei den Konsolen-SoCs vorgenommen hat? (Denn AMD hat schon längst eine Raytracing-HW-Funktionalität implementiert.) Man wird abwarten müssen.
Schlussendlich muss jeder Hersteller anhand seiner Architektur selbst entscheiden wie und wo diese Funktionalität am besten unterzubringen ist. Für den Anwender ist das irrelevant, da die Programmierung über ein einheitliches API erfolgt, wie bspw. DXR (als Bestandteil von DX12).
Nur für (auch nur nahezu) Lau gibt es nun einmal keine Mehrleistung (selbst SMT steigert die Chipkomplexität und erhöht die Transistorzahl/Chipfläche etwas). Am Ende bleiben nur zwei Wege: a) das bestehende Design muss schneller rechnen, also höher takten oder b) es müssen mehr parallel arbeitende Funktionseinheiten her (und selbstredend gibt es auch eine Mischung aus beidem). Und in beiden Fällen muss auch noch das Speichersubsystem mitkommen, was derzeit schon ein beträchtliches Problem darstellt. a) ist weitaus schwieriger zu realisieren, da man hier schnell an aktuelle Fertigungsgrenzen stößt, b) ist die besser umsetzbare Variante, also noch breitere Designs mit noch mehr Durchsatz pro Taktzyklus, bringt jedoch seine ganz eigenen Probleme mit, die bspw. auch mit MultiChipDesigns nicht einfach zu lösen sind.
(Gerüchten zufolge geht Intel aber letzten Endes mit Xe den MCM-Weg inkl. Foveros. Es bleibt spannend.)
*) Interessantes Detail am Rande: Erst Turing kann effektiv FP16 (Half Precision) berechnen und verwendet hierfür die Tensor Cores und nicht etwa die FP32-Einheiten der SMs. (AMD berechnet FP16 dagegen schon auf Vega 10 mit doppeltem Durchsatz, während Pascal dies nur zu Kompatibilitätszwecken unterstützte.)
Insofern hat AMDs Treiber/Software-Raytracing zumindest die Möglichkeit (relativ gesehen) etwas schneller zu sein als RTX auf Pascal, wenn hier FP16 sinnvoll verwendet werden kann, was davon abhängt, ob die Präzision ausreichend ist und ob die FP-Berechnungen einen ausreichend hohen Anteil an der Gesamtoperation haben., d. h. Vega und Navi könnten durchaus etwas vorzeigen, wenn auch natürlich grundlegend langsamer als HW-beschleunigt. Jedoch zeigte bereits Crytek's Neon Noir Demo, dass man das durchaus gewinnbringend einsetzen kann. Auf dem PC wird AMD aber das Treiber/Software-Raytracing zweifelsfrei als Übergangslösung verwenden, bis man eine echte Hardwareunterstützung auf den PC bringen kann (darf).
