Liittyen keskusteluun. AMD:llä on pitkään on chiplet visio ja on ihmetelty monta sukupolvea että mikä nVidialla on vikana kun eivät saa chiplet tuotantoaan toimimaan. Onkohan lie kuitenkin niin nykyisen spekulaation valossa että nVidia on tasan tarkkaan tiennyt että jos haluavat olla se defacto nopein/paras niin se nyt vain valitettavasti on niin että siihen ei chiplettejä kannata sotkea? Monoliitti ratkaisulla on myös ne hyvät puolensa ja näyttääkin siltä että nVidia tulee porskuttamaan super kalliiden monoliittien kanssa vielä tovin. Muuttuuko ne super-kalliista hyper-kalliiksi? Ehkä. Mutta se on kummeli termein:"Onks se hyvä? Se on paras!"
Ajattelutapa "monoliitti vs chiplet" on väärä. Relevantimpi ajattelutapa on "UMA vs NUMA". Ja jotkut chiplet-ratkaisut vaatii/implikoi NUMAa, toiset ei.
Vaikka AMDllä on useampi piilastu monessa paketissaaan (sekä CPUissa että näyttiksissä), on AMDllä arkkitehtuuri kaikissa nykypaketeissaan arkkitehtuuri paketin sisällä edelleen UMA eikä NUMA, eli muistiviive kaikkialta kaikkialle on yhtä nopea.
AMDn CPU-piireissä on yksi muistiohjainpiilastu, ja kaikki liikenne kulkee sen kautta, ja itse laskenta on hajautettu monelle laskentapiilastulle. AMDn Navi31/navi32-näyttiksissä taas on yksi laskentapiilastu, mutta jokainen muistikanava tai pari muistikanavia on saanut oman muistiohjainpiilastunsa (jossa on myös sitä muistialuetta kakuttava L3-kakku).
Kummassakaan ratkaisussa ei synny mitään ongelmia sen suhteen, että data voi olla eri paikassa kuin missä laskenta halutaan tehdä (tosin muistin viiveet toki on pidemmät verrattuna ratkaisuun, jossa muistiohjaimet olisi samalla piilastulla, mutta näyttiksissä kaista on tärkeämpää kuin viiveet).
Sen sijaan NUMA-arkkitehtuurissa, jossa on sekä monta eri muistiohjaimen sisältävää piilastua että monta eri laskennan tekevää piilastua, tulee ongelmia siitä, että jos data on "väärässä paikassa", laskenta hidastuu selvästi dataa odotellessa, ja geneerisessä tapauksessa on monimutkainen liian monia tuntemattomia muuttujia sisältävä optimointiongelma yrittää sijoitella dataa lähelle sellaista laskentayksikköä, jossa sillä lasketaan.
(Sen sijaan NUMA toimii hyvin, jos ei yritetä laskea geneerisiä workloadeja vain vain sellaisia workloadeja, joista tiedetään ennakolta että se data ja laskenta voidaan sijoitella aina "ystävällisesti"). Ja kun systeemi menee tarpeeksi järeäksi, UMA ei vaan ole vaihtoehto, koska sitten se muisti alkaisi käydä kaikille aina hitaaksi.
Esim. AMDn ekan sukupolven Zen-palvelinmallit ja threadripperit oli NUMA, niissä samalla piilastulla oli sekä laskenta että muistiohjaimet, mutta näitä piilastuja oli paketissa useampia (mutta zen2n myötä siirryttiin UMAan kun tuli vain yksi järeä muistiohjainpiiri). Ja intelillä taitaa nyt tuoreimman sapphire rapids-palvelinpiirit olla myös NUMA.
Ja monen soketin kokoonpanot on sitten viimeiset reilut parikymmentä vuotta olleet pakettien välillä NUMA.
Mutta esim. näyttiksissä NUMA on ongelmallinen sen suhteen, että vaikka itse pääframepuskurin saakin yksinkertaisessa hajautettua sen laskentapiilastun yhteyteen, joka sinne piirtää, siellä on paljon esim. tekstuuridataa joka pitäisi sitten duplikoida kaikkiin muisteihin että se olisi nopeaa kaikille. Ja suurempia ongelmia tulee siinä vaiheessa, kun aletaan tehdä esim. "render to texture"-temppuja, jos nämä tekstuurit pitäisi sekä jakaa kokonaisuudessaan kaikille piireille, mutta niiden sisäisesti laskenta halutaan hajauttaa, tästä seuraa suuri kaistapullonkaula.
