AMD K12 AMD ZEN 17h - spekulace a info

[Maor]

Prostě nevim jak a komu by to masově prodali, nevidim v tom úspěch. Pokud se HSA prosadí tak to musí bejt zdola, tzn přes mainstreamSW. Shora ne, tam jsou mnohem rychlejší Xeony, larabe, testly, atd.

Ty velký APU by možná šly na servery na emulaci klientských session s GPU akcelerací. Kdyby k tomu udělali i nějaký superlevný Soc pro klienty, mohlo by to fungovat.
Ale stále si myslím, že 16core APU + HBM nedává smysl, protože to bude moc drahý pro spotřebitelský trh a v profi to je dost riskantní, pokud nemaj domluvenýho odběrtele a pak to bude semicustom a na volný trh se to nedostane.

[DOC_ZENITH]

S funkční GPU akcelerací... ve virtuálu... OK, fajn, k tomu ale potřebuješ VT-D,a nevim o tom ( to by asi dokázal odpovědět Spring, ten tady z místního fóra asi nejvíce virtualizuje ), že by šlo GPU sdílet. Tím chci říci, že můžeš sdílet CPU, ala jednotlivá CPU jádra přiřadit jednotlivejm mašinám, nebo je dát všechny všem ať si o ně bojujou, atd. Ale s GPu tohle udělat nemůžeš, ta je standard ve virtualu komplet emulovaná, a pokud použiješ VT-D, tak můžeš použít direct-IO, tzn sebereš defakto PCI-E slot a to co je v něm se napojí do virtual mašiny jako kdyby ten slot byl tam. Normálně tam pak nahraješ drivery a jedeš. To neni jen o GPU, ale o čemkoliv zapojeném, řadiče a pod.

Ale... GPU nejde sdílet, tzn v tu chvíli jej nemůže používat jinej virtual, ani host systém. Tzn AMD by muselo ještě vyvinout technologii jak sdílet i GPU skrze virtual mašiny. Jinak by jsi na každém CPU mohl mít max 1 (oka pokud by byly dual- node tak 2) instance s GPU, zbytek CPU only.

[havli]

Ja osobne teda neverim v uspech, at uz to bude APU nebo ne. Za vic nez 30let existence nedokazalo AMD vytvorit solidni vlastni navrh CPU. 286, 386, 486 vsechno kopirovani intelu. K5 sice Pentium P54 dokazala vesmes dorovnat (u nizsich modelu), ale za cenu dvojnasobne velkeho jadra a mizerneho skalovani s frekvenci. Posledni K5 koncila okolo 120 MHz, zatimco P54 na 200 MHz.
K6 koupena od Nexgenu - prvni 350nm varianty dokazaly sice konkurovat Pentiu MMX, ale za cenu dvojnasobne spotreby, pozdeji K6-2 a 3 docela ok, ale jen jako konkurence pro celerony.

K7 koupena tusim od Digitalu - na tu dobu perfektni CPU, casem upraveno na K8 a K10.... a tim to tak nejak konci. Od BD dal uz to vsichni zname, ani ty low power architektury za mnoho nestoji. Koupit hotovy navrh neni kde a vytvorit vlastni, mno uvidime.

[Raikkonen]

Já zase v úspěch spíše věřím. Proč? Protože Zen určitě nebude horší než Bulldozer a jeho následovníci. Stačí být vcelku konkurenceschopný, nasadit levnější cenu úměrnou nižšímu výkonu a hlavně mít slušný výrobní proces a rozměry čipu. I když to nebude trhač asfaltu, tak to AMD dá šanci vedle monopolního Intelu slušně přežít. AMD akorát nesmí podlehnout opět nějakému sebeklamu a jít do hloupé cenové války, kterou by stejně mohla vyhrát jen zázrakem. Horší by bylo, kdyby Intel musel sám šlápnout na plyn kvůli jiné konkurenci (např. ARM), ale to by snad ještě pár let hrozit nemělo.

[Maor]

DOC: VDI už firepro má, s virtualizací desktopu pro vícero klientů problém neni. plné 3D akcelerace bysme se mohli dočkat s DX12.

[DOC_ZENITH]

API s tim nemá co dělat. To musej uměr virtualizační schopnosti HW a SW, host OS, typicky třeba Vmware ESX a pod. Koukal jsem na to firepro a je to napůl cesty, je to defakto emulace kde se na něco používá GPU a na něco emulace, proto třeba omezení na DX9 a pod. Chtělo by to full feature, co umí GPU dostupné na všech virtualech.

Raikkonen - Co znamená lepší jak Bulldozer? Víš... v dobách kdy AMD stálo za to byli každou generaci kandidát na top CPU, ne kandidát na něco pomalého + levného co bude lepší jak Bulldozer. Řekněme to naplno, uplnyuly 4 roky od 32nm sandyho, pokud to nebude lepší jak Sandy (jak IPC tak celkovej výkon) tak epic fail, obvzláště má li to bejt 14nm finfet produkce.

[yuri.cs]

Rika se, ze hlavni otazky HPC sveta je prenos dat. Netusim, jestli je zrovna po tomhle poptavka, ale jestli je, tak HPC segment si rad zaplati za obri APU.

I Bobcat porazil Tahiti pokud mu sedel typ ulohy, takze dat mu primo Tahiti GPU?

[DOC_ZENITH]

Přenos dat kam? mezi CPU a GPU? A co když bude GPU CPU capable? Píše se rok 2016 nebo 17, to už NV bude mít pascall s NVlinkem, nebo, proč proto třeba nepoužít larabe kterej se dá použít jako koprocesor či přímo jako tuna x86 CPU. Opět poukazuji, kde to má kupce že neni lepší alternativa, já to místo na trhu momentálně nevidim.

[Maor]

Nakonec to stejně skončí akorát ve steam machines a noteboocích.

[flanker]

A je to tu

[webwalker]

Přenos dat kam? mezi CPU a GPU? A co když bude GPU CPU capable? Píše se rok 2016 nebo 17, to už NV bude mít pascall s NVlinkem, nebo, proč proto třeba nepoužít larabe kterej se dá použít jako koprocesor či přímo jako tuna x86 CPU. Opět poukazuji, kde to má kupce že neni lepší alternativa, já to místo na trhu momentálně nevidim.

Na NVlink bys musel ukecat Intel, nebo myslíš, že IBM je rozhodující v tomhle byznysu? Navíc u NVlink nebo LRB se jedná stejně o připojení externí linkou, která těžko asi bude konkurovat vnitřnímu busu, ale kdo ví?

[DOC_ZENITH]

To právě má dělat, nahradit PCI-E (kterej nikdy nebyl na GPGPU stavěnej) a fungovat na bázi rychlého bezlatenčního přístupu, něco jak funguje dejme tomu QPI či HT. A to jsou sběrnice tak rychlé že neavdí když jsou data v ram či i cache jiného CPU. O odstranění tohoto přesně jde, současná komunikace mezi RAM a Vram je totiž dost zkriplená, Vram-řadičGPU-front-end GPU-PEG-PEG v CPU-NB/řadič CPU-RAM na CPU. HSA umí i non-APU Radeony, ala HSA zprostředkuje možnost pracovat s daty Vram a RAM jako s jednim unifikovanym prostorem, ale pro zkrouhnutí oněch latencí je právě třeba nové sběrnice.

Co se superpočítačů pro GPU výpočty týče, tak architektura CPU je celkem druhořadá (pokud se samotné CPU bude starat jen o distribuci dat, nebude samo také něco počítat). Třeba oak ridge s prvníma Teslama K6000 běhal na bází G34 FX opteronů první generace. Bylo to efektivn ířešení? Ihmo ne, ale aby tam idlovaly a dristribuovaly data jedotlivejm GPU to stačilo.

Prostě nevim jako ono velké APU bude silěnjší jak Xeony s Larabe či Teslama...nevim no. + V budoucnu ještě něco od IBM, NVlink od NV, a to nepočítám ten moment kdy GPU budou defakto samočinná, ala jejich CPU schopnosti budou natolik dosbré že budou moc spouštět kód samy na sobě ve své paměti aniž by musely komunikovat s host OS/CPU, tam budou jen odesílat výsledy či získávat nové úkoly.

[yuri.cs]

Cray Titan aka Tesla K6000 + 16c BD... Cray mel dlouhou dobu celou architekturu postavenou na HT only, takze AMD bylo jaksi dane. Proto ho docela mrzely odklady BD a pak konecny vysledek. V dusledku presel na QPI Intely.

AMD ma knowhow na interconnety vseho druhu at uz inhouse nebo od SeaMicro. Nejaky fabric je vyvyjeny uz od doby zruseni G/C2012 - ucel je skalovatelne propojeni APU/GPU/CPU.

[DOC_ZENITH]

Cray je cluster, jednotlivé bloky spolu komunikují stylem jako kdyby byly na síti. Rozhodně neni PC to PC komunikace na bázi HT. HT je tam jako součást G34 platformy na které je to postavené, ala propojuje chipset + jednotlivá CPU a to jest vše, nic víc nic míň a už v té době bylo dost zastaralé. G34 podporuje jen 2Ghz HT a PCI-E 2.0, z northbridge jde max 32 linek total, žádná sláva. A 3.0 ani mít nemůže protože 2Ghz HT na to nemá dost dobrou prostupnost.

Ta platfroma je tam jen jako nutné zlo, podvozek co zásobuje GPU daty, to jest vše. A G34 už v té době byla pro toto dost au au nedostatečná. Problém byl že nebylo moc alternativ, bylo to v době kdy LGA2011 ještě moc použít nešlo (early ES měly tunu bugů s PEG, VT-D a pod), a starej Nehalem/Westemere based se jim asi nechtělo a oddalovat celej proces také ne. Já si myslim že G34 byla takové nutné zlo + byla levná.

[del42sa]

http://www.fudzilla.com/news/processors ... u-detailed

16 jader (32 threads) čili SMT , 16GB HBM, 4 channel DDR4, Greenland GPU

Each Zen core gets 512 KB of L2 cache and each cluster or four Zen cores is sharing 8MB L3 cache. In case we are talking about a 16-core, 32-thread next generation Zen based x86 processor, the total amount of L2 cache gets to a whopping 8MB, backed by 32MB of L3 cache.

klastr se čtyřmi jádry to hodně připomíná Jaguar doplněný o L3 cache a SMT

[flanker]

wow, to nevypadá zle! Pokud to teda stihnou včas

[del42sa]

tohle je ale pro HPC ne do desktopu

AMD is using coherent fabrics to interconnect the Zen CPU die and Greenland graphics die, and it also uses coherent fabric for inter communication between Zen die CPUs and Caches, PSP, Times, counters, ACPI or Legacy interface, GMI Physics, Combo Physics, Host Controllers like USD, SATA or GbE and Memory controllers. GMI stands for Global Memory interconnect and this is the interface between Zen die and Greenland die, or between two chips on the same multi-chip module package.

to by potvrzovalo nějaký nový interconnect jako náhrada za Hyper Transport.

Otázkou zůstává odkud to všechno Fudzilla vycucala

[flanker]

takže servery jakoby, ale z toho by šel stavět i desktop, ne? 5ekněmě 4C/8smt nebo 8C/16smt

[DOC_ZENITH]

Je otázka čemu řikaj clustery. Aby se to nechovalo separaticsticky (jako G34 CPU) tzn L3 by byly nesdílené a jednotlivé bloky by byly Numa nody, to by v serverech neuspělo protože 1 CPU už by byl 4x numa.

Dále náčrt vypadá že i přes parametry by CPU část vůči ostatním byla dost pidi, tzn čekat od ňí výkon zní docela jako utopie. Když doplnim slow jaguar o 4x tolik jader L3 a dam mu SMT pořád to bude děsně slow CPU. Tohle do desktopu nemůže, pokud nehrabnou i na IPC a nepoběží to na 4Ghz. A to vzhledem k velikosti jádra nevypadá.

[Maor]

Potuněný jaguar na 4GHz s L3, no nezní to zle, pořád lepší než PD a osobně ani moc velký výkon v single nepotřebuju, jen to nesmí být tragédie.
Jen se bojím ceny