Kacha schrieb:
Fuer die WGP gibt es wahrscheinlich nochmals ein anderes Patent. Ich werde es mir aber nicht antun danach zu suchen.
Ist ja verständlich, im Endeffekt sind wir hier ja nur aus Spaß an unserem Hobby am Diskutieren, da muss man nicht immer alles bis ins kleinste Detail belegen.
Kacha schrieb:
Das stellt das Patent nicht ganz klar. Es hoert sich aber danach an, dass CUs in Clustern sind. Aber ja, koennte natuerlich auch anders sein.
Die CUs wurden ja bisher immer, sowie die WGP in den Shader Array/Engine organisiert. (Ich weiß gerade nicht ob das Shader Array erst mit RDNA dazu kam als neue zwischen Stufe oder schon immer da war.
Aber im Patent wird eben von dem Shader Array/Engine gesprochen und die CU die in diesen organisiert sind und dass dort der L1-Cache verbunden wird.
Frage ist halt jetzt, wenn sie es auf RDNA mit anwenden irgendwann, ob nun die L0d - entspricht im Paper den L1d, verbinden oder dort einfach die WGP so lassen mit ihrem LDS und L0d und die L1 im Shader Array verbinden, wenn es zu zu vielen misses kommt.
Ich muss dazu aber auch sagen, dass ich früher oder später durchaus auch sehe, dass die RDNA CU/WGP und der Aufbau auf Shader Array und Shader Engine durchaus auch bei CDNA sehe.
Man sagt zwar RDNA eine »Compute«-Schwäche nach, aber das ist in der Betrachtung so nicht ganz richtig, wenn man Vega56 als auch Vega64 mit der 5700 XT vergleicht. Da stehen 40 CU gegen 56 und 64 und selbst Takt normiert stehen dann 10,1 TFlops gegen 5,83 und dass Vega dann mit NAVI den Boden wischt ist klar.
Der »passendere« Vergleich - Anzahl der CU - wäre eher die RX 480/580 gegen die 5700, beide haben 2304 Shader in 36 CUs. Bei der RX 580 steht dann takt normiert 4,8 TFlops gegen 5,3 TFlops. Und in dem Vergleich schneidet Navi in OpenCL-Benchmarks plötzlich eben nicht mehr so schlecht ab gegenüber GCN. Da gibt es dann natürlich ein paar Benchmarks die für GCN sprechen und GCN mit Navi durchaus den Boden wischt, genau so gibts aber auch einige Benchmarks dann, bei den Navi mit GCN regelrecht den Boden wischt.
Kacha schrieb:
Und selbst dann ist der Overhead nicht so hoch wie es sich anhoert.
Und auch dann kommt es immer noch darauf an, ob wir von OoO-Designs oder IO-Designs reden und ob der Prozessor eine spekulative Ausführung von Befehlen unterstützt, ob eine Sprungvorhersage usw. notwendig ist.
Moderne CPUs können bei einen vollständigen Cache-Miss und dann der Anforderung aus dem Arbeitsspeicher, im schlimmsten Fall sogar vom Datenträger, noch andere Aufgaben dazwischen schieben, die sie ausführen können, während man auf Daten wartet.
Und bei In-Order-Designs gibt es genug Möglichkeiten die Gefahr für einen Cache-Miss quasi auf 0 zu reduzieren.
Kacha schrieb:
Wir hatten es im Studium bei einem primitiven Prozessor der nur die Mandelbrotmenge berechnet hat. Der Cache hat die Berechnung locker mehr als verdoppelt.
Wir hatten was Ähnliches gehabt. Später dann auch in einer Vorlesung. Wir haben dann auch in einer Vorlesung darüber gesprochen, wie intelligentes Prefetching von Daten auch die Ausführungsgeschwindigkeit erhöht und wie man mögliche »Flaschenhälse« umgehen kan.
Kacha schrieb:
Die Bandbreiten und Geschwindigkeiten sind hoeher je naeher man an der Execution Unit sitzt.
Wobei hier die Bandbreite ja mehr »Nebeneffekt« der Nähe zu den Registern ist und diese eben die Daten schnell genug in die passende Register schaufeln müssen.
Aber ja, je näher man kommt, umso schneller wird der Cache, wobei man hier ja auch wieder etwas »unterscheiden« muss. Der L1 heute ist an die »Register« schneller angebunden als an den L2, während der L2 an den L1 schneller angebunden ist als an den L3 usw.
Ach, jetzt wird es kompliziert, ich bekomme Kopfschmerzen!
Kacha schrieb:
Wenn man das ganze noch etwas intelligenter handhabt geht da wirklich viel. Das ist den meisten halt nicht klar.
Es ist ja auch ein komplexes Thema, dass auch einiges an Knowhow benötigt. Es ist nicht »kompliziert«, die Grundlagen sind sogar recht simpel, aber man muss schon einiges an Hirnschmalz verwenden um zu wissen, wann welche Daten wo sein müssen.
Kacha schrieb:
Damit skaliert die Leistung, wenn auch nicht ganz, fast linear und man kann extrem billig weitere Leistung drauf packen. Wer auch immer damit zuerst bei GPUs kommt hat einiges gewonnen.
Wobei die Skalierung hier eher davon abhängt wie die Tiles/Chiplets usw. organisiert werden.
Kacha schrieb:
Jup, wuerde sich perfekt anbieten bei Chiplets. Und selbst das koennte man wieder, wenn man uebertreibt, hierarchisch aufbauen wenn noetig.
Also gerade bei der Bildsynthese bietet es sich an dass man mit einem Controller-Worker-Prinzip arbeitet, erade beim Tiled-Based-Rendering. Der Controller verteilt die Daten auf die freien Worker, lässt diese rechnen und nimmt die fertigen Daten und gibt die dann raus.
Gleichberechtigte Worker, die sich synchronisieren müssen, könnten hier recht schnell die Skalierung massiv nach unten ziehen.
Kacha schrieb:
Ich bin ja gespannt wann es kommt und ob dann gleich der 160 CU Chip auftaucht. 4 x 40 CU Chiplets duerften ziemlich klein und guenstig werden in 5nm.
Also RDNA 3 halte ich durchaus für realistisch, die Weichen sind dafür gestellt. Intel scheint ja bei Xe bereits mit »Tiles« zu arbeiten, wobei hier aktuell die Frage ist, was man da unter Tiles versteht.
AMD hat auf jeden Fall nun bei RDNA 2 eine Struktur aufgebaut, die sich als Grundlage für ein Chiplet-Design eignet.
Wollt auch grad schreiben: 
MFG Piet
