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

[digieffe]

Originariamente inviato da paolo.oliva2

Domanda:

Perché di solito la cache L1 istruzioni e dati sono di dimensioni uguali (sia Phenom II che Intel) e BD invece avrebbe una L1 di 64KB per le istruzioni e invece per i dati solamente 16KB (1/4 di quelle per le istruzioni?) è un errore di digitazione o è effettivamente così?

provo a rispondere sperando di non scrivere castronerie

Phenom II è da tempo immemore (credo dal k8) che porta la L1 64I + 64D (con poche vie)

stessa cosa da lungo tempo per intel L1 32I + 32D (però più veloce, e con + vie, credo per compensare la dimensione più piccola)

BD ha 64I per i 2 core del modulo... e 1 da 16D per ogni core (32D x modulo, anche se non si sommano)

queste ultime da 16D sono writethrough (significa che appena hanno il dato lo scrivono e non attendono come il write back) al contrario delle altre gi descritte,

tant'è che ad ognuna da 16D c'è una ulteriore cache da 4kb non menzionata che serve a raggruppare le scritture ed altro evitando di sovraccaricare i livelli inferiori di caches.


edit: mi era sfuggito

Originariamente inviato da paolo.oliva2

Domanda:

Perché? (per il punto 1)
Un BD X8 ha 8x64... un BD X4 ha 4x64, questo non è un errore.
Al limite c'è un errore quello che ho riportato sopra io...

sono 64 ogni modulo codivise tra i 2 core... 4x64

[digieffe]

Originariamente inviato da gi0v3

altro articolo interessantissimo (imho) su semiaccurate...
http://semiaccurate.com/2011/06/22/a...orces-at-last/
tra oggi e domani vi traduco qualche pezzo, in soldoni dice che
- all'amd fusion event è stato annunciato, e neanche tanto tra le righe, che AMD e ARM faranno, in un futuro non tanto lontano, una APU "a quattro mani"...
-amd ha dichiarato che vuole "aprire le proprie apu",
- parla di compatibilità a basso livello,
- parla della possibilità anche per altri produttori di cpu e interfacce di inserirle direttamente dentro la APU, che diventerebbe un calderone dove tutto è gestito tramite il bus pcie ( il 3.0, dice semiaccurate, infatti si parla del futuro ),
- dice che il "finalizer" ovvero l'elemento aggiuntivo prodotto da terzi, può riordinare la memoria... quindi potrebbe funzionare anche per una cpu con un'architettura non-x86, visto che nella APU la gpu c'è già non è dcerto di quello che si parla
- le slide di ARM parlano della stessa cosa, ma vista dal loro punto di vista

ultima cosa, interessante anche questa: la riflessione che fa il tizio è che per arrivare a una completa interoperabilità e integrazione tra le due realtà, servirebbe una cpu amd semplice come una ARM, che sia "sintetizzabile con un basso numero di array specifici", e anche "facilmente trasferibile attraverso le diverse tecnologie produttive"...


e da questo deduce che


"Se qualcuno pensava che Dirk Meyer non avesse una strategia per l'elettronica di consumo, e/o che non fosse già stabilita da tempo, beh, si sbagliava."

domani con più calma vedo di tradurvi tutto, le parti più tecniche farò il possibile ma non sono un informatico, quindi magari qualcuno mi dirà qual è la traduzione in italiano di alcuni termini

attendo il resto...

per i termini informatici sono a disposizione anche se domani avrò una giornata particolare e non so quanto potro stare vicino al pc.

cmq, se ho capito bene AMD vuole vendere la parte gpu dell'apu come progetto, esattamente come fa ARM in modo che altri possano usarle nelle loro cpu ad iniziare da chi implementa arm?

avremo apu arm?

forse anche .nt.l userà fusion ?!?

[blindwrite]

Originariamente inviato da paolo.oliva2

Se hai notato, ho scritto che non mi intendo, però, nella mia ignoranza, sono stato il 1° a supporre che AMD potesse avere uno step di silicio con solo HKMG e non anche con l'ULK, come invece era stato dichiarato. Io ho fatto supposizioni... poi chi se ne intende può dire se può avere una giustificazione o meno.

L'HKMG si riferisce al dielettrico utilizzato nella giunzione MOS (metallo ossido semiconduttore) ed è stato introdotto a partire dal 32nm nel core process dell'alleanza (IBM-GF-Infineon-STM-Renesas e altre) ed è nello specifico un HKMG gate first. Ciò vuol dire che il polisilicio che forma la gate è separato dal substrato per mezzo di un dielettrico ad alta permittività in modo da ridurre drasticamente il leackage (fuga di corrente verso il substrato) del transistor stesso. A livello di performance non è detto che una integrazione HKMG migliori le cose dato che la capacità della gate verso il substrato incrementa se si mantiene lo stesso spessore dell'ossido rispetto alla integrazione normale in SiO2.
Il passaggio ad HKMG è stato necessario più per ridurre i consumi che per aumentare le prestazioni, ed in ogni caso è un trade-off (isolazione vs performance).

L'integrazione Back-End in ULK invece è presente per tutti (prima del 32nm non c'era l'alleanza ed ognuno si sviluppava il suo processo) sicuramente da 65nm in poi, credo anche nei 90nm.
Lo scopo dell'ULK è di ridurre la capacità di accoppiamento tra le linee di metallo che servono a interconnettere i transistor

i transistor sono nell'immagine al disotto del M1.

Front-End (transistor) e Back-End (interconnessioni) sono sviluppati da team separati. Il back-end 32nm dell'alleanza è in ogni caso un Back-End classico con metalli sottili in ULK e metalli spessi in TEOS/FTEOS.

Il processo 32nm di base (quindi implementazione minima per tutti, quella sviluppata in comune) è così. Non esiste uno stack metallico che non preveda ULK per i metalli sottili e non ci sono dispositivi che non siano HKMG gate first.

[carpo93]

Originariamente inviato da capitan_crasy

Ciumbia; allora deve essere vero...
Se non l'hai ancora capito quello era un esca per i "persici trota"...
E secondo te AMD da via così i propri sample soprattutto a uno che li vende di straforo???
Siamo seri per cortesia...

Il sample l'ha preso in cina attraverso canali non ufficiali, non gli è stato dato nulla da AMD per quanto ne so io

[paolo.oliva2]

Originariamente inviato da blindwrite

L'HKMG si riferisce al dielettrico utilizzato nella giunzione MOS (metallo ossido semiconduttore) ed è stato introdotto a partire dal 32nm nel core process dell'alleanza (IBM-GF-Infineon-STM-Renesas e altre) ed è nello specifico un HKMG gate first. Ciò vuol dire che il polisilicio che forma la gate è separato dal substrato per mezzo di un dielettrico ad alta permittività in modo da ridurre drasticamente il leackage (fuga di corrente verso il substrato) del transistor stesso. A livello di performance non è detto che una integrazione HKMG migliori le cose dato che la capacità della gate verso il substrato incrementa se si mantiene lo stesso spessore dell'ossido rispetto alla integrazione normale in SiO2.
Il passaggio ad HKMG è stato necessario più per ridurre i consumi che per aumentare le prestazioni, ed in ogni caso è un trade-off (isolazione vs performance).

L'integrazione Back-End in ULK invece è presente per tutti (prima del 32nm non c'era l'alleanza ed ognuno si sviluppava il suo processo) sicuramente da 65nm in poi, credo anche nei 90nm.
Lo scopo dell'ULK è di ridurre la capacità di accoppiamento tra le linee di metallo che servono a interconnettere i transistor

i transistor sono nell'immagine al disotto del M1.

Front-End (transistor) e Back-End (interconnessioni) sono sviluppati da team separati. Il back-end 32nm dell'alleanza è in ogni caso un Back-End classico con metalli sottili in ULK e metalli spessi in TEOS/FTEOS.

Il processo 32nm di base (quindi implementazione minima per tutti, quella sviluppata in comune) è così. Non esiste uno stack metallico che non preveda ULK per i metalli sottili e non ci sono dispositivi che non siano HKMG gate first.

Quindi, parlando di 32nm HKMG sarebbe sottinteso ULK perché ci sarebbe sempre e se scrivono 32nm HKMG sarebbe per semplicità perché per gli addetti ai lavori sarebbe scontato?

[capitan_crasy]

Originariamente inviato da carpo93

Il sample l'ha preso in cina attraverso canali non ufficiali, non gli è stato dato nulla da AMD per quanto ne so io

O forse la trovato nel famoso ovetto di cioccolato...
Oltre la violazione del NDA ce anche il possesso e la ricettazione di tecnologia rubata; di bene in meglio...
Ma solo io trovo strano che questo tizio vende CPU di dubbia origine fregandosene altamente del NDA AMD e poi si dia la briga di cancellare le caratteristiche degli screen su BD?

[george_p]

Originariamente inviato da capitan_crasy

O forse la trovato nel famoso ovetto di cioccolato...
Oltre la violazione del NDA ce anche il possesso e la ricettazione di tecnologia rubata; di bene in meglio...
Ma solo io trovo strano che questo tizio vende CPU di dubbia origine fregandosene altamente del NDA AMD e poi si dia la briga di cancellare le caratteristiche degli screen su BD?

No, più volte è stata riportata addietro, in questo stesso thread, l'inaffidabilità di questo utente attraverso link su semiaccurate et simili, dove molti utenti lo definiscono bugiardo e troll, a quanto pare è stato cacciato da diversi forums.

Continuare a postare links al suo blog equivale a dare importanza a niente e aumentare click al suo sito.

[Walrus74]

Sembra che l'overclocker "Chew" stia mettendo le mani su un BD sotto LN2...



Fonti:
http://www.xtremesystems.org
http://www.omnixedia.com/

[Polpi_91]

Chew è affidabile è uno dei principali clocker su amd e forse ci lavora anche dentro non mi ricordo

[kiriranshelo]

Originariamente inviato da capitan_crasy

Caso mai Hypertransport...
Ripeto:
ES si chiama FX-3214, le prime due sigle rappresentano la frequenza di clock della CPU...

ma la dicitura FX-x2xx non era relativa a Komodo/Trinity in uscita nel 2012?

[gi0v3]

Originariamente inviato da Walrus74

Sembra che l'overclocker "Chew" stia mettendo le mani su un BD sotto LN2...



Fonti:
http://www.xtremesystems.org
http://www.omnixedia.com/

sto seguendo anche io il thread su xtremehw, appena si smuove qualcosa vi avviso

[capitan_crasy]

Originariamente inviato da kiriranshelo

ma la dicitura FX-x2xx non era relativa a Komodo/Trinity in uscita nel 2012?

Ma anche se fosse stiamo parlando di ES e non di versioni definitive...
Tanto per fare un esempio ecco alcuni OPN di ES Bulldozer:

[niubbo69]

Originariamente inviato da Níðhöggr

http://techreport.com/articles.x/21099/11

Impressionante
Finora si è sempre parlato solo di fps per definire la bontà di un IGP, ma la differenza di qualità tra le due soluzioni è davvero notevole.

[paolo.oliva2]

Originariamente inviato da niubbo69

Impressionante
Finora si è sempre parlato solo di fps per definire la bontà di un IGP, ma la differenza di qualità tra le due soluzioni è davvero notevole.

Purtroppo spesso il discorso del confronto assume aspetti di bandiera considerando solo quello che si vuole.

[greeneye]

Originariamente inviato da Níðhöggr

A questo proposito sarà interessante vedere chi userà sysmark nelle recensioni, dopo che AMD, NVIDIA e VIA hanno salutato lasciando Intel da sola sul barcone...

Diciamo ...tutti quelli che lo usavano prima?

[Vash_85]

Effettivamente se c'è rimasta solo intel nel consorzio sysmark che metro di comparazione potranno avere?

[phicrand_6358]

Originariamente inviato da phicrand_6358

ho sentito dire che Llano desktop avrà un turbo che clocca gpu e cpu in base a quale delle due fa da collo di bottiglia, cosa se ne sa a riguardo?
sarebbe bello anche se tale comportamento fosse controllabile tramite bios... magari un Labview a caso potrebbe dare un occhio a qualche bios per Fm1..

up

[ramino008]

considerato che in molti stiam ripetendo da parecchio che llano non è una piattaforma per giocare (e non solo) direi che chi si interessa dei frame della igp è solo chi vuole abbinarci ram iperveloci.
La prova è abbastanza parziale e sinceramente non riporta (ancora non leggo tutto) se c'è il supporto ai bd 3d, l'hdmi come si comporta, i vari filtri amd se sono applicabili assieme o c'è il limite come per le schede tipo hd 5550 e via dicendo
Che poi vada meglio di intel lo vorrei ben sperare, non ha mai brillato in qulità in fatto di chipset integrati, per questo spesso su htpc ci si monta comunque una discreta (fra l'altro non è supportata neanche da coreavc, almeno nelle versioni "pre core i", grosso limite)

[Matalf]

Originariamente inviato da phicrand_6358

up

sulle versioni mobile il Turbo praticamente non si attivava praticamente mai, la versione descktop top non ce l'ha neanche....



Ma solo io penso che il Turbo core sia solo una trovata pubblicitaria?


il 10/15% di frequenza in più quando non sto utilizzando tutti i core, cosa mi serve?

Sui serve può anche avere un senso, ma su un Pc di fascia bassa/OEM è solo un ennesimo bollino sull'case.

[paolo.oliva2]

Originariamente inviato da Matalf

sulle versioni mobile il Turbo praticamente non si attivava praticamente mai, la versione descktop top non ce l'ha neanche....



Ma solo io penso che il Turbo core sia solo una trovata pubblicitaria?


il 10/15% di frequenza in più quando non sto utilizzando tutti i core, cosa mi serve?

Sui serve può anche avere un senso, ma su un Pc di fascia bassa/OEM è solo un ennesimo bollino sull'case.

Io non l'ho e non l'ho provato... però non capisco il perché delle rece analizzando l'architettura praticamente riportano che il Turbo serve l'IGP o i core in base dove c'è maggior richiesta, l'IGP può passare da 400-440MHz a punte di 800MHz (qui praticamente raschieremmo il 100%), il Turbo dei core raschia il +50%. L'unico Llano che non ha il Turbo al momento è il 100W desktop.
Se a te risulta il 10-15% al massimo in più con tutti i limiti, ne dedurrei che le rece che hanno testato Llano, o avevano bios ancora beta oppure c'erano compromessi tipo alimentazione/batteria/consumo perché se AMD riporta n caratteristiche non capisco il perché non siano applicate.

Inoltre il Turbo di Llano è diverso appunto perché riserva i TDP del Turbo o ai core o all'IGP a seconda di dove si crea il collo di bottiglia. Nei server invece lo troverei discutibile... non tanto quello di +500MHz su tutti i core ma quello di +1GHz su 8 core sui 16 totali.