AMD:n huhutaan valmistelevan Milan-X-koodinimellistä prosessoria X3D-paketoinnilla

[Kaotik]

AMD on aiemmin esittänyt roadmapin, jossa nykyisiä paketointiteknologioita seuraisi X3D:ksi ristitty teknologia, joka yhdistää ns. 2,5D- ja 3D-paketoinnit samaan pakettiin.
Nyt luotettavista vuodoistaan tuttu Patrick Schur on kertonut yhtiöllä olevan työn alla koodinimellä Milan-X-varustettu prosessori X3D-paketoinnilla.



Toisen niin ikään luotettavaksi aiemmin osoittautuneen vuotajan ExecutableFixin mukaan kyseessä on Genesis-IO-sirulla ja pinoituilla tarkemmin määrittelemättömillä siruilla (chiplets) varustettu kokonaisuus.

 

[ANTI_L]

Tässä kun miettii, niin mikä hyöty olisi noista päällekkäin pakatuista siruista pelkässä prosessorissa, jo nyt on ongelmana siirtää lämpöä pois, joten ainoa järkevä ratkaisu olisi kasasta muistia pari kerrosta päällekkäin, kuten nandissa tehdään ja nuokin alkaa jo käydä kuumana pitkässä rasituksessa, jos on paljon kerroksia.

Itse CPU ytimien päällekkäin pakkausta en usko, ellei sitten ole kelloja laskettu niin paljon, että tuplattu ydinmäärä on kannattavampi. Ei kai sitä ole muuta tehtävä kuin odotella. Hauskana pointtina noissa X3D paketoinnin esittelyssä on (C/G)PU chiplettejä, joiden kaverina ei ole erillistä IO-piiriä, joka olisi kyllä aika hienoa kehitystä, jokaiseen chiplettiin tuo IO-piiri sisään ja monikanavaisena, niin voi tehdä vaikka kuinka isoja chiplet alueita.

 

[Kaotik]

Tässä kun miettii, niin mikä hyöty olisi noista päällekkäin pakatuista siruista pelkässä prosessorissa, jo nyt on ongelmana siirtää lämpöä pois, joten ainoa järkevä ratkaisu olisi kasasta muistia pari kerrosta päällekkäin, kuten nandissa tehdään ja nuokin alkaa jo käydä kuumana pitkässä rasituksessa, jos on paljon kerroksia.

Itse CPU ytimien päällekkäin pakkausta en usko, ellei sitten ole kelloja laskettu niin paljon, että tuplattu ydinmäärä on kannattavampi. Ei kai sitä ole muuta tehtävä kuin odotella. Hauskana pointtina noissa X3D paketoinnin esittelyssä on (C/G)PU chiplettejä, joiden kaverina ei ole erillistä IO-piiriä, joka olisi kyllä aika hienoa kehitystä, jokaiseen chiplettiin tuo IO-piiri sisään ja monikanavaisena, niin voi tehdä vaikka kuinka isoja chiplet alueita.

Henk.koht. veikkaisin että Genesis-IO-siru + chipletit tarkoittaisi IO-sirun päälle pinottua muistia

 

[jive]

Vai olisiko PoP hengessä HBM ja sen päälle CPU/GPU piirinen?

 

[pomk]

Vai olisiko PoP hengessä HBM ja sen päälle CPU/GPU piirinen?

IO sirun päälle ne HBM pinot kannattaa laittaa, muuten latenssit on epäsymmetriset. Nykyisen päälle menis koon puolesta 6-8 pinoa.

 

[KoneenKokoaja]

Henk.koht. veikkaisin että Genesis-IO-siru + chipletit tarkoittaisi IO-sirun päälle pinottua muistia

Samaa mietin itsekin, koska jollain tavalla AMD ja Intelin pitää alkaa reagoimaan (ainakin jossain vaiheessa) Applen konseptiin missä muisti integroidaan CPU kanssa samaan kiveen ja saadaan todella isoja suorituskykyparannuksia jossain käyttötapauksissa.

 

[Kaotik]

Samaa mietin itsekin, koska jollain tavalla AMD ja Intelin pitää alkaa reagoimaan (ainakin jossain vaiheessa) Applen konseptiin missä muisti integroidaan CPU kanssa samaan kiveen ja saadaan todella isoja suorituskykyparannuksia jossain käyttötapauksissa.

Apple ei ole integroinut muisteja samaan kiveen ts siruun vaan samaan paketointiin. Sekä Intelillä että AMDllä on pitkät kokemukset samasta

 

[-Marras-]

Mua kiinnostaa, että miksei vielä olla nähty x86 -puolella prosessoripakettia, jossa olisi paketointiin integroitu HBM-muistia GB tai pari, GPU:n kanssa tai ilman. Onko ollut jotain toteutuksellisia pullonkauloja tai taloudellisia realiteetteja, jonka takia tuota ei ole ollut järkevää tehdä? Tai siis miksi sellainen on (ehkä) tulossa vasta nyt, ja koodinimestä päätellen palvelinpuolelle.

 

[Griffin]

HBM:n edelliset versiot on kait olleet jotenkin hanklalia. 3:s version pitäiai olla kait helpompi..

 

[jive]

IO sirun päälle ne HBM pinot kannattaa laittaa, muuten latenssit on epäsymmetriset. Nykyisen päälle menis koon puolesta 6-8 pinoa.

Palvelinpuolella isompi etu olisi suurempi kaista, kuin latenssit. Toisaalta en oikein usko että muita kuin 1-on-1 pinoja ainakaan ensialkuun lähdetään tekemään. Sinänsä todennäköinen kyllä että tulee eDRAM tyyppinen ratkaisu IO piirin yhteyteen kuin jokaiselle piiriselle erikseen. Varsinkin jos jotain tensorirautaa tai muuta hämärää sisällytetään IO piiriin.

 

[pomk]

Palvelinpuolella isompi etu olisi suurempi kaista, kuin latenssit. Toisaalta en oikein usko että muita kuin 1-on-1 pinoja ainakaan ensialkuun lähdetään tekemään. Sinänsä todennäköinen kyllä että tulee eDRAM tyyppinen ratkaisu IO piirin yhteyteen kuin jokaiselle piiriselle erikseen. Varsinkin jos jotain tensorirautaa tai muuta hämärää sisällytetään IO piiriin.

chiplettien päällä ongelmaksi tulee se, että schedulerin pitäisi ymmärtää että mitä keskusmuistialuetta säilytetään minkäkin chipletin päällä ja osata osoittaa sitä muistialuetta käyttävät säikeet kyseiselle chipletille, muuten kyseisen chipletin IF linkki menee potentiaalisesti pahastikkin tukkoon jos sieltä haetaan jatkuvasti dataa jonkun toisen chipletin säikeen toimesta. Tilanne jossa datasetti jakautuu kaikkien HBM pinojen kesken ja sitä käyttää satunnaisella patternilla kaikki säikeet tulee IF linkit olemaan aika pahasti tukossa joka suuntaan menevien muistihakujen takia ja IF kaistaa chiplettien ja IO piirin välille tarvitaan noin kaksinkertaisesti samaan suorituskykyyn verrattuna tilanteeseen jossa HBM pinot on IO piirin päällä. Lisäksi jäähdytys on helpompi ongelma ratkaista jos HBM pinot on IO piirin päällä.

HBM pinot chiplettien päällä on parempi vaihtoehto jos, ja vain jos, siellä säilytetään vain kyseisellä chipletillä ajossa olevien säikeiden käyttämää dataa. joku 8-16 gigan HBM on IMO aivan tarpeettoman iso LLC ratkaisuna ja siksi en usko että niitä chiplettien päälle iskettäisiin.

 

[-Cone-]

HBM pinot chiplettien päällä on parempi vaihtoehto jos, ja vain jos, siellä säilytetään vain kyseisellä chipletillä ajossa olevien säikeiden käyttämää dataa. joku 8-16 gigan HBM on IMO aivan tarpeettoman iso LLC ratkaisuna ja siksi en usko että niitä chiplettien päälle iskettäisiin.

Äkkiseltään näytti tuotokset olevat tarkoituttu datakeskusksiin, joissa on useampia spessukiihdyttimiä mm. kompressio- ja verkkokiihdyttimet, joka tehoprofiililtaan ovat soveltuvaisia myös toimimaan IO-piirin päällä. Voisi olla yksi käyttötapaus. Isoissa datakeskuksissa ajettavat erilaiset tallennusratkaisut ovat monesti sen verran massiviisia, ettei tuo 8-16 GB:n LLC äkkiseltään kuulosta pahaltakaan idealta. Ylivoimaisesti suurin osa tietokantoihin tulevista kyselyistä on kuitenkin yleensä lukuja, joten tuolla ratkaisulla mahdollistettaisiin erittäin hyvä hitrate LLC:lle ja siten pienempi tehonkulutus kun db löytyy LLC:stä. Nopeus on toki myös parempi. Sama koskee puhtaita in-memory db:itä. Nämä ovat tosin enemmän niche-käyttötapausia. Lisäksi hyvänä puolena on, ettei tuo vaadi erillistä softatukea.

 

[hkultala]

Isoissa datakeskuksissa ajettavat erilaiset tallennusratkaisut ovat monesti sen verran massiviisia, ettei tuo 8-16 GB:n LLC äkkiseltään kuulosta pahaltakaan idealta.

Gigatavuluokan LLC kaatuu siihen, että sen TAGit (kirjanpito) olisi liian iso. Jos ne TAGit on DRAMilla, ne on liian hitaita, ja jos ne TAGit on SRAMia itse piirillä, ne veisi aivan liikaa tilaa että piirin koko kasvaisi aivan liikaa.

Ainoa keino miten gigatavuluokan LLC:n voisi saada toteutettua ilman että TAGien koko räjähtää pilviin tai kaikki muistiaccessit käy hyvin hitaiksi hitaan TAG-accessin takia olisi se, että sillä LLCllä olisi järkyttävän isot välimuistilinjat. Mutta tämä olisi hyvin ongelmallista hyvin monella eri tavalla.

Intelillähän Crystal Wellin (64-128 MiB eDRAM LLC) kanssa n. neljäsosa piirin SRAM-L3-kakusta vaihtaa roolia sen eDRAM-LLC:n TAGeiksi.

 

[pomk]

Gigatavuluokan LLC kaatuu siihen, että sen TAGit (kirjanpito) olisi liian iso. Jos ne TAGit on DRAMilla, ne on liian hitaita, ja jos ne TAGit on SRAMia itse piirillä, ne veisi aivan liikaa tilaa että piirin koko kasvaisi aivan liikaa.

Ainoa keino miten gigatavuluokan LLC:n voisi saada totetutettua ilman että TAGien koko räjähtää pilviin tai kaikki muistiaccessit käy hyvin hitaiksi hitaan TAG-accessin takia olisi se, että sillä LLCllä olisi järkyttävän isot välimuistilinjat. Mutta tämä olisi hyvin ongelmallista hyvin monella eri tavalla.

Intelillähän Crystal Wellin (64-128 MiB eDRAM LLC) kanssa n. neljäsosa piirin SRAM-L3-kakusta vaihtaa roolia sen eDRAM-LLC:n TAGeiksi.

Epyc IO sirun jos tekisi 7nm tekniikalla, niin sinne mahtuisi kunnon läjä srammiakin, jota voisi käyttää noiden HBM pinojen tagien säilömiseen. Tai sit käyttää HBM pinoja yhteisen LLC:n sijaan vaan omana keskusmuistipoolina.

 

[zepi]

Oma "suosikkini" (joskaan ei kovin todennäköinen vaihtoehto) olisi seuraava:

Epyc + FPGA special versio jossa on 4x 8-ZEN ytimen chiplettiä x86:sta, io-die ja 4x xilinx FPGA-chiplettejä joiden alla on HBM-muistia tarjoamassa rivakkampaa työmuistia FPGA:ille.

 

[hkultala]

Epyc IO sirun jos tekisi 7nm tekniikalla, niin sinne mahtuisi kunnon läjä srammiakin, jota voisi käyttää noiden HBM pinojen tagien säilömiseen. Tai sit käyttää HBM pinoja yhteisen LLC:n sijaan vaan omana keskusmuistipoolina.

Juu, tämä olisi mahdollista, mutta aika kallista. Esim. 4 gigan välimuisti 52 tuetulla fyysisellä osoitebitillä ja 64 tiellä tarkoittaisi pikaisesti laskettuna 28 bitin osoitteen tagiosaa, tilabittit n. 3 lisää ja pyöristetään 32 bittiin. Ja 64 tavun linjakoolla välimuistilinjoja olisi 2^26 eli 64 miljoonaa kappaletta, eli TAGien koko olisi luokkaa 256 megaa.

Tosin IO-piirillä se välimuisti voisi olla memory side cacheä jolle sitä välimuistilinjan kokoa pystyisi kasvattamaan ilman koherenttiusongelmia ja aiheuttamatta ongelmia softalle näkyviin flushauskäskyihin, ja maltillinen kasvatus ei vielä aiheuttaisi pahoja muita ongelmia, 256-tavuisilla linjoilla 4 gigan kakun TAGit olisivat "vain" 64 megaa.

 

[demu]

AMD tarjoaa ensimmäisessä 3D-ratkaisussa 64MB SRAM -lisävälimuistia / Zen3 CCD.

AMD Demonstrates Stacked 3D V-Cache Technology: 192 MB at 2 TB/sec

www.anandtech.com

Today AMD presented the first stage of its 3D chiplet journey. The first application is a stacked cache on top of a standard processor chiplet. On stage, Lisa Su showcased one of AMD’s Ryzen 5000 dual-chiplet processors with Zen 3 cores. On one of the compute chiplets, a 64 MB SRAM built on TSMC’s 7nm was integrated on the top, effectively tripling the amount of cache that the cores have access to.

That means that the original Ryzen 5000 chiplet, with eight cores having access to 32 MB of L3 cache, now becomes an eight-core complex with access to 96 MB of L3 cache. The two dies are bonded with Through Silicon Vias (TSVs), passing power and data between the two. AMD claims that the total bandwidth of the L3 cache increases to beyond 2 TB/sec, which would technically be faster than the L1 cache on the die (but with higher latency).

As part of the chip diagram, the TSVs would be direct copper-to-copper bonding. The cache die is not the same size as the core complex, and as a result additional structural silicon is needed to ensure that there is equal pressure across both the bottom compute die and the top cache die. Both dies are thinned, with the goal to enable the new chiplet in the same substrate and heatspreader technology currently in use in Ryzen 5000 processors.


The prototype processor shown on stage had one of its chiplets using this new caching technology. The other chiplet was left as standard to show the difference, and the one chiplet that had the cache die ‘exposed’ made it obvious and comparable with the regular non- integrated chiplet. CEO Dr. Lisa Su said that the 64 MB SRAM in this case is a 6mm x 6mm design (36 mm2), which puts it at just under half the die area of a full Zen 3 chiplet.