AMD Steamroller/Excavator (28nm)-informace, spekulace

[del42sa]

zatim jsou vsechny narusty vykonu pouze teoreticke,pouze na zaklade simulaci. Vzdyt AMD nema zatim ani fukcni samply. Staci vzpomenout na Bulldozer.ten taky v simulacich vychazel jako crushing monster a realita byla vime jaka. Vykon na jadro horsi nez minula generace ....

[THANATOS]

45% v priemere je cista utopia. Toto su len simulacie, takze mozu byt pravdive aj nemusia ako sme zbadali pri BD, alebo tie simulacie pre BD boli v skutocnosti pre SR Najvacsi tahak bude aj tak IGP, ktore pri troche stastia bude mat nejaku vlastnu pamat, aby nebol bandwidth starved.

[flanker]

proto jsem napsal slůvko "až" 45%, ne průměr. A nikdy se neporovnává v prezentacích výkon na takt, ale výsledný prodejní takt, případně i to, že by Zambezi bylo 8-core a Steamroller (čistě náhodou kdyby...) 10 core.

[THANATOS]

flanker nemyslel som konkretne teba, ale ten clanok. Nemyslim si, ze porovnavali 4M vs 5M, ale mozem sa mylit.

[flanker]

průměr asi ne, leda iGPU, 45% nárust je z říše fantazie, to snad neměl žádný procesor za posledních 6 let...

[yuri.cs]

FM2 by mel byt kompatibilni se dvema nastupci Trinity - zrejme Trinity 2.0 i Kaveri

http://chinese.vr-zone.com/34275/amd-tr ... -09182012/

[del42sa]

Kaveri má mít sideport pro integrovanou grafiku a ten bude určitě potřebovat nějaké ty piny z patice navíc oproti FM2, čili tipuji něco jako "FM3" patici nebo "FM2+" která bude pro Kaveri APU, ale tentokrát zřejmě kompatibilní s Trinity/Trinity 2.0 (narozdíl od nekompatibility patic FM1 versus FM2)

PS: je také docela možné že vylepšené Trinity 2.0 bude mít sideport také. Toto řešení bude mnohem levnější než stohované paměti ala TSV + interposer.


\\ věrohodného zatím nic http://lenzfire.com/2011/10/amd-trinity ... too-22431/

\\\ ale už Llano je limitováno paměťovou propustností a Trinity potažmo Kaveri na tom budou ještě hůře. TSV je sice elegantní řešení, ale jak se ukazuje na Haswellu bude se jednat o řešení poměrně drahé, což nekoresponduje s "cenově dostupnými řešeními" od AMD. Zatím se tedy zdá, že TSV/interposer ani triple channel u AMD APU nehrozí, takže nejpravděpodobněším řešením je SIDEPORT. Jaká ale bude konkrétní implementace zatím nikdo neví....

\\\\ něco přece, jedná se sice o mobilní verzi s jiným socketem, ale těmi 512MB video memory nemůže být myšlena systémová paměť:

One of the AMD Linux engineering systems for Trinity is running nicely even on Ubuntu 11.04 with the Linux 2.6.38 kernel. The CPU string is AMD Eng Sample 2M252057C4450_32/25/16_9900_609 and its graphics are the Trinity Devastator Mobile with 512MB of video memory and an AMD Pumori motherboard. The PCI ID on the Trinity Devastator appears to be 0x9900. This Trinity APU is quad-core and running at 2.50GHz. The current quad-core Llano offerings are clocked at 2.6GHz (A6-3650) and 2.9GHz (A8-3850), while this Trinity part is clocked slower, it's numbers are nice compared to my A8-3850 Linux system

http://www.phoronix.com/scan.php?page=a ... arly&num=1

ale možná je to celé jenom špatně pochopeno a žádný SIDEPORT se nekoná Každopádně ať už AMD zvolí jakékoliv řešení, nejspíše se podobně jako u Haswellu toto vylepšení bude týkat jen mobilních verzí APU, kde to i dává větší smysl (kvůli pomalejším operačním pamětem a navíc single channelu) než v desktopu, kde se operační paměti (navíc v dual channel ) dají snadno přetaktovat.

[yuri.cs]

Je nekde k nalezeni neco verohodneho o tom, ze pamet. system Kaveri nebude totozny s Llano/Trinity?

//nemam ted cas na freepatentsonline.com, ale neverim, ze by AMD melo uz s Kaveri nejakou super cool novou technologii. AMD = value, Intel bude svoji pamet tlacit jenom v te opravdu 'premium' class. Tam nema AMD co delat. Bylo by tez neco slyset - AMD ma skluz v technologiich a timhle by ho pekne dohnala.

//Po Llano SUMO je DEVASTATOR grafika Trinity. Nic vic, nic min.

[webwalker]

V každém případě by imho pro sideport byl nutný další paměťový řadič pro VRAM. Llano bylo na řadič RAM připojeno 256b sběrnicí. Pokud by VRAM byla nějaká DDR5 stačilo by asi 128b, ale je FM2 na tohle připraven???

[del42sa]

To je právě otázka.... Nejspíše není. FM2 má jen o jeden pin navíc oproti FM1. Takže buď bude muset být nová patice (FM2+ nebo rovnou FM3 ?) s podporou SIDEPORTu nebo to nějak navěsí na jeden DDR3 kanál přes nějaký switch. ( i když to by bylo celkem prasácké řešení)

\\Yuri: odněkud se to info o té (ne)systémové videopaměti pro Devastator vzalo (nejspíše z ovladačů nebo biosu)

Nějak tomu že by se AMD podařilo už na Kaveri dostat řešení co zatím existuje jen jako prototyp moc nechce věřit (obzvláště co po IDF 2012 začalo prosakovat, že to bude cenově ne zrovna levné řešení které zatím má pořád své mouchy)

SIDEPORT by byl jako řešení nejlevnější a nejjednodušší vzhledem k ceně. Jeden 128-Bit GDDR5 čip by byl přiletovaný přímo na základní desce, což mi k levnému řešení ala AMD pasuje....

\\\ leda že by byl Sideport pořešen v rámci package. Pak by patice FM2 mohla zůstat stejná a změny by se odehrály jen uvnitř čipu. Díky za tip NO-Xovi (nejednalo by se vlastně o TSV, ale jen o jeden GDDR5 čip v rámci balení APU čipu) Něco jako embeded Radeony E6460 :

[flanker]

Mno, pokud je to pravda, dočkáme se konečně AMD FX1090FX?:)

CHIP DESIGNER AMD has said that its upcoming Vishera chip will not be the last to use Socket AM3+.

AMD's desktop Piledriver processor, which is better known by its Vishera codename, will use the firm's Socket AM3+, effectively meaning the chip is a drop-in replacement from previous generation Zambezi processors. The firm said that it will continue to support the AM3+ socket and that this won't be the last processor to use the socket.


AMD's statement regarding top-to-bottom socket compatibility means that its upcoming accelerated processor units (APUs) will have another three years or so using the FM2 socket that will make its debut with Trinity in October. The firm said Trinity's use of FM2 will be the last socket change before it standardises on one socket for all of its desktop processors.


http://www.theinquirer.net/inquirer/new ... teamroller

PS: já bych uvátal nějaký redesign a něco iplmementoval do procesoru.

[del42sa]

http://extrahardware.cnews.cz/socket-am ... at-ci-fama

BTW v téhle souvislosti by mě docela zajímalo jak se liší serverový CPU Delhi od Vishery ??? Jedná se o stejné CPU nebo Delhi podporuje více instrukcí než Vishera ? viz: http://pctforum.tyden.cz/viewtopic.php? ... U#p8265132

V případě CPU Zurich (socket AM3+) se snad jedná o totožné CPU jako Bulldozer jen s podporou ECC ( ale tu snad umí BD také nebo ? )

[flanker]

Pozor, to, že je nějaký socket nemá nic přece společného s CPU. Samotný socket u FX není plně využíván (jedne enbo dva volné piny) a většina těch pinů slkouží přímo k napájení CPU části. Už FX Zambezi má na svém die místo pro PCIe řadič. Kdyby byl v procesoru, nemá to nic proti socketu AM3+. V tom byhc problém neviděl. Například čipset s emůže jmenovat nově 1090FX.

[yuri.cs]

A je tu GCC bdver3/SR patch. I kdyz je lehce zvlastni...

Rozsireni x86 jsou ty same jako u PD. FP pipes jsou ocekavatelne FMA0, FMA1 a FSTO. L1D zustava na 16k a L2 na 2MB. Prefetche jsou nekam ukladany (do nekonecne struktury...).

Fetch je (32B?) za 2 cykly. Poznamky udavaji u SR 3 FastPath (single/double) dekodery a 1 VectorPath (microcode) - neni nikterak zmineno, ze je to cele 2x. FP a VP, klasicky, nebezi paralelne. Ovsem text zminuje, ze 1 dekoder zpracuje 4 mops/2 cykly...

Smysl to moc nedava.

http://www.phoronix.com/scan.php?page=n ... px=MTIwNDY
//OK. Takze brano z pohledu 1 threadu. Dekoder dostava od data jednou za 2 cykly a ma 3 + 1 konfiguraci. Otazka velikosti fetche je nezodpovezena.

[del42sa]

Takže jeden cyklus jeden dekodér ( thread/jádro 1) druhý cyklus druhý dekodér ( thread/jádro 2 ) ??? Fetch tedy střídavě "krmí" oba dekodéry. Pořád tu ale zůstává otázka , jak se popere zeštíhlená FPU (pouze tři pipeline místo čtyř) s až 8 macro-ops od obou dekodérů a jak to bude řešeno ? (který dekodér bude mít přednost ?) Nebude to pro FPU overkill ?? viz diskuze Možná je to částečně pořešeno právě tím střídavým fetchem (jednou za dva cykly), není to ale ve výsledku stejné jako mít jeden dekodér a fetch každý cyklus ?

[yuri.cs]

Dle toho updatu to vypada na max 6 mops. Dlouha mikrokod vyuzivajici instrukce v BD/PD zablokovala celej dekoder pro obe vlakna. Tady to druhe pobezi nerusene dal.

FPU muze mit buffer nebo proste zastavi fetch.

Zvlastni je ale to, ze to zni, jako by to fungovalo skutecne cyklus/cyklus a nebylo mozno priradit jednomu jadru cely fetch (coz BD IIRC umi).

[webwalker]

U BD bylo popsáno, nepletu-li se, IFetch 16B+16B pro modul nebo max. 22B pro single thread.
Dekódování přes microcode samozřejmě vše zablokovalo, ale bylo tam tuším ještě jedno omezení a to dekódovat v jednom taktu do 2x2mops, vždycky pouze 2+1+1 nebo 1+2+1 nebo 1+1+2 mops.
Popravdě mě ale tohle moc netrápí, tato vylepšení se všechna týkají průchodnosti threadů v modulu (který je proti Intelu a HTT už tak dobrý), nikoliv navýšení IPC v single-threadu.

[flanker]

je vůbec nějaká cesta, jak významněji v BD navýšit IPC v singlu? Hlavně x87? X86 ještě není až tak špatná...

[del42sa]

Intel jde cestou - více ex. jednotek, více portů, univerzálnější L/S jednotky, wide FPU jednotky, větší registry.

AMD od Bulldozeru jde cestou méně ex. jednotek (méně ALU), sdílená 128 bit FPU (nyní jen tři jednotky místo 4), gigantická cache s pomalým zápisem. Tohle prostě ani dva dekodéry nevyřeší....

Když nad tím tak přemýšlím a koukám na to rozložení ALU/AGU tak stále více ve mně sílí podezření, že těch udávaných až 4 macro-ops pro dekodér Bulldozeru je ve skutečnosti spíše 2 x 2 macro-ops (2macro-ops per core) Takže ve finále nejen že ubylo ALU oproti Phenomu, ale i decodér se ve výsledku "smrsknul" (2mops/jádro u BD verus 3mops/jádro u Ph II)

Navíc mi původní rozložení ALU/AGU (3+3) u Phenomu II přišlo mnohem flexibilnější než 2+2 uspořádání u BD. Vždyť BD/PD potřebuje téměř o 1GHz vyšší takty, aby se vůbec mohl poměřovat výkonově se starším Ph II.

A ten střídavý fetch u Steamrolleru mi přijde také hodně zvláštní řešení. Všechny ty "zlepšováky" v modulární architektuře mi přijou nějaké překombinované.Stejně s tím přidáním dalšího dekodéru u ST defakto myšlenka modulu ztrácí svůj původní význam, protože se tím z jednoho modulu se dvěma INT clustery staly v podstatě dvě opravdové jádra,které sdílí FPU..

It is when the whole point of cluster disappeared. In BD you have 1 decoder, 2 integer clusters and 1 FPU. In Steamroller you have 2 cores and 1 FPU. The cluster turned into a core by having its dedicated decoder.

Nakonec AMD stejně přijde na to, že nejlepší řešení pro výkon bude vrátit se ke klasickému systému jader jaké používá Intel

Jsem opravdu velice zvědavý na reálný výkon Steamrolleru


PS: ohledně toho zvýšení IPC, zvláštní na tom celém je to, že jakmile někdo navrhne aby AMD přidalo do modulu více jednotek, více ALU, aby udělala 256 bit FPU tak se okamžitě objeví protiargumenty, že by to příliš zvedlo spotřebu, velikost die, komplexitu , že to je zbytečné, že je na tom AMD dobře a já nevím co ještě, ale že to samé dělá s úspěchem Intel a přitom v každé nové generaci mají jeho CPU menší spotřebu to už nějak těm mudrlantům z SA nedochází

[ttxman]

je vůbec nějaká cesta, jak významněji v BD navýšit IPC v singlu? Hlavně x87? X86 ještě není až tak špatná...

Ja kdybych si mel tipnout, tak by vykonu pomohlo vylepseni cache (L1,L2,L3) aspon na uroven intelu(rychlost, writeback, ..)

Pro x87, pri zachovani modularnosti udelat aby 256bit FPU zvladala 4* 64bit instrukci.