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

[Athlon 64 3000+]

http://www.xbitlabs.com/news/other/d...s_for_AMD.html

Sembra che IBM abbia messo a disposizione uno dei suoi impianti produttivi per la produzione dell'APU Trinity.

[winebar]

Originariamente inviato da Athlon 64 3000+

http://www.xbitlabs.com/news/other/d...s_for_AMD.html

Sembra che IBM abbia messo a disposizione uno dei suoi impianti produttivi per la produzione dell'APU Trinity.

Non so se la notizia è già stata segnalata ma per steamroller hanno cambiato piani:

http://www.tomshw.it/cont/news/amd-r...a/35718/1.html

In pratica il passaggio ai 28 nm è previsto solo per le APU, scelta comprensibile dato che AMD ha ottimi riscontri con gli ibridi. Probabilmente aspetteranno un passaggio a 20nm per un cambio di pp in fascia enthusiast, ALMENO 2 anni dopo i 28 nani, quindi forse il 2015 (quando Intel, lo ricordo, dovrebbe essere prossima ai 12/10nm).
Inoltre il tanto agognato controller quad channel ci sarà, ma solo per ALCUNE cpu server su un determinato socket

Edit: Ovviamente potrei aver interpretato male la notizia, e potrebbero rilasciare Stemaroller a 28 nani a inizio 2014 per rimediare a possibili rese produttive scarse/brutte figure rispetto a PD stesso.

[Cocco83]

Originariamente inviato da Athlon 64 3000+

http://www.xbitlabs.com/news/other/d...s_for_AMD.html

Sembra che IBM abbia messo a disposizione uno dei suoi impianti produttivi per la produzione dell'APU Trinity.

Sbaglio o Rory Read veniva proprio da IBM.... sarebbe interessante verificare il 32nm IBM e il 32nm GF..... io mi aspetto grosse sorprese xD

Aggiungo che nella notizia si parla di + 25% in performance rispetto a Llano nella produttività e +50% nel comparto video.....

[wolfnyght]

Ragazzi , se volete leggere una recensione del FX 4170 : http://www.the-overclock-hole.it/rec...bulldozer.html
ed aggiungerla alla lista recensioni

[capitan_crasy]

Originariamente inviato da Athlon 64 3000+

http://www.xbitlabs.com/news/other/d...s_for_AMD.html

Sembra che IBM abbia messo a disposizione uno dei suoi impianti produttivi per la produzione dell'APU Trinity.

A prima vista sembra che GF abbia ancora qualche problema di troppo sui 32nm...
La cosa interessante è che il silicio SOI di IBM è il migliore e che producano solamente (se non sbaglio) 32nm SOI HKMG con ultra low-k...

Originariamente inviato da winebar

Non so se la notizia è già stata segnalata ma per steamroller hanno cambiato piani:

http://www.tomshw.it/cont/news/amd-r...a/35718/1.html

In pratica il passaggio ai 28 nm è previsto solo per le APU, scelta comprensibile dato che AMD ha ottimi riscontri con gli ibridi. Probabilmente aspetteranno un passaggio a 20nm per un cambio di pp in fascia enthusiast, ALMENO 2 anni dopo i 28 nani, quindi forse il 2015 (quando Intel, lo ricordo, dovrebbe essere prossima ai 12/10nm).
Inoltre il tanto agognato controller quad channel ci sarà, ma solo per ALCUNE cpu server su un determinato socket

Edit: Ovviamente potrei aver interpretato male la notizia, e potrebbero rilasciare Stemaroller a 28 nani a inizio 2014 per rimediare a possibili rese produttive scarse/brutte figure rispetto a PD stesso.

Una volta convertito Steamroller al 28nm il passaggio da APU a una classica CPU è relativamente semplice, grazie al progetto modulare introdotto con i 45nm e affinato con i 32nm.
Questi 28nm dovrebbe essere di origine GF e secondo alcune voci sarebbero più evoluti degli attuali 28nm utilizzati da TSMC per le nuove GPU AMD...
Mantenendo i tempi odierni prevedo l'uscita (parlo di CPU Steamroller) tra i terzo e il quarto trimestre 2013...

[carlottoIIx6]

Originariamente inviato da shellx

No no ma analisi architettura a parte.
Il tuo problema è a livello float e matematico.
Tu mi sposti la virgola nei decimali come se fosse un palo di bandiera e la metti dove vuoi come se il risultato fosse sempre lo stesso.
Prima 12,5 poi l'ho trasformi in 1,25 (tanto è lo stesso valore vero ?)
Poi mi dici che l'aumento è complessivo 12,5 a core poi 1,25 a core ,poi 25% a modulo...
Allora se è 1,25 a core (che poi sichiama cluster) allora dovrebbe essere 2,50 a modulo con la mia matematica.
Cavolo hai fatto un casino.
Ma allora sta virgoletta dove la mettimamo dopo la prima o dopo la secondà unità ?

Secondo me manco tu sai cio che dici e spari a go a go solo per difendere qualcosa.
Ma almeno se vuoi farlo fagli meritare un buon avvocato.

ho fatto uno sbaglio di calcolo (non ho fatto calcoli a virgola mobile ) ma seimplicemente go dovuto costatare che per fare un modulo in più ci vuole un aumento di di ipc del 25% per core invece di quello che avevo (sbagliando) pensato prima (del 12,5%).
detto ciò il caclolo è giusto .
ma ho dovuto costatare che il 25% non è possibile con un semplice aumenti di ipc quindi (senza conforndermi tra ipc e ips) ho dovuto ammettere che oltre all'ipc, amd deve amumentare anche la frequenza per "fare" un modulo.
rimango dell'idea che il 10% si riverisca all'ipc, ma questa p una mia idea che potete anche non condividere.

[carlottoIIx6]

Originariamente inviato da paolo.oliva2

Io la penso in questo modo...

Finchè AMD/GF non riescono ad ottenere molto di più dal silicio, un 5 moduli nel desktop sarebbe inutile.

Metto dei valori indicativi... tralasciando il CMT e quant'altro proprio per semplificare.

Poniamo che BD perda il 20% di IPC a core rispetto al Phenom II, quindi per pareggiare l'IPC ed avere la stessa potenza dovrebbe avere una frequenza del 20% superiore.
Se AMD arrivasse a questo risultato, BD avrebbe comunque un potenziale del 33% superiore al Thuban per il fatto di avere il 33% in più di core.

Secondo me AMD/GF il VERO problema che hanno sul silicio è quello di salire in frequenza più che il TDP a frequenze basse ma con più moduli.

Un BD X16 mi sembra possa arrivare a 3,4GHz come frequenza massima (o 3,5GHz? ), e se lo rapportiamo all'8150, cosa abbiamo? A fronte del 100% in più dei core (anzi, 100% in più di tutti i transistor di un 8150), perde solamente il 25% di frequenza massima, ed il 44% sulla frequenza def (se non mi sbaglio BD X16 è 2,5GHz def).

Quindi anche senza migliorie di silicio, AMD comunque potrebbe realizzare un X10 almeno a 3,3GHz def... ma a che scopo? Forse nei server potrebbe avere un senso, ma non nel desktop... i prezzi della mobo aumenterebbero (stando al progetto iniziale del quad channel), la potenza ST diminuirebbe ulteriormente e il tutto con un vantaggio nell'MT insignificante rispetto alla spesa superiore (3,6GHz x 8 core = 28,8GHz di un ipotetico core... 3,3GHz x 10 = 33GHz che sarebbe simile già ad un 8170 3,9GHz x 8 = 31,2GHz).

be in single le frequenza sarebbero maggiori di quelle attuali quindo guadagnerebbe anche

Lo so che l'esempio ' come le pere e le mele, ma era per semplificare.

Cioè... per me l'IPC dell'architettura BD per esprimersi ha bisogno di clock, aumentare i core non risolverebbe il problema.

secondo me il problema è il prodotto ipc * frequenza, quindi o si aumenta molto uno o si aumenta molto l'altro, o si aumentano tutte e due (la cosa che penso).

[carlottoIIx6]

Originariamente inviato da shellx

Se x = y
e una cpu perde x% di ipc, mi spieghi perchè debba per forza avere y% di frequenza in piu per ripristinare l'efficienza perduta a causa del -x% di ipc ?
Non capisco perchè siete convinti che basta la stessa percentuale di frequenza per sopperire alla analoga percentuale di ipc perduta.
Secondo me non è cosi che funziona sempre.

basta fare un esempio:
supponiamo di avere un ipc = 1 e di farlo girare ad un 1HZ.
ogni secondo la cpu fa una operazione.
supponiamo di avere un aumento ipc = 2 (aumento del 100%).
allora ogni secondo la cpu fa due operazioni.
quando devo aumentare la frequenza per avere due istruzioni a secondo con ipc=1?
se porto la frequnza a 2Hz (aumento del 100%) ottendo due operazioni:
cioè la cpu fa una operazione ogni mezzo secondo.

[blackshard]

Originariamente inviato da wolfnyght

Ragazzi , se volete leggere una recensione del FX 4170 : http://www.the-overclock-hole.it/rec...bulldozer.html
ed aggiungerla alla lista recensioni

Questo però è lollissimo :

http://www.the-overclock-hole.it/ima...0parte/018.jpg

[Cocco83]

Scusa sarà l'ora.... ma cosa c'è di divertente?

[wolverine]

Originariamente inviato da blackshard

Questo però è lollissimo :

http://www.the-overclock-hole.it/ima...0parte/018.jpg

Questa fa più ridere..

[digieffe]

Originariamente inviato da Randa71

la difficoltà è ben un'altra cioè: le FPU x87 sono fatte per eseguire determinate istruzioni in virgola mobile (quelle dell'ISA x87/SSE/AVX etc etc)...e di conseguenza sono 'disegnate' per quelle istruzioni. Le FPU delle schede video sono differenti molto differenti dall'ISA X87 e dalle varie SSE/AVX in tutte le loro versioni....perchè se fosse come dici, stai un attimo a integrare FPU di BD e mettergli i moduli FPU delle schede video.... ma questo non è ancora successo. perchè? perchè, per me , una delle più grosse difficoltà che avranno sarà quella di far eseguire le ISA x87/SSE/AVX sulle FPU delle GPU....perchè a livello hardware una GPU è profondamente diversa da una FPU x87....
Il discorso fusion sta proprio nel cercare un punto di incontro tra questi due mondi....e sono curioso di capire come faranno.....spero solo che non ci piazzino uno strato software che traduca ISA x87 in istruzioni direttamente eseguibili dalla FPU della GPU, con il rischio di un calo di performance....Una delle soluzioni l'ha adottata Sony con la cpu cell: la parte powerpc general purpose è ridicola come prestazioni, ma serve solo ad alimentare i 7 SPE (Synergistic Processing Elements) che sono i veri 'tritacarne' della CPU..i quali SPE sono ciò che c'è di più simile alle unità delle GPU...secondo me mireranno a fare qualcosa di concettualmente simile...

Premettendo che le fpu (stream processors) delle gpu in genere gestiscono al max numeri in virgola mobile (float) a 64bit e quindi non sarebbero in grado di gestire dati x87 a 80bit e FMAC a 128bit...

apportate le dovute implementazioni per gestire questo tipo di dati... per il resto gestiscono sufficientemente bene interi di diverse dimensioni in genere fino a 32 bit e float fino a 64 bit...

la struttura con la quale gestistono questi dati è una struttura vettoriale non troppo diversa dalle AVX...

essendo le compute unit molto flessibili e con un numero maggiore di registri e strutture delle avx, non dovrebbe essere molto difficile tramite il decoder hardware convertire le istruzioni x87, sse(n), avx(n) in dati trattabili dalle stesse unità per poi renderle in output così come avviene con la flexpf di BD.

un altra differenza è che normalmente una gpu viene programmata dal driver con un vero è proprio kernel (in esecuzione nella gpu) nel caso in cui dovesse essere utilizzarta come un coprocessore matematico sarebbe necesario utilizzare le unità in modo diretto con un dispacher e senza kernel...

Immagino che questa sarà la situazione quando darà concluso il processo HSA.

Non dimentichiamoci che i processori x86 attuali (intel e amd) sono di fatto tutti RISC ed eseguono il codice x86 tramite il decoder che genera le mops (RISC) nel caso di AMD e le uops nel caso di Intel... quindi non vedrei nulla di strano se il decoder trasformasse le istruzioni x87, sse(n), avx(n) in istruzioni di stream processors...

[digieffe]

Originariamente inviato da Athlon 64 3000+

http://www.xbitlabs.com/news/other/d...s_for_AMD.html

Sembra che IBM abbia messo a disposizione uno dei suoi impianti produttivi per la produzione dell'APU Trinity.

Era da tempo che speravo in una partnership con Ibm...

ora però spero che non sia una partnership al ribasso, cioè, non di mero aumento della produzione senza apporto di qualità ma se ce n'è e se possibile un travaso di tecnologie e know-how...

[carlottoIIx6]

Originariamente inviato da wolfnyght

Ragazzi , se volete leggere una recensione del FX 4170 : http://www.the-overclock-hole.it/rec...bulldozer.html
ed aggiungerla alla lista recensioni

mi sembra un processore molto tostigno.
quando le nuove istruzini sono supportate supera bene il 980
e se non capisco male, sembra che consumo meno sia in idle che full
anche se l'uso medio stranamente avvantagia i phenom.
cmq sia sono ancora più convinto che è meglio consigliare gli FX dei phenom.

inoltre arriva a 5Gh, questo prova un miglioramento nel silicio (che i primi usciti siano i peggiori?) e questo potrebbe fare epnsare che il 8170 arrivi anche e superi i 5 GHz.

[carlottoIIx6]

Originariamente inviato da Randa71

No. non confondere PRESTAZIONI (IPS - instructions per second) con IPC (instructions per cycle).
Le prestazioni di una CPU sono date da= IPC e MHZ (clock). Punto
Se un 2600k lo mandi a 500MHZ vedrai che le prestazioni saranno molto inferiori a quelle di quando è a 3400MHZ a prescindere dall'IPC che ha. Sei d'accordo?
Io mandando BD a 4.2 GHZ su tutti i C.U. (compute unit) ho aumentato le prestazioni del 15% in MT rispetto alla freq def, ma non ho toccato IPC, quindi quello che tu dici è palesemente sbagliato....

onestamente non capisco cosa tu dici di diverso da quello che ho detto

Ha ragione Gianni quando dice che se AMD dice che PD avrà il 10% in +, PRESUMIBILMENTE, il miglioramento sarà la somma tra IPC e clock.
Potrebbe essere anche solo IPC, ma potrebbe anche essere solo clock..non è detto che non percorrino anche la strada dell'innalzamento del clock...e soprattutto UNA NON ESCLUDE L'ALTRA, ANZI
Non è matematico che avere 10% in + di PRESTAZIONI GLOBALI sia fatto solo migliorando le unità interne...lo puoi fare anche alzando il clock (vedi il mio esempio)....perchè i transistor aprendosi e chiudendosi + velocemente hanno un output di istruzioni + elevato (la corrente/i segnali escono dalla CPU + velocemente).
quindi il clock c'entra eccome nell'ouput finale delle prestazioni.
cut

ma io ho solo detto che AMD si riferisce SOLO all'ipc con quel dato
per una questione di italiano, ovvero ha senso parlare di IPS quando ti riferisci a una istruzione? ha per me senso parlare di IPC
e quindi essendo per me sicuro un aumento di frequenza presumo prestazioni supriore (ipc e frequenza) al 10% indicato.
Rimane un mio parere, nulla più, aspetto nuovi input.

[carlottoIIx6]

Originariamente inviato da digieffe

cut

Immagino che questa sarà la situazione quando darà concluso il processo HSA.

Non dimentichiamoci che i processori x86 attuali (intel e amd) sono di fatto tutti RISC ed eseguono il codice x86 tramite il decoder che genera le mops (RISC) nel caso di AMD e le uops nel caso di Intel... quindi non vedrei nulla di strano se il decoder trasformasse le istruzioni x87, sse(n), avx(n) in istruzioni di stream processors...

e quindi che concludi?

[B|4KWH|T3]

Originariamente inviato da digieffe

Premettendo che le fpu (stream processors) delle gpu in genere gestiscono al max numeri in virgola mobile (float) a 64bit e quindi non sarebbero in grado di gestire dati x87 a 80bit e FMAC a 128bit...

...

Sono due cose diverse, gli standard sul formato dei dati sono fp32, fp64 (quelli supportati dalle GPU, non so se possano gestirne altri) e superiori

http://en.wikipedia.org/wiki/Floatin...dern_computers

Le SSE lavorano su ->vettori<- di 128 bit, mentre le AVX sono l'estensione delle SSE a vettori di 256 bit. Ovviamente il vettore è composta da PIU' dati.

[Randa71]

Originariamente inviato da digieffe

Premettendo che le fpu (stream processors) delle gpu in genere gestiscono al max numeri in virgola mobile (float) a 64bit e quindi non sarebbero in grado di gestire dati x87 a 80bit e FMAC a 128bit...

apportate le dovute implementazioni per gestire questo tipo di dati... per il resto gestiscono sufficientemente bene interi di diverse dimensioni in genere fino a 32 bit e float fino a 64 bit...

..

infatti alla fine il risultato dovrebbe essere quello previsto da entrambi: un APU che conterrà al suo interno tutta una serie di CU delle gpu, adattate, che faranno i calcoli, al posto o in aiuto alle classiche FPU x87 e/o unità degli interi, lavorando in parallelo...almeno così interpreto il progetto HSA e almeno così avrebbe senso...una fusione vera e propria appunto...

[carlottoIIx6]

Originariamente inviato da B|4KWH|T3

Sono due cose diverse, gli standard sul formato dei dati sono fp32, fp64 (quelli supportati dalle GPU, non so se possano gestirne altri) e superiori

http://en.wikipedia.org/wiki/Floatin...dern_computers

Le SSE lavorano su ->vettori<- di 128 bit, mentre le AVX sono l'estensione delle SSE a vettori di 256 bit. Ovviamente il vettore è composta da PIU' dati.

faccio una ipotesi:
la FP di BD lavora a 256 bit x1 o 128bit x2.
perche non farne del tipo 64 bit x4...
che sia il modo con cui si faranno le FP con le GPU.
qui davvero ho fatto un volo pindalico per quel che sono le mie conoscenze in amteria.

[digieffe]

Originariamente inviato da carlottoIIx6

e quindi che concludi?

Che essendo tutto poggiato sul decoder hardware (comprese le x86) non dovrebbe essere troppo difficile sostituire qualsiasi parte della cpu/apu

(giusto per capirci sia intel core, che k10, che BD eseguono (più o meno) le stesse istruzioni ma hanno modi differenti per eseguirle ci pensa il decoder a convertirle per le relative unità di esecuzione)