[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[bjt2]

Originariamente inviato da capitan_crasy

Aggiornamento:

Finalmente l'architettura ufficiale!

Da queste slide si capiscono le seguenti cose:

- Buldozer potrà avere solo un numero di cores pari.
- Differenze e somiglianze tra HyperThreading INTEL e doppio core AMD:
- Fetch e decode unico per due thread per entrambi gli approcci.
- Unità FP condivisa tra i due thread per entrambi, ma essendo le due unità FP uguali, possono essere accopiate per fare una istruzione a 256 di un solo thread (il mitico reverse HyperThreading), mentre i core INTEL hanno si due unità FP, ma una fa solo addizioni e una solo moltiplicazioni.
- Unità intere SEPARATE per l'architettura AMD. E in più le pipeline sono 4. Se sono uguali a quelle del K8/9/10, ossia formate da una ALU+AGU, allora è un passo in avanti. Se sono 4 ALU come quelle INTEL, allora è un passo indietro, ma comunque rispetto a INTEL è un passo in avanti, perchè i 2 thread si contendono 4 ALU, mentre qui i 2 thread hanno il proprio set di 4 ALU dedicate.
- Cache L1 dati (e unità load store) separate: grande vantaggio AMD
- Cache L2 condivisa: siamo pari.

Quindi il pubblicizzare questo cluster di due core, come due core separati è giustificato.
Le unità FP nel K8/9/10 sono 3, ma non sono generiche. Qui abbiamo 2 unità FP a 128 bit generiche. Quindi lo scheduling dovrebbe essere semplificato.

[F1R3BL4D3]

Se interessa, questa è la roadmap 2010/2011 direttamente da AMD Italia:

Overview per il 2010:



Riconfermandosi la sola azienda sul mercato in grado di offrire piattaforme bilanciato dall’elevata capacità elaborativa, visiva e multimediale, AMD prevede di introdurre le seguenti piattaforme:



· “Danube”: la piattaforma di nuova generazione AMD Mainstream Notebook che monta il primo processore AMD mobile quad-core e che promette di offrire più di 7 ore di autonomia della batteria;

· “Nile”: la terza piattaforma AMD Ultrathin notebook, progettata per offrire una maggiore autonomia della batteria (più di 7 ore);

· “San Marino” e “Maranello”: due nuove piattaforme in ambito server con supporto DDR3. “Maranello” si baserà sul processore “Magny-Core” a 8 e 12 core, mentre “San Marino” offrirà nuovo valore ed efficienza energetica che contribuirà alla crescita del Web e del Cloud Computing;

· “Leo”: la prossima generazione della piattaforma per PC desktop dedicata agli “enthusiast” basata sul primo processore per desktop a 6 core



Overview per il 2011:



Nel 2011 AMD darà vita a una nuova era dell’elaborazione introducendo le seguenti piattoforme (nomi in codice):



* “Bulldozer” e “Bobcat”: due nuovi core x86 studiati per specifiche piattaforme e segmenti di mercato “Bulldozer” sarà una architettura completamente nuova studiata per soluzioni server mainstream, desktop e notebook che sfrutterà un nuovo approccio multithreaded in grado di offrire sempre maggiore efficienza e prestazioni. L’architettura “Bulldozer” offre un’ esclusiva funzionalità in grado di stabilire una connessione diretta tra la CPU e unità di elaborazione grafica (GPU) per creare una soluzione a singolo chip, definita come Accelerated Processing Unit (APU), per offrire massima scalabilità.
“Bobcat” è studiato per il mercato dei PC ultra sottili a basso consumo energetico, e sarà in grado di scalare facilmente in combinazioni con altri componenti nelle configurazioni APU (Accelerated processing Unit)
* “Llano”: sarà la piattaforma dedicata ai notebook e desktop mainstream. L’APU (accelerated processing unit) sarà la prima a identificare l'unione di una CPU e una GPU in un unico die.
* “Brazos”: piattaforma per ultra portatili economici, si baserà sulla APU “Ontario”, con due core basati sulla nuova architettura “Bobcat”.
* “Zamberi”: processore per sistemi desktop dedicato al segmento “enthusiast” con 8 core basato sull’architettura indicata con il nome in codice di Bulldozer.

[bjt2]

Originariamente inviato da capitan_crasy

Secondo le informazioni rilasciate da AMD, la prima APU (accelerated processing unit) nome in codice Llano sarà basata su 4 core X86-x64 AMD derivanti dall'architettura "Stars" o più comunemente chiamata K10; il modello di riferimento è il core Propus, naturalmente riveduto e corretto.
Costruita a 32nm SOI Llano avrà una cache L2 da 512Kb per core X86 e la classica cache L3 da 4MB.
La GPU integrata nello stesso pezzo di silicio, avrà ben 480 stream processors divisi in 6 SIMD engines (80 stream processors per engine) con una capacità di calcolo massima classe "Gigaflops"; CPU e GPU condivideranno lo stesso controller di memoria DDR3 PC3-12800 (1600Mhz)
Questa APU avrà circa un 1 miliardo di transistor e sarà la prima GPU AMD costruita con tecnologia SOI.

L'uscita è attesa per il 2011...


Clicca qui...

E' possibile che questi 480 stream processor vadano a una velocità elevata, tipo 1,2-1,5GHz?

[okorop]

Originariamente inviato da bjt2

E' possibile che questi 480 stream processor vadano a una velocità elevata, tipo 1,2-1,5GHz?

dovrebbero essere lincati con la frequenza della gpu integrata come sulle soluzioni ati radeon, poi se si tratta della nuova architettura non si sa

[capitan_crasy]

Originariamente inviato da bjt2

Finalmente l'architettura ufficiale!

Da queste slide si capiscono le seguenti cose:

- Buldozer potrà avere solo un numero di cores pari.
- Differenze e somiglianze tra HyperThreading INTEL e doppio core AMD:
- Fetch e decode unico per due thread per entrambi gli approcci.
- Unità FP condivisa tra i due thread per entrambi, ma essendo le due unità FP uguali, possono essere accopiate per fare una istruzione a 256 di un solo thread (il mitico reverse HyperThreading), mentre i core INTEL hanno si due unità FP, ma una fa solo addizioni e una solo moltiplicazioni.
- Unità intere SEPARATE per l'architettura AMD. E in più le pipeline sono 4. Se sono uguali a quelle del K8/9/10, ossia formate da una ALU+AGU, allora è un passo in avanti. Se sono 4 ALU come quelle INTEL, allora è un passo indietro, ma comunque rispetto a INTEL è un passo in avanti, perchè i 2 thread si contendono 4 ALU, mentre qui i 2 thread hanno il proprio set di 4 ALU dedicate.
- Cache L1 dati (e unità load store) separate: grande vantaggio AMD
- Cache L2 condivisa: siamo pari.

Quindi il pubblicizzare questo cluster di due core, come due core separati è giustificato.
Le unità FP nel K8/9/10 sono 3, ma non sono generiche. Qui abbiamo 2 unità FP a 128 bit generiche. Quindi lo scheduling dovrebbe essere semplificato.

Grande bjt2, appena ho un po di tempo ti metto in prima pagina...
una cosa volevo chiederti:
Corsini nel suo articolo dice che AMD con Bulldozer ha prediletto i calcoli interi piuttosto che quelli in virgola mobile, lasciando quest'ultimi tra i due cluster integer, oppure dedicate specificamente ad uno dei due core per ogni ciclo di clock.
Che ne pensi? mi sembra un pò troppo limitante... (premetto che la mia competenza in questi argomenti è sotto al noviziato )

[okorop]

Originariamente inviato da capitan_crasy

Grande bjt2, appena ho un po di tempo ti metto in prima pagina...
una cosa volevo chiederti:
Corsini nel suo articolo dice che AMD con Bulldozer ha prediletto i calcoli interi piuttosto che quelli in virgola mobile, lasciando quest'ultimi tra i due cluster integer, oppure dedicate specificamente ad uno dei due core per ogni ciclo di clock.
Che ne pensi? mi sembra un pò troppo limitante... (premetto che la mia competenza in questi è vicino è sotto al noviziato )

i calcoli in virgola mobile a mio avviso li lascia alla gpu che è molto piu' veloce in questo tipo di calcolo ottimizzando la cpu per tutto il resto

[capitan_crasy]

Originariamente inviato da okorop

i calcoli in virgola mobile a mio avviso li lascia alla gpu che è molto piu' veloce in questo tipo di calcolo ottimizzando la cpu per tutto il resto

Ok , però i primi esemplari di Bulldozer non avranno le GPU integrate...

[okorop]

Originariamente inviato da capitan_crasy

Ok , però i primi esemplari di Bulldozer non avranno le GPU integrate...

amd vuole venderti tutto completo cpu e gpu e scheda madre ergo se le proprie gpu riescono a fare calcoli in virgola mobile con un vantaggio comparato rispetto alle cpu specializzano le gpu in quel settore e le cpu nei rimanenti.

ti faccio un banale esempio attuale: un intel core i7 per convertire un file video ci impega x (in unità di tempo), una scheda ati ne impiega x-1 (son dati appurati) allora perchè utilizzare il processore in questi ambiti? non avrebbe senso giusto ergo amd non specializza la cpu manco nel farlo e passano attraverso la gpu. Io mi aspetto dei software ottimizzati fusion che permettano un giusto carico delle varie componenti del sistema e le utilizzi quando han vantaggi. Probabilmente soluzioni buldozzer accoppiate a soluzioni nvida non daranno le stesse prestazioni in ambito 2d come buldozzer + ati.

[Pihippo]

Originariamente inviato da capitan_crasy

Grande bjt2, appena ho un po di tempo ti metto in prima pagina...
una cosa volevo chiederti:
Corsini nel suo articolo dice che AMD con Bulldozer ha prediletto i calcoli interi piuttosto che quelli in virgola mobile, lasciando quest'ultimi tra i due cluster integer, oppure dedicate specificamente ad uno dei due core per ogni ciclo di clock.
Che ne pensi? mi sembra un pò troppo limitante... (premetto che la mia competenza in questi argomenti è sotto al noviziato )

Ciao
Se posso permettermi, potrei parlarne io. Premetto che possono essere solo castronerie:
Dunque quello che ha detto corsini non è proprio vero. Infatti la unità Fp è composta due parti speculari con ampiezza a 128bit. Se nel thread che sta eseguendo la cpu sono presenti vettori a 256bit allora il thread che richiede il vettore monopolizzerà la Fp per un ciclo di clock per eseguire l'operazione, da come si evince nella slide, l'unità amd è un FMAC, ovvero in grado di eseguire oltre a moltiplicazioni, addizioni, ed altre operazioni aritmetiche anche operazioni con la memoria (MOV) conversioni ed altro. Questo implica che le unità da 128bit siano dual ported ognuna verso la cache, dunque ognuna di essa può eseguire 2 operazioni per ciclo di clock. Questo approccio nasce dal fatto che le unità FP nel software corrente sono sottoutilizzate, essendo la maggioranza di istruzioni di tipo integer e sopratutto istruzioni che lavorano con la memoria( e speriamo che vi siano 4 agu). Quindi per farti un esempio un k10 può eseguire nella stragrande maggioranza dei casi possibili, NB non avviene quasi mai per il motivo detto sopra sulla natura del codice, 2 operazioni aritmetiche FP + un operazione non aritmetica. Buldozzer essendo strutturato cosi portebbe eseguire, essendo lo scheduler FP dedicato tra 2 core, 4 operazioni FP, 2 aritmetiche e due non, con conseguenza miglior sfruttamento delle risorse.
Come detto primase ho detto cassate correggetemi.

[capitan_crasy]

Originariamente inviato da okorop

amd vuole venderti tutto completo cpu e gpu e scheda madre ergo se le proprie gpu riescono a fare calcoli in virgola mobile con un vantaggio comparato rispetto alle cpu specializzano le gpu in quel settore e le cpu nei rimanenti.

ti faccio un banale esempio attuale: un intel core i7 per convertire un file video ci impega x (in unità di tempo), una scheda ati ne impiega x-1 (son dati appurati) allora perchè utilizzare il processore in questi ambiti? non avrebbe senso giusto ergo amd non specializza la cpu manco nel farlo e passano attraverso la gpu. Io mi aspetto dei software ottimizzati fusion che permettano un giusto carico delle varie componenti del sistema e le utilizzi quando han vantaggi. Probabilmente soluzioni buldozzer accoppiate a soluzioni nvida non daranno le stesse prestazioni in ambito 2d come buldozzer + ati.

E' questo il punto...
Inoltre si rischia di avere, in alcuni casi, un Llano per il mercato mainstream più veloce di un Bullodozer per il mercato enthusiast...

[okorop]

Originariamente inviato da capitan_crasy

E' questo il punto...
Inoltre si rischia di avere, in alcuni casi, un Llano per il mercato mainstream più veloce di un Bullodozer per il mercato enthusiast...

non escludo la possibilità di una scheda video integrata nel chipset anche per soluzioni enthusiast, magari senza uscita video, ma dedicata a fare proprio i calcoli in cui il processore e carente, con inoltre la possibilità di adottare soluzioni hybrid crossfire con lo spegnimento delle vga dedicate per un risparmio energetico

[carlottoIIx6]

http://www.hwupgrade.it/articoli/cpu...-fusion_5.html

[Ren]

Ciao
Se posso permettermi, potrei parlarne io. Premetto che possono essere solo castronerie:
Dunque quello che ha detto corsini non è proprio vero. Infatti la unità Fp è composta due parti speculari con ampiezza a 128bit. Se nel thread che sta eseguendo la cpu sono presenti vettori a 256bit allora il thread che richiede il vettore monopolizzerà la Fp per un ciclo di clock per eseguire l'operazione, da come si evince nella slide, l'unità amd è un FMAC, ovvero in grado di eseguire oltre a moltiplicazioni, addizioni, ed altre operazioni aritmetiche anche operazioni con la memoria (MOV) conversioni ed altro. Questo implica che le unità da 128bit siano dual ported ognuna verso la cache, dunque ognuna di essa può eseguire 2 operazioni per ciclo di clock. Questo approccio nasce dal fatto che le unità FP nel software corrente sono sottoutilizzate, essendo la maggioranza di istruzioni di tipo integer e sopratutto istruzioni che lavorano con la memoria( e speriamo che vi siano 4 agu). Quindi per farti un esempio un k10 può eseguire nella stragrande maggioranza dei casi possibili, NB non avviene quasi mai per il motivo detto sopra sulla natura del codice, 2 operazioni aritmetiche FP + un operazione non aritmetica. Buldozzer essendo strutturato cosi portebbe eseguire, essendo lo scheduler FP dedicato tra 2 core, 4 operazioni FP, 2 aritmetiche e due non, con conseguenza miglior sfruttamento delle risorse.
Come detto primase ho detto cassate correggetemi.

Sono dubbioso sul load & store address e sulla LSU.

Quali saranno le unità che calcoleranno l'indirizzo delle cache ?

Vedendo 4 pipeline intere, mi viene da pensare ad una composizione 4alu + 4 agu 64bit indipendenti o concorrenti (stile P6), che al occorrenza calcolano insieme un indirizzo a 256bit.
Sparo sta boiata, perchè lo schema del bobcat specifica espressamente le unità alu e L&S, invece nel bulldozer c'è un generico integer pipe.

Queste unità dovranno manipolare 256 bit di dati verso ogni singola cache, quindi non si potranno condividere le unità address dei due cluster,perchè ogni indirizzo fa capo ad una cache L1 data, tranne che le due cache siano in mirroring, cioè condividano gli stessi dati.

La LSU di ogni cluster dovrà avere almeno due porte a 128bit in lettura o scrittura.

Ovviamente, sempre se le AVX 256 saranno eseguite in un ciclo.

Scusate se ho sparato delle amenità...

[Pihippo]

Originariamente inviato da Ren

Sono dubbioso sul load & store address e sulla LSU.

Quali saranno le unità che calcoleranno l'indirizzo delle cache ?

Vedendo 4 pipeline intere, mi viene da pensare ad una composizione 4alu + 4 agu 64bit, che al occorrenza calcolano insieme un indirizzo a 256bit.

Queste unità dovranno manipolare 256 bit di dati verso ogni singola cache, quindi non si potranno condividere perchè ogni indirizzo fa capo ad una cache L1 data, tranne che le due cache siano in mirroring, cioè condividano gli stessi dati.
La LSU di ogni cluster dovrà avere almeno due porte a 128bit se la cache rimane a due vie 256bit.

Ovviamente, sempre se le AVX 256 saranno eseguite in un ciclo.

Scusate se ho sparato delle amenità...

Ciao
Le agu del k10 calcolano tuttora gli addresses in un singolo ciclo di clock. . Gli indirizzi delle cache\ram verranno sempre calcolati dalle agu, inoltre le L1 data sono reserved per ogni cluster di integer mentre vi sarà una singola grossa L1 instructions. Ogni cluster dispone di 4 integer pipe(dalla slide ho capito questo) e considerando la tendenza di Amd nella progettazione delle sue cpu di accorpare operazioni logiche\aritmetiche ad operazioni di memoria(i decoder amd mandano ognuno 3 mop agli scheduler, costituite da 2 op matematiche\logiche più op di memoria) si può pensare che ogni cluster avrà un proprio set di agu. Inoltre la agu calcolano l'indirizzo di memoria, ma è la L\S unit che dovrà avere un datapath verso la cache di 256bit per poter caricare\salvare in un singolo ciclo di clock gli operandi nella memoria(oppure 2 cicli se saranno a 128bit) Dunque l'ampiezza da valutare non è quella delle agu(almeno cosi ho capito che funzionano le address generator uniti) ma delle unità di load e store.

[Ren]

Ciao
Le agu del k10 calcolano tuttora gli addresses in un singolo ciclo di clock. . Gli indirizzi delle cache\ram verranno sempre calcolati dalle agu, inoltre le L1 data sono reserved per ogni cluster di integer mentre vi sarà una singola grossa L1 instructions. Ogni cluster dispone di 4 integer pipe(dalla slide ho capito questo) e considerando la tendenza di Amd nella progettazione delle sue cpu di accorpare operazioni logiche\aritmetiche ad operazioni di memoria(i decoder amd mandano ognuno 3 mop agli scheduler, costituite da 2 op matematiche\logiche più op di memoria) si può pensare che ogni cluster avrà un proprio set di agu. Inoltre la agu calcolano l'indirizzo di memoria, ma è la L\S unit che dovrà avere un datapath verso la cache di 256bit per poter caricare\salvare in un singolo ciclo di clock gli operandi nella memoria(oppure 2 cicli se saranno a 128bit) Dunque l'ampiezza da valutare non è quella delle agu(almeno cosi ho capito che funzionano le address generator uniti) ma delle unità di load e store.

Quindi le AGU non dovranno essere a 256bit (o in alternativa più unità a 64bit) come nel Sandy bridge ?
Sulla LSU mi sono spiegato male, ho ipotizzato l'obbligatorietà di almeno due porte load a 128bit o due porte store sempre a 128 bit.

Attualmente il k10 dispone di due unit LSU, una effettua due store a 64bit ed un altra che effettua due load a 128bit.
Il datapath verso la L1 Data è 256bit(2vie).

[MonsterMash]

Sono molto di fretta, quindi scrivo giusto due righe: riguardo all'utilizzo della gpu per le operazioni floating point, non è una cosa fattibile, perchè la gpu non esegue le classiche istruzioni che eseguono le cpu (x86, mmx, sse, x64, etc, etc). Non accadrà presto (e non certo entro l'uscita di buldozer) di vedere la totalità del software in grado di sfruttare la potenza elaborativa di una gpu. Saranno ancora a lungo (relativamente) pochi software a farlo, e solo quelli che usano le istruzioni DirectCompute, o OpenCL (o al più cuda per nvidia, e CAL per ati).

Non avrebbe senso quindi che amd rinunciasse ai calcoli fpu nella cpu.

[Pihippo]

Originariamente inviato da Ren

Quindi le AGU non dovranno essere a 256bit (o in alternativa più unità a 64bit) come nel Sandy bridge ?
Sulla LSU mi sono spiegato male, ho ipotizzato l'obbligatorietà di almeno due porte load a 128bit o due porte store sempre a 128 bit.

Attualmente il k10 dispone di due unit LSU, una effettua due store a 64bit ed un altra che effettua due load a 128bit.
Il datapath verso la L1 Data è 256bit(2vie).

Ciao
Per quello che ne capisco io, no.
Comunque il k10 ha solo 1 L\S unit. Però questa Load\Store unit ha 2 code. LS1 accetta le operazioni di Load a 128bit e ne può eseguire 2 per ciclo(contro 1 di penryn), mentre LS2 accetta le operazioni di store a 128bit ma è capace di scrivere solo 64bit alla volta, quindi c'è ne vogliono 2 di cicli, infatti i k10 hanno un'elevata velocità di lettura della memoria ed una modesta di scrittura.

[papafoxtrot]

iscritto

[genesi86]

scusatemi potreste dirmi se i bulldozer saranno compatibili col socket AM3?

[sniperspa]

Originariamente inviato da genesi86

scusatemi potreste dirmi se i bulldozer saranno compatibili col socket AM3?

Sembra proprio di si.