News Intel Meteor Lake: Grafikeinheit bekommt L4-Cache, CPU-Teil exklusiv den L3

[Matthias B. V.]

Naja... AMD wird wohl erst reagieren, wenn Intels iGPU konkurrenzfähig wird. Bis jetzt ist das noch nicht der Fall. Außerdem scheint bei AMD noch ein ganz anderes Problem vorzuherrschen, und zwar die breite Verfügbarkeit von deren APUs (abseits von Handhelds).

Stimme zu dass AMD die Verfügbarkeit und Kapazitäten erhöhen muss - insbesondere für OEM Produkte wie Notebooks.

Wenn AMD erst reagiert wenn Intels iGPUs konkurrenzfähig sind ist es zu spät. Man sieht ja wie es bei Intel gelaufen ist wenn man sich zu sehr ausruht. Und die Entwicklungszyklen sind 3-5 Jahre...

 

[markox]

[...] MTL, GT [...] LLC [...] CPU [...] ADM/L4 [...] MOCS/PAT [...].

Ein toller Satz .

 

[7H0M45]

Mal ne Laienfrage, warum kann man nicht generell mehr Cache verwenden? Ist das ein Platzproblem? Preisproblem? Energie, Thermik?

Bei AMD ist ja das Problem des 3D Caches dass er zwar platzsparend verbaut ist aber die Temperaturen problematisch sind. Könnte man sowas durch eine größere Fläche besser lösen oder sprechen da andere dinge dagegen?

 

[mannduro]

Das mit dem eDRAM funktioniert heute noch ganz gut. Siehe Signatur 😉

https://youtube.com/@mannduro

Was mit Broadwell ging wird auch mit Meteorlake gehen

 

[Cr4y]

Mal ne Laienfrage, warum kann man nicht generell mehr Cache verwenden? Ist das ein Platzproblem? Preisproblem? Energie, Thermik?

So ziemlich alles, was du genannt hast ist (irgendwann) ein Problem. Latenzen würde ich noch anführen. Je größer der Cache, desto länger die Leitung und desto größer die Latenz. Und dann profitiert auch nicht jede Anwendung von großen Caches. Sieht man ja an den 3D Modellen von AMD. Also auch ne schnöde Kosten-/Nutzen-Rechnung.

Ganz allgemein unterliegt alles irgendwann dem Gesetz des abnehmenden Grenznutzen: Ab einem gewissen Punkt bringt eine zusätzliche Einheit von irgendwas (z.B. Cache) immer weniger zusätzlichen Nutzen, bis der zusätzliche Nutzen irgendwann 0 ist und sich ggf. ins negative dreht.

 

[stefan92x]

Bei AMD ist ja das Problem des 3D Caches dass er zwar platzsparend verbaut ist aber die Temperaturen problematisch sind.

AMD scheint dafür für die Zukunft schon eine Lösung zu haben und den Cache unterhalb der Core-Chiplets einzubauen. Dadurch muss die Abwärme nicht mehr durch den Cache und das ganze wird besser kühlbar.

Angekündigt ist das im Moment aber nur für die MI300 für HPC-Systeme, für normale Prozessoren ist das wohl noch nicht absehbar.

 

[ETI1120]

AMD scheint dafür für die Zukunft schon eine Lösung zu haben und den Cache unterhalb der Core-Chiplets einzubauen. Dadurch muss die Abwärme nicht mehr durch den Cache und das ganze wird besser kühlbar.

Dafür müssen alle Signale und die Power durch den Cache geführt werden. Es gibt fast nichts was nur Vorteile hat.

Das eigentliche Problem des 3D-Stacking ist, dass die aktive Fläche im Chip größer wird aber die Fläche, über die die Wärme abgeführt werden kann, gleich bleibt. AFAIK geht es weniger um die Durchleitung als um die gesamte Wärme, die auf mehreren Ebenen in einem Flächensegment unter dem Kühler entsteht.

Angekündigt ist das im Moment aber nur für die MI300 für HPC-Systeme, für normale Prozessoren ist das wohl noch nicht absehbar.

Aber hier haben wir eine GPU und außer dem Infinity Cache ist wohl auch der Memory Controller im Base Die. D. h. hier muss nur die Power direkt von außen durch den Base Die geführt werden.

Wie der CPU-Anteil umgesetzt wird, ist spannend. Werden hier normale CCDs verwendet oder spezielle Chiplets?

Und zu Meteor Lake: Da Intel einen Interposer verwendet, steht eigentlich viel Fläche zur Verfügung. Es ist die Frage wann Lakefield einen Nachfolger bekommt.

 

[Volker]

Intel hat ja viel Erfahrung mit Multi-Chip-Packages, das geht im Notebook und Desktop ja zurück bis Clarkdale, die erstmals großflächig kamen: https://www.computerbase.de/2010-01/test-intel-core-i3-530-540-und-core-i5-661/
Kaby Lake-G mit Vega dran war dann ja ein schickes Experiment ( https://www.computerbase.de/2018-05/intel-nuc-hades-canyon-kaby-lake-g-test/ ) die ganze EDRAM-Sache lief ja ein halbes Jahrzehnt.

Lakefield war das nächste große Experiment, daran wird in Zukunft angesetzt. Auf Chiplets und Stacking setzen sie ja massiv, da dürfte auch Platz für zusätzliche 128 MB Cache sein. Und die können wie früher auch oder auch bei AMD auch anders gefertigt sein, es ist ja nur Cache. Also vergleichsweise preiswert.

 

[whynot?]

Mal ne Laienfrage, warum kann man nicht generell mehr Cache verwenden? Ist das ein Platzproblem? Preisproblem? Energie, Thermik?

Im Prinzip genau das, mehr Cache->größere Die Area -> teurer. Deswegen sind die Caches immer nur mit Nodesprüngen großartig gewachsen.

 

[Volker]

Hier hat Intel mit dem EDRAM damals ja sein Ding durchgezogen: Der war sechs Jahre quasi exakt gleich, immer in 22 nm gefertigt. Und genau das wärde mit so einem Multi-Chip-Package ja easy wieder drin. Da braucht es keine 5 nm oder EUV oder so, nimmst die altbekannten 10 nm und packst Cache dann wieder extra als Block. Das kann Intel selbst günstig in eigenen Fabs fertigen.

 

[Calaphos]

Mal ne Laienfrage, warum kann man nicht generell mehr Cache verwenden? Ist das ein Platzproblem? Preisproblem? Energie, Thermik?

Bei AMD ist ja das Problem des 3D Caches dass er zwar platzsparend verbaut ist aber die Temperaturen problematisch sind. Könnte man sowas durch eine größere Fläche besser lösen oder sprechen da andere dinge dagegen?

Scheint irgendwo auch ein Marktproblem zu sein. Apple baut große integrierte GPUs mit sehr viel Cache auf SOC Ebene. Nimmt dafür aber halt auch sehr große Dies in aktuellster Fertigung in Kauf. Zumindest für die Pro und Max Versionen.

Intel und AMD waren da bislang deutlich zurückhaltender, die mobile Prozessoren haben auch nie sonderlich große Dies. Denke die Motivation aufwendige, große iGPUs zu bauen ist geringer wenn die meisten Kunden dafür sowieso diskrete bevorzugen.

 

[Smartbomb]

Scheint irgendwo auch ein Marktproblem zu sein. Apple baut große integrierte GPUs mit sehr viel Cache auf SOC Ebene. Nimmt dafür aber halt auch sehr große Dies in aktuellster Fertigung in Kauf. Zumindest für die Pro und Max Versionen.

Intel und AMD waren da bislang deutlich zurückhaltender, die mobile Prozessoren haben auch nie sonderlich große Dies. Denke die Motivation aufwendige, große iGPUs zu bauen ist geringer wenn die meisten Kunden dafür sowieso diskrete bevorzugen.

Genau wie bei den SoCs für iPhone und Co:
Apple kann sich die super teuren Chips (weil große Fläche) leisten, weil sie sie 1.) nicht verkaufen müssen wie alle anderen und die Kosten durch ihre enormen Gerätepreise subventionieren.
Qualcomm, Mediatek etc würden nie so riesige Chips herstellen - denn die wären zu teuer und niemand würde sie ihnen abkaufen.
Aber in >1k€ Handys die Apple massenweise verkauft - da hat man genug Kohle dafür.

Denke die Motivation aufwendige, große iGPUs zu bauen ist geringer wenn die meisten Kunden dafür sowieso diskrete bevorzugen.

Richtig. Die iGPU in der CPU ist nur dafür da, ein Bild zu machen und evtl noch Video codecs zu beschleunigen.
Zum Zocken, eine 250W Grafikkarte, wirst du in eine CPU nicht reinquetschen können.

Kurz: für die OEMs zu teuer und für die privaten meist nicht nötig. Und wenn dann gleich a "gscheite" Grafikkarte.

Also wenn dann evtl noch für kleine, platz- und stromsparende Geräte imteressant. Ergo: Mobilgeräte und Thinclients. Und da dürfen Fläche, damit Kosten und Leistungsaufnahem auch nicht explodieren.
Cache ist schnell, groß, braucht viel Strom.
Wie immer bei Speicher: Je schneller dieser ist, umso mehr (physischen) Platz pro Byte braucht er und umso mehr Strom. Also teuer und "heiß".
Darum haben MobilCPUs neben weniger Takt auch meist weit weniger Cache, weil man so die Leistungsaufnahme drückt.

 

[spotz]

Bei PC Games Hardware steht das genaue Gegenteil zur ComputerBase Nachricht: dort heißt es der L4 Cache sei CPU exklusiv, CB schreibt der L4 sei iGPU exklusiv.

bin verwirrt, was stimmt denn nun?

https://www.pcgameshardware.de/CPU-...D-Meteor-Lake-soll-L4-Cache-bekommen-1417392/

 

[Volker]

Hier steht nix von GPU exklusiv.
Hier steht nur das der L3 alias LLC exklusiv ist für die CPU und die iGPU das nicht mehr kann. Und das steht so im originalen Englisch "On MTL, GT can no longer allocate on LLC - only the CPU can"

Vom L4 ist es nicht sicher, denke nicht das sie da CPU komplett ausnehmen, ein SoC ist halt nix ohne die CPU, wohl aber ohne GPU. Es wird wohl so ein Package-Ding sein, wie hier im Thread ja schon dargelegt: https://www.computerbase.de/forum/t...pu-teil-exklusiv-den-l3.2139486/post-28098163
Ein separater On-Package-Cache in einer alten Node zu fertigen ist superbillig (wie eDRAM 6 Jahre in 22 nm), und wenn das mit den Kacheln dann zum Erfolg führt, für mehrere Bereiche, bringt es auch was.

 

[latiose88]

Also ich habe gelesen gehabt das die onboard gpu keinen Zugriff mehr auf den l3 Cache haben wird aber dafür einen l4 Cache exklusive nur für die gpu. Damit jeder einen Cache hat. Damit nimmt die onboard gpu der CPU auch keine Bandbreite mehr weg und kann sich beiden vollkommen entfalten. Und Leistung verliert man so auch nicht mehr. Also ja das begrüße ich voll sowas.

 

[spotz]

Ich habe nur wenig Ahnung von Technik, aber ich hatte beim Lesen den Eindruck das sich CB und PCGH in der Meldung zum L4 Cache unterscheiden, auf welche Cachestufe die CPU nun exklusiven Zugriff hat. Darauf wollte ich nur aufmerksam machen. Wenn ich es falsch verstanden habe, dann bitte ich um Entschuldigung.

 

[Volker]

Alles gut. Das ist ja eben auch die Sache mit solchen Info-Happen. Es bleibt Interpretationsspielraum. Fest ausgesagt ist nur, dass die GPU nicht mehr als den LLC randarf, der bleibt bei der CPU. Was genau ADM/L4 ist, das bleibt das große Geheimnis, da versuchen sich so einige Profis gerade dran: https://www.coelacanth-dream.com/posts/2023/04/12/mtl-adm_l4/
Da geht die Vermutung dahin, dass der Cache im Base-Tile sein könnte - dort hätten quasi alle Zugrifff wenn Intel das will und nicht nur die GPU. Aber die Schaubilder, die dafür zurate gezogen werden, sind ziemlich ungenau.

 

[Piktogramm]

@Volker
Genaugenommen ist der L3 Cache kein LLC, wenn L4 vorhanden ist

#########################

Die Email dazu auf der Linux Kernel Mailing List (lkml) ist im Bereich des Prosatexts uneindeutig. Der L3-Cache wird da als LLC bezeichnet, gleichzeitig wird jedoch ein L4-Cache erwähnt, der nach Wortdefinition von LLC ja eigentlich der LLC wäre.
Die Interpretation an der Stelle kann also sein, dass die iGPU nicht mehr an den L3-Cache des CPU-Die herankommt, oder dass es zwar einen L4-Cache gibt, aber die iGPU da nicht herankommt.

Was ich für wahrscheinlich halte, dass die iGPU nicht an den L3 der CPU herankommt. Da zwischen GPU und CPU Die ja noch das SoC Die liegt, wäre der Zugriff der iGPU auf Caches auf dem CPU-Die (energetisch) recht teuer. Wenn Intel für Meteor Lake wieder einen gegenläufigen Ringbus verwendet, wäre das egal in welche Richtung mindestens zwei Hops auf fremden Dies.
Und ein L4-Cache wird wahrscheinlich im SoC Die liegen, wobei dieser L4 als LLC für iGPU, CPU, Coprozessoren dienen wird. Quasi als letzte Gelegenheit einen Cachtreffer zu landen, bevor es vom SoC Die in Richtung lahmen Arbeitsspeicher geht.
Die iGPU selbst wird 2..3 eigene Cachlevel haben.

Edit: https://lists.freedesktop.org/archives/intel-gfx/2023-April/323891.html

PS: Die Spekulation über eDram scheint von allen zu kommen, die sich bei Phoronix als Quelle bedienen. Da schient es als erstes aufzukommen und wie bei Phoronix üblich ist da wenig erkenntlich, was Fakt und wilde Spekulation vom Betreiber der Seite ist.

Edit2:
https://lists.freedesktop.org/archives/intel-gfx/2023-April/323893.html
LLC disabled für die iGPU.
Wilde, weitere Spekulation:
Entweder verwendet Intel in ihren Treibern LLC analog mit L3-Cache und ein L4 Cache wäre damit eine Stufe über LLC. Das wäre aber Imho recht merkwürdig. Ich würde eher vermuten, dass der L3 auf dem CPU-Die liegt und die iGPU nicht an diesen herankommt. Der SoC-Die hat einen L4-Cache, diesen aber als "Victim Cache" implementiert. Daher iGPU, CPU und der ganze andere Kram der Speicherzugriff haben will, hat keine Kontrolle über den L4.

 

[Volker]

Joa gute Punkte, könnte alles irgendwie passen. Das mit L3 und CPU only weil auf einem Chip dachte ich mir auch schon. Die Frage ist halt wirklich, wo der L4 sitzt. Im GPU-Die vermutlich nicht, würde den aufblähen und weil er in teurer Fertigungsstufe kommt,ä zu teuer machen weil zu groß. Also bleiben ja nur noch 2 Sachen: SoC oder Base. Die Base Tile war bisher immer der, der die schlechteste Fertigungsstufe hat, da braucht es nicht das beste. Genau hier wäre für kostengünstige Lösung ein L4 ziemlich gut aufgehoben. Im SoC weiß ich nicht, auch der ist meist nicht State-of-the-Art gefertigt, aber he, mal sehen was sie zaubern.

 

[latiose88]

@Piktogramm
Du schreibst von letze chance einen Cache Treffer bei l4 zu haben. Wie sieht es denn aus wenn ne Anwendung von sich aus ne sehr niedrige missrate von l1 zu l2 schon hat und damit ne sehr hohe hitrate. Wie wird es dann weiter gehen von l2 zu l3 und dann l4 wenn dazwischen ebenso ne super hitrate ist. Wird das dann immer weniger Wirkung zeigen die höhere Ebene dann?
Und hätte das dann geringere Auswirkung bei der Bandbreite dann insgesammt?

Und wenn man nun das ganz noch verschärft mit 2 x die selbe Anwendung. Schmeißt dann die erste die Infos der zweiten dann aus dem Cache raus oder was passiert in diesen Fall dann? Weil ist ja nicht viel langsamer geworden von 1 auf 2 gleiche Anwendung.
Ist zudem ebenso die Frage wie sich das ganze mit dem cache und der onboard gpu und deren Aufbau sich so auswirken wird.