Krautmaster schrieb:
Kleine Frage noch ... wieso war bisher der on Die Cache bisher keine Option wenn es deiner Ausführung nach eigentlich primär Vorteile bringt. Es ist doch wie bei allem so - es müssen nicht gleich 128MB sein, 32 oder 64 MB wären ja schon lange eine Option gewesen.
Die banalste Antwort ist: Früher hätte ein L3-Cache einfach zu viel Platz gefressen, deswegen hat man sich damit nicht beschäftigt. Zudem war es bisher einfach die Bandbreite zu erhöhen. Breiteres SI + schnellerere RAM.
Die komplexere Antwort ist: Es ist nicht damit getan einfach nur den Cache hinzuzufügen. Da die GPUs recht simpel aufgebaut sind, brauchen die GPUs Hilfe dabei ihre Daten zu strukturieren. Man muss sich hier also auch Gedanken machen, wie man die Daten strukturiert und die Daten im VRAM und den Caches organisiert. Die Software-Ebene wird hier durchaus komplexer.
Wir haben uns mal in einer Vorlesung mit dem intelligenten Vorausladen von Daten befasst, und was man da an Bandbreite sparen aber auch an Geschwindigkeit gewinnen kann in recht simplen In-Order-CPUs. Es ist nicht kompliziert, aber eben sehr komplex, da man das Speicher-Management entsprechend anpassen und auch erweitern muss.
Ich verweise hier ja nicht umsonst auf HBCC und ebenso DSBR. Erst wenn man weiß, welche Daten wann benötigt werden und die Daten entsprechend organisiert, kann man hier intelligent mit einer weiteren Cache-Stufe die Bandbreite des SI kompensieren.
Das Bild hier veranschaulicht das »Problem« doch recht gut:
Man sieht hier auch eine Entwicklung bei AMD: Bei Fiji hatte man Bandbreite, aber durchaus ein Speicherproblem. Die Bandbreite konnte das Problem mehr schlecht als recht Kaschieren. Aus diesen Erfahrungen hat man sich vermutlich überlegte: Wie können wir »Speicher« sparen und gleichzeitig die limitierende Bandbreite als auch Latenz von PCIe umgehen. Vega hatte mit 8GB HBM zwar »genug« Speicher, es zeigte sich aber, sobald der Platz nicht reicht: Es funktioniert.
Der nächste Schritt, dass ganze nun »intelligent« in einem Cache zwischen zu speicher - Infitie-Cache - ist auf den »ersten« Blick - heute - durchaus logisch, aber gerade in solchen »simplen« Entwicklungen steckt oft mals mehr Hirnschmalz, als man denkt.
Die einfache Antwort auf deine Frage warum jetzt: Weil die durchaus komplexere Software als auch Hardware-Struktur nun mehr Vorteile bietet und wirtschaftlicher ist, als einfach das SI zu verbreitern oder die RAM-Geschwindigkeit zu erhöhen.
Krautmaster schrieb:
Was L1 und L2 angeht scheinen sich Navi und Ampere hier ja nicht so unterschiedlich zu sein oder?
Doch, die Cache-Struktur ist bei Navi als auch Ampere vollkommen unterschiedlich und man kann beide auch nicht wirklich mit einander vergleichem.
Bei NVIDIA besteht eine SM aus 4 Blöcken mit einem eigenen Register-File, die über 3* Datenpfade 32 ALU (16 + 16) und einen Tensor-Core ansprechen. Jeder diese Blöcke hat einen eigenen L0i Cache (Instruktionen). Die SM aus diesen 4 Blöcken (64 + 64 ALU + 4 Tensore Cores *Es sind immer noch 3 Datenpfade, deswegen nach außen 64 + 64 Shader + 4 Tensore Cores). Diese SM hat dann einen L1d (data) Cache von 128 KiB.
Dann folgt bei NVIDIA der GPC, der hat keinen eigenen Cache und dann der L2-Cache für die ganze GPU. Hier ein kurzer Einschub für
@Kacha und
@Colindo . Ich habe mir jetzt das Paper, das Patent sowie das Architektur-Paper für RDNA angesehen und kann soweit wohl, glaub ich, schreiben: Wir sehen Teile des Papers als auch des Patents bereits bei RDNA.
Bei AMD ist es nun so, dass eine CU aus 2 Vec32 ALUs + 2 sklaren ALUs für bestimme Operationen aufbauen und jetzt geht es los. 2 CUs werden zu einer WGP verbunden. Hier finden wir das LDS (Local Data Share), diese besteht aus 2 * 64 KiB (ist das, was wir bei NVIDIA als Registerfile pro Block vorhanden). Beide CU haben Zugriff auf den LDS und können darüber auch »Daten« austauschen. Pro WGP kommen dann 2 * L0d mit 16 KiB hinzu, sowie ein L0i mit 32 KiB.
5 WGP bilden dann ein Shader Array bei AMD und hier kommt nun der L1-Cache mit 128 KiB. Darüber steht dann bei AMD die Shader Engine aus 2 Shader Arrays. x Shader Engines bilden dann die GPU mit dem L2-Cache und nun eben dem Infinti Cache.
Sieht man sich das an, dann hat AMD das Paper
@Kacha und
@Colindo durchaus auch umgesetzt. 1. Indiz: der LDS (Registerfile) der aus 2 Blöcke zu 32 Banken zu 512 Einträgen mit 32 Bit besteht. Beide CUs können darauf zu greifen. An diesem LDS hängt dann an 2 Datenpfaden jeweils ein L0d (das, was bei CU der L1d war und im Paper als L1 bezeichnet wird). 10 L0d hängen dann gemeinsam an einem L1 Cache, des Shader Arrays. Man hat also das Paper wohl in vereinfachter Form umgesetzt, in dem man 2 CU zur WGP verbunden hat und 5 WGP einen gemeinsamen L1 gegeben hat.