Tycker det kvarstår ett rätt rejält frågetecken kring hur mycket desktop Zen2 kommer skilja sig från server Zen2. Personligen tror jag det är ett misstag att försöka återanvända allt för mycket i båda segmenten då deras krav har divergerat rätt kraftigt senaste 10-15 åren.
Ser flera dra slutsatsen att CPU-kretsarna numera skulle bestå av en CCX med 8-kärnor. Finns det någon konkret information alls som pekar på detta? Det som talar emot är
man verkar inte ha ändrat mikroarkitekturen speciellt mycket utöver att öka bredden på SIMD-enheterna till 256-bitar
kärnor och L3$ är ihopkopplade med en cross-bar i Zen, om man inte ändrat detta till Zen2 känns 8 kärnor per CCX rätt osannolikt då antalet transistorer ökar exponentiellt(!) med antalet kopplingar i en x-bar. X-bar har fördelar i att ha väldigt låg och helt homogen latens för alla noder, nackdelen är hur den skalar
Också rätt mycket spekulation kring om PCIe-kontroller ligger i I/O-kretsen eller i CPU-kretsarna. AnandTech spekulerar att PCIe ligger i CPU-kretsarna, vilket beroende på hur man tänkt göra desktop-varianten kan vara vettigt. Men hoppas ändå AT spekulerar fel här och finns lite saker som blir konstigt om PCIe-kontroller inte ligger i I/O-kretsen.
Både Epyc och Ryzen är pin-kompatibel, så antalet PCIe lär vara det samma. Då man dubblat antalet CPU-kretsar i Epyc Rome skulle endera hälften av kretsarna ha 32-PCIe (vilket är fallet i Zen1) alt. så skulle alla fått 16-PCIe vilket ställer till det för desktop då den plattformen behöver 24 PCIe (16 till GPU och liknande, 4 är dedicerade till NVMe samt 4 går till chipset). Ligger PCIe-kontroller i I/O-chippet krävs bara en variant av kretsen för desktop (om nu desktop ens har en I/O-krets).
Sågade Epyc Naples designen vid fotknölarna när den lanserades förra året, en sågning som sågades av den AMD-vänliga expertpanelen här på forumet (tydligen var problemet bara att vi programmerare inte är kapabla att lösa saker som att kommunicera snabbare än ljuset och så...). Tycker ändå det faktum att man helt designade om den delen pekar på att man efter två försök (Magny Cours och Epyc Naples) med i princip identiskt resultat borde kunna dra slutsatsen att det inte är en gångbar väg.
Vad man nu har gjort kommer fungera, det är en redan beprövad teknik. Vad man gör nu är på ett logiskt plan helt identiskt med tidigare front-side bus + north-bridge. Är ju det Intel gjorde med Core2Quad (två klistrade kärnor, men OS:et samt program såg och kunde jobba med resultatet som en CPU inte som flera separata CPUer som råkar dela paket).
Faktum är att IBM har en produkt med väldigt snarlik design, zEnterprise 196
Flera CPU chiplets kopplade till en I/O-krets
Och rimligen borde förklaringen till den väldigt stora I/O-kretsen i Epyc Rome ligga i att man stoppat dit en relativt stor L4$.
Att återgå till en front-side bus (som nu råkar prata infinity fabric protokollet) och north-bridge ger högre minneslatens. Går inte att fixa latensen mot RAM, men däremot kan man minska genomsnittlig latens som CPU-kretsarna "ser" genom att stoppa in L4$ i I/O-kretsen.
På det stora hela: detta är, till skillnad från Naples, "chiplets done right"!!!
Ovan ställer än mer frågetecken kring hur desktop Zen2 kommer se ut. En stor L4$ är inte direkt billig och även om en sådan minskar genomsnittlig latens så ökar varje extra nivå av cache latens mot RAM. För desktop är latens viktigare än för servers, så frågan är om man ändå skapar en speciell desktop variant av CPU-kretsen där minneskontroller fortfarande är integrerad.
Om så är fallet lär vi se samma sak mellan Ryzen och Threadripper som vi ser mellan SKL-S och SKL-X, HEDT kommer tappa prestanda relativt konsumentversioner för de flesta program. Självklart finns nischer där HEDT ändå är vettig, men det blir då som SKL-X där nischen klart krymper i storlek.
