Notiz Infinity Cache: Geschützte Marke für AMDs potenzielle Geheimwaffe

[jemandanders]

Aber die Gerüchte sagen, dass der Infinity Cache ein L2/L4 cache ist,

Welche Gerüchte besagen das denn?
Meine "Gerüchte" besagen das es ein Shared L1 Cache ist.

 

[Mcr-King]

Welche Gerüchte besagen das denn?
Meine "Gerüchte" besagen das es ein Shared L1 Cache ist.

Ähm beide Recht mehr oder weniger.

 

[jemandanders]

Ähm beide Recht mehr oder weniger.

Dann klär mich doch mal bitte etwas auf. Ich möchte nicht Dumm sterben.

 

[w0mbat]

Welche Gerüchte besagen das denn?
Meine "Gerüchte" besagen das es ein Shared L1 Cache ist.

RGT war der erste, der mit dem "Infinity cache" ankam, und der hat was von einem großen 128MB cache erzählt.

Die Patente mit dem shared L1 hab ich auch gesehen, aber der L1 ist sicher keine 128MB groß.

Aber das ist irrelevant, weil beides ganz anders als HBCC/NVCache ist.

 

[Mcr-King]

Dann klär mich doch mal bitte etwas auf. Ich möchte nicht Dumm sterben.

okay brauche aber eine Zeichnung zum verständlich machen also dauert etwas bis um 22 Uhr ca.

 

[jemandanders]

@Mcr-King Foto einer Handskizze reicht vollkommen

 

[BlackRain85]

We could be talking about a 128MB cache here, compared to the existing Radeon RX 5700 XT which has 4MB of L2 cache, to give you some perspective – it’s a massive increase. Therefore, using this clever design, there shouldn’t be as much need to run to the video memory so often – there will be more cache hits – and therefore any constraints on the memory bus are offset by this approach.

Das Schreibt zumindest mal Techaradar. Und bevor man wieder der Tugend Deutschlands alle ehre macht und einfach alles scheiße redet, beschäftigt man sich mal erstmal bitte damit. ---> Damit ist Seite 1 und 2 mindestens mal gemeint.

Und da AMD gefühlt einen anderen Weg eingeschlagen hat, damit meine ich den Fokus auf Performance pro Watt, würde so etwas ausgeklügeltes voll dazu passen. Günstiges Board Design und günstiger Endkundenpreis dabei trotzdem Profit.

Mir zumindest erscheint es so, als interessiert AMD die Performance Krone nicht wirklich. Alle Produkte sind absolut auf eine Zielgruppe Fokussiert -> die Masse (Server mal ausgenommen) und die Masse bringt Marktanteile.

 

[jemandanders]

Die Patente mit dem shared L1 hab ich auch gesehen, aber der L1 ist sicher keine 128MB groß.

Wer weiß? Normal ist der für einen einzelnen Kern ja winzig, wenn aber alle Kerne zusammen da dran hängen wird das schon eine gewisse Größe erreichen. Könnte natürlich auch den L2 und L3 mit zusammen fassen bzw. direkter anbinden und dadurch eine Gesamtgröße von 128 darstellen.
Allein durch den geteilten L1 gibt es anscheinend (meistens) einen ziemlich gewaltigen Schub. Als ich das heut Nachmittag gelesen und das Video dazu gesehen habe, habe ich direkt geahnt, warum NV seine Karten an der Kotzgrenze betreibt.

 

[Benji18]

Es ging dabei weniger um die Skalierbarkeit im Sinne von Chiplets, sondern mehr um die bessere Auslastung bei steigender Anzahl an CUs.

nein da gings um bessere skalierbarkeit die flexibilität bietet. Die bessere CU Auslastung haben sie ja schon mit RDNA erreicht da waren Sie schon auf Turing niveau.

 

[Colindo]

Also es ist wohl das hier, unter "geilem Marketing -Namen" nun:
https://www.freepatentsonline.com/20200293445.pdf
Würde auch zeitlich passen, denn das Patent wurde schon Anfang 2019 eingereicht. 1,5 Jahre um es nun final zum Einsatz zu bringen.

Das klingt echt interessant. So wie ich das verstehe werden die L1-Caches von CUs, die an den gleichen Daten arbeiten, zusammengeschaltet. So hätten 5 CUs zusammen 5x soviel L1-Cache, wenn sie eine ähnliche Aufgabe bearbeiten. Sollte eine CU plötzlich andere Daten brauchen, geht die Miss-Rate hoch und die Gruppe wird neu aufgeteilt, so dass die eine CU wieder ihren eigenen L1-Cache hat und die restlichen 4 CUs mit 4xL1 weiterarbeiten.

Konnte mir das Paper von @Kacha noch nicht durchlesen, vielleicht morgen.

Da wird nichts ausgeliehen, vielmehr kann man die Recheneinheiten in mehrere Cluster Teilen, so lang die dann geteilten Caches noch vernünfige hit rates produzieren.

Bei dir klingt das aber so, als würde die Caches geteilt, also kleiner. Ich verstehe das als ein Zusammenschließen der Caches, oder nicht?

könnte der Infinity Cache, damit zusammenhängen?

Das klingt zwar wie eine clevere Idee, aber wie von Volker schon gesagt, wäre ein asynchrones Speicherinterface (außer der HBM ist exakt so schnell wie der GDDR6) in der Realität nicht so leicht von Vorteil.

Ergänzung (6. Oktober 2020)

Bezüglich 128 MB Cache-Größe geben die offiziellen Dokumente da gar nichts zu her. Woher kommt denn das Gerücht? Das würde ich erstmal seeeehr kritisch betrachten.

 

[ThePlayer]

Bei den ganzen Gerüchten die zu RDNA2 im Umlauf sind würde ich mich am liebsten bis zum 28.10. in Cryoschlaf versetzen lassen. Das ist so spannend. Wie soll man da noch 3 Wochen aushalten 😵

 

[Colindo]

Dann verpasst du aber den 8.10. Der wird sicher auch gut

 

[BlackRain85]

Bei den ganzen Gerüchten die zu RDNA2 im Umlauf sind würde ich mich am liebsten bis zum 28.10. in Cryoschlaf versetzen lassen. Das ist so spannend. Wie soll man da noch 3 Wochen aushalten 😵

Ohhhhh ja, bin heute auf "AMD TURBO LONG" gegangen mit nem hebel 18x 😵😵😵
Das selbe will ich am 26. auch machen.

https://www.gs.de/de/produkte/hebelprodukte/long-short-knock-outs/amd/DE000GF3WA75

Falls jemand mitmachen will ^^

 

[jemandanders]

Mal ein per deepl übersetzter Ausschnitt aus dem Patent
Den letzten Abschnitt finde ich sehr interessant. Die CUs werden bei Bedarf dynamisch zusammen gefasst.
Ein flexibel zu nutzender gemeinsamer L1 Cache.
Toll.

DETAILLIERTE BESCHREIBUNG
Verarbeitungseinheiten wie Grafikverarbeitungseinheiten (GPUs) und Allzweck-Grafikverarbeitungseinheiten (GPGPUs) umfassen in der Regel eine große Anzahl von Recheneinheiten (CUs), die so konfiguriert sind, dass sie Anweisungen gleichzeitig oder parallel ausführen. GPUs sind auf Bandbreite angewiesen, um einen hohen Durchsatz zu erzielen. Zu den Quellen dieser Bandbreite gehören lokale (d. h. private) Caches, gemeinsam genutzte Last Level Caches (LLCs), Scratchpad und Speicher. Bei vielen High Performance Computing (HPC)-Anwendungen treten Leistungsprobleme aufgrund eines Bandbreitenengpasses bei den LLCs auf, der auf die viel zu geringe Kommunikation zwischen den CUs und den LLCs/L2s zurückzuführen ist. Außerdem hängt die Leistung verschiedener GPU-Anwendungen von der lokalen L1-Cache-Größe der Compute Units (CUs) ab. Die Erhöhung der physischen L1-Cache-Größe pro CU ist jedoch eine kostspielige Lösung, um die L1-Trefferraten zu erhöhen und den Datenverkehr zu den LLCs zu verringern.

Einige Anwendungen, die auf der GPU ausgeführt werden, weisen ein beträchtliches Volumen der gemeinsamen Nutzung durch ihre Arbeitsgruppen auf, was dazu führt, dass auf mehrere Kopien derselben Daten (d.h. der Cache-Zeile) über verschiedene CUs hinweg zugegriffen wird. GPU-L1-Caches sind in der Regel softwarekohärent, was eine einfache Lastverteilung ermöglicht, und GPUs weisen im Allgemeinen im Vergleich zu CPUs eine höhere Latenztoleranz auf. Dementsprechend kann der Gesamtdurchsatz von Anwendungen durch eine dynamische Anpassung des Replikationsgrads der Cache-Zeile über L1s hinweg auf der Grundlage des aktuellen Verhaltens der laufenden Anwendung verbessert werden.

Um die GPU-Systemleistung zu verbessern, veranschaulichen die Abbildungen 1-10 Methoden und Systeme zur Steuerung der Replikationsebenen über GPU-Caches hinweg durch dynamisches Clustering von Compute-Units und den zugehörigen Caches. In verschiedenen Ausführungsformen wird durch Verringerung der Replikationsebene über L1s hinweg die gesamte effektive L1-Cache-Kapazität im GPU-System erhöht, ohne die L1-Cache-Größe pro CU zu erhöhen, wodurch die L1-Trefferrate erhöht und die L2-Zugriffe verringert werden.

In verschiedenen Ausführungsformen umfasst eine Methode für eine erste Clustering-Konfiguration von CUs die Bestimmung, ob eine aktuelle Cache-Fehltrefferrate eine Fehltrefferratenschwelle überschreitet. Auf der Grundlage der aktuellen Cache-Fehltrefferrate, die den Schwellenwert für die Fehltrefferrate überschreitet, werden die CUs in einer zweiten Mehrzahl von Recheneinheiten-Clustern geclustert, die kleiner als die erste Mehrzahl ist. Durch die Bildung von Clustern mit erhöhter Anzahl von CUs (und damit L1-Caches) und die Verschachtelung des Speicheradressbereichs zwischen den CUs innerhalb eines Clusters werden die Replikationsebenen der Cache-Zeilen verringert. Diese resultierende CU/L1-Konfiguration mit weniger Clustern und mehr CUs pro Cluster sorgt für höhere Trefferraten und verringert den Druck auf die LLC-Caches.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

 

[McLovin14]

Die bessere CU Auslastung haben sie ja schon mit RDNA erreicht da waren Sie schon auf Turing niveau.

Das wissen wir eben nicht, RDNA 1 gab es nur mit bis zu 40 CUs, wie es sich darüber hinaus verhält, kann keiner sagen.

 

[Novasun]

Also wenn Infinity-Cache so einschlägt wie Infinity Fabric...
Dann wünsche ich AMD noch ganz viele Infinity Erfindungen...

 

[ThePlayer]

@BlackRain85 leider stagniert der Kurs heute oder es kommt sogar ein kleines minus raus.

 

[Mickey Cohen]

"Geheimwaffe"

wohl eher "Kundenverarsche". bei dem vermuteten einsatzzweck denke ich eher an turbocache.

 

[incurable]

Bei dir klingt das aber so, als würde die Caches geteilt, also kleiner. Ich verstehe das als ein Zusammenschließen der Caches, oder nicht?

Im Patent wird nichts "zusammengeschlossen". Es gibt pro Berechnungseinheit eine Anzahl an Recheneinheiten und eine Anzahl an Cacheeinheiten.

Abhängig von den aktuell ausgeführten Aufgaben (bzw. deren Cachefreundlicheit) arbeiten nun entweder (1) alle Recheneinheiten an einer Aufgabe und verwenden den Pool von Cacheeinheiten gemeinsam oder (2) werden die Recheneinheiten mit ihren Cacheeinheiten in zwei Untergruppen geteilt, die verschiedene Aufgaben abarbeiten.

Ausschlaggebend für die Wahl zwischen (1) und (2) ist im Patent die hit rate des Caches, wenn also die aktuelle abzuarbeitende Aufgabe unter Verwendung aller Rechen- und Cacheeinheiten eine hit rate unter einem festzulegenden Schwellenwert hat, bleibt alles beim alten und die Gruppe muss Auslastung in der temporalen Domäne finden.

Ist die hit rate über der Schwelle kann der Pool geteilt werden, so dass die aktuelle Aufgabe auf einem Teil der Einheiten weiter aus Sicht des Cachings gut genug läuft, während der Scheduler sich nach einer (hoffentlich ebenso mit hoher hit rate im dann natürlich ebenfalls kleineren sekundären Cachepool) weiteren Aufgabe umsieht, die parallel ausgeführt werden kann.

Der Gewinn liegt hier übrigens nicht im parallelen Ausführen mehrerer Aufgaben in einer Untergruppe, sondern darin dass durch die Auslagerung der cachefreundlichen Aufgaben anderswo in der GPU Einheiten frei werden, die sich um die Aufgaben mit größerem Cachebedarf kümmern können.

 

[BlackRain85]

@BlackRain85 leider stagniert der Kurs heute oder es kommt sogar ein kleines minus raus.

macht nix, hab ne knock out schwelle von 5,9%.