Ja besitzen sie. Aber halt in der normalen CU integriert, sprich im schlimmsten Fall kann man dann nur das eine oder das andere berechnen zur selben Zeit. Da ist nVidia mit den extra RT Kernen schon im Vorteil, denn dort "blockiert" die RT Berechnung nicht die normalen Shadereinheiten.
Ähmm... Nicht wirklich.
Eine CU bei AMD kann aktuell bis zu 2 Threads zur gleichen Zeit aus führen - in der modernen
WGP bei RNDA - sind es wie zu GCN-Zeit 4 Threads!
Dem entsprechend hat AMD auch das Verhältnis CU zu TMU gewählt: 1:4. Auf eine CU kommen 4 TMUs. Sprich eine CU kann 4 Texel oder nun eben 4 "Rays" anfordern.
Auch bei AMD können FP32-Berechnungen, INT32-Berechnungen, RT sowie Texel-Anforderung zur gleichen Zeit stattfinden.
Die Aufgaben der RT-Cores übernehmen die TMUs.
RT-Cores sind -siehe Folien zu der RTX2x00-Serie- vereinfacht gesagt, "Fixed-Function-Units" die einen sehr effizienten Algorithmus abbilden, mit dem man den BVH-Tree durchsucht. Diese Funktionen machen nichts anderes, als den BVH-Tree zu durchforsten. Diese Suche ist sehr aufwändig, weil bei einer komplexen Szene eine Vielzahl an Verknüpfungen durchsucht werden müssen.
AMD erweitert nun ihre TMUs um eine weitere Funktion, nämlich eine "Fixed-Function-Unit", nur dass diese nicht separat ausgeführt, sondern in die TMU eingegossen wird. Die TMU bei AMD kann entweder eine Texturabfrage oder eine BVH-Abfrage beantworten und dessen Wert zurück geben.
Shader sind kleine Programme die aufgerufen werden und dann ihre Berechnungen ausführen, das können FP32, INT32, Texel oder eben RT-Berechnungen sein. Dieser Ablauf im Shader ist SERIELL NICHT PARALLEL! Siehe dazu das vereinfachte Fluss-Diagramm im Turing-Paper.
Im Shader-Programm können aufgrund der seriellen Ausführung - bis auf wenige Ausnahmen - keine voneinander Abhängigen Schritte parallel ausgeführt werden. Hier bedeutet es: Sobald der Shader ein Ergebnis aus dem BVH-Baum braucht um weiter zu rechnen, wartet der Shader bis er das Ergebnis aus dem BVH-Baum hat und rechnet erst dann weiter.
Während der Shader auf sein Ergebnis aus dem RT-Aufruf wartet, wird er als "wartend" markiert und andere Shader auf der CU - nun WGP - können dann die restlichen Vec32, SALUs sowie eben auch TMUs nutzen.
Sprich: Der Shader an sich ist in seinem Programmablauf an die imperativen sowie seriellen Paradigmen gefesselt, die CU selbst nicht!
Die CU/SM berechnet den Effekt, während des Effektes kommt es dann zu einer BVH-Abfrage, diese BVH-Abfrage wird dann an den RT-Core oder an die TMU gestellt - hier müssen "Millionen" an Pixel der Szene durchforstet werden, deswegen auch eine "Fixed-Function-Unit". Die CU macht im Endeffekt das gleiche wie die SM bei NVIDIA bei der RT-Berechnung, nur dass eben kein RT-Core den Suchbaum durchstöbert, sondern die TMU. Sobald der Eintrag aus dem BVH-Baum zurückgegeben wird, kann die CU dann weiter rechnen oder eben die SM.
AMDs-Ansatz nutzt aus, dass während einer Berechnung im Shader entweder eine Textur-Anfrage oder eine BVH-Anfrage kommen kann, beides gleichzeitig aus derselben CU ist wegen des imperativen Ablauf von Shadern höchst unwahrscheinlich. Jeder Pixel ist sein eigener Thread in diesem Fall, innerhalb des Pixels wird nicht noch mal parallelisiert.
Der größte Irrtum, der hier - aber auch im Internet - verbreitet ist, dass die "RT-Effekte" bei NVIDIA auf den RT-Cores berechnet werden, das ist aber falsch. Die Effekte an sich werden auch bei NVIDIA in der SM berechnet, das hat NVIDIA auch selbst recht klar kommuniziert.
©Teralios
Ich hoffe mal, das ich jetzt alles richtig wiedergegeben habe. Im groben sollte es aber so stimmen.
Falls es jmd. genauer wissen sollte, bitte korrigieren / erweitern.
. Aber hier und heute hat es sich schon ausgezahlt. Egal, ob sie nun hier und da 10% über oder unter der Leistung von Intel oder NVidia liegen. Sie sind gegen beide Konkurenz fähig! Und das ist gut so. Auch für Intel und NVidia Fans ... denn es beginnt wieder ein echter Kampf auf Augenhöhe. Beim Preis, bei den Features, bei der Leistung!
