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

[capitan_crasy]

Originariamente inviato da Ren

Ricordo che con il passaggio a 32nm debutteranno le T-RAM (thyristor random-access memory), un tipo di memoria scelta da AMD in sostituzione della Z-RAM che promette densità 4 volte superiori alla attuali tecnologie.
E' probabile, ma non certo che Bulldozer adotterà questa tecnologia in sostituzione della cache ordinaria.

Ma speriamo che questa volta sia quella buona!
Comunque sia dopo l'esperienza della Z-Ram aspetto una conferma ufficiale da parte di AMD o GF sul suo utilizzo...

[checo]

bel topic!
2 cose

1- deluso da quel che sarà fusion, detta così sembra solo gpu+cpu come fa intel, io immaginavo più un approccio alla cell.

2-finalmente il reverse hypertreading o come lo volete chiamare! dico finalmente perchè nel mio piccolo pensavo da molto che una soluzione per aumentare le prestazioni fosse utilizzare due core come uno solo passando per un unità di coordinamento, così da fruttare il multithreading anche in thread single.
a livello teorico mi sebra il guadagno di prestazioni sia evidente

[capitan_crasy]

Originariamente inviato da checo

bel topic!
2 cose

1- deluso da quel che sarà fusion, detta così sembra solo gpu+cpu come fa intel, io immaginavo più un approccio alla cell.

manca ancora l'ufficialità ma l'APU di AMD molto probabilnmente sarà CPU+GPU nello stesso pezzo di silicio, quindi ben distante dall'approccio Intel...
AMD ha cancellato la soluzione multichip package CPU+GPU composta da un derivato del core Regor e GPU RV720...

2-finalmente il reverse hypertreading o come lo volete chiamare! dico finalmente perchè nel mio piccolo pensavo da molto che una soluzione per aumentare le prestazioni fosse utilizzare due core come uno solo passando per un unità di coordinamento, così da fruttare il multithreading anche in thread single.
a livello teorico mi sebra il guadagno di prestazioni sia evidente

Il Reverse Hypertransport non è solo quello, ma avrà una funzione molto più importante:

Originariamente inviato da bjt2

Per quanto riguarda il core buldozer... Se le voci che girano sono esatte, quel reverse hyperthreading di cui si vociferava dovrebbe essere il seguente: le unità FP sono sempre a 128 bit, ma due (o più) core fisici condividono le unità intere e FP nel senso che entrambi i core possono utilizzarle. Questo perchè nelle precedenti architetture si è visto che le unità sono sottoutilizzate. Una istruzione a 256 bit è sempre spezzata in 2 a 128 bit, ma essendoci più unità intere e FP (anche se in comune) se non sono tutte utilizzate, le due parti a 128 bit possono essere eseguite in parallelo.

[checo]

che cpu e gpu siano sullo stesso chip o meno poco cambia per me finchè rimangono due cose distinte, diverso il discorso se la cpu nell' eseguire un Thread va ad attingere alle risorse gpu qualora ne abbia bisogno.

[capitan_crasy]

Originariamente inviato da checo

che cpu e gpu siano sullo stesso chip o meno poco cambia per me finchè rimangono due cose distinte,

E perchè?

diverso il discorso se la cpu nell' eseguire un Thread va ad attingere alle risorse gpu qualora ne abbia bisogno.

Senza il software in grado di utilizzare le GPU per i calcoli generici, core GPU separato o unito nel core X86, la situazione non cambia...

[checo]

Originariamente inviato da capitan_crasy

E perchè?

Senza il software in grado di utilizzare le GPU per i calcoli generici, core GPU separato o unito nel core X86, la situazione non cambia...

appunto unito o separato non cambia se rimane comunque indipendente

[MonsterMash]

Originariamente inviato da checo

appunto unito o separato non cambia se rimane comunque indipendente

Una gpu che esegue codice x86 non la vedremo mai, però pare ormai vicino il momento in cui sarà possibile compilare codice che faccia uso delle librerie openCL, e in cui le API openCL abbiano un'interfaccia sui driver delle schede video .

[checo]

riguardo al core cluster, avendo la fpu in comune non è come raddoppiare le alu ed associarvi una l1 ad ogn'una?

[M4R1|<]

Originariamente inviato da capitan_crasy

Jim Doran (senior vice presidente e general manager della Fab 1 di Globalfoundries) conferma che il processo produttivo a 32nm con tecnologia SOI e HKMG (high-K metal gate) entrerà in fase di produzioni in volumi nella seconda parte del 2010.
Attualmente i test sulle produzioni di SRAM da 24Mb (più veloci del 50% se paragonati con la produzione a 45nm) hanno una resa del 50%, ma entro fine anno dovrebbe raggiungere la resa massima; inoltre con il brevetto proprietario APM (Automated Precision Manufacturing) i difetti di produzione sono eccezionalmente ridotti al minimo.
In linea generale questa notizia non cambia i tempi sull' uscita di Bulldozer prevista sempre per il 2011, ma conferma l'utilizzo del HKMG sul 32nm SOI.

Clicca qui...

Ottima notizia, è molto probabile di vedere dei k10 a 32nm nel 2010 per poi avere un lancio in concomitanza con Sandy Bridge di Bulldozer

[Mister_K]

Iscritto!!!

[Severnaya]

è plausibile pensare che vi siano già dei sample funzionanti???

[capitan_crasy]

Originariamente inviato da Severnaya

è plausibile pensare che vi siano già dei sample funzionanti???

Direi di no...
Secondo me è troppo presto; credo ce vedremo qualcosa nel Q1 2010....

[Pihippo]

Ciao a tutti.
Sperando non sia old.

http://www.freepatentsonline.com/7565513.pdf

Qui c'è un hint su come bulldozer potrebbe avere una FPU configurabile che a secondo al carico di lavoro aggiusta la sua ampiezza.
Dagli schemini non c'ho capito nulla.

[bjt2]

Originariamente inviato da Pihippo

Ciao a tutti.
Sperando non sia old.

http://www.freepatentsonline.com/7565513.pdf

Qui c'è un hint su come bulldozer potrebbe avere una FPU configurabile che a secondo al carico di lavoro aggiusta la sua ampiezza.
Dagli schemini non c'ho capito nulla.

Il brevetto è per una FPU a risparmio energetico. La pipeline dell'esempio è del K10, quindi è possibile che sia implementata nei Deneb. E' un procedimento molto generico che consente di avere un modo a piena precisione, nell'esempio a 128 bit, o a precisione ridotta, nell'esempio 64 bit, più lento ma meno esoso in termini di comsumo...

[Pihippo]

Originariamente inviato da bjt2

Il brevetto è per una FPU a risparmio energetico. La pipeline dell'esempio è del K10, quindi è possibile che sia implementata nei Deneb. E' un procedimento molto generico che consente di avere un modo a piena precisione, nell'esempio a 128 bit, o a precisione ridotta, nell'esempio 64 bit, più lento ma meno esoso in termini di comsumo...

Ciao.
Quindi è possbile che bulldozer implementiuna tecnica simile per le AVX, ovvero, da quello che ho capito, potrebbe avere una FPU con datapath a 256bit o 128x2 in modo che in assenza di vettori a 256bit possa operare come se fossero 2 pipeline con datapath a 128bit, quindi potendo assistere i due cluster di alu poste in ogni core, Sbaglio?

[Ren]

BJT è possibile differenziare il clock della pipeline FP dei processori AMD ?
Avevo in mente un meccanismo simile al Pentium 4, data la natura indipendente della FP pipeline, nonché la sua lunghezza superiore in stadi...

ps. non mi riferisco al brevetto, ma in generale.

[checo]

io non credo che il clock della fpu si possa variare rispetto al resto..

cmq patent== brevetto

[Pihippo]

Originariamente inviato da Ren

BJT è possibile differenziare il clock della pipeline FP dei processori AMD ?
Avevo in mente un meccanismo simile al Pentium 4, data la natura indipendente della FP pipeline, nonché la sua lunghezza superiore in stadi...

ps. non mi riferisco al brevetto, ma in generale.

Ciao.
Ti viene in mente le agu del p4 che erano clocckate al doppio della frequenza del processore?
Considera che ora come ora nel k10 la FPu è di 17 stadi e le alu\agu sono 12. Magari in bulldozer aggiungeranno qualche altro stadio (ad esempio nehalem ha le alu se non erro lunghe 20 stadi e qualcosina in più per la FPU)

[bjt2]

Originariamente inviato da Pihippo

Ciao.
Quindi è possbile che bulldozer implementiuna tecnica simile per le AVX, ovvero, da quello che ho capito, potrebbe avere una FPU con datapath a 256bit o 128x2 in modo che in assenza di vettori a 256bit possa operare come se fossero 2 pipeline con datapath a 128bit, quindi potendo assistere i due cluster di alu poste in ogni core, Sbaglio?

Quel brevetto è per un risparmio energetico. Consente di processare istruzioni SIMD per intero o spezzettato, in base al risparmio energetico impostato. Probabilmente sarà implementato nella versione k10 per notebook...

[bjt2]

Originariamente inviato da Ren

BJT è possibile differenziare il clock della pipeline FP dei processori AMD ?
Avevo in mente un meccanismo simile al Pentium 4, data la natura indipendente della FP pipeline, nonché la sua lunghezza superiore in stadi...

ps. non mi riferisco al brevetto, ma in generale.

Si può fare tutto... Daltronde NVIDIA ha le ROP e gli stream processors che vanno a frequenze indipendenti e non multiple l'una dell'altra...