0xffffffff schrieb:
Ich könnte mir vorstellen, dass der Turing-Nachfolger keinen dedizierten Chip für das Raytracing und DLSS gedöhns mehr haben wird, stattdessen eher wieder einen Chip der eben alles kann.
Alles falsch und zwar sowas von!
RT als auch DLSS werden bei Turning nicht über dedizierte Chips ausgeführt, sondern über dedizierte Rechenwerke im Chip und das wird nvidia auch so schnell nicht ändern, weil die normalen CUDA-Cores entsprechende Aufgaben überhaupt nicht so schnell lösen können, wie es notwendig wäre. Ich geh gleich auf ein paar technische Eigenheiten ein - auch um den Weg von AMD und nVidia etwas aufzuzeigen.
Aktuell besteht bei Turning ein nVidia-Chip aus folgenden Funktionseinheiten:
Textur Mapping Unit - TMU. Übernimmt die "Texturierung" der Polygone. Direkt an den gemeinsamen Cache angebunden und damit näher am Arbeitsspeicher.
RayTracing-Core - RT-Core (RTC). Spezielle Funktionseinheit für
BVH-Tree-Suchen.* Direkt an den gemeinsamen Cache angebunden und damit näher am Arbeitsspeicher.
CUDACores (FP32) - Skalare FP32-Alu. Eigener kleiner Cache, kein direkten Zugriff auf gemeinsamen Cache.
CUDACores (Int32) - Skalare Int32-Alu. Eigener kleiner Cache, kein direkten Zugriff auf gemeinsamen Cache.
CUDACores (FP64) - Skalare FP32-Alu. (Kommt vorwiegend bei den Tesla-Chips zum Einsatz. Aktuell Volta, davor Pascal als GP100 (nicht der 102er auf den Titan oder GeForce GTX1080Ti!) Eigener kleiner Chache, kein direkten Zugriff auf gemeinsamen Cache.
Tensor-Cores - TC. Matrizen-ALU (Multiplikation + Addition) zur
Tensor-Berechnung. Eigener kleiner Cache, keinen direkten Zugriff auf gemeinsamen Cache.
Render-Output-Units - Mappen das Bild dann auf die "Pixel", ich kanns nicht einfach erklären. Direkt an dem gemeinsamen Cache angebunden und damit näher am Arbeitsspeicher.
Gemeinsamer Cache - (L2-Cache)
nVidia oragnisiert dabei die Funktionseinheiten in Gruppen. Die kleinste Gruppe ist ein Streaming-Multi-Processor. Der besteht grob aus 1 RTC 64 CC-FP32, 64 CC-INT32, 8 TCs. 4 SM bilden dann ein TPC (Texutre-Processing-Cluster). hier kommen dann die 4 TMUs hinzu. 8 TPCs bilden dann einen GPC (Graphic-Processing-Cluster) und dieser hängt über die "TMUs" direkt am L2-cache. Am L2-Cache hängen dann auch noch die ROPs in 8er Blöcken. Der "Dreh" und Angelpunkt ist also der L2-Cache, an dem auch dann der RAM häng.
Sieht man sich Schaltbilder an, dann sieht man, dass Einheiten, die direkten Zugriff auf den RAM oder L2-Cache brauchen näher an diesem Platziert werden. So sind TMUs als auch die RT-Cores so platziert, dass sie direkt auf den Cache und damit auf den RAM zugreifen können. TMUs wegen den Texturen, die RT-Cores wegen des BVH-Trees.
AMDs aktuelle RDNA ist ähnlich aufgebaut in den Grundzügen.
Vec32-ALU - Dient zur berechnung von INT32, FP32, FP16, INT16, INT8, INT4 usw. 32 besagt in dem Fall, dass die Vecktor-ALU für 32 FP32-Berechnungen ausgelegt ist!
INT32/FP32 SALU - Dient zu brechnung bestimmter Funktionen (Ich hab gerade nicht im Kopf, welche es waren.)
TMU
ROP
Die Gruppierung bei RDNA: Compute-Unite (CU) bestehend aus 2 * Vec32 und 2 * SALU.
Workgroup-Processor (WGP), gebildet aus 2 * 1 CU + 2 TMU + 1 L0-Cache.
Shader-Array: 5 WGP + L1-Cache
Shader-Engine: 2 SA.
Am Ende kommt noch der L3-Cache.
Auch hier gilt: TMUs sind näher an den Caches und können darüber schneller mit dem nächsten Cache und dem Arbeitsspeicher kommunizieren. Nun zum Thema RT bei AMD. Das aktuelle Patent bei AMD beschreibt, dass man die TMU um spezielle Funktionen für die BVH-Tree-Suche erweitert (also das was nVidia mit ihren RT-Cores macht). Das liegt daran, dass eben die TMUs direkt am Cache angebunden sind und so wesentlich schneller an die benötigten Daten aus dem BVH-Baum kommen.
AMDs Lösung wird leider sowohl hier als auch allgemein in der deutschen Presse als auch in den Foren oft als eine Hybrid-Lösung angesehen, man schreibte hier - glaub ich - von einer hardwareunterstützen Software-Lösung über Shader, während man bei nVidia von einer Hardware-Lösung spricht. Diese Aussagen sind aber - freundlich ausgedrückt - stark verfälscht und wenn man es etwas klarer mag: Eigentlich Bullshit!
Der aktuelle Berechnungsweg für RT bei nVidia sieht ungefähr so aus - ach ich hab mal wieder Quelltext gelesen, yeah: Auf RTX-Karten wird ein Bild bis zu einem Zeitpunkt X berechnet. Alle während dessen "anfallenden" Strahlen werden gesammelt. Sobald der Zeitpunkt X erreicht ist, während alle gesammelten Strahlen durch die RT-Cores abgearbeitet und entsprechend durch den BVH-Tree geschossen. Sobald man da auf ein Objekt trifft, werden die von dort ausgehenden Strahlen der Liste der "gesammelten" Strahlen hinzugefügt und das "Objekt" wird mit dem entsprechenden Strahl markiert. Aus den Objekten sowie Strahlen wird ein neuer Baum aufgebaut der (stark vereinfacht) aus dem "Strahl" als Ast besteht und dem darauf folgendne Objekt als Knoten und dann gehts weiter. Sobald alle Strahlen ihr Ziel gefunden haben, steht entsprechend ein neuer Baum und dieser wird dann nicht mehr durch die RT-Cores gejagt, sondern ab diesem Zeitpunkt arbeiten wieder die Shader und berechnen nun final alle Effekte.
Die "nVidia"-Lösung ist also auch eine Mischung aus den RT-Cores (zur Verfolung der Strahlen im BVH-Tree) und Shadern.
AMDs Lösung sieht aktuell ähnlich aus, unterscheidet sich aber an einigen Punkten.
1. AMD wird vermutluich keine "dedizierten" RT-Cores nutzen, aber die TMUs um entsprechende Funktionen erweitern, die es der TMU ermögliuchen den BVH-Tree effektiv mit dem gegeben Strahl zu durchsuchen.
2. Wie bei nVidia sendet der "Shader" für den Effekt einen Strahl aus, statt das er aber erst in einer Liste gesammelt wird, wird im Shader entschieden "bin ich der Endpunkt, wenn ja, pfeif drauf!" oder "Ne, ich bin Start/Zwischenpunkt, ich sende mal weitere Strahlen aus.". Diese Strahlen gehen dann in die TMU und diese sucht dann im BVH-Baum nach den passenden Zielen.
Was ich geschrieben habe sind dabei - und ich sag es klar - Vermutungen, die auf Beobachtung der Auslastung der Funktionseinheiten der RTX-Karten beruht sowie die Betrachung der Patente. Es kann so sein, muss aber nicht. Ich habe genug Ahnung um solche Annahmen zu treffen, bin aber nicht tief genug drinn, dass ich es bestätigen könnte.
.
