[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[Polpi_91]

secondo me il quad channel lo vedremo solo nei server con piledriver perchè altrimenti AMD dovrebbe cambiare sia mobo, che socket che chipset mentre si sa che ha annunciato per la fascia desktop il chipset 1090fx (che non è altro che un 990FX migliorato) su socket AM3+

[shellx]

Originariamente inviato da Polpi_91

secondo me il quad channel lo vedremo solo nei server con piledriver perchè altrimenti AMD dovrebbe cambiare sia mobo, che socket che chipset mentre si sa che ha annunciato per la fascia desktop il chipset 1090fx (che non è altro che un 990FX migliorato) su socket AM3+

mobo e socket no, il chipset si...
magari sarà proprio la novità nel chipset 1090FX e per tutto il resto sarà una normale revisione del 990FX?

[papafoxtrot]

Originariamente inviato da shellx

Comunque prima leggevo il discorso che ti sei fatto con papafoxtrot sule IOMMU.
Lui dice che le IOMMU 2 sono perché trinity ha la gpu integrata, e quindi il controller ram è unico tra CPU e GPU.
Invece la IOMMU 1 è quella classica, che permette di passare i puntatori alla memoria ad un'altro MC, di una GPU su pci-express.

Potreste spiegarmi meglio questo concetto ?
Nel caso io avessi un trinity e contemporaneamente una scheda video discreta su pci-e , come si compoeta per l'accesso su gpu su pci-express ?

Allora:
Le iommu servono per consentire al controller di memoria della GPU di prelevarsi i dati dalla ram principale, almeno questo nel caso delle GPU discrete.
Per come sono ora le cose (senza IOMMU), se devo eseguire un calcolo sulla GPU, devo prima trasferire tutti i dati di input dalla memoria centrale alla memoria della GPU, e questo è gestito a livello di codice e compilazione del software. A quel punto l'elaborazione può cominciare.
Nel caso di Llano, la ram è fisicamente la stessa tra CPU e GPU, ma in realtà è partizionata, per cui di nuovo, prima di iniziare l'elaborazione devo prelevare i dati da una parte della ram (quella cpu), portarli al memory controller, e di qui reinviarli alla ram, ma dalla parte dedicata alla GPU.

Con le IOMMU 1 cosa posso fare? Quando alla GPU, nel corso del calcolo, serve un dato, il processore passerà il puntatore alla cella di memoria centrale che lo contiene al MC della GPU, il quale potrà così andare a leggerselo.
Il problema in pratica era di mappatura della memoria; la GPU poteva anche accedere alla ram centrale, ma non conoscendo la disposizione dei dati non avrebbe potuto fare nulla. La CPU ora può "dire" alla GPU "il dato che ti serve è li"".

Con Trinity il discorso è ancora diverso. Il memory controller è lo stesso, ma serve sia la CPU, sia la GPU. Se alla GPU serve un dato, il mc non deve interrogare nessuno per sapere dove si trova, perché è lui stesso a mappare l'intera ram centrale. Per cui basta che faccia riferimento alla mappatura della memoria dedicata alla cpu e vada a prelevare il dato, mandandolo poi alla GPU.

L'ultimo livello di integrazione sarà invece quello di avere una mappatura unica della memoria, in cui la ram non sarà partizionata, ma sarà condivisa tra CPU e GPU; non vorrei sbagliarmi, ma a quanto ho capito questo livello di integrazione arriverà solo successivamente.

[Cocco83]

Originariamente inviato da Trokji

In teressante il passo diretto al quad channell, bypassando il tri -channell.
Anche se penso sia una mossa più preventiva e di marketing che di reale necessità per le prestazioni, visto che le ddr3 dual ancora non sono sfruttate appieno, nè tantomeno è data di default la compatibilità con ddr3 a frequenza abbastanza elevata come le ddr3 2000, e visto che a fine anno dovremmo già vedere le prime ddr4.
10 cores sicuramente è molto interessante, ma quello di cui c'è bisogno realmente è un aumento dell'ipc abbinato ad un boost delel frequenze di minimo 1 ghz..
Magari con cpu così supererebbero (sperano anche in consumi in oc non più così imbarazzanti) sb e2500-600-700, mentre ivy e sb-e sono ancora probabilmente fuori portata

Originariamente inviato da gefri

tutta la banda ram dovrebbe tornare utile per la parte gpu (so che e` assente).
magari si preparano ai futuri fusion, con la gpu che svolgera` un ruolo importante nei calcoli virgola mobile (e` da steamroller che esisteranno solo apu?).

secondo me come è stato fatto notare il quad tornerà molto utile per sfruttare la serie 7 fornendogli una banda enorme.... adesso se non sbaglio la 7970 ha bus a 384bit e 3gb di ram per mi pare 250Gb/s di dati.....

[Trokji]

sì ma una gpu come quella della attuale 7970 forse si vedrà su un'apu tra 10 anni..

[papafoxtrot]

Ci ho pensato adesso: se sarà implementato su tutte le CPU, anche desktop, il MC quad channel servirà per supportare le specifiche IOMMU: in pratica ora come ora la GPU, grazie alle IOMMU, può certo accedere alla memoria centrale, ma già questa è separata dalla GPU da una filadi link (pci-express - Hyper transport), e le latenze si alzano.
Se poi la memoria ram è così lenta rispetto a quella della GPU si perde ogni vantaggio, e torna ad essere conveniente il precaricamento di tutti i dati, come si fa ora.
Con un bel quad channel si può riservare abbastanza banda alle GPU, anche discrete, che necessitino di accedere alla ram centrale. Certo si guadagnerà bene dall'integrazione del controller pci-e sulla cpu, da questo punto di vista, ma credo che l'abbiano rimandato per evitare di portare un'altra fonte di calore, ed altri transistor dentro nel processore, che già oggi soffre per limiti di tdp...

Un po' alla volta tutto si sta preparando per rendere le GPU importanti dal punto di vista computazionale; io credo che la transizione sarà più veloce del previsto, per i software che richiedono alte prestazioni, perché i vantaggi sono davvero enormi.

[capitan_crasy]

Originariamente inviato da Polpi_91

secondo me il quad channel lo vedremo solo nei server con piledriver perchè altrimenti AMD dovrebbe cambiare sia mobo, che socket che chipset mentre si sa che ha annunciato per la fascia desktop il chipset 1090fx (che non è altro che un 990FX migliorato) su socket AM3+

Sono d'accordo, anche secondo me Piledriver desktop non avrà il quad channel per via della necessità di un nuovo socket; per quanto riguarda il chipset non è necessario un nuovo modello per gestire nuovi canali RAM in quanto, tale elemento non c'entra assolutamente niente con le memorie.
Komodo, secondo le vecchie roadmap, doveva avere un controller Triple channel ma in questo caso si parlava specificatamente di un nuoco socket, sia per il desktop sia per i server.
Se AMD manterrà il socket AM3+ in pratica cambierà solo l'architettura dei core mentre il "contorno" (controller RAM dual channel, Hypertransport) sarà uguale alle attuali CPU Bulldozer, tranne ovviamente le frequenze RAM DDR3 portate a 2133Mhz...

[carlottoIIx6]

il primo "fusion" è cinese
http://www.tomshw.it/cont/news/upu-l...d/35380/1.html

[paolo.oliva2]

@Acegranger

Non lo sapevo che Intel avrebbe sfornato i proci 22nm prima per il socket 1155, ora lo so, ma comunque l'ottica del mio discorso non cambia, perché sino a che Intel non potrà offrire potenze sul socket 2010 superiori agli SBe X6, come hanno detto anche altri, gli IVY socket 1155 avranno potenze ridotte.

Il mio concetto era che AMD comunque deve lavorare già per arrivare ad un 2600K, quindi mi sono astenuto nel confrontare un Piledriver X10 ad un SBe X6 (a meno che GF non faccia un miracolo sul 32nm ).

Pero' spero che concorderai con me che mentre sarebbe già un problema "commerciale" per Intel proporre un IVY X4 con una potenza X% superiore a quella del 2600K, magari pure allo stesso prezzo, un Piledriver X10, anche senza sperare in miracoli sul silicio, dovrebbe poter garantire un incremento % superiore (discorso OC a parte, discorso prezzi da vedere, discorso IPC MT certamente più favorevole ad AMD rispetto al discorso IPC ST).

Su questa base, mi sembra più plausibile una situazione più favorevole ad AMD rispetto a quella odierna 8150 vs 2600K/2700K.

Se poi cosi' non fosse... io tra 40 giorni ritorno e ho una gran voglia di smanettare... Se AMD sforna qualche cosa di nuovo, ben venga, se lo annuncia... dipende dall'attesa, altrimenti mi prendo un SBe X6.... anche perchè dopo ripartiro' ancora e sto giro non voglio stare con un I5....

[shellx]

Originariamente inviato da papafoxtrot

Allora:
Le iommu servono per consentire al controller di memoria della GPU di prelevarsi i dati dalla ram principale, almeno questo nel caso delle GPU discrete.
Per come sono ora le cose (senza IOMMU), se devo eseguire un calcolo sulla GPU, devo prima trasferire tutti i dati di input dalla memoria centrale alla memoria della GPU, e questo è gestito a livello di codice e compilazione del software. A quel punto l'elaborazione può cominciare.
Nel caso di Llano, la ram è fisicamente la stessa tra CPU e GPU, ma in realtà è partizionata, per cui di nuovo, prima di iniziare l'elaborazione devo prelevare i dati da una parte della ram (quella cpu), portarli al memory controller, e di qui reinviarli alla ram, ma dalla parte dedicata alla GPU.

Con le IOMMU 1 cosa posso fare? Quando alla GPU, nel corso del calcolo, serve un dato, il processore passerà il puntatore alla cella di memoria centrale che lo contiene al MC della GPU, il quale potrà così andare a leggerselo.
Il problema in pratica era di mappatura della memoria; la GPU poteva anche accedere alla ram centrale, ma non conoscendo la disposizione dei dati non avrebbe potuto fare nulla. La CPU ora può "dire" alla GPU "il dato che ti serve è li"".

Con Trinity il discorso è ancora diverso. Il memory controller è lo stesso, ma serve sia la CPU, sia la GPU. Se alla GPU serve un dato, il mc non deve interrogare nessuno per sapere dove si trova, perché è lui stesso a mappare l'intera ram centrale. Per cui basta che faccia riferimento alla mappatura della memoria dedicata alla cpu e vada a prelevare il dato, mandandolo poi alla GPU.

L'ultimo livello di integrazione sarà invece quello di avere una mappatura unica della memoria, in cui la ram non sarà partizionata, ma sarà condivisa tra CPU e GPU; non vorrei sbagliarmi, ma a quanto ho capito questo livello di integrazione arriverà solo successivamente.

è chiaro, grazie per il chiarimento...beh adesso che ho inquadrato alcuni dettagli, sto quad channel inizio a considerarlo più utile, anche se leggo qualcuno che dice che sara solo su server, ma pensandoci, mi sa che hanno ragione.
Mi sbagliavo anchio prima quando dicevo del chipset, in effetti il northbridge sulla mobo integra solo il controller pci-express, l'MC è integrato nella cpu, ergo per avere un quadchannel, serve un nuovo socket e no un nuovo chipset. E come dice il capitano, era possibile in caso di socket FMx, ma rimanendo ancora sulla frustrante infrastruttura AMx trovo un pò difficile che verrà implementato un ampliamento di canali sulla gestione DRAM da parte del memory controller. Dovrebbero mettere mani all'architettura e all'MC...non so se è possibile/conveniente per amd questa cosa.
Quindi rettifico il pensiero: anche secondo me piledriver sara ancora dual channel e il quad solo per server.
Invece è possibile X10 desktop. (questo lo ritengo ancora inutile, a meno qualcuno mi convinca che l'aggiunta di due core aiutano gli FX, per me e coprire la merda con il fango).

Ci ho pensato adesso: se sarà implementato su tutte le CPU, anche desktop, il MC quad channel servirà per supportare le specifiche IOMMU: in pratica ora come ora la GPU, grazie alle IOMMU, può certo accedere alla memoria centrale, ma già questa è separata dalla GPU da una filadi link (pci-express - Hyper transport), e le latenze si alzano.
Se poi la memoria ram è così lenta rispetto a quella della GPU si perde ogni vantaggio, e torna ad essere conveniente il precaricamento di tutti i dati, come si fa ora.
Con un bel quad channel si può riservare abbastanza banda alle GPU, anche discrete, che necessitino di accedere alla ram centrale. Certo si guadagnerà bene dall'integrazione del controller pci-e sulla cpu, da questo punto di vista, ma credo che l'abbiano rimandato per evitare di portare un'altra fonte di calore, ed altri transistor dentro nel processore, che già oggi soffre per limiti di tdp...

Un po' alla volta tutto si sta preparando per rendere le GPU importanti dal punto di vista computazionale; io credo che la transizione sarà più veloce del previsto, per i software che richiedono alte prestazioni, perché i vantaggi sono davvero enormi.

Questo è interessante. Ma rimane sempre il dubbio se sto quadchannel sarà ache per desktop.
Forse magari non subito. Verra implementato in un secondo momento, quando verra cambiato socket.
Mi sorge un dubbio: i secondi modelli piledriver saranno convertiti a 28nm, magsari sara quel periodo in cui cambieranno socket (ipotetico FM3), quindi aggiunta quadchannel nell'mc, integrazione del controller pci-e nella cpu.
O forse tutto questo avverrà con steamroller ? Buu ?
Il vero è che avverrà...ma è da capire quando amd ha queste intenzioni, perchè secondo me, ha bisogno come il pane di cambiare socket.
Non vedo più cosa tirare all'AMx.
Forse sapremo di piu a febbraio ?
Io ancora oggi spero che a febbraio ci dicono: ok gente...nel Q3-2012 si cambia socket, piledriver sara su nuovo socket, implementera il pci-e dentro (ergo meno latenze, e rimozione dell'inutile bus HT),anche senza gpu integrata, socket FMx (ergo unico socket per entrambe le fasce, e a questo punto visto trinity dovrebbe essere FM2, a meno che non decidano di continuare sulla strada socket diverso ma sempre FMx -es FM2 per trinity, FM3 per FX-piledriver), ma tutte queste sono fanta ipotesi, ma possibili.

Ma vi faccio un esempio sarcastico: vi immaginate se AMD a Febbraio se ne esca fuori con la notizia che vuole fare un ipotetico AM4 ? LOOOL
Vi giuro che li lincio

[digieffe]

qualcuno ha iniziato ad analizzare BD:

http://www.ilsistemista.net/index.ph...bulldozer.html

io non ho ancora letto... però ad una prima occhiata fa dei test delle capacità della unità di store da qui in poi:
http://www.ilsistemista.net/index.ph...r.html?start=5

EDIT: ho dato una letturina.... mah..

[Polpi_91]

Originariamente inviato da capitan_crasy

Sono d'accordo, anche secondo me Piledriver desktop non avrà il quad channel per via della necessità di un nuovo socket; per quanto riguarda il chipset non è necessario un nuovo modello per gestire nuovi canali RAM in quanto, tale elemento non c'entra assolutamente niente con le memorie.
Komodo, secondo le vecchie roadmap, doveva avere un controller Triple channel ma in questo caso si parlava specificatamente di un nuoco socket, sia per il desktop sia per i server.
Se AMD manterrà il socket AM3+ in pratica cambierà solo l'architettura dei core mentre il "contorno" (controller RAM dual channel, Hypertransport) sarà uguale alle attuali CPU Bulldozer, tranne ovviamente le frequenze RAM DDR3 portate a 2133Mhz...

concordo in pieno, finchè non vedremo un nuovo socket non ci sarà tri/quad channel.

sulla recensione di confronto postata da Digieffe:

Punti buoni secondo la recensione: velocità del MCH (non sto parlando della bandwidth), unita integrer

Punti buoni ma azzoppati da difetti: FPU per la mancanza della seconda porta d'accesso e la mancanza di bandwidth

Cosa proprio non va: Scarse prestazioni del silicio di GF con elevato leackage che comporta calore e consumi troppo elevati che compromettono le frequenze, la cache in particolare la L1 e la L2 in write che hanno prestazioni abbastanza scandalose che compromettono il buon afflusso di dati al processore soprattutto nelle applicazioni intensive come mole di dati e secondo me anche il branch predictor va notevolmente rivisto.

speriamo che piledriver migliori questi aspetti

[AceGranger]

Originariamente inviato da paolo.oliva2

Pero' spero che concorderai con me che mentre sarebbe già un problema "commerciale" per Intel proporre un IVY X4 con una potenza X% superiore a quella del 2600K, magari pure allo stesso prezzo, un Piledriver X10, anche senza sperare in miracoli sul silicio, dovrebbe poter garantire un incremento % superiore (discorso OC a parte, discorso prezzi da vedere, discorso IPC MT certamente più favorevole ad AMD rispetto al discorso IPC ST).

Su questa base, mi sembra più plausibile una situazione più favorevole ad AMD rispetto a quella odierna 8150 vs 2600K/2700K.

l'IPC di PD viene eliminato dall'IPC di IB, parte delle frequenze serviranno per raggiungere il 2600K e un'altro pochino per il 2700K, il rimanente dovrebbe quindi poter permette di superare il 3770K;

pero, IB dovrebbe arrivare l'8 Aprile, PD arrivera 5-6 mesi dopo, e IB-E circa 3 mesi dopo PD.

quindi nelle piu rosee aspettative, AMD avra una CPU superiore al 3770K e 3820 per 3 soli 3 mesi, ma continuando ad avere sempre problemi di efficienza e stando sempre sotto al resto delle CPU 2011, insomma non è che cambi molto la situazione.

Io spero vivamente che con Steamroller cambino nettamente strada.

[papafoxtrot]

Originariamente inviato da shellx

Questo è interessante. Ma rimane sempre il dubbio se sto quadchannel sarà ache per desktop.
Forse magari non subito. Verra implementato in un secondo momento, quando verra cambiato socket.
Mi sorge un dubbio: i secondi modelli piledriver saranno convertiti a 28nm, magsari sara quel periodo in cui cambieranno socket (ipotetico FM3), quindi aggiunta quadchannel nell'mc, integrazione del controller pci-e nella cpu.
O forse tutto questo avverrà con steamroller ? Buu ?

Hem, che io sappia i 28nm potrebbero arrivare con streamroller... Se non altro perché non saranno pronti prima del 2013, e per quell'anno ci sarà appunto streamroller.
Attendere il nuovo processo per integrare le nuove features (MC quad channel e pci-e) avrebbe un senso, perché permetterebbe di contenere il die size. E' anche vero che in ambito server il die size non è un problema, mentre in ambito desktop, se ci sarà una diversificazione tra i die, come era per k10, tra server e desktop, si può fare un po' di posto eliminando gli HT (in ambito server continuano a servire per le comunicazioni tra i proci).

Originariamente inviato da shellx

Il vero è che avverrà...ma è da capire quando amd ha queste intenzioni, perchè secondo me, ha bisogno come il pane di cambiare socket.
Non vedo più cosa tirare all'AMx.
Forse sapremo di piu a febbraio ?
Io ancora oggi spero che a febbraio ci dicono: ok gente...nel Q3-2012 si cambia socket, piledriver sara su nuovo socket, implementera il pci-e dentro (ergo meno latenze, e rimozione dell'inutile bus HT),anche senza gpu integrata, socket FMx (ergo unico socket per entrambe le fasce, e a questo punto visto trinity dovrebbe essere FM2, a meno che non decidano di continuare sulla strada socket diverso ma sempre FMx -es FM2 per trinity, FM3 per FX-piledriver), ma tutte queste sono fanta ipotesi, ma possibili.

Non so, se hanno annunciato che restano su am3+ e che faranno un nuovo chipset, secondo me fanno fatica a smentirsi nel giro di pochi mesi... con il lancio a 6 mesi di distanza.
E' un po' un peccato, anche perché il socket diviso rompe, ma probabilmente gli serviva ad accorciare i tempi. Visti i continui ritardi magari hanno capito che komodo con il pci-e integrato e il nuovo socket non sarebbe arrivato entro l'autunno, e piuttosto che restare con questo BD zoppo hanno deciso di fare una via di mezzo...

Secondo me però l'idea di mettere un quad channel in un die server non è il massimo; lo dico solo perché escludo che amd voglia abbandonare il design multi chip package per le cpu server di fascia alta; tutto sommato è l'unica cosa che gli permette di confrontarsi in qualche modo con la concorrenza.
Anche che piledriver abbia 10 core e un ipc molto più alto, nonché frequenze alte per via del minor numero di core, difficilmente raggiungerebbe l'attuale bulldozer...
Per cui ammesso che il MCP rimanga, così da produrre CPU a 20 core e confrontarsi con gli attuali SB X6 e X8 (speriamo), 8 canali di memoria non servirebbero a niente.
Per contro nei server di fascia bassa non vedo il motivo di fare un die apposta, diverso da tutti gli altri, per integrare una feature che tutto sommato servirebbe a poco; a chi serve tanta memoria si becca l'opteron di fascia alta.

Insomma, per quanto sembri inutile e paradossale, se è vero che in piledriver ci sarà il quad channel, secondo me lo troveremo sul desktop.
E se il socket sarà AM3+ vorrà dire semplicemente che potremmo gestire solo 4 banchi di ram (come è adesso, con due canali e due slot per canale), rinunciando alla possibilità di avere 8 slot come su LGA2011. Alla fine dal socket esce una pista per slot... se poi i 4 slot sono su due o quattro canali, forse cambia poco.

Un triple channel sarebbe statop più problematico; toccava accontentarsi di 3 banchi, perché sennò si doveva andare a 6 e non c'erano uscite. E i kit da tre banchi nel tempo non stanno più venendo aggiornati con prodotti aggressivi... Intel aveva la forza ed il market share per convincere tutti a produrre kit triple channel, mi sa che per AMD non sarebbe stato lo stesso.
Insomma,
- o si teneva il dual channel, ma almeno per motivi di immagine, e per prepararsi alle future novità (necessità di più banda, APU, IOMMU) era meglio inziare a fare un passo avanti.
- o faceva un triple channel, ma a costo di trovarsi con kit di memoria vecchi di due anni, e allora se devo scegliere tra 3 canali a 1600 e due canali a 2000 magari prendo la seconda... Che almeno monto 4 banchi e ho più spazio.
- o faceva un quad channel limitato a 4 banchi.

Che ne dite? Secondo me come ragionamento può filare. Certo il MC quad channel consuma, lo vediamo anche su SB-E (e lo si vedeva sui bloomfield/gulftown), per cui su un bulldozer, che non brilla certo per performance per watt, sonio un po' watt buttati ecco... Vero anche che con un bel power gating si può sempre disattivare mezzo MC e far andare la CPU con un dual channel, all'occorrenza...

[Sayan V]

Proviamo anche questo processore

[Pat77]

Originariamente inviato da Sayan V

Proviamo anche questo processore

Ma hai già overcloccato o lo tieni a default per i primi test?

[Sayan V]

Originariamente inviato da Pat77

Ma hai già overcloccato o lo tieni a default per i primi test?

Mi è appena arrivato il pacco, devo ancora assemblarlo

[Trokji]

Originariamente inviato da digieffe

come ho scritto nel post precendente si dice che questo pp dovrebbe "solo" migliorare il consumo ai "bassi" comunque secondo me si arriverà, ad aria, intorno ai 5ghz +/- qualche centinaio

mm a 22 nm non penso, a 5 ghz ci arriva sandy!
E poi avranno consumi a default molto bassi, io mi aspetto tanto margine, probabilmente 6 ghz ad aria.
Comunque vedremo

[winebar]

Originariamente inviato da Trokji

mm a 22 nm non penso, a 5 ghz ci arriva sandy!
E poi avranno consumi a default molto bassi, io mi aspetto tanto margine, probabilmente 6 ghz ad aria.
Comunque vedremo

Secondo me invece, arriverà a 5,3/5,4 ad aria e intorno ai 6 a liquido.
Comunque meglio tornare in topic.

Riprendo la mia domanda di un paio di pagine fa.
In vista di acquisto futuro, qualcuno sa quando uscirà lo step B3 per Bulldozer?

[Cocco83]

Mi sà che non esce proprio XD