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

[capitan_crasy]

[Thread Ufficiale]
CPU serie FX
AMD "Bulldozer"
http://www.xtremeshack.com/immagine/i114079_bulldozer-die.jpg
Aspettando
AMD "Piledriver"
http://www.xtremeshack.com/immagine/i114080_amd-roadmap-fx-next-r.jpg
(CPU a 32nm SOI)

Premessa.
Questo Thread ha lo scopo primario di raccogliere notizie e indiscrezioni sulle nuove CPU con architettura Bulldozer e CPU Piledriver (Bulldozer di seconda generazione) con tecnologia produttiva a 32nm SOI HKMG.
Il [Thread Ufficiale] AMD APU Llano (Desktop) e aspettando Trinity - Krishna/Wichita lo provate a questo indirizzo! (http://www.hwupgrade.it/forum/showthread.php?t=2371637)
Il thread ufficiale su Zacate/Ontario, APU a 40nm Bulk, lo provate a questo indirizzo! (http://www.hwupgrade.it/forum/showthread.php?t=2321343)
Per cercare di avere ordine il thread sarà diviso in 6 pagine ognuna dedicata dal riassunto di uno specifico argomento.

Indice del thread

Prima Pagina:
Premessa, indice e regolamento del Thread

Seconda Pagina
Caratteristiche Architettura AMD Bulldozer (http://www.hwupgrade.it/forum/showpost.php?p=29090000&postcount=2)

Terza Pagina
Modelli attualmente/prossimamente in commercio (http://www.hwupgrade.it/forum/showpost.php?p=29090016&postcount=3)

Quarta Pagina
Notizie dalla rete (http://www.hwupgrade.it/forum/showpost.php?p=29090024&postcount=4)

Quinta Pagina
Link recensioni CPU serie FX dalla rete (http://www.hwupgrade.it/forum/showpost.php?p=29090030&postcount=5)

Sesta Pagina
Approfondimento su Bulldozer/Piledriver (http://www.hwupgrade.it/forum/showpost.php?p=29090037&postcount=6)

Settima Pagina
Post di servizio (http://www.hwupgrade.it/forum/showpost.php?p=29090037&postcount=6)



Regolamento

* non sono ammessi notizie o commenti sull'andamento finanziario ( compreso i titoli quotati in borsa ) o di mercato da parte di AMD e/o Intel.
* non sono ammessi commenti catastrofici o comunque in grado di generare FLAME
* non sono graditi commenti stile Fanboy sia da parte AMD sia da parte Intel
* non sono ammessi post stile "consigli per gli acquisti"; in pratica niente consigli o suggerimenti per la scelta di un nuovo hardware
* non sono ammessi discussioni sulle CPU K8/K9 Athlon64/X2
* Le discussioni sull'architettura K10 sarà consentita solo per confronti diretti o di paragone sulle prestazioni o differenze architetturali
* Cerchiamo di limitare al minimo gli argomenti OT, se proprio non ce la fate comunicate attraverso i messaggi privati
* Per evitare di appesantire eccessivamente il Thread le immagini postate non dovranno superare la risoluzione 800X600 pixel

http://www.xtremeshack.com/immagine/i114081_attenzione-th400.jpg

Per evitare che i post OT e AMD vs Intel inquinino il Thread ricordo che il moderatore di sezione "gianni1879" vigila continuamente sull'andamento del thread; ogni grave violazione del regolamento del Thread e del forum saranno "segnalati" con possibili e probabili sanzioni più o meno gravi.


Il contenuto di questo post (dal primo, al sesto post) è rilasciato con licenza "Creative Commons Attribution-Noncommercial-Share Alike 2.5" (http://creativecommons.org/licenses/by-nc-sa/2.5/it/)

[capitan_crasy]

Caratteristiche Architettura AMD Bulldozer

Nuova architettura CPU di AMD, la quale andrà a sostituire l'attuale Tecnologia "Hammer" dove si basano gli attuali K8/K9/K10.

Un po di storia

L'architettura Bulldozer è stata progettata completamente da zero, a differenza di quanto avvenuto con Barcelona e Shanghai che rappresentano evoluzioni dell'architettura K8.
L'annuncio fu dato prima ancora che il K10 fosse presentato ufficialmente, ma questo non era una assoluta novità per AMD.
Il progetto originario del primo Bulldozer prevedeva una CPU a 4/6 core sul processo produttivo a 45nm SOI con supporto alle SSE5.
L'uscita prevista era stata annunciata per fine 2009 dallo stesso neo CEO AMD Dirk Meyer e il suo concorrente diretto era l'architettura Nehalem di Intel.
Purtroppo dopo i primi risultati da laboratorio sui primi sample, AMD decise la cancellazione della versione a 45nm SOI per passare direttamente al processo produttivo a 32nm SOI con importanti cambi architetturali, quali l'abbandono delle istruzioni SSE5 e l'adozione delle AVX di Intel.
Non sapremo mai cosa andò storto, tuttavia la tecnologia low-k presente del Six core K10 AMD è cugina del lavoro svolto su Bulldozer a 45nm SOI.

Bulldozer in dettaglio

L'architettura Bulldozer prevede due core per elaborazioni Integer, affiancati da un'unità Floating Point che è condivisa.
La scelta di AMD è quella di raddoppiare la sola parte Integer delle proprie CPU, lasciando condivisa quella Floating Point, dato che la maggior parte del calcolo riguarda proprio le unità Integer (in media per l'80%). Questo tipo di filosofia architetturale ha l'obbiettivo di ottenere il miglior rapporto tra prestazioni e consumo duplicando la parte Integer, massimizzando quindi il parallelismo delle operazioni e lasciando unificata un'unità in virgola mobile la quale avrà al suo attivo una notevole potenza di calcolo.
Le caratteristiche della Floating Point per ogni modulo Bulldozer prevede due unità Multiply and Accumulate a 128 bit, a monte delle quali troviamo anche uno scheduler in virgola mobile; mentre per quanto riguarda le ISA sono supportate tutte le principali istruzioni (tranne le 3DNow) quali SSE3, SSE 4.1 and 4.2, AVX, AES, FMA4, XOP, PCLMULQDQ.
La principale novità sono le istruzioni AVX (Advanced Vector eXtensions) a 256bit; lo sfruttamento di queste istruzioni verrà compiuto da Bulldozer mettendo in parallelo le due unità Floating Point a 128bit la quale, dal tipo di applicazione in esecuzione, possono essere configurate anche come 4x64bit, 2x128bit e 1x256bit.
Altra novità importante e il nuovo decoder a 4 vie, completamente ridisegnato rispetto al tradizionale 3 vie adottato da AMD nelle ultime precedenti architetture (al K7 in su); la conseguenza diretta e che ora si può unire istruzioni branch x86 aumentando l'ampiezza del decoder.
Sono anche presenti 3 distinti scheduler divise per le due unità Integer e uno per il Floating Point.
Ogni unità Integer è dotata di una cache L1 per i dati da 16KB, valore inferiore ai 64KB integrati per ogni core nell'architettura K10, a monte dell'unità di fetch troviamo una seconda cache L1 da 64KB a 2 vie per istruzioni.
AMD, rispetto al K10, ha allungato la pipeline interna alle unità di calcolo Integer in modo da ottenere frequenze di clock più elevate rispetto alle sue "vecchie" architetture.
La scelta di questa soluzione però potrebbe provocare un eccessiva dipendenza dalle unità di branch prediction; AMD quindi ha integrato il Branch Prediction e il Fetch Logic facendoli operare in modo indipendente l'una dall'altra, evitando spiacevoli situazioni di stallo quando una di queste si arresti per un qualsiasi motivo. Un'unità di prefetch così aggressiva accoppiata a una pipeline più lunga, richiedono maggiori prestazioni (in termini di banda) per quanto riguarda il memory controller integrato; per il momento AMD non ha rilasciato le caratteristiche di questo componente, anche se ha confermato il suo totale ridisegno per fruttare al massimo la banda messa a disposizione dalle memorie RAM DDR3.
Non si conosce quali frequenze possa gestire il controller RAM, tuttavia è ipotizzabile che possa adottare configurazioni superiori agli attuali Dual channer presenti nei controller Ram dei K10.
La quantità della cache L2 (16 vie) dovrebbe essere da 2MB (valore non confermato ufficialmente da AMD) la quale sarà unificata tra i 2 core per modulo; ci sarà una anche una cache L3 verosimilmenteda 8MB (valore non confermato ufficialmente da AMD) condivisa anch'essa da tutti i moduli/core.
AMD con Bulldozer, al contrario di Intel con la tecnologia HyperThreading o l'SMT (Simultaneous Multi Threading) che esegue per ogni core due threads in parallelo, ha scelto di integrare due unità di calcolo Integer complete affiancate da una complessa unità in virgola mobile che è condivisa.


http://www.pctunerup.com/up/results/_201008/20100824120034_bulldozerthreads.jpg


Bulldozer di fatto integra due core che condividono le risorse di elaborazione in virgola mobile, avendo pipeline dedicate per quelle Integer
AMD ha scelto la via della condivisione delle risorse, creata in modo tale da ottimizzare le prestazioni al consumo massimo ottenibile; non a caso si prevede che la presenza della sola seconda unità di calcolo Integer all'interno di ogni modulo Bulldozer, implichi un incremento della superficie complessiva del chip pari al 12%, valore particolarmente contenuto considerando il boost prestazionale ottenibile.
Sul capitolo consumi Bulldozer con i suoi moduli, potrà gestire dinamicamente e indipendentemente l'uno dall'altro il Vcore e frequenza di clock, anche se questo non può essere fatto per singolo core ma solo per coppia di core legato comunque al modulo Bulldozer.
Novità in vista anche per il Turbo Core AMD, introdotto con i K10 step E, la quale si dovrebbe avvicinare molto a quella Turbo Boost introdotta da Intel con le CPU della famiglia Nehalem.

Il socket AM3r2 o AM3+

AMD ha confermato l'uscita di un (nuovo?) socket chiamato molto genericamente AM3r2 o AM3+.
Al momento ci sono poche informazioni ma quello sicuro è che le CPU Bulldozer non saranno compatibili con gli attuali e future schede madri socket AM3.
La causa è da imputare ad un cambio radicale legate alla circuiteria di alimentazione; la stessa AMD ha dichiarato che adattare Bulldozer sugli attuali socket AM3 avrebbe portato ad un aumento dei costi finali e la impossibilità di utilizzare tutte le nuove caratteristiche della nuova architettura limitando eccessivamente le prestazioni finali.
Resta da confermare la compatibilità dei socket AM3+ sulle attuali CPU K10 socket AM3 attualmente presenti sul mercato.

Piattaforma AMD "Scorpius"

Con l'uscita delle CPU Bulldozer AMD presenterà una nuova piattaforma chiamata "Scorpius", la quale sarà composta da nuovi chipset AMD serie 900 modello 990FX, 990X (Crossfire ready) e 970.
Ci saranno anche dei nuovi southbridge serie 900, in particolare il modello Hudson D3 sarà in grado di supportare 4 porte USB 3.0 senza l'aiuto di chip esterni.


http://www.pctunerup.com/up/results/_201008/20100824115453_buildingbulldozer.jpg


Le prime soluzioni della famiglia Bulldozer sono attese al debutto nella prima parte del 2011 e saranno costruite da GlobalFoundries con il processo produttivo a 32nm SOI.
Le prime cpu della famiglia Bulldozer che vedremo sul mercato con tutta probabilità saranno quelle della famiglia Opteron, con versioni 6/8/12 e 16 core.
Le versioni desktop della famiglia Zambezi sono attesi subito dopo con modelli 4/(forse)6 e 8 core.
AMD ha comunicato che Bulldozer sarà pronto nella prima parte del 2011.


http://www.pctunerup.com/up/results/_200910/20091007115145_20091007amd_roadmap.jpg


http://www.pctunerup.com/up/results/_200909/20090930162251_scorpius.jpg

[capitan_crasy]

Perchè integrare CPU e GPU in un unico elemento

Integrazione tra GPU e CPU: è questa la principale evoluzione tecnologica che AMD e ATI si aspettano di presentare al mercato nei prossimi anni. Il nome scelto per i prodotti che integreranno GPU e CPU è quello di Fusion, che ben simboleggia l'unione tra architetture sulla carta e di fatto molto differenti tra di loro. La risultante saranno una serie di prodotti sviluppati per svariati ambiti di impiego, nei quali quindi la combinazione tra parte CPU classica e parte GPU assumerà pesi differenti tra di loro.

Per quale motivo si vuole giungere a fornire soluzioni che integrino al proprio interno una GPU? La principale giustificazione è legata all'elevata potenza elaborativa di cui sono capaci le GPU, in termini di Gflops, rispetto a quanto accessibile con una CPU. Merito di questo risultato è l'innata capacità delle GPU di eseguire un gran numero di elaborazioni parallele, richieste per la generazione delle scene 3D. Sfruttando un'analogia, una CPU opera come un aereo da combattimento, estremamente veloce ma in grado di trasportare solo due persone contemporaneamente; una GPU è invece paragonabile ad un aereo di linea, meno veloce in assoluto ma capace di trasportare molte più persone e quindi di svolgere complessivamente più lavoro.

Le GPU hanno una potenza di elaborazione massima teorica estremamente elevata, sintetizzata dai Gflops che possono processare; si tratta tuttavia di una capacità per molti versi vincolata, che può essere sfruttata solo con quelle applicazioni che richiedono l'elaborazione di un elevato numero di dati in parallelo. Per questo motivo gli ambiti di utilizzo delle GPU in elaborazioni non grafiche di calcolo generale, o più semplicemente GP-GPU, sono limitati ad alcune tipologie di elaborazione; è evidente come nel corso dei prossimi anni gli sviluppatori software, grazie all'introduzione delle OpenCL e anche alla disponibilità di GPU sempre più complesse oltre che potenti e estremamente programmabili, potranno operare ad una nuova tipologia di software dove la GPU si prenda in carico i calcoli più pesanti in modo da eseguire operazioni in minor tempo possibile.


http://www.hwupgrade.it/immagini/amd_ati_cto_2.gif



Un pò di storia

In un intervista al vice presidente esecutivo AMD Henri Richard vengono svelati alcuni dettagli sulla tecnologia AMD Fusion.
"Penso che "Fusion" sia un processo evolutivo, piuttosto che una fusione"
In poche parole AMD pensa a questo progetto come un vero e proprio processo evolutivo delle attuali CPU.

Il primo tentativo in assoluto fu la creazione di un Dual core nativo K10 senza cache L3 a 45nm SOI la quale sarebbe stato accoppiato sullo stesso package una IGP della serie RV620 (cioè la stessa degli attuali chipset AMD 785G/880G) costruita a 55nm bulk; lo stile costruttivo era lo stesso dei processori Intel core Clarkdale.
Il progetto fu accantonato per problemi logistici legati alle differenti tecnologie costruttive dei due chip principali (CPU IBM SOI e GPU TSMC bulk); così il primo progetto Fusion fu cancellalo ma AMD come eredità rilasciò sul mercato il K10 Dual core nativo con il nome di Athlon2 core Regor.

APU Llano: il futuro di AMD!

http://www.hwupgrade.it/articoli/portatili/2871/schema_apu_1.jpg

AMD passò quindi allo scenario più complesso cioè un unico componente di silicio nel quale i transistor della parte CPU sono integrati con quelli della parte GPU e viceversa con tecnologia costruttiva a 32nm SOI.

APU (Accelerated Processing Unit) Llano sarà composto da core X86 derivanti dall'architettura K10 e una GPU DX11 costruiti e prodotti entrambi a 32nm con tecnologia SOI provenienti da Globalfoundries; questa soluzione rappresenterà la prima GPU ATI costruita con la tecnologia SOI di IBM.
Ciascuno dei core x86 implementati nella APU avrà una superficie complessive molto contenuta, pari a 9,69 millimetri quadrati, per un totale di poco più di 35 milioni di transistor; da questo conteggio è esclusa la cache L2 da 1 Mbyte, indipendente per ciascuno dei core. AMD dichiara un range di consumo variabile da un minimo di 2,5 Watt sino a 25 Watt per ciascuno dei core: questo significa, con tutta probabilità, che sarà possibile vedere sul mercato versioni di APU con valori di TDP molto diversi tra loro.
Grazie a alcune precise strategie di design, la APU introduce la modalità Package C6, la quale permette di diminuire l'alimentazione sull'intera struttura compresa la GPU e modulo UVD.
L'introduzione di tale modalità permette a ogni singolo core X86 di venir spento, anche il core grafico può essere completamente spento, mentre il consumo del controller RAM per la componente grafica può essere gestito dinamicamente.
Per ottenere tutto questo AMD ha implementato una singola linea di alimentazione VDDNB condivisa tra GPU, UVD, controller memoria grafico e northbridge; con questa è possibile gestire dinamicamente sia la tensione sia la frequenza di clock, con il primo elemento che viene selezionato in funzione dello stato nel quale si trovano questi componenti.
Ulteriore ottimizzazione al consumo dell'intero sistema è implementata con la tecnologia adaptive backlight modulation; in pratica l'immagine riprodotta a schermo viene analizzata in modo da ridurre gradualmente l'intensità della backlight incrementando la luminosità dei pixel, riducendo il consumo complessivo dello schermo senza che questo porti ad una variazione percepibile da parte dell'utente della luminosità complessiva dell'immagine a video.
Per metà 2012 AMD utilizzerà l'architettura Bulldozer di seconda generazione per le future soluzioni APU denominate "Trinity"; questo avverrà, con tutta probabilità nel corso del 2012.

http://www.hwupgrade.it/articoli/portatili/2871/schema_apu_2.jpg

Piattaforma AMD "Linx"


http://www.pctunerup.com/up/results/_200911/th_20091113192852_ScreenHunter_110.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091113192852_ScreenHunter_110.jpg)

http://www.hwupgrade.it/articoli/portatili/2871/schema_apu_3.jpg

A partire dal 2011 AMD, per il mercato mainstream, presenterà la piattaforma "Linx" dove ci saranno le prime APU basate sulla tecnologia FUSION.
La APU 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 grazie anche al processo produttivo a 32nm SOI.
Llano avrà una cache L2 da 1MB per core X86, mentre la cache L3 sarà assente.
La GPU integrata nello stesso pezzo di silicio, dovrebbe avere 400/320 stream processors divisi in 6/5 SIMD engines con una capacità di calcolo massima classe; questa modello di APU avrà circa un 1 miliardo di transistor. "Gigaflops"; CPU e GPU condivideranno lo stesso controller di memoria DDR3 con una frequenza massima massima di 1866Mhz.
La nuova APU non avrà bisogno di alcun chipset o Northbridge tradizionale in quanto tale elemento sarà integrato; per quanto riguarda il Southbridge AMD presenterà la nuova serie Hudson; in particolare la versione Hudson M/D3 sarà il prima a supportare lo standard USB 3.0.


http://www.pctunerup.com/up/results/_200911/th_20091111183737_ScreenHunter_116.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111183737_ScreenHunter_116.jpg)


Lista modelli Socket FM1


☆A8-Series Socket FM1☆
32nm SOI
Quad core
Core Llano
Step B0
GPU DX11
cache L2 1MB x 4
Memoria supportata
Dual channel DDR3


・A8-3850 - HD6550D・
Frequenza di clock
2.90Ghz
Frequenza Turbo Core
Assente
Stream Processor GPU
400
Frequenza di clock GPU
600Mhz
Memorie Supportate
Dual channel DDR3-1333-1600-1866Mhz
TDP
100W

・A8-3800 - HD6550D・
Frequenza di clock
2.40Ghz
Frequenza Turbo Core
2.70Ghz
Stream Processor GPU
400
Frequenza di clock GPU
600Mhz
Memorie Supportate
Dual channel DDR3-1333-1600-1866Mhz
TDP
65W


☆A6-Series Socket FM1☆
32nm SOI
Quad core
Core Llano
Step B0
GPU DX11
cache L2 1MB x 4
Memoria supportata
Dual channel DDR3


・A6-3650 - HD6530D・
Frequenza di clock
2.60Ghz
Frequenza Turbo Core
Assente
Stream Processor GPU
320
Frequenza di clock GPU
443Mhz
Memorie Supportate
Dual channel DDR3-1333-1600-1866Mhz
TDP
100W

・A6-3600 - HD6530D・
Frequenza di clock
2.10Ghz
Frequenza Turbo Core
2.40Ghz
Stream Processor GPU
320
Frequenza di clock GPU
443Mhz
Memorie Supportate
Dual channel DDR3-1333-1600-1866Mhz
TDP
65W




Piattaforma AMD "Sabine"


http://www.pctunerup.com/up/results/_200911/th_20091113193241_ScreenHunter_113.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091113193241_ScreenHunter_113.jpg)


Per il mercato Mobile AMD presenterà la piattaforma "Sabine".
La APU "Llano" in versione mobile sarà presumibilmente uguale alla versione Desktop, quindi con 4 core X86-x64 AMD K10 con L2 da 1MB senza cache L3; la GPU dovrebbe avere circa 400/480 stream processors con una capacità di calcolo massima classe "Gigaflops"; CPU e GPU condivideranno lo stesso controller di memoria DDR3.
Anche in questo caso la APU non avrà bisogno di alcun chipset o Northbridge tradizionale in quanto tale elemento sarà integrato; per quanto riguarda il Southbridge AMD presenterà la nuova serie SB900 la quale la versione Hudson M/D3 sarà il prima a supportare lo standard USB 3.0.



☆A8-Series Socket FS1☆
32nm SOI
Quad core
Core ???
GPU DX11
Step ??
cache L2 1MB x 4
Memoria supportata
Dual channel DDR3/DDR3L


・A8-3530MX - HD6620G・
Frequenza di clock
1.90Ghz
Frequenza Turbo Core
2.60Ghz
Stream Processor GPU
400
Frequenza di clock GPU
444Mhz
Memorie Supportate
Dual channel DDR3-1333-1600Mhz/DDR3L-800-1066-1333Mhz
TDP
45W

・A8-3510MX - HD6620G・
Frequenza di clock
1.80Ghz
Frequenza Turbo Core 2.0
2.50Ghz
Stream Processor GPU
400
Frequenza di clock GPU
444Mhz
Memorie Supportate
Dual channel DDR3-1333-1600Mhz/DDR3L-800-1066-1333Mhz
TDP
45W

・A8-3500MX - HD6620G・
Frequenza di clock
1.50Ghz
Frequenza Turbo Core
2.40Ghz
Stream Processor GPU
400
Frequenza di clock GPU
444Mhz
Memorie Supportate
Dual channel DDR3-1066Mhz-1333Mhz/DDR3L-800-1066-1333Mhz
TDP
35W


☆A6-Series Socket FS1☆
32nm SOI
Quad core
Core ???
GPU DX11
Step B?
cache L2 1MB x 4
Memoria supportata
Dual channel DDR3/DDR3L

・A6-3410MX - HD6520G・
Frequenza di clock
1.60Ghz
Frequenza Turbo Core
2.30Ghz
Stream Processor GPU
320
Frequenza di clock GPU
400Mhz
Memorie Supportate
Dual channel DDR3-1333-1600Mhz/DDR3L-800-1066-1333Mhz
TDP
45W

・A6-3400MX - HD6520G・
Frequenza di clock
1.40Ghz
Frequenza Turbo Core
2.30Ghz
Stream Processor GPU
320
Frequenza di clock GPU
400Mhz
Memorie Supportate
Dual channel DDR3-1066-1333Mhz/DDR3L-800-1066-1333Mhz
TDP
35W


☆A4-Series Socket FS1☆
32nm SOI
Dual core
Core ???
GPU DX11
Step B?
cache L2 1MB x 2
Memoria supportata
Dual channel DDR3/DDR3L

・A4-3310MX - HD6480G・
Frequenza di clock
2.10Ghz
Frequenza Turbo Core
2.50Ghz
Stream Processor GPU
240
Frequenza di clock GPU
444Mhz
Memorie Supportate
Dual channel DDR3-1066Mhz-1333Mhz/DDR3L-800-1066-1333Mhz
TDP
45W

・A4-3300M - HD6480G・
Frequenza di clock
1.90Ghz
Frequenza Turbo Core
2.50Ghz
Stream Processor GPU
240
Frequenza di clock GPU
444Mhz
Memorie Supportate
Dual channel DDR3-1066Mhz-1333-1600Mhz/DDR3L-800-1066-1333Mhz
TDP
35W


☆E2-Series Socket FS1☆
32nm SOI
Dual core
Core ???
GPU DX11
Step B?
cache L2 1MB x 2
Memoria supportata
Dual channel DDR3/DDR3L

・E2-3000M - HD6380G・
Frequenza di clock
1.80Ghz
Frequenza Turbo Core
2.40Ghz
Stream Processor GPU
160
Frequenza di clock GPU
400Mhz
Memorie Supportate
Dual channel DDR3-1066Mhz-1333Mhz/DDR3L-800-1066-1333Mhz
TDP
35W




Architettura "Bobcat"



http://www.hwupgrade.it/articoli/cpu/2522/slide_12.jpg


Abbiamo visto come AMD per Llano abbia adattato una GPU ATI costruita con tecnologia bulk alla tecnologia SOI di IBM; per quest'altra APU AMD ha studiato il processo inverso.
In pratica ha adattato dei core X86 AMD utilizzando tecnologia produttiva bulk wafer TSMC con lo scopo di creare una CPU senza la tecnologia SOI di IBM, in modo da adattare i due componenti (CPU AMD e GPU ATI) in un unica catena produttiva.
Tale soluzione verrà utilizzata per la piattaforma "Brazus", composta da un APU con core X86 derivanti da una nuova architettura denominata "Bobcat" e una GPU DX11, costruiti entrambi con silicio 40nm bulk provenienti dalla fonderia TSMC; questa nuova soluzione andrà nello stesso mercato delle CPU ATOM di Intel.

"Bobcat" è il nome dell'architettura X86 studiata per i sistemi a basso consumo, dove attualmente vede le CPU Atom come leader.
Il primo elemento distintivo dell'architettura Bobcat è la possibilità di operare con un livello di consumo inferiore a 1 Watt con alcune specifiche versioni
A differenza di Atom, Bobcat è un architettura di tipo out of order, comune alla maggior parte dei moderni processori x86, questa soluzione permette di ottenere migliori prestazioni grazie alla possibilità del processore di riorganizzare le istruzioni in modo tale che la loro esecuzione sia la più efficiente possibile in termini di prestazioni velocistiche.
L'altra faccia della medaglia è un certo dazio da pagare in termini di consumi massimi; tuttavia Bobcat dovrebbe essere l'ideale tra consumi, ridotte dimensioni e potenza elaborativa di una cpu x86 moderna.

L'architettura di Bobcat utilizza un design Dual issue, con due pipeline a 15 fasi contro le 16 fasi nell'architettura Atom.
L'ago delle prestazioni rimane a favore di Bobcat grazie al design out of order, la quale permetterà di avere livelli prestazionali, a parità di clock, ben più elevati delle soluzioni Atom su applicazioni single threaded; Bobcat supporta i set di istruzioni SSE sino alla release 3 comprese le tecnologie di virtualizzazione.
Per quanto riguarda la cache L1 sarà in due blocchi da 32KB ciascuno, rispettivamente per dati e istruzioni, del tipo associativa a 8 vie con latenza di 3 cicli di clock.
La cache L2 sarà di 512KB a 16 vie, con latenza di 17 cicli di clock.
I core X86 di Bobcat verrà utilizzato nelle prime soluzioni APU della famiglia Fusion, la GPU dovrebbe avere circa 80 stream processors cioè paragonabile più o meno alla GPU HD5450; anche in questo caso CPU e GPU condivideranno lo stesso controller di memoria DDR3.
Per economizzare al massimo i consumi AMD ha implementato le tecnologie clock gating, power gating e states di tipo low power; quest'ultimo consente di abbassare al massimo il livello di consumo in idle.
A completare le funzionalità una serie di innovazioni micro architetturali che riducono al minimo i trasferimenti di dati interni al chip, oltre a ridurre il numero di loro letture allo stretto indispensabile.

AMD non ha fornito informazioni ufficiali sul memory controller DDR3, tuttavia alcune voci parlano di un supporto massimo alle DDR3 1333Mhz a basso consumo; il controller RAM verrà condiviso tra i core X86 e GPU.
Bobcat troverà spazio nelle soluzioni APU Ontario, costruite con tecnologia produttiva a 40nm bulk prodotto da TSMC.
L'uscita di Ontario è prevista per i primi mesi del 2011.

Piattaforma "Brazos"


http://www.pctunerup.com/up/results/_200911/th_20091113193241_ScreenHunter_113.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091113193241_ScreenHunter_113.jpg)


Attesa per il 2011 la piattaforma "Brazos" sarà composto da CPU con core "Ontario" costituito dall'architettura X86 "Bobcat" in configurazione single/dual core e una GPU DX11; il valore TDP può variare tra i 9W e i 18W a secondo dei modelli.
Ci sarà anche una versione desktop a basso consumo chiamata “Zacate” la qualè riprende tutte le caratteristiche sia di TDP sia di core, GPU della piattaforma Brazos core Ontario.
Entrambi le piattaforme avranno dei nuovi Southbridge serie SB900 modello Hudson M/D1 la quale potranno gestire porte SATA3 ma NON le USB 3.0.
Il socket FT1 salta direttamente la APU alla scheda mamma quindi sarà impossibile cambiare la l'elemento in un secondo momento; tutte le APU sono vendute con la propria scheda mamma...


Modelli attualmente in commercio!

☆E-Series Socket FT1☆
40nm Bulk
Core Zacate
GPU DX11
Step ??
cache L2 512KB x 2
Memoria supportata
Single channel DDR3/DDR3L-800-1066-1333Mhz

●AMD E-350 Dual core/HD6310
Frequenza di clock
1.60GHz
Numero Stream processor GPU
80 (40+40)
Frequenza di clock GPU
500Mhz
TDP
18W

●AMD E-250 Single core/HD6310
Frequenza di clock
1.50GHz
Numero Stream processor GPU
80 (40+40)
Frequenza di clock GPU
500Mhz
TDP
18W


☆C-Series Socket FT1☆
40nm Bulk
Core Ontario
GPU DX11
cache L2 512KB x 2
Memoria supportata
Single channel DDR3/DDR3L-800-1066-1333Mhz

●AMD C-50 Dual core/HD6250
Frequenza di clock
1.00GHz
Numero Stream processor GPU
80 (40+40)
Frequenza di clock GPU
280Mhz
TDP
9W

●AMD C-30 Single core/HD6250
Frequenza di clock
1.20GHz
Numero Stream processor GPU
80 (40+40)
Frequenza di clock GPU
280Mhz
TDP
9W

[capitan_crasy]

Raccorta delle notizie del "[Thread Ufficiale] Aspettando Bulldozer e Llano".
Dal 28.08.2009 al 30.12.2010(cliccare sulla scritta) (http://www.hwupgrade.it/forum/showpost.php?p=34961638&postcount=12721)


02.01.2011
AMD Brazos anche nei tablet!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34069109&postcount=6672)

03.01.2011
AMD mobile "Comal": L'erede di Sabine nel 2012!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34077084&postcount=6690)

04.01.2011
Gigabyte GA-E350N-USB3: Piattaforma Brazos in dettaglio!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34086470&postcount=6736)

Ufficiale: AMD presenta la piattaforma Brazos!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34087087&postcount=6741)

05.01.2011
990FX: Prime (fugaci) immagini made in MSI!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34097432&postcount=6795)

Piattaforma Brazos per Gigabyte, Asus e MSI!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34097534&postcount=6796)

HWiNFO32: In arrivo nuovi socket per Trinity?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34098020&postcount=6807)

08.01.2011
Socket AM3+ a 942 pin, uno in più del socket AM3!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34124629&postcount=6957)

12.01.2011
MSI 890FXA-GD65 compatibile con le CPU Socket AM3+?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34167488&postcount=7292)

13.01.2011
GF su Llano: Tempi più brevi per la presentazione?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34175332&postcount=7429)

Zambezi più veloce del 50% sul i7 950/Phenom2 1100T?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34170846&postcount=7361)

20.01.2011
Nuovi dettagli sui chipset AMD serie 900!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34234285&postcount=8058)

21.01.2011
Hybridcrossfire Ready per Llano!
Clicca qui.. (http://www.hwupgrade.it/forum/showpost.php?p=34246725&postcount=8230)

24.01.2011
Più 50% di Bulldozer: ecco la slide di riferimento!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34268777&postcount=8312)

25.01.2011
Chipset serie 900 prima del previsto?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34276023&postcount=8402)

28.01.2011
Review MSI E-350IA: APU E-350 alla prova!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34305136&postcount=8658)

02.02.2011
Nuovi dettagli sulla tecnologia Turbo Core nelle CPU AMD Bulldozer
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34351807&postcount=8983)

04.02.2011
Versione Mobile di Llano anticipato a maggio?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34367814&postcount=9134)

11.02.2011
Addio ai brand Phenom, Athlon e Sempron per BD e Llano?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34426273&postcount=9613)

14.02.2011
In arrivo 890FX Deluxe5, la prima scheda mamma ASRock AM3+ con 890FX+SB850!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34455851&postcount=9817)

15.02.2011
ASRock 890FX Deluxe5 (Bios UEFI) Socket AM3+ in foto!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34463241&postcount=9874)

01.03.2011
16 Core Processor: Upgrade from AMD Opteron 6100 Series to Upcoming "Interlagos"!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34574111&postcount=10300)

AMD Fusion APU Llano in a Multi-Tasking Technology Demonstration!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34574162&postcount=10303)

MSI/ASrock: Schede mamme socket AM3+ in arrivo ad aprile!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34577321&postcount=10350)

Chipset 990FX con southbridge SB950 in foto!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34582471&postcount=10385)

02.03.2011
AMD presenterà Bulldozer al E3 show il 7/9 Giugno?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34584728&postcount=10397)

03.03.2011
Prime schede mamme AM3+ per Gigabyte!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34593465&postcount=10461)

04.03.2011
Llano VS i7: Secondo video!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34601979&postcount=10532)

06.03.2011
Nuove slide su Llano!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34621365&postcount=10642)

07.03.2011
Nuova roadmap 2011/2012 sulle soluzioni Mobile AMD!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34625177&postcount=10694)

08.03.2011
CPU Bulldozer a Giugno: Nuove conferme! (APU Llano Serie "A" a Luglio)
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34634418&postcount=10725)

10.03.2011
Gigabyte presenta 6 schede mamme socket AM3+!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34650106&postcount=10803)

11.03.2011
ASRock 890GM Pro3 R2.0 AM3+ in Giappone!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34660341&postcount=10862)

12.03.2011
I (presunti) loghi di Bulldozer!!!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34668609&postcount=10927)

14.03.2011
Nuovi dettagli sui modelli Bulldozer in arrivo!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34681797&postcount=11000)

Nuove notizie sui modelli Bulldozer e Llano per il mercato desktop!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34683607&postcount=11021)

16.03.2011
I modelli Llano socket FM1 per il mercato desktop!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34700353&postcount=11197)

25.03.2011
Labview: Differenze tra ASRock 890FX Deluxe5 e ASRock 890FX Deluxe4!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34777402&postcount=11678)

31.03.2011
Nvidia sblocca lo SLI sui chipset AMD serie 990FX e 990X!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34831054&postcount=11893)

04.04.2011
Variazione negli accordi di fornitura tra AMD e GlobalFoundries
Clicca qui... (http://www.businessmagazine.it/news/variazione-negli-accordi-di-fornitura-tra-amd-e-globalfoundries_36162.html)

05.04.2011
Schede madri Gigabyte con socket AM3+
Clicca qui... (http://www.hwupgrade.it/news/skmadri/schede-madri-gigabyte-con-socket-am3+_36169.html)

Soluzioni AMD Llano in consegna ai partner OEM
Clicca qui... (http://www.hwupgrade.it/news/cpu/soluzioni-amd-llano-in-consegna-ai-partner-oem_36171.html)

AMD, GlobalFoundries e gli accordi di fornitura: alcune considerazioni
Clicca qui... (http://www.businessmagazine.it/news/amd-globalfoundries-e-gli-accordi-di-fornitura-alcune-considerazioni_36189.html)

06.04.2011
CPU socket AM3+: anche MSI ne conferma la compatibilità
Clicca qui... (http://www.hwupgrade.it/news/skmadri/cpu-socket-am3+-anche-msi-ne-conferma-la-compatibilita_36200.html)

Gigabyte attacca gli hack di ASUS e MSI sul socket AM3!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34875364&postcount=12144)

Processori AMD Bulldozer: al debutto il 7 Giugno?
Clicca qui... (http://www.hwupgrade.it/news/cpu/processori-amd-bulldozer-al-debutto-il-7-giugno_36210.html)

11.04.2011
Nuove informazioni sulle soluzioni AMD Llano
Clicca qui... (http://www.hwupgrade.it/news/cpu/nuove-informazioni-sulle-soluzioni-amd-llano_36267.html)

Software Optimization Guide Per CPU Bulldozer: L'analisi di bjt2!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=34912464&postcount=12369)

14.04.2011
Processori Bulldozer su socket AM3? E' possibile
Clicca qui... (http://www.hwupgrade.it/news/cpu/processori-bulldozer-su-socket-am3-e-possibile_36313.html)

Un cambio di strategia per AMD Vision
Clicca qui... (http://www.hwupgrade.it/news/portatili/un-cambio-di-strategia-per-amd-vision_36305.html)

23.04.2011
Labview: Nuove differenze tra il socket AM3+ e il socket AM3!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35001330&postcount=12916)

Step A1 e Step B0: I primi step di Bulldozer!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35005865&postcount=12956)

27.04.2011
Llano A8-3510MX Vs i7 2600 desktop: potenza di calcolo GPU a confronto!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35024716&postcount=13050)

28.04.2011
AMD mostra il socket FM1 per Llano e una nuova roadmap!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35033196&postcount=13099)

03.05.2011
Nuovi rumors sulle date di uscita di Bulldozer e Llano!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35067366&postcount=13230)

Primi prezzi di 3 schede mamme socket AM3+ con chipset 900 di MSI!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35073313&postcount=13255)

04.05.2011
I primi bench di Bulldozer e Llano?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35076032&postcount=13273)

Prima immagine della Asus M5A99X Evo con chipset 990X!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35081249&postcount=13347)

06.05.2011
Asus: Pronte 6 nuove schede mamme socket AM3+ e chipset 900!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35087898&postcount=13394)

07.05.2011
Prima immagine di un scheda mamma socket FM1 (da laboratorio) per Llano!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35099597&postcount=13522)

09.05.2011
Le possibili combinazioni del HybridCrossfire destinato alle APU Llano!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35110803&postcount=13651)

14.05.2011
Nuove immagini del socket FM1!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35150764&postcount=14006)

Jetway HA13 con chipset 990X!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35151829&postcount=14031)

15.05.2011
Primi prezzi delle schede MSI con chipset serie 900!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35156926&postcount=14070)

19.05.2011
MSI 990FXA-GD80 in foto!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35190830&postcount=14458)

21.05.2011
Gigabyte GA-990FXA-UD7 In foto!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35206577&postcount=14787)

23.05.2011
Prime conferme sulle frequenze/TDP delle APU Llano per il mercato Mobile!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35213426&postcount=14895)

Prime foto delle soluzioni APU Llano per il mercato Mobile!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35218482&postcount=14949)

24.05.2011
Ufficiale: I primi bench delle APU Llano per il mercato Mobile!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35228474&postcount=15153)

25.05.2011
Prime Analisi del BIOS compatibile alle CPU 8 core Bulldozer by Labview!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35234929&postcount=15296)

27.05.2011
Nuove slide su Llano!
Clicca qui.. (http://www.hwupgrade.it/forum/showpost.php?p=35245977&postcount=15456)

FX-8130P già in listino nel mercato cinese???
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35246239&postcount=15462)

30.05.2011
AMD presenta i chipset serie 900!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35267229&postcount=15844)

31.05.2011
Piattaforma "Colman" e "Deccan": le APU Mobile del 2012!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35275048&postcount=16081)

01.06.2011
AMD smentisce se stessa (parte seconda): Bulldozer solo nel terzo trimestre 2011!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35278557&postcount=16184)

AMD: Bulldozer posticipato a tavolino unicamente per "favorire" le soluzioni Llano!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35282800&postcount=16338)

02.06.2011
AMD conferma il 10 core "Komodo" per il mercato desktop entro il 2012!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35290031&postcount=16519)

07.06.2011
Nuova roadmap sulle CPU Bulldozer!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35319400&postcount=16868)

AMD "Finalmente" mostra le CPU FX Bulldozer!!!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35319904&postcount=16877)

08.06.2011
Rumors AMD (da prendere con le dovute cautele)!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35328921&postcount=17133)

09.06.2011
Primi bench di Llano modello A8-3800!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35338120&postcount=17146)

13.06.2011
AMD A8-3800 Llano APU & Gigabyte GA-A75-UD4H in video più Bench!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35362764&postcount=17685)

14.06.2011
AMD presenta le APU Llano per il mercato Mobile!
Clicca qui... (http://www.hwupgrade.it/articoli/portatili/2871/amd-llano-la-nuova-piattaforma-notebook_index.html)

Addio al socket AM3+ per le soluzioni "Komodo" nel 2012!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35370012&postcount=17819)

Nuove informazioni sul Turbo Core di Bulldozer!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35373187&postcount=17894)

15.06.2011
AMD: +50% di GFLOPS per Trinity!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35377951&postcount=17980)

Preview Llano A8-3850 Desktop by AnandTech!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35378059&postcount=17981)

20.06.2011
Revision Guide for AMD Family 12h Processors: Le analisi di bjt2!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35416905&postcount=18546)

21.06.2011
Nuove informazioni su Bulldozer entro il 16 Luglio?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35421066&postcount=18591)

22.06.2011
Gigabyte presenta le prime schede mamme FM1 e conferma lo step B0 per Llano!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35427022&postcount=18630)

30.07.2001
AMD presenta la piattaforma Lynx composta da APU Llano per il mercato desktop!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35479974&postcount=19194)

Lista recensioni APU Llano Socket FM1!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35480179&postcount=19201)

09.07.2011
Donanimhaber: Primi bench di un ES Bulldozer step B1, anzi NO!!!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35538362&postcount=19538)

21.07.2011
Operation Scorpius – The Legend of FX Returns!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35613060&postcount=20184)

24.07.2011
Prime conferme sulla data d'uscita e frequenze dei modelli Bulldozer Desktop!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35626499&postcount=20260)

25.07.2011
Socket FM2 per Komodo e Trinity!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35632513&postcount=20328)

27.07.2011
CPU Bulldozer posticipate (ancora) al quarto trimestre 2011?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35645024&postcount=20433)

02.08.2011
AMD punta (a sorpresa) sui 28nm nel 2013 per il mercato Server!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35680923&postcount=20682)

10.08.2011
Ufficiale: Gli opteron Bulldozer definitivi sono basati sugli step B2!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35726014&postcount=20960)

16.08.2011
Primi codici OPN per i modelli FX-8150/FX-8120!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35747736&postcount=21057)

31.08.2011
http://www.xtremeshack.com/immagine/i107367_20100311183258-esclusivabd00.gif
Gigabyte: Rilasciati i BIOS e le caratteristiche per le CPU FX!!!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35836638&postcount=21637)

01.09.2011
Labview: Ecco i codici OPN delle CPU Bulldozer rilasciati da ASrock!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35839808&postcount=21668)

21.09.2011
Donanimhaber: CPU AMD FX il 12 ottobre!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35973872&postcount=23803)

24.11.2011
Donanimhaber: Slide finali delle CPU FX!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35996005&postcount=24025)

26.09.2011
GlobalFoundries: Cancellati i 22nm, 20nm per il 2014!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=36011519&postcount=24379)

02.10.2011
Entro domani i BIOS definitivi per le CPU FX?
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=36056384&postcount=25081)

03.10.2011
Donanimhaber: Piledriver anche su socket AM3+!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=36058841&postcount=25164)

[capitan_crasy]

Aggiornamento 28.08.2010

Il caro Dresdenboy si prende una settimana di "riposo", ma prima ci lascia un post sul suo blog MOOOOOOLTO interessante:

http://citavia.blog.de/2010/08/27/a-quick-round-of-links-9265110/

La cosa più interessante è la seguente:

Thuban e company hanno una pipeline di 22 FO4 (non 24, sorry). Mentre Bulldozer ha una pipeline di 17 FO4. Quindi una pipeline del 30% più veloce. Questo vuol dire che a parità di processo (quindi anche se buldozer fosse fatto con il 45nm low-k liscio di adesso), potrebbe andare fino al 30% più veloce in clock. Considerando il nuovo processo, questo significa frequenze MOLTO alte. Ricordo che il FO4 del Pentium 4 è stimato in 16. Quindi possiamo aspettarci anche frequenze dell'ordine del 5GHz (almeno in turbo mode)...

Facciamo 2 conti per un ipotetico bulldozer X6. Un X6 Phenom II attuale va a 3.2GHz. +30% per la pipeline più lunga, +40% per il processo più parco, sono 5.8 GHz. Ora non credo che arriveremo a tanto perchè penso che AMD faccia i transistors più piccoli (e quindi più lenti) per occupare meno area e comunque con una pipeline del 30% più veloce non si va il 30% più su di clock perchè i tempi di ritardo tra i vari stadi non migliorano e quindi una pipeline così corta garantisce un 15, massimo 20% in più. Questo per dire che un clock stock di oltre 4GHz come X6 e forse anche come X8 lo si può sperare...


Il FO4 è una misura della complessità dello stadio della pipeline. Fissata la pipeline, la complessità è data. Poi si può implementarla a 130, 90, 65, 45, 32nm ecc... A seconda del processo, sarà maggiore la frequenza a cui potrà andare... Non esiste un limite intrinseco al clock dato un processo, o meglio, esiste un limite intrinseco dato un FO4 di una architettura. La combinazione di FO4 e processo da la velocità.

Per esempio. Il Power 7 ha un FO4 di 17 (mi pare) ed è stato implementato con il 45nm, mi pare con il Low-k. Ora quel processore ha una caterva di transisors. Il quadcore arriva a 4.14 GHz e l'octacore a 3.96 Ghz... Un ipotetico bulldozer X4 fatto a 45nm (il processo del Thuban) sarebbe arrivato a 4.2-4.3 stock, minimo, sia perchè il Power 7 ha molti più transistors e molte più unità attive (un quad core ha 16 thread, e ogni core ha mi pare 12 unità di esecuzione), sia perchè il Power 7 è una CPU server e tradizionalmente queste hanno qualche centinaia di MHz in meno delle controparti desktop...

EDIT: in ogni caso, nel caso peggiore, un buldozer X4 a 4.1 Ghz e un Bulldozer X8 a 3.9 Ghz è fattibile visto il Power 7, anche con questo 45nm Low-k. Ricordiamo che IBM usa lo stesso processo di GF/AMD...

EDIT: Su wikipedia dice che esiste una versione quadcore da 4.25 Ghz. Il Power6 che aveva un FO4 di 13 arrivava a 5GHz e IBM aveva in laboratorio un prototipo funzionante a 6GHz...

EDIT: sto leggendo su google gruppi che tra Thuban e Buldozer, c'è un progetto cancellato che aveva un FO4 di 13... Sarebbe arrivato a 5GHz con il 45nm! Dice anche che BD dovrebbe avere un IPC (A PARITA' DI FREQUENZA) del 20-25% in più. Il tizio sembra essere un ex dipendente AMD che ha lavorato al progetto... Il gruppo in guestione è http://groups.google.de/group/comp.arch/browse_thread/thread/45018bf3214f6049?hl=de# e il tipo si chiama Mitch_qualcosa...

Aggiornamento 28.08.2010

@Bjt2.

Domanda da nubbio. :)

La lunghezza delle pipeline è una costante o comunque dipendente dal silicio?
Tipo... procio X, pipeline 10 su 90nm, max 5GHz, se il silicio arriva a quella frequenza bene, altrimenti amen. Stesso procio, pipeline 10, ma silicio 45nm, l'architettura avrebbe lo stesso limite di 5GHz anche se il silicio potesse dare 6GHz? Oppure la pipeline risente comunque di latenze inferiori per la riduzione del silicio e quindi permettere di più?

Perché il PIV era fatto a 90nm o 120nm? Se Buldozer ha una pipeline simile ma 32nm è equiparabile o promette più velocità?

In un circuito digitale sincrono (con clock), il critical path è il percorso del circuito che provoca maggiori ritardi e di conseguenza limita la frequenza.
Solitamente c'è un registro sorgente, un circuito che elabora il contenuto del registro ed infine il registro di destinazione. Il circuito per poter funzionare ad una data frequenza deve essere in grado di presentare i risultati in modo stabile all'ingresso del registro qualche istante prima del nuovo fronte di clock (esattamente Tsetup + Thold dei flip-flop che compongono i registri).
Chiamando Tcp il tempo massimo di attraversamento del circuito, o meglio il T di attraversamento del critical path, abbiamo che:

Tsetup + Thold + Tcp < T

dove T è il periodo di clock, cioè 1 / F (F è la frequenza di clock).

Semplificando...la pipeline non è altro che una suddivisione in stadi (stage) dell'esecuzione di una istruzione. Ogni stadio esegue una piccola parte dell'istruzione fra un registro sorgente ed un registro di destinazione. Lo stage successivo, al clock successivo, prende il risultato e mette a sua volta il suo risultato in un altro registro entro la fine del ciclo di clock.
Di fatto nella pipeline abbiamo in esecuzione un massimo di una istruzione per stage della pipeline (le cose possono anche andare diversamente in caso di duplicazione delle unità di esecuzione, ma come dicevo: semplifichiamo).
Con la pipeline a regime abbiamo comunque la terminazione di una istruzione per ciclo di clock. Con la pipeline vuota dobbiamo attendere un numero di clicli di clock pari alla lunghezza della pipeline prima che l'esecuzione di una istruzione sia terminata.
Quindi possiamo applicare il discorso fatto prima: il critical path di una CPU è il critical path con ritardo più alto fra i critical path di ogni stage. Questo critical path servirà a determinare la frequenza massima raggiungibile dalla CPU con una determinata tecnologia litografica (potenza permettendo).

Aumentare il numero di stadi ha però delle contro-indicazioni: se la pipeline va in stallo (cioè deve essere svuotata) in caso di misprediction (fallimento della branch prediction, l'algoritmo che "prevede" dove andrà a finire un salto condizionale e quindi riempirà di conseguenza la pipeline) o per il cambio di contesto, prima di terminare una nuova istruzione passeranno ben 31 cicli di clock. E' chiaro che per ovviare a questi overhead bisogna avere un ottimo algoritmo di branch prediction e bisogna avere la possibilità di raggiungere frequenze nettamente maggiori dei concorrenti.

Il Prescott aveva una pipeline di 31 stadi per gli interi. Una cosa praticamente mai vista (normalmente sono intorno ai 10-12 stadi per gli interi, tranne le prime implementazioni). Aveva però gravi problemi di leakage (è uno degli elementi che vanno a determinare la potenza necessaria a far funzionare la CPU) che non gli permettevano di raggiungere le frequenze che gli ingegneri avrebbero voluto fargli raggiungere (pensate che Intel avrebbe voluto raggiungere gli 8-10 Ghz entro due generazioni litografiche). Questa fu la motivazione per cui il progetto Tejas, il successore di Prescott, non arrivò nemmeno sul mercato.

Aggiornamento 28/09/2010

Sandy Bridge Vs Bulldozer:
il confronto di bjt2


Allora... Per smorzare un po' i toni e per chiarire una volta per tutte parliamo del confronto Sandy bridge core vs Bulldozer module.

2 thread vs 2 thread. Poi vediamo un confronto alla buona 1 thread vs 1 thread considerando metà delle risorse condivise.

Decodifica istruzioni:
Un core SB può decodificare al massimo 3 istruzioni semplici e una complessa oppure una sola microcodificata alla velocità di 3 uop per ciclo, questo per ciclo di clock e per un dato thread, mentre un core BD può decodificare un qualsiasi mix di istruzioni semplici o moderatamente complesse (2 mops) purchè non si superi le 4 mops per ciclo, oppure una microcodificata alla velocità di 4 mop per ciclo, tutto questo per ciclo e per thread. Anche ammettendo che le uop intel siano equipotenti alle mops AMD, qui c'è un chiaro vantaggio AMD (ancora maggiore se si pensa che le MOP amd ammettono fino a 3 ingressi e una uscita, vedi FMAC, mentre quelle INTEL max 2 ingressi e una uscita, da cui le FMA3). Se il mix di istruzioni non è del tipo complessa+3 semplici, il decoder INTEL perde MOLTISSIMO in prestazioni. Per fortuna che un compilatore decentemente inteligente riordina le istruzioni quando possibile, ma il rischio ovviamente c'è... Però per compensare, SB usa una cache delle microoperazioni che può sparare fino a 18 uop/ciclo... Non si sa se anche BD la usa. E i branch prediction sono stati migliorati sia in SB che BD e non si sa quale sia meglio. L'approccio del BD con le code degli IP predetti è però interessante...

Dispatch:
Qui dovrebbe avvenire il micro/macro op fusion. Entrambe le architetture possono fare il dispatch di 4 uops/mops. L'architettura INTEL può fare una uop fusion per ciclo, arrivando a 5. Anche BD può fare la uop fusion, ma non si sa se una o più di una e in che casi. Comunque considerando le MOP e le uop equivalenti in potenza (anche se non è vero), siamo in situazione di parità.

ROB:
Qui INTEL ha un enorme ROB che deve dare spazio a due thread (160 uop). AMD ha 2 ROB (da 128 mops l'uno) per il fatto che i due cores sono fisicamente separati. Qui giacciono le istruzioni in attesa di esecuzione o di ritiro.

Scheduler:
Qui le differenze si fanno interessanti. AMD separa INT e FP. Ha 2x40 mops intere/memoria più 60 mops FP, condivise tra i due thread. INTEL ha un unico calderone di soli 54 elementi condivisi tra interi, memoria FP e per di più di entrambi i thread. E' inutile dire chi ha le potenzialità maggiori...

Esecuzione:
INTEL ha 6 porte dove sparare le micro ops. Quindi può sparare 6 uop per ogni ciclo di clock, condiviso tra due thread. 3 porte sono dedicate alla memoria: 2 per le 2 AGU e una per gli store. 3 porte sono per le operazioni. Badate bene: le 3 porte residue sono CONDIVISE tra operazioni INT e SIMD/FP di ENTRAMBI i thread. Ossia in ogni ciclo si possono al massimo fare 3 operazioni tra INT e FP/SIMD.
AMD può, per ogni ciclo di clock e per 2 thread, sparare: 4 istruzioni FP (di entrambi i thread), 4 AGU/memoria (2 per thread max) e 4 ALU/intere (2 per thread MAX).
Considerando che anche un codice fortemente FP comunque contiene istruzioni per i loop, salti, confronti, insomma contiene istruzioni INTERE che su INTEL si contendono le 3 porte (per di più i thread sono 2!) mentre su AMD corrono su binari separati. Solo le istruzioni per la memoria hanno binari separati. Ma questo anche in AMD. Ecco che il potenziale AMD è maggiore.

Memoria:
Su SB si possono fare 2 letture a 128 bit e una scrittura a 128 bit per ciclo. Poichè però la cache L1 ha solo 2 porte, questo può essere fatto per breve tempo. E comunque queste 3 operazioni devono essere condivise tra i due threads.
Su BD, invece, ogni thread ha la sua cache L1, le sue 2 porte, le sue due letture a 128 bit e scrittura a 128 bit, le sue code di lettura e scrittura e le sue AGU. Inutile dire chi vince in questo caso.
E' vero che SB può fare fino a 3 operazioni FP a 256 bit per ciclo (1 add, 1 mul e una shuffle), ma può farlo per molto? No.

Retirement:
Qui siamo 4 a 4, ma sempre presupponendo che le mops AMD non siano più potenti di quelle INTEL.

Frequenza operativa:
A giudicare dalle latenze delle caches, sembrerebbe che BD possa avere un clock nettamente superiore a SB. Poichè la banda memoria è maggiore, anche a parità di clock, i due thread dovrebbero scorrere più fluidamente su un BD, considerando che la velocità di ritiro è la stessa e supponendo che le unità prima dello stadio di ritiro siano veloci a sufficienza (più probabile per BD che per SB alla luce di quanto visto). Se poi consideriamo che il clock sarà probabilmente maggiore...

Confronto alla buona 1 thread vs 1 thread considerando metà delle risorse condivise. In realtà in INTEL alcune risorse sono condivise dinamicamente.

Decodifica istruzioni:
Qui valgono le stesse considerazioni del 2 vs 2 considerando che la decodifica è probabilmente fatta a cilci alterni.

Dispatch:
Qui valgono le stesse considerazioni del 2 vs 2 considerando che il dispatch è probabilmente fatto a cilci alterni.

ROB:
Qui INTEL ha un enorme ROB condiviso, quindi un thread ha da 0 a 160 uop di spazio. AMD ha ROB separati da 128 mops l'uno. A secinda del carico INTEL può essere svantaggiato o meno. In un caso medio siamo 80 vs 128.

Scheduler:
AMD ha 40 mops int + 0-60 mops FP. In media 40+30.
INTEL ha 0-54 uops condivise. In media 27 totali.
La differenza è alta anche nel caso peggiore.

Esecuzione:
INTEL ha 0-6 porte disponibili per un thread. In media 3.
AMD ha 2 ALU + 2 AGU/MEM + 0-4 FP. In media 2+2+2.
La differenza è alta anche nel caso peggiore.

Memoria:
INTEL da 0 a 3 operazioni memoria. In media 1.5.
AMD 3 operazioni memoria.
Inutile dire chi vince in questo caso.

Retirement:
Qui siamo 4 a 4, ma sempre presupponendo che le mops AMD non siano più potenti di quelle INTEL.

Frequenza operativa:
Entrambi qui hanno il turbo. Il leackage in AMD è di partenza più basso. Poi lo spegnimento dei core con gli NFET è più efficiente. Prevedo che per AMD la frequenza turbo core sia ancora più elevata...




Conclusioni:
In sostanza a parità di thread Bulldozer dovrebbe surclassare SB. A parità di cores (come li intendono INTEL e AMD) non è detto che AMD la spunti. Ma comunque c'è addirittura questa possibilità...

Aggiornamento 27.12.2010

http://support.amd.com/us/Processor_TechDocs/40546.pdf

Manuale di programmazione AMD aggiornato. Menziona la famiglia 10h e 12h. Questo 12h dovrebbe essere Llano. Sono arrivato a metà e finalmente sono incappato in differenze di prestazioni: il fantomatico processore famiglia 12h (mai nominato il nome commerciale fino alla metà che ho letto) ha la divisione intera nettamente più veloce, fino al doppio, probabilmente paragonabile a quella INTEL (non ricordo le latenze a memoria)... E' molto probabile che questo 12h sia Llano... Proseguo la lettura e vi faccio sapere se ci sono altre differenze... (la parte più ghiotta è alla fine dove parla delle latenze delle istruzioni)

E' molto probabile che il 12h sia Llano, perchè dice che non ha cache L3, ha l'ICU allargato (28x3=84 mops, sia intere che float) e lo scheduler intero che passa da 24x3 a 30x3. In più l'integer divide è un circuito in più attaccato alla terza ALU. Evidentemente nelle CPU precedenti la DIV era microcodificata, quindi vector path, per cui non c'era una vera e propria unità per la divisione. Questo consente sicuramente velocizzazioni elevate di codice intero con molte divisioni... Continuo la lettura...

EDIT: ora la FPU ha 14x3 mops nel reorder buffer. Se non ricordo male era 12x3 nel 10h...

EDIT2: il 10h ha controller RAM DDR2 e DDR3, il 12h è espressamente DDR3 only... Il 12h non supporta ECC e non supporta DIMM con chip da 4 bit... L'ECC sopratutto esclude una CPU server... Il 12h supporta solo la modalità unganged, inoltre supporta le interfacce "Onion" e "Garlic" (letteralmente cipolla e aglio)... Ho scorso velocemente quella parte... Ci ritorno dopo per cercare di capire cos'è, ma probabilmente è l'interfaccia con la GPU integrata... Il 12h supporta 8 streams di prefetching (mi pare che il 10 ne supporti 5, o 3, non ricordo)... Quindi controller migliorato...

EDIT3: il 12h non ha il controller hypertransport... Ciò implica che avrà qualche altra cosa, probabilmente PCIExpress...

EDIT FINALE: per le latenze delle istruzioni, a parte quelle sulla divisione intera, le differenze sono minime. Per poche istruzioni (di cui la maggior parte sono istruzioni di sistema) è riportato solo il valore per la CPU 12h. Non è dato sapere se migliora o peggiora, ma suppongo sia diverso da quello del 10h. Se qualcuno avesse la versione vecchia, si potrebe confrontarli... Comunque modifiche di poco conto...


In sostanza la CPU 12h ha scheduler migliorati, divisione intera migliorata, prefetcher migliorati e qualche cosa piallata, come le memorie DDR2, l'ECC, il controller ganged (che non serve a molto con 4 core + GPU), l'hypertransport...


Aggiornamento 11/04/2011

Allora... Menziono le cose più importanti mano a mano che leggo...


- E' confermato che internamente BD usa ancora macro-op (operazione intera oppure FP + operazione memoria). Ciò è importante per stabilire quanto riesce a macinare...

- E' confermato che esistono ancora operazioni single, double e vector (anche se i nomi sono cambiati: FastPath Single, FastPath Double e Microcode). Ciò è importante per stabilire la potenza del decoder.

- Parla delle istruzioni supportate: AVX, XOP, FMA(C) ecc... Tutto confermato. Più qualche cosa poco nota come istruzioni per l'estrazione della parte frazionaria di un numero FP e istruzioni vettoriali di rotazione, shift, shuffle.

- Menziona le nuove unità FP a 128 bit e dice che le prestazioni possono essere fino al doppio. Non mi è chiaro questo punto. Anche le unità del K10 sono a 128 bit. Ma poi spiega l'uso del FMAC che non è automatico e dice che l'FMA è più preciso di una ADD+MUL (si sapeva già). Forse è a questo che si riferisce quando parla di prestazioni doppie.

- Ora BD non soffre più in prestazioni se le istruzioni sia di load/store, sia load/execute lavorano su dati non allineati. Possibili benefici con codice con dati non allineati. Questo potrebbe essere un refuso del documento del K10. Mi pare di ricordare che era una delle novità del passaggio da K8 a K10...

- Novità del fetching istruzioni. Non più una finestra di 32 bytes, ma DUE finestre di 32 bytes da cui possono essere prodotte fino a 4 mops/ciclo. Si accenna al fatto che queste due finestre assieme alla FPU a 128 bit consentono di avere un ritmo di fetch/execute/retire di 4 mops/ciclo... Ora come ora è molto nebulosa la cosa. Non menziona mai il fatto che è condivisa tra due thread...

- Accenno al fatto che molte istruzioni sono state promosse da vector a double o a single, che sono migliorate le latenze e che molte istruzioni FPU sono state spostate di pipe... ATTENZIONE! Fino ad ora avevamo supposto che l'architettura a FO4 17 avrebbe comportato l'aumento delle latenze delle istruzioni... Secondo quanto scritto qui E' IL CONTRARIO! :D Potrebbe anche questo essere un refuso della modifica del documento del K10.

- Miglioramento in velocità delle istruzioni di shuffle, di trasferimento registri FP-interi (nonostante la FP condivisa!), di trasferimento FP-FP (quello a cui accennava JF-AMD degli zero latency move), delle operazioni su stringhe (i vari REP, SCAS ecc), delle operazioni stack e del paging a 1GB.

- Le operazioni di shuffle (tallone di achille) possono essere fatte al quadruplo della velocità grazie a più unità, al fatto che sono a 128 bit (???) e ora le istruzioni sono Direct Path e non vector path (mi sa che è un refuso del vecchio documento perchè parla delle pipeline FADD, FMUL e FSTORE... anche per le operazioni di move reg-reg)

- poi parla delle TLB e della virtualizzazione.

--- FINE SEZIONE INTRODUTTIVA ---

- Confermate le cose che si sapevano sull'architettura (caches ecc). Predizione e fetch sono disaccoppiati, decoding a 4 vie (limite teorico). Scheduling dinamico. 2 istruzioni ALU + 2 AGU per ciclo (confermato). 2 128 BIT FPU. Supporto AVX, XOP ecc. Superforwarding (probabilmente quella cosa del poter usare subito i risultati di una operazione).

- Descrive il fatto delle 4 microop/ciclo. Dice che può fare il fetch di 32 bytes per ciclo e che puo fare la scansione di due blocchi da 16 bytes per ciclo (su due finestre di 32 bytes). Può decodificare fino a 4 mops/ciclo. E' un limite teorico che dipende dalle istruzioni presenti nelle finestre di 16 bytes e anche dalla modalità in cui si trova la CPU: FAST o SLOW (???)

- Schema a blocchi della CPU: nulla da notare se non che non divide le ALU/AGU ma le chiama genericamente pipeline e anche qui la FPU è indicata con solo le due pipeline a 128 bit...

- Caches: L1 istruzioni UNICA da 64 KB, a 2 vie con linea da 64 bytes e lettura di 32 bytes (come quella del K10). Quando è letta una nuova cache line è automaticamente fatto il prefetch di quella successiva. Il predecoing è fatto subito dopo il load. La L1 dati è da 16 KB. Può fare 2 load a 128 bit per ciclo. Ha 16 banchi e un solo load per banco. Quindi i due load sono simultanei se sono in banchi separati. Latenza di 4 cicli (! data l'alta latenza, prevedo clock stratosferici). Menziona genericamente il prefetching. La cache L1 è write through e non write back come il K10... Hanno imparato da INTEL... Ci sono vantaggi nello snooping. Solo la cache L2 va testata... Quest'ultima appunto è inclusiva e condivisa tra i due core. Menziona il write trough e finalmente conferma che le caches sono due. La latenza è 18-20 cicli e la cache è full speed (quindi con il clock alto... :D). Il perchè è presto detto: la dimensione è dipendente dall'implementazione! Ci possono essere modelli con più o meno L2 per core (magari parzialmente disattivata per difetti...). La cache L3 può essere massimo 8MB con 4 blocchi di massimo 2MB (anche qui il binning per difettosità...). La cache L3 è non inclusiva e victim buffer. Ci vanno i dati buttiati dalle L2. Un dato rimane nella L3 se è usato da più cores (un predittore?). Altrimenti va nella L1 del core che la usa. La L3 è dichiarata migliorata come banda. Latenza non specificata.

- Branch prediction: penalità da 15 a 20 cicli in caso di miss. In caso di hit, un solo ciclo se è nella cache L1, 4 cicli se è nella L2. La L1 è 4x128 entry e la L2 5x1024 entry. 512 entry per gli indiretti e 24 per il return stack. Il branch prediction è abbastanza complesso ma credo che sia simile a quello del K10...

- Fetch e decode. Sono letti 32 bytes/ciclo. Le finestre sono di 16 bytes e esistono due code (una per thread). Si possono decodificare fino a 4 istruzioni per ciclo contenute in 2 finestre a 16 bytes.

- TLB: L1 istruzioni 48 4KB, 24 2MB o 1GB. Entry da 4MB occupano due entry da 2MB. L1 dati 32 (64 per i modelli 20H-2FH) per 4KB, 2MB e 1GB. Entry da 4MB occupano due entry da 2MB. L2 istruzioni 512 4KB. L2 dati 1024 condiviso tra 4KB, 2MB e 1GB. Entry da 4MB occupano 2 slot.

- Esecuzione intera: c'è lo scheduler e le unità di esecuzione. Lo scheduler è completamente data-driven. Non ci sono più le lane del K10. Ossia è più inteligente: l'unico limite è la disponibilità dei dati e delle unità. Inoltre tiene traccia del completamento e delle eccezioni delle istruzioni FP: è questa unità che decide il da farsi. L'unità FP fa solo il "lavoro sporco"... Lo scheduler intero può ricevere e schedulare fino a 4 mops/ciclo. Fa il register renaming e sveglia le istruzioni in attesa. Le unità di esecuzione sono 4. ATTENZIONE: 2 ALU e 2 AGLU. Le due ALU sono chiamate Ex0 e Ex1. Possono fare tutte le operazioni aritmetiche, logiche e di shift. La Ex0 fa anche DIV e POPCNT. La EX1 fa anche MUL e BRANCH. Le AGLU possono fare le AGU e operazioni ALU SEMPLICI. NOVITA' rispetto al K10: le mops sono divise nello scheduler in microops. Possono essere eseguite indipendentemente e fuori ordine (non più le lanes... :D) quando dati e unità esecutiva sono libere, in particolare in contemporanea in ALU e AGLU separate. Lo scheduler può ricevere 4 MOPS/ciclo (quindi potenzialmente 4 istruzioni intere più 4 memoria). Questo è un dispatch group. Il divisore di EX0 non è pipelined ed è a latenza variabile. Il moltiplicatore in EX1 è pipelined. L'AGLU contiene una ALU semplice per fare istruzioni aritmentico logiche semplici... Guardando le tabelle delle latenze sembra che le AGLU siano sfruttate in poche istruzioni, giusto per non usare le EX unit. LZCNT e POPCNT sono gestite in EX0.

- FPU. E' dichiarato che la FPU ha 4 volte la potenza di picco di quella del K10. 4 pipeline. 2 FMAC a 128 bit. Una può fare anche le IMAC (multiply - accumulate su dati interi) e le conversioni tra int e fp e una ha un crossbar per gli shuffle SIMD. 2 unità SIMD intere per MMX e SIMD intere. Una delle due ha la pipeline FSTORE. C'è poi una unità di load/store che può fare 2 letture a 128 bit + una scrittura a 128 bit. La CPU può ricevere fino a 4 mops/ciclo, ma da un solo thread alla volta. Il thread può cambiare a ogni ciclo. La FPU può eseguire 4 mops/ciclo. Una volta ricevute in cicli separati, poi possono essere eseguite anche inframezzate nello stesso ciclo, al ritmo di 4/ciclo. Nella FPU possono essere accettati fino a 2 loads per ciclo, anche da 2 thread separati. 4 pipeline, 2 FP e 2 INT. 2 128 bit FMAC. Ognuno può fare anche ADD e MUL anche x87. Ogni FMAC ha anche un divisore e calcolo radice quadrata a latenza variabile. Una istruzione a 256 bit può essere eseguita in un ciclo. Se non ci sono due unità libere è spezzata in due senza penalità. Cioè in pratica una istruzione a 256 bit è spezzata in due subistruzioni a 128 bit che possono essere eseguite indipendentemente (e anche in due cicli separati) senza bloccare le altre. Massima flessibilità, dunque.

- Unità di load/store. Una per core, due per modulo. Ogni unità supporta 2 letture a 128 bit e una scrittura a 128 bit per ciclo. La coda di scrittura è di 24 entry. La coda di lettura ha 40 entry. Due pipeline per ogni unità LS per fare 2 operazioni in contemporanea. Menziona il fuori ordine per le operazioni memoria ma non entra nei dettagli. Il write combining supporta 4 stream, con 4 buffer da 64 bytes (condivisi tra i due cores). C'è una cache di 4KB prima della L2 (64 blocchi da 64 bytes) per gestire il write combining da sorgenti varie (compreso il write chaining per la trasmissione su bus HT).

- Controller RAM. Supporta DIMM da 4, 8 e 16 bit, interleaving, ECC, e canali a 64 bit indipendenti. Ha algoritmi di scheduling e predizione ottimizzati in particolare per sequenze alternate di read e write. Il prefetcher tiene i dati nel controller e non li spedisce alle caches. Può adattarsi a pattern ascendenti e discendenti e altri più complicati. Le specifiche del MC possono cambiare da modello a modello.

- HT: supporto a 25.6GB/s (quindi 3.2 GHz) e varie features dell'HT 3. HT assist per sistemi a 4 o più socket: ancora con consumo di 1-2 MB di L3.

- Branch fusion. Non è specificato un limite al numero massimo di branch fusion però molto probabilmente al massimo uno. Perchè i limiti sono che il compare e il branch devono essere adiacenti, che il compare non deve essere la quarta istruzione del dispatch group, che il branch deve avere indirizzamento rip-relativo, che il compare non deve avere dati immediati o indirizzamento SIB.

- LATENZE istruzioni. Purtroppo è difficile confrontare le latenze senza avere a fianco quelle del K10. Ci dobbiamo fidare dei proclami dell'inizio del PDF. Molte istruzioni hanno un N/A, non so se per NDA oppure perchè effettivamente al tempo di stesura del PDF non erano note. Però lo scheduler data-driven, le uops che possono andare indipendentemente, le pipeline intere e FP separate possono addirittura far sperare in un IPC superiore al SB!

Questo è quanto...

Aggiornamento 21.06.2011
Revision Guide for AMD Family 12h Processors: Le analisi di bjt2!

Dunque. Leggendo il documento si nota subito che parla solo dei Llano mobile (forse quando usciranno quelli desktop aggiorneranno il documento). C'è un solo step ed è contrassegnato come B0. Ipotizzo che sia questo quindi lo step in vendita. C'è la solita filippica sugli errata fix e gli errata che devono essere visibili al SO e non ci sono errata gravi che richiedono dei fix. Tutti gli errata elencati successivamente hanno un "no fix planned", quindi non sono gravi... Suggested workaround è "nessuno", tranne dove indicato espressamente.

57: errore lieve che consiste nel riportare in rari casi errori più gravi del dovuto nel caso di errori cache dati.
60: in alcuni casi un errore di parità nella cache dati viene erroneamente riportato come errore multiplo anzichè singolo.
77: mancata segnalazione di errore per call o jump far in casi che non si verificiano in realtà
230: errore nell'accesso a una precisa locazione di I/O se si effettua un accesso non allineato. Si suggerisce di farlo allineato (come sarebbe norma)... :D
250: problema con l'accesso in modalità compatibile dell'area I/O allocata per la VGA. Non grave.
297: come il 60 ma per la cache istruzioni.
343: problema di perdita dati quando la cache L2 è usata come meoria al BOOT dal BIOS (e quindi prima di abilitare il controller RAM). La soluzione è disabilitare una feature, probabilmente della cache, quando si usa la L2 come memoria. Ovviamente nell'operatività normale deve essere riabiliata.
361: in rarissimi casi una eccezione di debug è persa in codice in una macchina virtuale. Qualche eccezione debug può essere persa in codice che gira in una macchina virtuale. Evento rarissimo e di nessun impatto nell'uso normale.
366: problema di affidabilità con la memoria se si settano dei parametri del controller memoria lontano dai valori raccomandati da AMD. Soluzione: usare i parametri raccomandati da AMD... :D
418: problema di traduzione pagine in una macchina virtuale se l'host usa il PAE (quindi SO a 32 bit con oltre 4GB di RAM, sostanzialmente versioni linux o windows server) e se le pagine guest sono nella parte iniziale della memoria. La soluzione proposta è che l'Hypervisor in tal caso non memorizzi la tabella pagine ad inizio memoria... Problema poco grave.
430: se un core è in stato CC6, non rileva i cambiamenti del segnale A20M. Essendo un segnale legacy usato solo da sistemi operativi non multicore (sostanzialmente DOS, vecchi windows) non c'è alcun problema, perchè essendo il SO mono-core, non c'è null'altro che può cambiare lo stato di quel segnale.
432: se si fa un warm reset durante una fase di accesso DMA al reset potrebbe essere riportato erroneamente un errore DMA.
441: un errata che riguarda il debug. Per trasferire lo stack pointer in un registro di debug si deve usare la codifica esatta della istruzione in linguaggio macchina. Altre codifiche che sono legali ma non standard, possono far caricare il valore sbagliato nel debug register.
465: il primo comando di settaggio RAM dopo l'inizializzazione del controller può impiegare fino a 2.5ms per essere compeltato e quindi far andare in timeout il BIOS. Workaround: usare un timeout superiore ai 2.5ms.
470: se si fa un warm reset nell'istante preciso in cui si accede ai registri di configurazione del PCI express il sistema si blocca. Il workaround è settare dei registri in un dato modo (ci vorrebbe il documento con i registri per sapere se inficia le prestazioni, ma poichè c'è no fix planned presumo che non impatti le prestazioni) e particolare cautela se si deve riconfigurare un link PCIex.
474: la funzione di azzeramento della memoria potrebbe non scrivere zero. Il suggested workaround è una procedura particolare di scrittura di zero in cache e poi rilettura della stessa, prima di avviare la procedura di azzeramento memoria.
541: problema con il conteggio di alcune statistiche se la CPU entra nello stato CC6 prima della lettura delle stesse. Il suggested workaround è che i software che usano queste statistiche devono leggere i dati prima di mandare la CPU in stato CC6.
564: questo sembra un baco non da poco e riguarda un possibile malfunzionamento nel ritorno dalla stato CC6 se si verifica una SMI esattamente quando si sta eseguendo l'HLT per portare la CPU in stato CC6. Dice di contattare il proprio AMD rapresentative... :mbe:
565: ancora sull'IBS, ossia le statistiche di uso. I registri sono separati per ogni core. Se si settano i cores in modo diverso ci potrebbero essere problemi di conteggio. La soluzione è settare tutti i cores in modo uguale.
573: questo sembra un baco non da poco e riguarda un possibile malfunzionamento dopo l'istruzione FSINCOS (una istruzione legacy della FPU x87 che fa calcolare seno e coseno assieme, evidentemente poco usata, poichè esistono istruzioni separate per seno e coseno). Dice di contattare il proprio AMD rapresentative... :mbe:
596: il NB può essere messo per sbaglio in clock gating in rare circostanze in cui si sta facendo un prefetch causando la corruzione dei dati. Dice che non è stato osservato nei software commerciali, ma comunque il workaround è disabilitare il clock gating del NB.

In sostanza non ci sono errata gravi e lo step messo in commercio è quello B0 :D (ciò potrebbe spiegare i clock bassi)

[capitan_crasy]

Le CPU serie FX-8000/FX-6000/FX-4000 con architettura Bulldozer dovrebbero essere presentati il 12 Ottobre 2011:
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=35973872&postcount=23803)

Le schede madri socket AM3+ con chipset AMD serie 900 sono attualmente in commercio!
Le APU Llano per il mercato mobile sono attualmente in commercio!
Le APU Ontario/Zacate sono attualmente in commercio!
La piattaforma "Lynx" composta da APU Llano per il mercato desktop è attualmente in commercio!

Le soluzioni Komodo (Bulldozer di seconda generazione) a 10/8/6 core sono attese per la prima parte del 2012! (data non confermata ufficialmente)

http://www.pctunerup.com/up//results/_200911/20091113194722_1255811929578.gif

[K Reloaded]

*indicizzato ;), grazie

[Vash_85]

Iscritto ;), potevo mica mancare.....

[Pihippo]

Evvai!
Propongo Capitan crasy for president!:D

[jurop88]

ping... iscritto

[-Maxx-]

Iscritto! Vediamo che combina AMD con Fusion :)

[Dre@mwe@ver]

Eccomi! :D

[Phenom95]

Evvai!
Propongo Capitan crasy for president!:D

Concordo, io faccio pochi interventi però leggo spesso il forum e lui è uno degli utenti da me preferiti per gli interventi che fa!!!

[sniperspa]

thread dovuto direi :asd:

[bjt2]

Benissimo. :)

Io proporrei di cambiare il regolamento del thread sul K10 per reindirizzare i post su buldozer qui... Se il regolamento già lo contemplava, allora bisogna essere meno permissivi di la... :)

Comunque... Iscritto!

[Defragg]

Seguo interessato :)

[Torpedo]

Eccomi :D

[^Robbie^]

Presente anche io ;)

Byez!

[TheBestFix]

http://img515.imageshack.us/img515/420/subt.jpg (http://img515.imageshack.us/i/subt.jpg/)

in effetti....:rolleyes:

[capitan_crasy]

Grazie a tutti per i complimenti, sono davvero lusingato...:flower:

Eccovi una chicca:
Sappiamo che la prima piattaforma desktop con le CPU Bulldozer si chiamerà "Scorpius"
Questa immagine la trovate sul sito AMD.

http://www.pctunerup.com/up/results/_200909/20090930162251_scorpius.jpg

[Athlon 64 3000+]

Iscritto,sono molto curioso di vedere come verrà fuori il progetto Buldozzer sperando che faccia rinascere AMD.

[Ren]

Non potevo mancare...:D

[M4R1|<]

Seguirò e parteciperò con un super interesse
Cmq Complimenti al Capitano!!!!!!!!!!!!!!!!!

http://img515.imageshack.us/img515/420/subt.jpg (http://img515.imageshack.us/i/subt.jpg/)

:sofico:

Grazie a tutti per i complimenti, sono davvero lusingato...:flower:

Eccovi una chicca:
Sappiamo che la prima piattaforma desktop con le CPU Bulldozer si chiamerà "Scorpius"
Questa immagine la trovate sul sito AMD.

http://www.pctunerup.com/up/results/_200909/20090930162251_scorpius.jpg

Prima Pagina :O

[787b]

lo scorpione crea la forma di un cuore :sofico:

[pandyno]

Va bien attendiamo anche questo uff :cool:

[-Maxx-]

http://img515.imageshack.us/img515/420/subt.jpg (http://img515.imageshack.us/i/subt.jpg/)

Questa jpeg è troppo lollosa! :asd:

[Defragg]

Grazie a tutti per i complimenti, sono davvero lusingato...:flower:

Eccovi una chicca:
Sappiamo che la prima piattaforma desktop con le CPU Bulldozer si chiamerà "Scorpius"
Questa immagine la trovate sul sito AMD.

http://www.pctunerup.com/up/results/_200909/20090930162251_scorpius.jpg

Come facciamo ad esserne certi? Tra l'altro non credo chiameranno i Bulldozer Phenom III, figuriamoci Phenom (come nell'immagine) ;)

[capitan_crasy]

Come facciamo ad esserne certi? Tra l'altro non credo chiameranno i Bulldozer Phenom III, figuriamoci Phenom (come nell'immagine) ;)

Dubiti della mia parola???
:eek:
:D
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=29052620&postcount=13919)

[M4R1|<]

Dubiti della mia parola???
:eek:
:D
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=29052620&postcount=13919)

:asd:

[vime76amd]

:D cavoli,me lo stavo perdendo.........ti rinnovo i complimenti per i tuoi thread capitano:)

[Defragg]

Dubiti della mia parola???
:eek:
:D
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=29052620&postcount=13919)

Dubito della slide, non di te Capitano! :D

[okorop]

iscritto e interessato, chissa se nel octa core scorpius riusciranno a metterci anche rv970xtx, sarebbe una belva :sofico:
si sa se c'è lo zampino di ibm per questa nuova architettra oppure no?

[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... (http://www.xbitlabs.com/news/other/display/20090930120901_Globalfoundries_on_Track_for_50_Natural_Yield_by_Year_End_with_32nm_Process_Technology.html)

[MonsterMash]

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... (http://www.xbitlabs.com/news/other/display/20090930120901_Globalfoundries_on_Track_for_50_Natural_Yield_by_Year_End_with_32nm_Process_Technology.html)

E soprattutto smentisce le voci dei giorni scorsi riguardo ad un ritardo sulla produzione a 32 nm di global founderies. :)

P.S. Sottoscritto anche io questo thread :)

[jacopo147]

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... (http://www.xbitlabs.com/news/other/display/20090930120901_Globalfoundries_on_Track_for_50_Natural_Yield_by_Year_End_with_32nm_Process_Technology.html)

tutte queste notizie succulente mi fanno :sbav: come una lumaca (immagine orribile lo so :D ) senza contare quello "Scorpius" dato che sono del segno dello scorpione sento una certa affinità... dai AMD, fammi un bel regalo per il 2011 :p

p.s.
mi associo agli obbligatori complimenti al capitano per questo e tutti gli altri Thread da lui creati e curati con taaanto amore, passione e competenza (violini zigani in sottofondo :asd: )

[Apfelsine]

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.
allora, forse, c'è una flebile speranza di vedere gli attuali k10 a 32nm

[capitan_crasy]

allora, forse, c'è una flebile speranza di vedere gli attuali k10 a 32nm

Su qualcosa devono per forza lavorare per sviluppare al meglio il silicio del 32nm (SRAM a parte); la cosa più semplice è fare un die shrink del K10 ( attualmente la CPU più semplice è il dual core Regor )...

[Ywes]

lo scorpione crea la forma di un cuore :sofico:

Sembra più l'imagine delle picche che quella di un cuore.

[Vash_85]

Sembra più l'imagine delle picche che quella di un cuore.

Speriamo di no :fuck:

[Ren]

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.


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.

[capitan_crasy]

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]

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:



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]

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]

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]

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|<]

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... (http://www.xbitlabs.com/news/other/display/20090930120901_Globalfoundries_on_Track_for_50_Natural_Yield_by_Year_End_with_32nm_Process_Technology.html)

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]

è 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. :D

[bjt2]

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. :D

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]

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]

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]

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]

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...

[Pihippo]

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...

Ciao.
Mi sono espresso male. Intendevo visto che è gia possibile ora spezzettare le istruzioni SIMD è possibile che anche bulldozer spezzeti un vettore da 256 a 128x2 in modo da eseguirle in parallelo, o no? E se possibile con performance inferiori od uguali ad una FPu con datapath a 256bit?

[Ren]

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)

Esatto, le alu intere del pentium 4 erano con clock doppio rispetto alla logica.

Mi veniva in mente un diverso clock proprio per via degli stadi in più.
Una situazione del genere riequilibrerebbe il rapporto integer/fp in un cluster core senza aumentare le unità funzionali.

Nehalem che io sappia ha 14 stadi... (dove lo hai letto ?)

[Ren]

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...

Avere clock indipendenti complica eccessivamente il circuito ?

[Pihippo]

Esatto, le alu intere del pentium 4 erano con clock doppio rispetto alla logica.

Mi veniva in mente un diverso clock proprio per via degli stadi in più.
Una situazione del genere riequilibrerebbe il rapporto integer/fp in un cluster core senza aumentare le unità funzionali.

Nehalem che io sappia ha 14 stadi... (dove lo hai letto ?)

Ciao:
http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=1
In effetti ho sbagliato pure io, qui dice chiaramente, prima pagina alla fine 16 stadi per le alu, per la Fpu non trovo nulla ma penso qualcosina in più o 16 stadi come minimo.

[bjt2]

Ciao.
Mi sono espresso male. Intendevo visto che è gia possibile ora spezzettare le istruzioni SIMD è possibile che anche bulldozer spezzeti un vettore da 256 a 128x2 in modo da eseguirle in parallelo, o no? E se possibile con performance inferiori od uguali ad una FPu con datapath a 256bit?

Certo. Ed è l'approccio probabile. Ovviamente l'approccio più veloce è una unità a 256 bit, per tre motivi: 1 è più veloce (1clock contro 2), 2 occupa meno slot istruzioni (1 contro 2), 3 l'istruzione è più semplice da decodificare (una macrooperazione in meno).

[bjt2]

Avere clock indipendenti complica eccessivamente il circuito ?

Ci voglioni delle code per disaccoppiare le parti... Siccome normalmente già ci sono le code tra i vari stadi della pipeline... Non complica molto il circuito... Però forse complica il testing...

[Pihippo]

Certo. Ed è l'approccio probabile. Ovviamente l'approccio più veloce è una unità a 256 bit, per tre motivi: 1 è più veloce (1clock contro 2), 2 occupa meno slot istruzioni (1 contro 2), 3 l'istruzione è più semplice da decodificare (una macrooperazione in meno).

Ciao.
Grazie per la risposta.
Secondo te è possibile che questo approccio sia dovuto al fatto che la FPU in bulldozer essendo condivisa, almeno cosi indicano i brevetti, da due cluster di alu, e che quindi dovendo far girare due thread(almeno cosi ho capito che sia il CMT) essa debba per forza "splittarsi" in 2 (a meno che son siano thread fatti solo di interi) per eseguire le operazioni in virgola mobile dei due thread?

[bjt2]

Ciao.
Grazie per la risposta.
Secondo te è possibile che questo approccio sia dovuto al fatto che la FPU in bulldozer essendo condivisa, almeno cosi indicano i brevetti, da due cluster di alu, e che quindi dovendo far girare due thread(almeno cosi ho capito che sia il CMT) essa debba per forza "splittarsi" in 2 (a meno che son siano thread fatti solo di interi) per eseguire le operazioni in virgola mobile dei due thread?

Anche se fosse una sola la FPU, andrebbero a turno...

[Pihippo]

Anche se fosse una sola la FPU, andrebbero a turno...

Ciao.
A turno intendi, un pò questo thread qui un pò quest'altro thread qua?
Allora mi sa che non ho capito cos'è il clustered multi threading ed il vantaggio di avere una FPU condivisa se si azzoppa un pò tutto...

[beautycase]

grazie a tutti per questo thread :cincin:

[bjt2]

Ciao.
A turno intendi, un pò questo thread qui un pò quest'altro thread qua?
Allora mi sa che non ho capito cos'è il clustered multi threading ed il vantaggio di avere una FPU condivisa se si azzoppa un pò tutto...

Se hai due core separati con ognuno una FPADD, una FPMUL, una FPMISC, è una cosa, se invece metti una mega unità FP con 2 FPADD, 2 FPMUL e 2 FPMISC in comune fra due core, con più o meno la stessa area e un'altra cosa (è meglio). Se invece la FPU è uguale a quella di un singolo core K10 allora consumerai semplicemente di meno con una leggera perdita di prestazioni. Ma a parità di TDP potrai salire di più di clock.

[Pihippo]

Se hai due core separati con ognuno una FPADD, una FPMUL, una FPMISC, è una cosa, se invece metti una mega unità FP con 2 FPADD, 2 FPMUL e 2 FPMISC in comune fra due core, con più o meno la stessa area e un'altra cosa (è meglio). Se invece la FPU è uguale a quella di un singolo core K10 allora consumerai semplicemente di meno con una leggera perdita di prestazioni. Ma a parità di TDP potrai salire di più di clock.

Ciao.
Grazie per la risposta, quindi in ambedue i casi Amd potrebbe comunque raggiungere elevate presatazioni pur condividendo la Fpu perchè può essere una FPU molto potente ( 2 unità FPSTORE 2 FPADD e 2 FPMUL) oppure alzando pesantemente i clock?

[bjt2]

Ciao.
Grazie per la risposta, quindi in ambedue i casi Amd potrebbe comunque raggiungere elevate presatazioni pur condividendo la Fpu perchè può essere una FPU molto potente ( 2 unità FPSTORE 2 FPADD e 2 FPMUL) oppure alzando pesantemente i clock?

Nel primo caso ci può essere una migliore utilizzazione delle unità, perchè ci sono due thread (o forse più... dipende se vogliono combinare il clustering con l'SMT aka Hyperthreading, e secondo quei pdf postati qualche pagina fa conviene farlo...) che si contendono le 6 unità, nel secondo caso, a parità di thread c'è la metà delle unità FP e quindi meno dissipazione, con possibilità di poter salire di più di clock...

[capitan_crasy]

Ora è quasi ufficiale!
La piattaforma che ospiterà le prime CPU desktop Bulldozer si chiamerà "Scorpius"; addio core Orochi, benvenuto core Zambezi!!
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=29052620&postcount=13919)

http://www.pctunerup.com/up/results/_200910/20091007115145_20091007amd_roadmap.jpg

Clicca qui (http://translate.google.com/translate?hl=it&sl=fi&tl=en&u=http%3A%2F%2Fplaza.fi%2Fmuropaketti%2Famdn-tyopoytaprosessorien-suunnitelmat-julki-vuoteen-2011-asti) (notizia in finlandese tradotta in italiano By Google)

[birmarco]

Ciao a tutti...
Quand'è che posso comprare la prima CPU AMD a 6 core? :D

PS. Non ritrovavo più il 3d... :D

[MonsterMash]

Ciao a tutti...
Quand'è che posso comprare la prima CPU AMD a 6 core? :D

PS. Non ritrovavo più il 3d... :D

Puoi comprarla anche adesso, solo che è una cpu opteron :D.

La prima cpu esacore per desktop dovrebbe uscire nel Q1 2010, e sarà ovviamente un k10, quindi questo è il thread sbagliato ;).

[birmarco]

Puoi comprarla anche adesso, solo che è una cpu opteron :D.

La prima cpu esacore per desktop dovrebbe uscire nel Q1 2010, e sarà ovviamente un k10, quindi questo è il thread sbagliato ;).

Che palle!! Mi tocca aspettare....e spero solo che sia su socket AM3. O che facciano un AM3+ retrocompatibile con AM3 (scelta inutile :stordita:)

[MonsterMash]

Che palle!! Mi tocca aspettare....e spero solo che sia su socket AM3. O che facciano un AM3+ retrocompatibile con AM3 (scelta inutile :stordita:)

Sarà sicuramente AM3, ovviamente retrocompatibile con am2+. Pare però che non sarà compatibile con il vecchio am2.

[birmarco]

Sarà sicuramente AM3, ovviamente retrocompatibile con am2+. Pare però che non sarà compatibile con il vecchio am2.

poco male... :) Oramai hanno tutti am3 o am2+. Ci sono un po' troppe poche schede con AM3 però...

[capitan_crasy]

poco male... :) Oramai hanno tutti am3 o am2+. Ci sono un po' troppe poche schede con AM3 però...

E' probabile che all'uscita del core Thuban sarà presentato anche la piattaforma "LEO" con i nuovi chipset AMD serie 800+SB850...

[birmarco]

E' probabile che all'uscita del core Thuban sarà presentato anche la piattaforma "LEO" con i nuovi chipset AMD serie 800+SB850...

bene bene... che questo sb770 che ho fa un po' schifo... :mc: una occasione per cambiare :) e poi non vedo l'ora di incrementare il numero di core!! :sofico:

[-Maxx-]

bene bene... che questo sb770 che ho fa un po' schifo... :mc: una occasione per cambiare :) e poi non vedo l'ora di incrementare il numero di core!! :sofico:

770 non è il SB ma il NB ;)

[birmarco]

770 non è il SB ma il NB ;)

:ops:




ehehe :D Va be... allora il NB770 fa schifo... infatti mi sono sempre chiesto perchè si diceva SB se poi era il northbrigde :asd: e infatti...

[capitan_crasy]

Notizia da prendere con le dovute cautele:
(era un bel pò che non usavo questa frase:D )

Ora che Windows 7 è alle porte, l'attenzione dei più appassionati al mondo Windows si sposta oltre: è già partita la caccia ad indiscrezioni e spiragli che lascino trapelare qualche dato circa il prossimo "Windows 8".

Da qualche tempo ormai, il celebre blog UXEvangelist (ora divenuto Microsoft Kitchen) sta proponendo numerose informazioni in merito, estrapolate soprattutto da inserzioni lavorative mediante le quali Microsoft ricerca professionisti interessati a lavorare a determinati aspetti del nuovo sistema operativo.

Particolarmente curioso è il post apparso qualche giorno addietro, nel quale l'autore ha avanzato la possibilità che Windows 8 e Windows 9 possano essere dotati di un kernel compatibile con le CPU a 128 bit.
La fonte

La fonte di tale informazione è comunque tutt'altro che certa: si tratta infatti del messaggio di presentazione pubblicato da tale Robert Morgan, auto-referenziatosi come "Programmatore senior della divisione ricerca e sviluppo di Microsoft", sulla propria pagina personale di LinkedIn, il social network dedicato ai professionisti.

"Sto lavorando in un dipartimento ad alta sicurezza di ricerca e sviluppo incentrato sulla pianificazione strategica di progetti a medio e lungo termine" dichiarava Mr. Morgan "Progetti di ricerca e sviluppo che includono la compatibilità con le architetture a 128 bit per il kernel di Windows 8 e Windows 9. Sto formando relazioni con i principali partner: Intel, AMD, HP e IBM".

Il professionista ha poi rincarato la dose nel messaggio personale dello stesso account: "Robert Morgan è stato chiamato in ufficio, gli allarmi la mattina sono così piacevoli. Qualcuno ha dimenticato di impostare a dovere il test per il nuovo AMD a 128 bit".

Con tutta probabilità, tale osservazione si riferisce alla CPU nota come "Bulldozer", la cui esistenza è stata svelata dal sito Bright side of news durante il mese di aprile.

Prima di accorgersi di essere seguito da qualcuno particolarmente interessato a questi aspetti e cancellarsi da LinkedIn, lo sbadato sviluppatore ha lasciato trapelare ancora qualche dettaglio (parecchio confuso, in effetti) "Robert Morgan sta lavorando per far sì che IA-128 possa lavorare all'indietro, con la completa compatibilità binaria con le istruzioni IA-64 dell'hardware. Simulazione di funzionamento per Windows 8 ed assolutamente Windows 9".

Clicca qui... (http://www.megalab.it/5234/windows-8-sara-anche-a-128-bit-windows-9-probabilmente-si)

bjt2, che ne pensi dell'ipotesi di Bulldozer a 128bit?

[ozlacs]

se non è una bufala si evincono alcune cosette:

- di quello che ci sarà in Bulldozer sappiamo praticamente niente, e invece crediamo di sapere molto :D ;
- alla Microsoft hanno un sample di Bulldzer funzionante :eek: ;
- i programmatori MS sono più lolloni di quanto si possa pensare :asd:


boh, cmq se non ricordo male, tempo fà bjt escluse l'ipotesi di una CPU a 128, basandosi cmq sulle informazioni fino ad ora conosciute :D

[Pihippo]

Notizia da prendere con le dovute cautele:
(era un bel pò che non usavo questa frase:D )

Ora che Windows 7 è alle porte, l'attenzione dei più appassionati al mondo Windows si sposta oltre: è già partita la caccia ad indiscrezioni e spiragli che lascino trapelare qualche dato circa il prossimo "Windows 8".

Da qualche tempo ormai, il celebre blog UXEvangelist (ora divenuto Microsoft Kitchen) sta proponendo numerose informazioni in merito, estrapolate soprattutto da inserzioni lavorative mediante le quali Microsoft ricerca professionisti interessati a lavorare a determinati aspetti del nuovo sistema operativo.

Particolarmente curioso è il post apparso qualche giorno addietro, nel quale l'autore ha avanzato la possibilità che Windows 8 e Windows 9 possano essere dotati di un kernel compatibile con le CPU a 128 bit.
La fonte

La fonte di tale informazione è comunque tutt'altro che certa: si tratta infatti del messaggio di presentazione pubblicato da tale Robert Morgan, auto-referenziatosi come "Programmatore senior della divisione ricerca e sviluppo di Microsoft", sulla propria pagina personale di LinkedIn, il social network dedicato ai professionisti.

"Sto lavorando in un dipartimento ad alta sicurezza di ricerca e sviluppo incentrato sulla pianificazione strategica di progetti a medio e lungo termine" dichiarava Mr. Morgan "Progetti di ricerca e sviluppo che includono la compatibilità con le architetture a 128 bit per il kernel di Windows 8 e Windows 9. Sto formando relazioni con i principali partner: Intel, AMD, HP e IBM".

Il professionista ha poi rincarato la dose nel messaggio personale dello stesso account: "Robert Morgan è stato chiamato in ufficio, gli allarmi la mattina sono così piacevoli. Qualcuno ha dimenticato di impostare a dovere il test per il nuovo AMD a 128 bit".

Con tutta probabilità, tale osservazione si riferisce alla CPU nota come "Bulldozer", la cui esistenza è stata svelata dal sito Bright side of news durante il mese di aprile.

Prima di accorgersi di essere seguito da qualcuno particolarmente interessato a questi aspetti e cancellarsi da LinkedIn, lo sbadato sviluppatore ha lasciato trapelare ancora qualche dettaglio (parecchio confuso, in effetti) "Robert Morgan sta lavorando per far sì che IA-128 possa lavorare all'indietro, con la completa compatibilità binaria con le istruzioni IA-64 dell'hardware. Simulazione di funzionamento per Windows 8 ed assolutamente Windows 9".

Clicca qui... (http://www.megalab.it/5234/windows-8-sara-anche-a-128-bit-windows-9-probabilmente-si)

bjt2, che ne pensi dell'ipotesi di Bulldozer a 128bit?

Ciao capitano
Dalla notizia da te postata si capisce veramente poco. Ovvero hanno espanso il Physical address dai 64 (48 in verità) a 128? I Gpr sono a 128 bit? Hanno aggiunto altri Gpr? Cioè da x86 ad x85 c'è un incremento medio del 10-15% dovuto solo al fatto che i general purpose register della cpu sono passati da 8 a 16, che stavolta si abbiano 32 gpr?

[Vash_85]

Notizia da prendere con le dovute cautele:
(era un bel pò che non usavo questa frase:D )

Ora che Windows 7 è alle porte, l'attenzione dei più appassionati al mondo Windows si sposta oltre: è già partita la caccia ad indiscrezioni e spiragli che lascino trapelare qualche dato circa il prossimo "Windows 8".

Da qualche tempo ormai, il celebre blog UXEvangelist (ora divenuto Microsoft Kitchen) sta proponendo numerose informazioni in merito, estrapolate soprattutto da inserzioni lavorative mediante le quali Microsoft ricerca professionisti interessati a lavorare a determinati aspetti del nuovo sistema operativo.

Particolarmente curioso è il post apparso qualche giorno addietro, nel quale l'autore ha avanzato la possibilità che Windows 8 e Windows 9 possano essere dotati di un kernel compatibile con le CPU a 128 bit.
La fonte

La fonte di tale informazione è comunque tutt'altro che certa: si tratta infatti del messaggio di presentazione pubblicato da tale Robert Morgan, auto-referenziatosi come "Programmatore senior della divisione ricerca e sviluppo di Microsoft", sulla propria pagina personale di LinkedIn, il social network dedicato ai professionisti.

"Sto lavorando in un dipartimento ad alta sicurezza di ricerca e sviluppo incentrato sulla pianificazione strategica di progetti a medio e lungo termine" dichiarava Mr. Morgan "Progetti di ricerca e sviluppo che includono la compatibilità con le architetture a 128 bit per il kernel di Windows 8 e Windows 9. Sto formando relazioni con i principali partner: Intel, AMD, HP e IBM".

Il professionista ha poi rincarato la dose nel messaggio personale dello stesso account: "Robert Morgan è stato chiamato in ufficio, gli allarmi la mattina sono così piacevoli. Qualcuno ha dimenticato di impostare a dovere il test per il nuovo AMD a 128 bit".

Con tutta probabilità, tale osservazione si riferisce alla CPU nota come "Bulldozer", la cui esistenza è stata svelata dal sito Bright side of news durante il mese di aprile.

Prima di accorgersi di essere seguito da qualcuno particolarmente interessato a questi aspetti e cancellarsi da LinkedIn, lo sbadato sviluppatore ha lasciato trapelare ancora qualche dettaglio (parecchio confuso, in effetti) "Robert Morgan sta lavorando per far sì che IA-128 possa lavorare all'indietro, con la completa compatibilità binaria con le istruzioni IA-64 dell'hardware. Simulazione di funzionamento per Windows 8 ed assolutamente Windows 9".

Clicca qui... (http://www.megalab.it/5234/windows-8-sara-anche-a-128-bit-windows-9-probabilmente-si)

bjt2, che ne pensi dell'ipotesi di Bulldozer a 128bit?

Azz.... mi sembra improbabile però che il prossimo win esca con supporto ai 128 bit....il 90% del mercato home è fermo a 32....piuttosto avevo sentito dire che win 7 sarebbe stato l'ultimo con supporto 32 bit...dal prossimo si passa direttamente ai 64

[^Robbie^]

Magari inizieranno ad implementare a livello del kernel il supporto per i 128bit in Win8 e ad espanderlo ad altre parti sel SO con Win9, anche perchè credo che nn vedremo una ipotetica CPU a 128bit a breve termine (nn credo proprio che Bulldozer possa implementare i 128bit in qualche modo).

Byez!

[calabar]

Perchè no? In fondo abbiamo visto che il software sta sempremolto dietro l'hardware, e difatti i 64 bit si trovano sui processori AMD dal 2003, ma ad oggi la fetta di sistemi MS 64 bit è ancora risicata (certo, se win7 uscisse di base a 64 bit, lasciando la versione a 32bit per i pc più vecchi e con hw più limitato, sarebbe già un grosso passo in avanti, e mi pare che le condizioni per un passo del genere oramai ci siano).

Se Bulldozer uscisse con supporto alle estensioni a 128 bit significherebbe che AMD sta cominciando a farsi una base per i sistemi del futuro.
Senza una base hardware adeguata è impossibile che il software si diffonda.

[capitan_crasy]

Magari inizieranno ad implementare a livello del kernel il supporto per i 128bit in Win8 e ad espanderlo ad altre parti sel SO con Win9, anche perchè credo che nn vedremo una ipotetica CPU a 128bit a breve termine (nn credo proprio che Bulldozer possa implementare i 128bit in qualche modo).

Byez!

Dubito che Microsoft faccia un sistema operativo 128bit solo per AMD; la storia passata del primo OS a 64bit è una testimonianza fin troppo chiara...
Se Invece sarà Intel ad preparare per prima una CPU a 128bit, l' OS uscirà in tempi molto più brevi senza l'obbligo di aspettare la concorrenza...

[jacopo147]

Notizia da prendere con le dovute cautele:
(era un bel pò che non usavo questa frase:D )

Ora che Windows 7 è alle porte, l'attenzione dei più appassionati al mondo Windows si sposta oltre: è già partita la caccia ad indiscrezioni e spiragli che lascino trapelare qualche dato circa il prossimo "Windows 8".

Da qualche tempo ormai, il celebre blog UXEvangelist (ora divenuto Microsoft Kitchen) sta proponendo numerose informazioni in merito, estrapolate soprattutto da inserzioni lavorative mediante le quali Microsoft ricerca professionisti interessati a lavorare a determinati aspetti del nuovo sistema operativo.

Particolarmente curioso è il post apparso qualche giorno addietro, nel quale l'autore ha avanzato la possibilità che Windows 8 e Windows 9 possano essere dotati di un kernel compatibile con le CPU a 128 bit.
La fonte

La fonte di tale informazione è comunque tutt'altro che certa: si tratta infatti del messaggio di presentazione pubblicato da tale Robert Morgan, auto-referenziatosi come "Programmatore senior della divisione ricerca e sviluppo di Microsoft", sulla propria pagina personale di LinkedIn, il social network dedicato ai professionisti.

"Sto lavorando in un dipartimento ad alta sicurezza di ricerca e sviluppo incentrato sulla pianificazione strategica di progetti a medio e lungo termine" dichiarava Mr. Morgan "Progetti di ricerca e sviluppo che includono la compatibilità con le architetture a 128 bit per il kernel di Windows 8 e Windows 9. Sto formando relazioni con i principali partner: Intel, AMD, HP e IBM".

Il professionista ha poi rincarato la dose nel messaggio personale dello stesso account: "Robert Morgan è stato chiamato in ufficio, gli allarmi la mattina sono così piacevoli. Qualcuno ha dimenticato di impostare a dovere il test per il nuovo AMD a 128 bit".

Con tutta probabilità, tale osservazione si riferisce alla CPU nota come "Bulldozer", la cui esistenza è stata svelata dal sito Bright side of news durante il mese di aprile.

Prima di accorgersi di essere seguito da qualcuno particolarmente interessato a questi aspetti e cancellarsi da LinkedIn, lo sbadato sviluppatore ha lasciato trapelare ancora qualche dettaglio (parecchio confuso, in effetti) "Robert Morgan sta lavorando per far sì che IA-128 possa lavorare all'indietro, con la completa compatibilità binaria con le istruzioni IA-64 dell'hardware. Simulazione di funzionamento per Windows 8 ed assolutamente Windows 9".

Clicca qui... (http://www.megalab.it/5234/windows-8-sara-anche-a-128-bit-windows-9-probabilmente-si)

bjt2, che ne pensi dell'ipotesi di Bulldozer a 128bit?

da niubbo in materia quale sono chiedo :D i vantaggi materiali di lavorare con un sistema a 128bit?

[ippo.g]

Dubito che Microsoft faccia un sistema operativo 128bit solo per AMD; la storia passata del primo OS a 64bit è una testimonianza fin troppo chiara...
Se Invece sarà Intel ad preparare per prima una CPU a 128bit, l' OS uscirà in tempi molto più brevi senza l'obbligo di aspettare la concorrenza...
ai tempi Microsoft e Crytec diedero il loro appoggio ad AMD, XP64 fallì per il mancato supporto driver.
da niubbo in materia quale sono chiedo :D i vantaggi materiali di lavorare con un sistema a 128bit?

e quello, che da ignorante, mi chiedo anche io.


p.s. in bocca al lupo anche da parte mia

[ivano444]

e quello, che da ignorante, mi chiedo anche io.



anche io in effetti :D

[jacopo147]

e quello, che da ignorante, mi chiedo anche io.


p.s. in bocca al lupo anche da parte mia

anche io in effetti :D

mi sento meno solo :fagiano: adesso qualche saggio ci spiegherà (capitano questo thread si preannuncia di estrema utilità, sopratutto per noi "inioranti" :D )

grazie ippo.g

[Pihippo]

ai tempi Microsoft e Crytec diedero il loro appoggio ad AMD, XP64 fallì per il mancato supporto driver.


e quello, che da ignorante, mi chiedo anche io.


p.s. in bocca al lupo anche da parte mia

Ciao
Provo a rispondere io.
Mi sono documentato un pocuccio. Dunque premettendo che l'implementazione a 128bit li come li riportata non vuol dire nulla, ovvero le possbilità sono molte:
1) E' cambiato solo il tipo dei dati(integer perchè gia in floating point avremo vettori larghi 256bit) su cui si può operare da 64bit a 128 ed allora in ambito desktop serviranno tanto e non quanto
2) Hanno raddoppiato i GPrs i general purposer registers, che sono i registri dove la cpu tiene internamente ovvero molto vicina alle execution unit operandi ed indirizzi della memoria, (da 16 in x64 a 32 in una ipotetica isa 128) ed allora grazie solo alla presenza di questo si potrebbe avere un aumento di performance come il salto dai 32 ad i 64 bit (10-15%)
3) E' cambianto il physical address space da 64(in realtà 48) bit a 128, ma in desktop questo significa poco, gia con 48bit possiamo indirizzare una quantità enorme di ram, questo però è diverso per le workstation e server

4) Hanno cambiato tutto dei punti 1 a 3 ed in più hanno ripulito l'ISA x86 (come fece amd al tempo con amd64)

Spero di essere stato esaustivo

[ippo.g]

Ciao
Provo a rispondere io.
Mi sono documentato un pocuccio. Dunque premettendo che l'implementazione a 128bit li come li riportata non vuol dire nulla, ovvero le possbilità sono molte:
1) E' cambiato solo il tipo dei dati(integer perchè gia in floating point avremo vettori larghi 256bit) su cui si può operare da 64bit a 128 ed allora in ambito desktop serviranno tanto e non quanto
2) Hanno raddoppiato i GPrs i general purposer registers, che sono i registri dove la cpu tiene internamente ovvero molto vicina alle execution unit operandi ed indirizzi della memoria, (da 16 in x64 a 32 in una ipotetica isa 128) ed allora grazie solo alla presenza di questo si potrebbe avere un aumento di performance come il salto dai 32 ad i 64 bit (10-15%)
3) E' cambianto il physical address space da 64(in realtà 48) bit a 128, ma in desktop questo significa poco, gia con 48bit possiamo indirizzare una quantità enorme di ram, questo però è diverso per le workstation e server

4) Hanno cambiato tutto dei punti 1 a 3 ed in più hanno ripulito l'ISA x86 (come fece amd al tempo con amd64)

Spero di essere stato esaustivo

si, molto :fagiano:

[Pihippo]

Ciao

Grazie per l'apprezzamento. Dubito che però vedremo programmi a 128bit. Molte software house ignorano toltalmente i benefici dei 64 bit semplicemente perchè l'utente medio non possiede S.O a 64 bit. E le cpu a x64 ci sono dal 2004.....

[jacopo147]

Ciao
Provo a rispondere io.
Mi sono documentato un pocuccio. Dunque premettendo che l'implementazione a 128bit li come li riportata non vuol dire nulla, ovvero le possbilità sono molte:
1) E' cambiato solo il tipo dei dati(integer perchè gia in floating point avremo vettori larghi 256bit) su cui si può operare da 64bit a 128 ed allora in ambito desktop serviranno tanto e non quanto
2) Hanno raddoppiato i GPrs i general purposer registers, che sono i registri dove la cpu tiene internamente ovvero molto vicina alle execution unit operandi ed indirizzi della memoria, (da 16 in x64 a 32 in una ipotetica isa 128) ed allora grazie solo alla presenza di questo si potrebbe avere un aumento di performance come il salto dai 32 ad i 64 bit (10-15%)
3) E' cambianto il physical address space da 64(in realtà 48) bit a 128, ma in desktop questo significa poco, gia con 48bit possiamo indirizzare una quantità enorme di ram, questo però è diverso per le workstation e server

4) Hanno cambiato tutto dei punti 1 a 3 ed in più hanno ripulito l'ISA x86 (come fece amd al tempo con amd64)

Spero di essere stato esaustivo

mi associo a ippo.g nell'apprezzamento :)

[Pihippo]

mi associo a ippo.g nell'apprezzamento :)


Ciao
Grazie mi fate arrossire :D
OT
Di nuovo in bocca al lupo per l'operazione ! Stai tranquillissimo e postivo di ste cose me ne intendo per lavoro ed andrà tutto bene!! --- Fine OT

[capitan_crasy]

ai tempi Microsoft e Crytec diedero il loro appoggio ad AMD, XP64 fallì per il mancato supporto driver.


Per XP 64 diciamo che Microsoft ha vanificato il vantaggio temporale che aveva AMD con AMD64 nei confronti di Inter, rinviando casualmente OS di circa 6/8 mesi per poter integrare le EM64T di Intel.
Non sarebbe cambiato molto, dato che solo da VISTA in poi si può chiamare un OS a 64bit, ma dubito che a parti invertite Microsoft avrebbe fatto la buona samaritana con AMD...
Per Farcry è stato sono un ottima parentesi,ma la realtà è che il mercato dei videogiochi ha letteralmente ignorato i 64bit...

Ciao
Grazie mi fate arrossire :D


mi associo per i complimenti...:)

[birmarco]

Cmq il fatto che windows 8 sarà compatibile con CPU 128bit non vuol dire che sarà a 128... ma che potrà funzionare ANCHE su CPU a 128bit. Quindi non è detto nè che ci saranno OS a 128bit nè CPU a 128bit. Considerando che Win8 uscirà ipoteticamente tra 2 anni e che durerà per 2 anni prima che arrivi il suo successore (OT: che sarà ancora Windows?? :stordita: ). QUindi Microsoft avrebbe messo le mani avanti per i prossimi 4 anni (2014). Le CPU a 32nm esistono circa dal 1990 e le 64bit dal 2004 (14 anni di 32bit). Se intorno al 2014 ci saranno CPU a 128bit la "tabella di marcia" sarebbe rispettata (le CPU a 16bit sono durate 12 anni...)

[bjt2]

Notizia da prendere con le dovute cautele:
(era un bel pò che non usavo questa frase:D )

Clicca qui... (http://www.megalab.it/5234/windows-8-sara-anche-a-128-bit-windows-9-probabilmente-si)

bjt2, che ne pensi dell'ipotesi di Bulldozer a 128bit?

Se per 128 bit indica l'estensione dei 16 GPR a 128 bit, non vedo questa grande rivoluzione, a meno che questo non voglia dire poter usare le istruzioni SIMD anche con i GPR. Sicuramente gli indirizzi NON saranno estesi a 128 bit (troppo spazio e comunque non sarà necessario per moooolti anni farlo). Estendere l'architettura a 128 bit può avere qualche vantaggio: poter usare anche i 16 GPR come registri per le SSE a 128 bit (MA NON PER QUELLE a 256 BIT), quindi per come è fatta l'architettura K10 (e probabilmente anche buldozer) poter far eseguire queste istruzioni nelle pipeline intere, raddoppiando di fatto il throughput SSE 128 bit (ma è una ipotesi).

Anche se non vengono estese le SSE 128 bit ai registri GPR, possono comunque essere create istruzioni intere a 128 bit oppure intere SIMD a 8-16-32-64 bit...

I vantaggi sono pochi, comunque. Forse per la crittografia, istruzioni intere a 128 bit accelererebbero di molto il calcolo, ma non vedo altre applicazioni eclatanti, a meno che non introducano, appunto, istruzioni SIMD sui GPR...

Il supporto da parte del SO si riduce solo a prevedere lo spazio necessario sullo stack kernel per i registri allargati, perchè esistono istruzioni CPU per fare il task switch...

[Pihippo]

Se per 128 bit indica l'estensione dei 16 GPR a 128 bit, non vedo questa grande rivoluzione, a meno che questo non voglia dire poter usare le istruzioni SIMD anche con i GPR. Sicuramente gli indirizzi NON saranno estesi a 128 bit (troppo spazio e comunque non sarà necessario per moooolti anni farlo). Estendere l'architettura a 128 bit può avere qualche vantaggio: poter usare anche i 16 GPR come registri per le SSE a 128 bit (MA NON PER QUELLE a 256 BIT), quindi per come è fatta l'architettura K10 (e probabilmente anche buldozer) poter far eseguire queste istruzioni nelle pipeline intere, raddoppiando di fatto il throughput SSE 128 bit (ma è una ipotesi).

Anche se non vengono estese le SSE 128 bit ai registri GPR, possono comunque essere create istruzioni intere a 128 bit oppure intere SIMD a 8-16-32-64 bit...

I vantaggi sono pochi, comunque. Forse per la crittografia, istruzioni intere a 128 bit accelererebbero di molto il calcolo, ma non vedo altre applicazioni eclatanti, a meno che non introducano, appunto, istruzioni SIMD sui GPR...

Il supporto da parte del SO si riduce solo a prevedere lo spazio necessario sullo stack kernel per i registri allargati, perchè esistono istruzioni CPU per fare il task switch...

Ciao
In effetti penso anch'io che l'allargamento dei gprs a 128bit porti vantaggi marginali, basta pensare che gli int a 64bit vengono utlizzati solo in crittografia od HPC per il resto ci sono i valori in float che garantiscono una simulazione maggiore dei numeri reali. Gia a 64bit si possono rappresentare integers con range elevatissimi, poi, secondo me, utilizzare gprs per operazioni matematiche non è che sia il massimo, sono gia pochi (quando si possono usare i registri mmx, xmm delle simd, ed addirittura quelli dell'x87)
Sinceramente non penso che con l'IA a 128 bit estenderanno i gprs ad operazioni con le simd, questo soprattuto considerando che con le AVX si avranno vettori a 256bit. Oltrettuto dovrebbero cambiare molte cose nelle architettura, ovvero come esegui operazioni int a 64-32 bit se i gprs vengono occupati da istruzioni SimD? A meno che non si aumentino i gprs totali di cui alcuni di quelli introdotti (ipotetici RAX-EAX17 ad RAX-EAX32 se li radoppiano da 16 a 32) utilizzati solo per quello, e l'os per poterli utilizzare dovrebbe operare in una long mode simile a quella che si utlizza in abiente x64...
Inoltre avere un radoppio dei registri condurrebbe ad uno snellimento del codice, sempre che gli sviluppatori abbiano voglia di "ricompilare" il codice, ovvero meno LOAD e STORE perchè hai più gprs per metterci dentro i dati, quindi anche più velocità.

[Pihippo]

Ciao
In effetti penso anch'io che l'allargamento dei gprs a 128bit porti vantaggi marginali, basta pensare che gli int a 64bit vengono utlizzati solo in crittografia od HPC per il resto ci sono i valori in float che garantiscono una simulazione maggiore dei numeri reali. Gia a 64bit si possono rappresentare integers con range elevatissimi, poi, secondo me, utilizzare gprs per operazioni matematiche non è che sia il massimo, sono gia pochi (quando si possono usare i registri mmx, xmm delle simd, ed addirittura quelli dell'x87)
Sinceramente non penso che con l'IA a 128 bit estenderanno i gprs ad operazioni con le simd, questo soprattuto considerando che con le AVX si avranno vettori a 256bit. Oltrettuto dovrebbero cambiare molte cose nelle architettura, ovvero come esegui operazioni int a 64-32 bit se i gprs vengono occupati da istruzioni SimD? A meno che non si aumentino i gprs totali di cui alcuni di quelli introdotti (ipotetici RAX-EAX17 ad RAX-EAX32 se li radoppiano da 16 a 32) utilizzati solo per quello, e l'os per poterli utilizzare dovrebbe operare in una long mode simile a quella che si utlizza in abiente x64...
Inoltre avere un radoppio dei registri condurrebbe ad uno snellimento del codice, sempre che gli sviluppatori abbiano voglia di "ricompilare" il codice, ovvero meno LOAD e STORE perchè hai più gprs per metterci dentro i dati, quindi anche più velocità.

Mi quoto per specficare una cosa, dopo ricerche non proprio approfonditissime posso affermare con assoluta, quasi , certezza che i programmatori di giochini se ne sbattono altamente di ricompilare i loro codici per avere maggiori performance..

[bjt2]

Ciao
In effetti penso anch'io che l'allargamento dei gprs a 128bit porti vantaggi marginali, basta pensare che gli int a 64bit vengono utlizzati solo in crittografia od HPC per il resto ci sono i valori in float che garantiscono una simulazione maggiore dei numeri reali. Gia a 64bit si possono rappresentare integers con range elevatissimi, poi, secondo me, utilizzare gprs per operazioni matematiche non è che sia il massimo, sono gia pochi (quando si possono usare i registri mmx, xmm delle simd, ed addirittura quelli dell'x87)
Sinceramente non penso che con l'IA a 128 bit estenderanno i gprs ad operazioni con le simd, questo soprattuto considerando che con le AVX si avranno vettori a 256bit. Oltrettuto dovrebbero cambiare molte cose nelle architettura, ovvero come esegui operazioni int a 64-32 bit se i gprs vengono occupati da istruzioni SimD? A meno che non si aumentino i gprs totali di cui alcuni di quelli introdotti (ipotetici RAX-EAX17 ad RAX-EAX32 se li radoppiano da 16 a 32) utilizzati solo per quello, e l'os per poterli utilizzare dovrebbe operare in una long mode simile a quella che si utlizza in abiente x64...
Inoltre avere un radoppio dei registri condurrebbe ad uno snellimento del codice, sempre che gli sviluppatori abbiano voglia di "ricompilare" il codice, ovvero meno LOAD e STORE perchè hai più gprs per metterci dentro i dati, quindi anche più velocità.

Portare i registri GPR e le attuali ALU int a 128 bit e renderle SIMD non è poi tutta questa complicazione... Non c'è alcuna penalità ad usare i GPR prima per operazioni normali e poi SIMD. Raddoppiare i registri non so se porti a un grosso vantaggio. Già adesso con 16 GPR, 16 registri SIMD a 128 bit (prossimamente a 256 bit e oltre) non c'è poi tutto questa necessità. Aumentare i regitri GPR o allargare i registri aumenta il tempo di task switch e può aumentare i tempi di cambio di privilegio (una routine IRQ deve salvare almeno i registri che usa prima di sovrascriverli, e se sono a 128 bit ci mette il doppio), quindi non sempre il gioco vale la candela.
Concettualmente rendere SIMD una ALU intera è molto semplice, anche perchè l'addizionatore, ad esempio, è già diviso in blocchi da 8, 16, 32 e 64 bit perchè si usa lo stesso addizionatore per tutte le istruzioni. E' abbastanza banale prendere un addizionatore a 64 bit e dividerlo in 8 addizionatori 8 bit, ad esempio... ;)

[Pihippo]

Portare i registri GPR e le attuali ALU int a 128 bit e renderle SIMD non è poi tutta questa complicazione... Non c'è alcuna penalità ad usare i GPR prima per operazioni normali e poi SIMD. Raddoppiare i registri non so se porti a un grosso vantaggio. Già adesso con 16 GPR, 16 registri SIMD a 128 bit (prossimamente a 256 bit e oltre) non c'è poi tutto questa necessità. Aumentare i regitri GPR o allargare i registri aumenta il tempo di task switch e può aumentare i tempi di cambio di privilegio (una routine IRQ deve salvare almeno i registri che usa prima di sovrascriverli, e se sono a 128 bit ci mette il doppio), quindi non sempre il gioco vale la candela.
Concettualmente rendere SIMD una ALU intera è molto semplice, anche perchè l'addizionatore, ad esempio, è già diviso in blocchi da 8, 16, 32 e 64 bit perchè si usa lo stesso addizionatore per tutte le istruzioni. E' abbastanza banale prendere un addizionatore a 64 bit e dividerlo in 8 addizionatori 8 bit, ad esempio... ;)

Ciao
E' sempre un piacere parlare con te, anche perchè cosi approfondisco\imparo cose di cui prima ne sapevo nulla :D
Comunque per quanto possa essere lungo il task switch verrebbe gestito dall'os prima che una applicazione possa effettivamente richiedere i registri a 128 bit a meno che la cpu non deve fare ping pong perchè l'applicazione in questione vuole sia i gpr a 64 che a 128bit, che, dato lo stato attuale del software è possibile. Questo gia succede con le interruption request in vista x64 a meno che non vi sia solo una linea ma penso ve ne siano 256. Per quanto ne so anche l'adder degli interi deve essere a 128bit quindi bisognerebbe per avere full performance in 128bit inserire nelle alu un adder a 128bit, ed allargare il datapath a 128bit quindi code a 128bit degli issue slot ed anche degli scheduler. Non so se sia complicato o meno ma certo ci vogliono transistor e si avvantaggierebbero poche applicazioni che nel desktop servono poco. Guarda io invece ritengo che più registri sono meglio è, alla fine dei conti 1\3 delle operazioni x86 nei programmi comuni non sono ne di aritmetica ne di logica sono load e Store(ed operazioni di memoria quindi pure con i registri gprs) con eventuale trip verso la ram se per disgrazia il dato\operando non è presente nella cache.

[bjt2]

Ciao
E' sempre un piacere parlare con te, anche perchè cosi approfondisco\imparo cose di cui prima ne sapevo nulla :D
Comunque per quanto possa essere lungo il task switch verrebbe gestito dall'os prima che una applicazione possa effettivamente richiedere i registri a 128 bit a meno che la cpu non deve fare ping pong perchè l'applicazione in questione vuole sia i gpr a 64 che a 128bit, che, dato lo stato attuale del software è possibile. Questo gia succede con le interruption request in vista x64 a meno che non vi sia solo una linea ma penso ve ne siano 256. Per quanto ne so anche l'adder degli interi deve essere a 128bit quindi bisognerebbe per avere full performance in 128bit inserire nelle alu un adder a 128bit, ed allargare il datapath a 128bit quindi code a 128bit degli issue slot ed anche degli scheduler. Non so se sia complicato o meno ma certo ci vogliono transistor e si avvantaggierebbero poche applicazioni che nel desktop servono poco. Guarda io invece ritengo che più registri sono meglio è, alla fine dei conti 1\3 delle operazioni x86 nei programmi comuni non sono ne di aritmetica ne di logica sono load e Store(ed operazioni di memoria quindi pure con i registri gprs) con eventuale trip verso la ram se per disgrazia il dato\operando non è presente nella cache.

Per il task switch esiste una istruzione in linguaggio macchina per salvare tutti i registri. Per passare da un processo a 32 bit a uno a 64 bit (o da uno a 64 a uno ipotetico a 128 bit) la sequenza è <salva stato> (che nella modalità a 32 bit salva solo 32 bit per registro), <passa a modalità 64 bit>, <ripristina stato> (che nella modalità a 64 bit ripristina tutti i 64 bit), e viceversa per passare da un task a 64 bit a uno a 32 bit.

Per quanto riguarda le considerazioni sul data path: sono tutte giuste. E' un piccolo vantaggio avere ALU a 128 bit. Mi viene in mente solo la crittografia oppure l'uso di istruzioni SIMD. Per quanto riguarda l'ALU a 128 bit, si può sempre fare che le addizioni a 128 bit abbiano latenza di due cicli, cosi' da non dover rallentare troppo la pipeline...

[Pihippo]

Per il task switch esiste una istruzione in linguaggio macchina per salvare tutti i registri. Per passare da un processo a 32 bit a uno a 64 bit (o da uno a 64 a uno ipotetico a 128 bit) la sequenza è <salva stato> (che nella modalità a 32 bit salva solo 32 bit per registro), <passa a modalità 64 bit>, <ripristina stato> (che nella modalità a 64 bit ripristina tutti i 64 bit), e viceversa per passare da un task a 64 bit a uno a 32 bit.

Per quanto riguarda le considerazioni sul data path: sono tutte giuste. E' un piccolo vantaggio avere ALU a 128 bit. Mi viene in mente solo la crittografia oppure l'uso di istruzioni SIMD. Per quanto riguarda l'ALU a 128 bit, si può sempre fare che le addizioni a 128 bit abbiano latenza di due cicli, cosi' da non dover rallentare troppo la pipeline...

Ciao
Veramente costruttivo parlare con te. Poi magari anche altri leggendo si potrebbero appassionare a ste cosuccie qui rendendo il thread ancora più interessante.
Ritornando al discorso sul task switch, io non pensavo che esistesse addirittura una istruzione a livello dell'isa che consente ciò e ti ringrazio per averlo specificato.
Per le latenze di un ipotetico ADD r,ri a 128bit secondo me chiederlo in 2 cicli è rallentare troppo la pipeline un add r,ri con operandi a 64bit (e dunque uso di gprs REX-EAX dal 8 in poi sino al 16) richeide 1 ciclo, si avrebbè un aumento del 50% di latenze che per operazioni abbastanza comuni come ADD è troppo.
Se casomai davvero buldozzer dovesse essere a 128bit, con isa a 128bit, mi aspetterei quanto meno che le istruzioni a 128bit richiedano latenze vicine a quelle a 64bit, poi aggiungendoci più gprs ed eliminando altre load e store magari si potrebbe avere un vantaggio consistente, ma di certo non dato da operazioni a 128 bit, magari server ed HPC ringrazieranno il desktop non so quanto.

[bjt2]

Ciao
Veramente costruttivo parlare con te. Poi magari anche altri leggendo si potrebbero appassionare a ste cosuccie qui rendendo il thread ancora più interessante.
Ritornando al discorso sul task switch, io non pensavo che esistesse addirittura una istruzione a livello dell'isa che consente ciò e ti ringrazio per averlo specificato.
Per le latenze di un ipotetico ADD r,ri a 128bit secondo me chiederlo in 2 cicli è rallentare troppo la pipeline un add r,ri con operandi a 64bit (e dunque uso di gprs REX-EAX dal 8 in poi sino al 16) richeide 1 ciclo, si avrebbè un aumento del 50% di latenze che per operazioni abbastanza comuni come ADD è troppo.
Se casomai davvero buldozzer dovesse essere a 128bit, con isa a 128bit, mi aspetterei quanto meno che le istruzioni a 128bit richiedano latenze vicine a quelle a 64bit, poi aggiungendoci più gprs ed eliminando altre load e store magari si potrebbe avere un vantaggio consistente, ma di certo non dato da operazioni a 128 bit, magari server ed HPC ringrazieranno il desktop non so quanto.

Se non mi sbaglio gli mnemonici sono XSAVE e XRESTORE... ;)
Per quanto riguarda la latenza... Io intendevo latenza di 2 cicli solo per la istruzione a 128 bit, lasciando 1 ciclo per quella a 64 bit... Se fosse per me, andrei all'estremo: velocizzerei le pipeline in modo che istruzioni a 8/16/32 bit richiedano un ciclo e istruzioni a 64 bit 2 cicli (ed eventualmente 4 cicli per quelle a 128 bit), cosi' da poter salire ancora di clock... Teoricamente si potrebbe avere il doppio del clock...
Non è conveniente far avere stessa latenza per istruzioni a differente ampiezza, perchè cosi' devi abbassare il clock... Le uniche istruzioni per cui non cambia la latenza sono quelle logiche...

[Pihippo]

Se non mi sbaglio gli mnemonici sono XSAVE e XRESTORE... ;)
Per quanto riguarda la latenza... Io intendevo latenza di 2 cicli solo per la istruzione a 128 bit, lasciando 1 ciclo per quella a 64 bit... Se fosse per me, andrei all'estremo: velocizzerei le pipeline in modo che istruzioni a 8/16/32 bit richiedano un ciclo e istruzioni a 64 bit 2 cicli (ed eventualmente 4 cicli per quelle a 128 bit), cosi' da poter salire ancora di clock... Teoricamente si potrebbe avere il doppio del clock...
Non è conveniente far avere stessa latenza per istruzioni a differente ampiezza, perchè cosi' devi abbassare il clock... Le uniche istruzioni per cui non cambia la latenza sono quelle logiche...

Ciao
Interessante il discorso che fai tu, alla fine non si penalizzerebbe molto nulla e si potrebbe salire di clock che non fa mai male.
Magari potrebbero fare pure cosi, ovvero allungare le lateze di un pochino ma salire molto di clock, che non è male. Chissà cosa sarà davvero buldozer ovvero clock speed alti e latenze un pò maggiorate, oppure latenze molto conservative(basse) ma da i clock speed limitati?
Secondo me intrapenderanno una via di mezzo:)

[bjt2]

Ciao
Interessante il discorso che fai tu, alla fine non si penalizzerebbe molto nulla e si potrebbe salire di clock che non fa mai male.
Magari potrebbero fare pure cosi, ovvero allungare le lateze di un pochino ma salire molto di clock, che non è male. Chissà cosa sarà davvero buldozer ovvero clock speed alti e latenze un pò maggiorate, oppure latenze molto conservative(basse) ma da i clock speed limitati?
Secondo me intrapenderanno una via di mezzo:)

Il processore ideale è quello asincrono, dove ogni dato è processato alla massima velocità possibile e alla fine se è richiesto il ritiro in order delle istruzioni (come nell'architettura x86), è li che avviene il riordinamento.

Per avvicinarsi basterebbe avere un clock molto elevato e ogni operazione fattibile in un multiplo di cicli dove solo l'operazione più semplice di tutte richiede esattamente un ciclo (penso alle AND, OR, XOR, NOT, Shift di un solo bit) e le altre di più... Teoricamente si potrebbe arrivare a svariati GHz.

Però poi si arriva al limite del silicio e quindi ci si accontenta di frequenze di qualche GHz dove le operazioni più semplici ci mettono una frazione di clock per essere completate.

[Pihippo]

Il processore ideale è quello asincrono, dove ogni dato è processato alla massima velocità possibile e alla fine se è richiesto il ritiro in order delle istruzioni (come nell'architettura x86), è li che avviene il riordinamento.

Per avvicinarsi basterebbe avere un clock molto elevato e ogni operazione fattibile in un multiplo di cicli dove solo l'operazione più semplice di tutte richiede esattamente un ciclo (penso alle AND, OR, XOR, NOT, Shift di un solo bit) e le altre di più... Teoricamente si potrebbe arrivare a svariati GHz.

Però poi si arriva al limite del silicio e quindi ci si accontenta di frequenze di qualche GHz dove le operazioni più semplici ci mettono una frazione di clock per essere completate.

Ciao
Come sempre spunti molto interassanti di discussione.
Penso, sottolineo penso, che quello che chiedi tu è non sia il processore ideale per quelli pipelined, mi spiego:
Se ogni istruzione fosse un multiplo esatto di un altra istruzione, si potrebbero avrebbero le temutissime bolle nella pipeline che sono quelle che ammazzano un pò tutta l'idea di base di avere pipeline. Mettiamo caso che ho una pipeline con 4 issue slot, mi arrivano 4 istruzioni e io pipeline sono contento perchè posso operare al massimo, nello specifico, per culo o miracolo del compiler queste istruzioni non hanno nessun input di dipendenza e quindi le posso processare come mi piace (out of order), sono 2 ADD r,ri un LEA + JMP
ADD mi richiede 2 cicli, LEA mi richiede 4 cicli ed il JMP 2 cicli(magari..) inizio col lea perchè è una operazione di memoria e sono quelle che rompono di più c"£$0ni, inizio ad eseguirla e siccome sono una pipeline fortunata e c'ho 4 issue slot pieni con operazioni indipendenti il ciclo dopo inizio l'add mentre la LEA è ancora in pipeline( e ci mancano 2 cicli) clock successivo mi inizio l'altro ADD r,ri, ma catastrofe a al prossimo inizio di clock ho 2 operazioni completate, siccome non posso salvarle nel retirement buffer mi stallo e le blocco nello stage di pipeline che sono arrivate. E questo nel caso migliore, ovviamente la pipeline si stalla anche se per esempio l'add ha bisogno del risultato del lea per essere completato.
Ovviamente ciò a mia opinione, cosa ne pensi?

[bjt2]

Ciao
Come sempre spunti molto interassanti di discussione.
Penso, sottolineo penso, che quello che chiedi tu è non sia il processore ideale per quelli pipelined, mi spiego:
Se ogni istruzione fosse un multiplo esatto di un altra istruzione, si potrebbero avrebbero le temutissime bolle nella pipeline che sono quelle che ammazzano un pò tutta l'idea di base di avere pipeline. Mettiamo caso che ho una pipeline con 4 issue slot, mi arrivano 4 istruzioni e io pipeline sono contento perchè posso operare al massimo, nello specifico, per culo o miracolo del compiler queste istruzioni non hanno nessun input di dipendenza e quindi le posso processare come mi piace (out of order), sono 2 ADD r,ri un LEA + JMP
ADD mi richiede 2 cicli, LEA mi richiede 4 cicli ed il JMP 2 cicli(magari..) inizio col lea perchè è una operazione di memoria e sono quelle che rompono di più c"£$0ni, inizio ad eseguirla e siccome sono una pipeline fortunata e c'ho 4 issue slot pieni con operazioni indipendenti il ciclo dopo inizio l'add mentre la LEA è ancora in pipeline( e ci mancano 2 cicli) clock successivo mi inizio l'altro ADD r,ri, ma catastrofe a al prossimo inizio di clock ho 2 operazioni completate, siccome non posso salvarle nel retirement buffer mi stallo e le blocco nello stage di pipeline che sono arrivate. E questo nel caso migliore, ovviamente la pipeline si stalla anche se per esempio l'add ha bisogno del risultato del lea per essere completato.
Ovviamente ciò a mia opinione, cosa ne pensi?

Ovviamente sarebbe peggiorativo se il clock fosse lo stesso. Ma spezzettando l'istruzione si potrebbero avere clock più elevati. Quindi pipeline più lunghe. Ma ciò poi ci porta all'incubo del pentium 4: i salti... Per fare questo con pipeline corte, si dovrebbero introdurre unità più complesse che facciano le varie operazioni con latenze di clock diverse, ovviamente fatte in modo che il clock possa essere elevato. Ma ciò porta a una notevole complicazione: un conto è un addizionatore che fa tutte le addizioni in un solo ciclo, anche se "lungo". Un conto è un addizionatore che fa le addizioni ad 8 bit in un ciclo, quelle a 16 in due, anche se il ciclo è molto più corto... Oltre ad essere più complesso, il clock dovrebbe essere velocissimo per avere velocità comparabili al caso precedente... Questo probabilmente porterebbe a grosse dissipazioni...

[gervi]

scusate se lo chiedo, ma non 'è ancora il topic

"aspettando sandy bridge di intel" ???

Poichè sarà l'architettura concorrente du bulldozer???

[capitan_crasy]

scusate se lo chiedo, ma non 'è ancora il topic

"aspettando sandy bridge di intel" ???

Poichè sarà l'architettura concorrente du bulldozer???

Lascio ad altri l'onore di aprire e gestire il thread su Sandybridge...

[Pihippo]

Ovviamente sarebbe peggiorativo se il clock fosse lo stesso. Ma spezzettando l'istruzione si potrebbero avere clock più elevati. Quindi pipeline più lunghe. Ma ciò poi ci porta all'incubo del pentium 4: i salti... Per fare questo con pipeline corte, si dovrebbero introdurre unità più complesse che facciano le varie operazioni con latenze di clock diverse, ovviamente fatte in modo che il clock possa essere elevato. Ma ciò porta a una notevole complicazione: un conto è un addizionatore che fa tutte le addizioni in un solo ciclo, anche se "lungo". Un conto è un addizionatore che fa le addizioni ad 8 bit in un ciclo, quelle a 16 in due, anche se il ciclo è molto più corto... Oltre ad essere più complesso, il clock dovrebbe essere velocissimo per avere velocità comparabili al caso precedente... Questo probabilmente porterebbe a grosse dissipazioni...

Ciao
Hai perfettamente ragione, per implementare un sistema cosi ci dovrebbero spendere parecchi transistor con conseguente aumento del die, consumi maggiori e temperature maggiori, sembra che tutte le architetture debbano fare un compromesso tra IPC clock ed ovviamente consumi, però sarebbè bello avere un ipotetico procio che non stalla mai e viaggia a clock pazzeschi. :D
Oppure potrebbero fare anche cosi, si utilizza come core di base i k10 che per quanto sfigati hanno una buona efficienza di base, tweakkarli in modo da essere anche leggermente (10-15%) più efficienti, magari migliorare l'unità dei salti allungare un pò la pipeline e farlo girare questo ipotetico bulldozer a 5ghz e più :D

[bjt2]

Ciao
Hai perfettamente ragione, per implementare un sistema cosi ci dovrebbero spendere parecchi transistor con conseguente aumento del die, consumi maggiori e temperature maggiori, sembra che tutte le architetture debbano fare un compromesso tra IPC clock ed ovviamente consumi, però sarebbè bello avere un ipotetico procio che non stalla mai e viaggia a clock pazzeschi. :D
Oppure potrebbero fare anche cosi, si utilizza come core di base i k10 che per quanto sfigati hanno una buona efficienza di base, tweakkarli in modo da essere anche leggermente (10-15%) più efficienti, magari migliorare l'unità dei salti allungare un pò la pipeline e farlo girare questo ipotetico bulldozer a 5ghz e più :D

Mi è venuta in mente una soluzione alternativa, che non richiede stravolgimenti: la vettorizzazione automatica. Mi spiego:
Supponiamo che tutte le ALU a 64 bit intere siano fatte in modo da poter fare anche 2 operazioni a 32 bit in parallelo. Con un po' di logica in più si potrebbero accorpare istruzioni uguali su dati diversi e farle in parallelo, mantenendo unità con latenze da 1 cliclo su tutte le istruzioni. E' una complicazione a livello di dispatch e ritiro, ma potrebbe aumentare le prestazioni. A maggior ragione con ALU a 128 bit e magari sfruttando anche le ALU SSE che sono nella FPU...

[Pihippo]

Mi è venuta in mente una soluzione alternativa, che non richiede stravolgimenti: la vettorizzazione automatica. Mi spiego:
Supponiamo che tutte le ALU a 64 bit intere siano fatte in modo da poter fare anche 2 operazioni a 32 bit in parallelo. Con un po' di logica in più si potrebbero accorpare istruzioni uguali su dati diversi e farle in parallelo, mantenendo unità con latenze da 1 cliclo su tutte le istruzioni. E' una complicazione a livello di dispatch e ritiro, ma potrebbe aumentare le prestazioni. A maggior ragione con ALU a 128 bit e magari sfruttando anche le ALU SSE che sono nella FPU...

Ciao.
Molto interessante questa proposta. Alu simd like possono essere molto più efficienti quando c'è un minimo di parallelismo nel codice ( ed i compilernon sono taroccati :D)
In effetti penso anche io che bisognerebbe "potenziare" un pochetto di più gli scheduler vari e le dispatch unit. Le prestazioni auemnterebbero di sicuro, utilizzare una alu che esegue due operazioni in parallelo potrebbe pure evitare stalli che sprecano performance, comunque in vista di questa tua idea che a me piace moltissimo, e visto che di bjt2 te ne intendi :D, ciò , non vorrebbe dire a fronte di una maggiore complessità di logica si avrebbero anche clock minori? Cioè pensavo che le parti di logica dei core sono quelle più "sensibili" e magari a clock alti schiattano prima delle pipeline e delle cache o sbaglio? Non vorrei che bulldozer se magari fosse cosi come ipotizziamo sia un k10 a 65nm v2 ovvero buona architettura di base ma che non saliva manco pregando in aramaico.

[bjt2]

Ciao.
Molto interessante questa proposta. Alu simd like possono essere molto più efficienti quando c'è un minimo di parallelismo nel codice ( ed i compilernon sono taroccati :D)
In effetti penso anche io che bisognerebbe "potenziare" un pochetto di più gli scheduler vari e le dispatch unit. Le prestazioni auemnterebbero di sicuro, utilizzare una alu che esegue due operazioni in parallelo potrebbe pure evitare stalli che sprecano performance, comunque in vista di questa tua idea che a me piace moltissimo, e visto che di bjt2 te ne intendi :D, ciò , non vorrebbe dire a fronte di una maggiore complessità di logica si avrebbero anche clock minori? Cioè pensavo che le parti di logica dei core sono quelle più "sensibili" e magari a clock alti schiattano prima delle pipeline e delle cache o sbaglio? Non vorrei che bulldozer se magari fosse cosi come ipotizziamo sia un k10 a 65nm v2 ovvero buona architettura di base ma che non saliva manco pregando in aramaico.

Queste complicazioni aggiungono solo transistors. Non dovrebbero impattare più di tanto sul consumo...

[capitan_crasy]

Il sito X-bit labs pubblica delle dichiarazioni di Dirk Meyer (CEO AMD) sulle prossime CPU+GPU in uscita nel 2011.
Meyer dice chiaramente che le prossime APU nome in codice Llano, primo chip ad utilizzare la tecnologia "Fusion", saranno realizzati utilizzando la tecnologia produttiva 32nm SOI (silicon-on-insulator).
Finalmente ci sono le prime conferme di una GPU pensata e costruita con lo stesso silicio utilizzato per la produzione delle CPU AMD.
Per il momento non si sa se tale GPU compatibile con le DX 11 sia un RV8x0 ridisegnato oppure derivi da un nuovo progetto.
Il sito conclude che con tutta probabilità sarà usato una CPU con architettura K10 con tecnologia produttiva a 32nm; tuttavia nessuno smentisce che la parte X86 delle APU Llano sia basata sull'architettura Bulldozer prevista anch'essa nel 2011 con tecnologia produttiva a 32nm SOI.

Clicca qui... (http://www.xbitlabs.com/news/cpu/display/20091015173531_AMD_s_First_Fusion_Processors_to_Be_Made_Using_32nm_SOI_Process_Technology_CEO.html)

[capitan_crasy]

Ti vedo in difficoltà nel trovare collocazione a queste news. Forse questo thread è nato un po' troppo presto :D

Ti spiego:
Il primo Fusion dalle ultime fonti ufficiali, è basata sull'architettura Bulldozer; ora però ci sono molti che avanzano l'ipotesi che Llano sia basato sul K10 Quad core a 32nm...
Aspettando dichiarazioni ufficiali da parte AMD (sarebbe anche ora che comunicasse i dettagli su Fusion e Bulldozer) ho pubblicato questa notizia su entrambi i thread ufficiali...
Dopo tutto per ora questo thread si basa non su notizie ufficiali, ma su voci e brevetti AMD...;)

[capitan_crasy]

Io ho i miei dubbi, ma possiamo sempre sperarci :help: :muro:


Ipotizzo qualcosa di molto interessante alla fine dell'anno dove AMD dovrebbe presentare una demo funzionante della tecnologia Fusion...

[capitan_crasy]

Il sito OCW pubblica una nuova roadmap di AMD dove vendono elencate alcune caratteristiche del core Zambezi basato sulla nuova architettura Bulldozer:

http://www.pctunerup.com/up/results/_200910/20091019194721_6x4thuban002a.JPG

http://www.pctunerup.com/up/results/_200910/20091019194742_6x4thuban002.jpg

Le CPU a 32nm saranno disponibile in modelli da 4 e 8 core con cache L3 da 8MB, controller di memoria DDR3 @ 1866Mhz; il socket sarà il misterioso socket AM3r2.
Le prime CPu Bulldozer sono attese per il 2011.
Per quanto riguarda il core Llano saranno disponibili CPU da 2 e 4 core con GPU compatibile DX11, supporto alle memorie DDR3 @ 1600 e per la prima volta appare un nuovo socket chiamato PM1.
Anche questa CPU o meglio APU è attesa per il 2011!

Clicca qui... (http://forums.ocworkbench.com/showthread.php?p=453733#post453733)

[sniperspa]

Speriamo che almeno il famoso soket AM3r2 sia compatibile con i normali AM3 anche se la vedo dura...

[MonsterMash]

Da quella roadmap sembrerebbe che tutto il 2010 sia affidato unicamente a thuban. Nessuna novità neanche nella altre fasce di mercato.

[capitan_crasy]

Da quella roadmap sembrerebbe che tutto il 2010 sia affidato unicamente a thuban. Nessuna novità neanche nella altre fasce di mercato.

Infatti non è previsto niente di eclatante, ma anche la roadmap di un anno fa non prevedeva Thuban...
L'unica vera novità nel 2010, 6 core a parte, potrebbe essere un K10 a 32nn...

[Efic]

speriamo almeno in questo:)

[frai17]

io mi aguro che AM3r2 sia qualcosa di molto simile a quello che è successo con il passaggio da AM2 a AM2+ cioè processori compatibili e qualche nuova carattaristica a cui rinunciare.

per quel che riguarda i processori con GPU integrata il cambio di socket mi sembra forzato non fosse altro che alcune schede madri AM3 non hanno nemmeno l'uscita VGA e quindi... poi vedremo che farà intel visto che con il 1156 dovrebbe trovarsi nella stessa identica situazione

[-Maxx-]

io mi aguro che AM3r2 sia qualcosa di molto simile a quello che è successo con il passaggio da AM2 a AM2+ cioè processori compatibili e qualche nuova carattaristica a cui rinunciare.

per quel che riguarda i processori con GPU integrata il cambio di socket mi sembra forzato non fosse altro che alcune schede madri AM3 non hanno nemmeno l'uscita VGA e quindi... poi vedremo che farà intel visto che con il 1156 dovrebbe trovarsi nella stessa identica situazione

IMHO AM3r2 sa molto di AM3+ per il futuro ;)

[sniperspa]

IMHO AM3r2 sa molto di AM3+ per il futuro ;)

sarebbe una manna :sperem:

[capitan_crasy]

Mi pare che la risposta sia chiara e non fraintendibile...

:read: :read:

Da dove sbuca questa "dichiarazione"?

Edit:

Trovato!!!

Clicca qui... (http://www.semiaccurate.com/forums/showpost.php?p=9917&postcount=86)

[Doom_94]

La roadmap in verde è un falso:



:asd:
Bella! Photoshop:asd: ma chi è John Fruehe???

[capitan_crasy]

La roadmap in verde è un falso:



:asd:

Non è proprio un falso, quella roadmap è stata creata dal sito 4gamer.net, la quale è stata utilizzata per commentare un articolo su Bulldozer...
La sua unica colpa è che qualcuno (OCW) la spacciata come Roadmad originale AMD...

Director of Business Development for Server and Workstation products

Conferma anche che il target è attualmente di far si che le CPU server basate su core Buldozer siano compatibili con i nuovi socket che verranno presentati ufficialmente per Magny-Cours (la parola usata è "dovrebbe")

La cosa non mi sorprende; anzi la compatibilità tra la piattaforma Maranello/San Marino e Bulldozer è in Roadmap AMD...

http://img231.imageshack.us/img231/8026/clip7y.jpg

[X-Wanderer]

complimenti per il thread capitan :)
una domandina però: in questo stesso thread informerai anche sui futuri chipset 8tipo 890fx7gx ecc...) o si tratta di un thread più indirizzato ai processori?

[capitan_crasy]

complimenti per il thread capitan :)
una domandina però: in questo stesso thread informerai anche sui futuri chipset 8tipo 890fx7gx ecc...) o si tratta di un thread più indirizzato ai processori?

Questo non è il thread giusto...
I nuovi chipset AMD serie 800 sono per la piattaforma LEO, quindi per CPU K10.
Per le CPU bulldozer non ci sono ancora informazioni sui chipset utilizzati per la piattaforma "Scorpius"...

[X-Wanderer]

scusaaaaaa!!!! hai perfettamente ragione, è che leggendo in questo thread, fatto molto bene per giunta, me ne ero dimenticato... :D
però ho notato che thread appositit per chipset in arrivo non ce ne sono, o sbaglio?
cmq speriamo che faccian faville eh?!! :) sarebbe ora....
cmq leggevo un tuo post su un ipotetico k10 a 32nm, un phenomII se non sbaglio... a tuo parere è plausibile (magari per la nuova piattaforma leo, scusa ancora l'OT tremendo :D )?!
però cm hai fatto notare tu, le aspettative maggiori ci saranno con bulldozer, visto che leo non è poi così tanto un'innovazione... chissà i proci poi :D

[capitan_crasy]

scusaaaaaa!!!! hai perfettamente ragione, è che leggendo in questo thread, fatto molto bene per giunta, me ne ero dimenticato... :D
però ho notato che thread appositit per chipset in arrivo non ce ne sono, o sbaglio?
cmq speriamo che faccian faville eh?!! :) sarebbe ora....
cmq leggevo un tuo post su un ipotetico k10 a 32nm, un phenomII se non sbaglio... a tuo parere è plausibile (magari per la nuova piattaforma leo, scusa ancora l'OT tremendo :D )?!
però cm hai fatto notare tu, le aspettative maggiori ci saranno con bulldozer, visto che leo non è poi così tanto un'innovazione... chissà i proci poi :D

Se ci sono novità aggiorno il thread del K10; quando usciranno credo che ci sarà un thread ufficiale... ;)
Comunque sia i nuovo chipset AMD avranno come novità più sostanziale i southbridge SB850 e SB810; mentre i northbridge saranno sostanzialmente uguali a quelli attuali...

[X-Wanderer]

e per quanto riguarda un possible procio phenomII a 32nm si sa niente, o sono solo voci?!
cmq grazie ancora cm al solito!:)

[Vash_85]

Se ci sono novità aggiorno il thread del K10; quando usciranno credo che ci sarà un thread ufficiale... ;)
Comunque sia i nuovo chipset AMD avranno come novità più sostanziale i southbridge SB850 e SB810; mentre i northbridge saranno sostanzialmente uguali a quelli attuali...

Ma i nb non stanno nella cpu?:mbe: :mbe:

[capitan_crasy]

e per quanto riguarda un possible procio phenomII a 32nm si sa niente, o sono solo voci?!
cmq grazie ancora cm al solito!:)

Sono solo voci...
Ma AMD prima o poi deve cominciare a sviluppare i 32nm e utilizzare un die shrink del K10 è la soluzione più ovvia ed economica...

Ma i nb non stanno nella cpu?:mbe: :mbe:

Il Northbridge delle CPU è una cosa, mentre i Northbridge delle schede mamme (o chipset) sono un altra cosa...

[capitan_crasy]

Questo lo penso anche io, ma il nostro amico "server guy" di AMD sostiene che non è così semplice come la mettiamo noi e che quando fai un nuovo progetto la scelda del nodo su cui farlo dipende da scelte di carattere economico. Dice che il tick tock di Intel è solo marketing, perché quando hai una CPU a 45nm se devi portarla a 32nm la devi ridisegnare completamente...

Io continuo a puntare su un K10 a 32nm :D

Che non è così semplice come noi la pensiamo sono d'accordo, ma sicuramente è più semplice partire da un architettura con anni di esperienza piuttosto che puntare subito su Bulldozer...:)

[capitan_crasy]

Non sono sicuro della fonte ma secondo il sito modlabs.net questa dovrebbe essere la prima immagine di Bulldozer:

http://www.pctunerup.com/up/results/_200910/20091030215349_bulldozer_dieshot.jpg

La parola agli esperti...

Clicca qui... (http://translate.google.com/translate?hl=it&sl=ru&tl=en&u=http%3A%2F%2Fwww.modlabs.net%2FAMD_Bulldozer_vosmiyadernoe_buduschee)

[Efic]

Non sono sicuro della fonte ma secondo il sito modlabs.net questa dovrebbe essere la prima immagine di Bulldozer:

http://www.pctunerup.com/up/results/_200910/20091030215349_bulldozer_dieshot.jpg

La parola agli esperti...

Clicca qui... (http://translate.google.com/translate?hl=it&sl=ru&tl=en&u=http%3A%2F%2Fwww.modlabs.net%2FAMD_Bulldozer_vosmiyadernoe_buduschee)

non sono un esperto..... ma sembra un dual core:oink:

[capitan_crasy]

non sono un esperto..... ma sembra un dual core:oink:

In realtà, teoricamente, quello che vediamo nella foto dovrebbe essere considerato un solo core anche se fisicamente ci saranno due core...
Questa dovrebbe rappresentare l'idea del HyperThreading AMD composto anche dal "Reverse HyperThreading"...

[X-Wanderer]

in che modo funzionerebbe questo reverse hyper threading?!

[capitan_crasy]

in che modo funzionerebbe questo reverse hyper threading?!

Preso dalla prima pagina, 5° post...


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.

[mack.gar]

Non sono sicuro della fonte ma secondo il sito modlabs.net questa dovrebbe essere la prima immagine di Bulldozer:

http://www.pctunerup.com/up/results/_200910/20091030215349_bulldozer_dieshot.jpg

La parola agli esperti...

Clicca qui... (http://translate.google.com/translate?hl=it&sl=ru&tl=en&u=http%3A%2F%2Fwww.modlabs.net%2FAMD_Bulldozer_vosmiyadernoe_buduschee)

Ciao a tutti!
Imho la foto sembra un vecchio k8 dual core cioè un a64x2... come sembra dalla disposizione dei blocchi funzionali: http://www.chip-architect.com/news/AMD_family_pic.jpg
Se prendiamo per buono lo schema di dresden boy basato su brevetti amd, dovrebbe esserci una sola cache L1 istruzioni (ma due L1 dati) mentre dalla foto si vede una iL1 per "core". Idem per il front end...

[marco XP2400+]

Ciao a tutti!
Imho la foto sembra un vecchio k8 dual core cioè un a64x2... come sembra dalla disposizione dei blocchi funzionali: http://www.chip-architect.com/news/AMD_family_pic.jpg
Se prendiamo per buono lo schema di dresden boy basato su brevetti amd, dovrebbe esserci una sola cache L1 istruzioni (ma due L1 dati) mentre dalla foto si vede una iL1 per "core". Idem per il front end...
mi raccomando questo è il primo post gli altri o di questo livello o superiore!!!
grazie della risposta!

[Judicator]

Chiedo scusa in anticipo se è un rumor già riportato:

ATI Ontario 40nm Fusion has Bobcat core Print E-mail
Written by Fuad Abazovic
Thursday, 05 November 2009 16:52



Image

Native 40nm bulk CPU

Back in September we mentioned that AMD has a mainstream Fusion part called Ontario. This is an APU, or accelerated processing unit that should bring a dual-core CPU and a DirectX 11 graphics core together.

We just recently found out some rather good news, Ontario in its 40nm won’t be based on Phenom / Athlon K10.5 45nm shrunk core. Originally we were thinking that AMD will simply take its dual-core in 45nm and will shrink it to 40nm bulk process, but we found out that the dual-core in that product is going to be Bobcat, a low-power dual core.

Bobcat was rumored to have one to 10W TDP and if you think about it, this guy will definitely go after Intel’s Atom. With its latest N4x0 series of Atoms, Intel already put graphics on the same chip, but if AMD does the job well, Ontario will be an all-integrated CPU plus GPU.

The only bad thing is that it is coming in 2011. Interestingly enough we wrote that such thing is coming back in 2007.

[capitan_crasy]

Dato che le prime APU AMD saranno basate sull'architettura K10, questo thread aggiorna i suoi obbiettivi.
Questa discussione sarà incentrata sulle future CPU/APU a 40nm bulk e 32nm SOI indipendentemente dall'architettura utilizzata; ciò significa che un eventuale K10 @ 32nm sarà discusso in questo thread...
Per le attuali/future CPU a 45nm rimane il Thead K10 V.4 come punto di riferimento...

[X-Wanderer]

be' allora speriamo tanto che AMD ci dia la possibilità di discutere anche di un K10 32nm :D
cmq bene capitano, speriamo che questo thread faccia faville...

[Ren]

Non riguarda direttamente AMD, ma emergono alcuni dettagli sulla pipeline AVX 256bit della prossima architettura Intel.

Molti pensavano ad un esecuzione simile alla prima revision delle SSE, cioè in due cicli di clock con unità a 64bit, invece l'approccio sarà differente.

Le unità saranno davvero da 256bit, compreso il LOAD & STORE, come da schema hanno intenzione di aumentare il bus verso la cache a 384bit.

http://aceshardware.freeforums.org/download/file.php?id=5&sid=6b43d5b9a78f66b79a1a581c8235f453

[greeneye]

Non è perfettamente IT ma fudzilla pubblica delle foto di uno dei primi wafer a 32 nm di Globalfoundries.

http://www.fudzilla.com/content/view/16343/1/

[capitan_crasy]

Non riguarda direttamente AMD, ma emergono alcuni dettagli sulla pipeline AVX 256bit della prossima architettura Intel.

Molti pensavano ad un esecuzione simile alla prima revision delle SSE, cioè in due cicli di clock con unità a 64bit, invece l'approccio sarà differente.

Le unità saranno davvero da 256bit, compreso il LOAD & STORE, come da schema hanno intenzione di aumentare il bus verso la cache a 384bit.

http://aceshardware.freeforums.org/download/file.php?id=5&sid=6b43d5b9a78f66b79a1a581c8235f453

Grazie per la segnalazione! (ogni tanto non mi arriva la mail per i nuovi post:muro: )

Non è perfettamente IT ma fudzilla pubblica delle foto di uno dei primi wafer a 32 nm di Globalfoundries.

http://www.fudzilla.com/content/view/16343/1/

FUDZILLA non si smentisce; foto già vista qualche mese fa...

[Pihippo]

Non riguarda direttamente AMD, ma emergono alcuni dettagli sulla pipeline AVX 256bit della prossima architettura Intel.

Molti pensavano ad un esecuzione simile alla prima revision delle SSE, cioè in due cicli di clock con unità a 64bit, invece l'approccio sarà differente.

Le unità saranno davvero da 256bit, compreso il LOAD & STORE, come da schema hanno intenzione di aumentare il bus verso la cache a 384bit.

http://aceshardware.freeforums.org/download/file.php?id=5&sid=6b43d5b9a78f66b79a1a581c8235f453

Ciao
Molto interessante come notizia. Non se avranno cambiato anche il front end, ma con un front end adeguato, ad esempio ciclo di fetch a 32bit e decode cache sandy bridge si presenta come una architettura molto veloce in Fp. Conferma che load e store in fp vengono eseguiti a 256bit quindi il procio potrà recuperare e salvare dati\operandi con un ciclo di clock per vettori a 256bit. Che non è da sottovalutare visto che un buon 40% delle istruzioni presenti nei normali programmi o giochini sono load e store.

[capitan_crasy]

AMD ha mostrato la sua Roadmap ufficiale sulla piattaforma "Scorpius" al Financial Analyst Day 2009.

http://www.pctunerup.com/up/results/_200911/th_20091111183347_ScreenHunter_110.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111183347_ScreenHunter_110.jpg)

Secondo la slide il core Zambezi da 4/8core sarà su architettura Bulldozer e basato sul socket AM3.
I Chipset dovrebbero essere gli stessi della piattaforma LEO, cioè la serie AMD8x0+SB8X0, previsti per il 2010.

[capitan_crasy]

Signori, sembra proprio che AMD abbia portato al Financial Analyst Day una demo funzionante della sua APU, la quale sarà la base del futuro core Llano, prima CPU+GPU AMD....:D

[capitan_crasy]

http://www.pctunerup.com/up/results/_200911/th_20091111194734_ScreenHunter_117.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111194734_ScreenHunter_117.jpg)

Aggiornamento:

http://www.pctunerup.com/up/results/_200911/th_20091112010831_ScreenHunter_130.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091112010831_ScreenHunter_130.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091112010859_ScreenHunter_132.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091112010859_ScreenHunter_132.jpg)

[sniperspa]

Signori, sembra proprio che AMD abbia portato al Financial Analyst Day una demo funzionante della sua APU, la quale sarà la base del futuro core Llano, prima CPU+GPU AMD....:D

C'è qualche video o foto che gira?:eek:

edit:non avevo visto l'ultimo post..

[okorop]

Signori, sembra proprio che AMD abbia portato al Financial Analyst Day una demo funzionante della sua APU, la quale sarà la base del futuro core Llano, prima CPU+GPU AMD....:D

bene bene spero che esca presto :)

per quanto riguarda buldozzer integrerà anch'esso il nb, e cache l2 ed l3 condivise al contrario di intel i7
io la sparo 2mb di cache l2 per core e 30 mb di cache l3

[mack.gar]

http://www.pctunerup.com/up/results/_200911/th_20091111194734_ScreenHunter_117.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111194734_ScreenHunter_117.jpg)
Per ora non ho altre informazioni...

Slide intrigante... finalmente qualcosa di certo da parte di AMD sull'architettura di bulldozer! Sembra confermato a grandi linee lo schema di dresden boy... anche se quelle "pipeline" possono voler dire qualsiasi cosa. Possono essere le solite 2x(agu + alu) o 4 unità si esecuzione generiche:confused: . Nessuna info nemmeno sulla eventuale cache o buffer prima delle unità di esecuzione e sulla lunghezza della pipe... mi sa che le cose più succose sono quelle che non dicono :cry:
La cosa più bella è nella slide sul 3d del k10 in cui dice che bulldozer sarà consegnato in prova ai parter già nel 2010... quindi dovrebbero essere ok coi tempi che si sono dati...

[mack.gar]

:ave: al capitano sulle news in anteprima!
Ho trovato questo:
http://www.semiaccurate.com/forums/showthread.php?t=1076
occhio al bobcat e Jfamd: "Call it a "bulldozer module" for now. There will be a fancier marketing name coming in the future. Don't call it CMT, we aren't using that phrase"

[Ren]

Finalmente abbiamo la conferma che dresdenboy aveva colto nel segno.
I brevetti coincidono perfettamente.

Ultimamente mi era venuto il dubbio che amd volesse solo adattare l'architettura Stars alle SSE5, invece hanno finalmente rischiato con qualcosa di nuovo.


Capitano hai anche le altre slide del Financial day ?

[Ren]

Hanno partorito anche una versione denominata Bobcat, con un singolo cluster intero che assomiglia come numero di unità funzionali al "Nano" di VIA.

L'avversario di Atom è finalmente giunto.

[capitan_crasy]

Finalmente abbiamo la conferma che dresdenboy aveva colto nel segno.
I brevetti coincidono perfettamente.

Ultimamente mi era venuto il dubbio che amd volesse solo adattare l'architettura Stars alle SSE5, invece hanno finalmente rischiato con qualcosa di nuovo.


Capitano hai anche le altre slide del Financial day ?

Eccole...;)

http://www.pctunerup.com/up/results/_200911/th_20091111212323_ScreenHunter_118.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212323_ScreenHunter_118.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111212549_ScreenHunter_119.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212549_ScreenHunter_119.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111212617_ScreenHunter_120.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212617_ScreenHunter_120.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111212643_ScreenHunter_121.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212643_ScreenHunter_121.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111212707_ScreenHunter_122.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212707_ScreenHunter_122.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111212822_ScreenHunter_123.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212822_ScreenHunter_123.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111212947_ScreenHunter_124.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111212947_ScreenHunter_124.jpg)

[Ren]

Hai per caso il PDF ?

Scusami se rompo...

[capitan_crasy]

Hai per caso il PDF ?

Scusami se rompo...

Chiedi e ti sarà dato!:D
Clicca qui... (http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9MjAzMTl8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1)

[X-Wanderer]

buonasera a tutti :)
be' che dire...intanto complimenti al capitano che le azzecca sempre tutte :D
poi non posso che essere contento di tutto ciò, anche perchè ho aspettato apposta ad aggiornare il mio trabiccolo...quindi mi ritengo contento :)
speriamo bene per AMD...

[capitan_crasy]

Ecco le prime immagini del DIE della APU AMD, prima in assoluto costruita con tecnologia FUSION.

http://www.pctunerup.com/up/results/_200911/20091111221956_ScreenHunter_126.jpg

Si nota molto chiaramente che tale APU è un Quad core...

[X-Wanderer]

e cosa sarebbe scusa capitano questa ALU?? :confused:

[capitan_crasy]

e cosa sarebbe scusa capitano questa ALU?? :confused:

:doh:
Cacchio...
volevo dire APU (Accelerated Processing Unit)

[capitan_crasy]

http://www.pctunerup.com/up/results/_200911/th_20091111224936_ScreenHunter_127.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111224936_ScreenHunter_127.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111225008_ScreenHunter_128.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111225008_ScreenHunter_128.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091111225055_ScreenHunter_129.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111225055_ScreenHunter_129.jpg)

[capitan_crasy]

http://www.pctunerup.com/up/results/_200911/th_20091112010831_ScreenHunter_130.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091112010831_ScreenHunter_130.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091112010859_ScreenHunter_132.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091112010859_ScreenHunter_132.jpg)

[checo]

la curiosità sale :D

[MonsterMash]

Wow, quante novità :D.
Ma ho visto in una slide una roadmap che mette i 32nm già a metà 2010, e i 28nm nel Q3 2010! Non sono date più vicine di quello che si pensava? O forse si riferiscono alla produzione di tipo bulk?
Inoltre conferma che i processi produttivi a 32 e a 28nm utilizzeranno l'high k metal gate.

[capitan_crasy]

Edit

[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...
http://www.pctunerup.com/up/results/_200911/th_20091111183737_ScreenHunter_116.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111183737_ScreenHunter_116.jpg)

Clicca qui... (http://www.xbitlabs.com/news/cpu/display/20091111143547_AMD_Displays_Llano_Die_4_x86_Cores_480_Stream_Processors.html)

[Athlon 64 3000+]

Capitano ieri avevi detto che Liano sarebbe stato basato sul core Buldozzer e non su K10 per via della slide di ieri,mentre oggi ritorni a dire che sarà basato di nuovo su K10.
Faccio a fatica capire Liano su che architettura sarà basato.

[Ren]

Si evince dalle foto del die che sarà basato sul core propus, ossia il K10 senza L3.
Probabilmente il passaggio dalle librerie di TSMC alle proprie, comporta delle difficoltà, quindi prefioriscono un design cpu già rodato.

Bulldozer arriverà più in la di fusion, probabilmente prima nel settore Server, verso il 2011.

[capitan_crasy]

Ma Propus non è quello senza cache?

Rick Bergman, (vice presidente di qualcosa e general manager AMD) ha dichiarato che i core X86 di Llano assomigliano a quelli di Propus, che volendo essere pignoli sono uguali a quelli di Deneb...
L'elemento cache L3 è comunque un componente indipendente dalla struttura dei core...

Capitano ieri avevi detto che Liano sarebbe stato basato sul core Buldozzer e non su K10 per via della slide di ieri,mentre oggi ritorni a dire che sarà basato di nuovo su K10.
Faccio a fatica capire Liano su che architettura sarà basato.
Errore mio, ti chiedo scusa!
Purtroppo ho tradotto male una piccola parte di alcune dichiarazioni ufficiali.
Confermo che Llano sarà basato sull'architettura K10 a 32nm per quanto riguarda i core X86...



Si evince dalle foto del die che sarà basato sul core propus, ossia il K10 senza L3.
Probabilmente il passaggio dalle librerie di TSMC alle proprie, comporta delle difficoltà, quindi prefioriscono un design cpu già rodato.

Bulldozer arriverà più in la di fusion, probabilmente prima nel settore Server, verso il 2011.

Llano sarà costruito con i 32nm SOI e avrà una cache L3, su questo nè sono sicuro...
APU costruita con silicio bulk TSMC 40nm (e forse di GF) sarà "Ontario", dove ci sarà l'architettura "Bobcat" come core X86...

[bjt2]

http://www.pctunerup.com/up/results/_200911/th_20091111194734_ScreenHunter_117.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111194734_ScreenHunter_117.jpg)

Aggiornamento:

http://www.pctunerup.com/up/results/_200911/th_20091112010831_ScreenHunter_130.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091112010831_ScreenHunter_130.jpg)
http://www.pctunerup.com/up/results/_200911/th_20091112010859_ScreenHunter_132.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091112010859_ScreenHunter_132.jpg)

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]

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...
http://www.pctunerup.com/up/results/_200911/th_20091111183737_ScreenHunter_116.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091111183737_ScreenHunter_116.jpg)

Clicca qui... (http://www.xbitlabs.com/news/cpu/display/20091111143547_AMD_Displays_Llano_Die_4_x86_Cores_480_Stream_Processors.html)

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

[okorop]

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]

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... :winner:
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 :D)

[okorop]

Grande bjt2, appena ho un po di tempo ti metto in prima pagina... :winner:
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 :D)
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]

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]

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]

Grande bjt2, appena ho un po di tempo ti metto in prima pagina... :winner:
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 :D)

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]

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]

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/2323/il-futuro-di-amd-tra-roadmap-e-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]

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]

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]

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

Sembra proprio di si.

[genesi86]

Sembra proprio di si.

YUPPIIIII

[sniperspa]

YUPPIIIII

Eheh speriamo che ci durino queste mobo!:)

[Ywes]

Quindi se non ho capito male l'architettura Bulldozer che uscirà nel 2011 sarà compatibile con il socket AM3? Se veramente sarà cosi allora verrà ancora più facile aggiornare il sistema per tutti coloro che gia possiedono una scheda madre AM3 passando cosi direttamente ad un bel Bulldozer a 8 core. Semplicemente fantastico!

[capitan_crasy]

Quindi se non ho capito male l'architettura Bulldozer che uscirà nel 2011 sarà compatibile con il socket AM3? Se veramente sarà cosi allora verrà ancora più facile aggiornare il sistema per tutti coloro che gia possiedono una scheda madre AM3 passando cosi direttamente ad un bel Bulldozer a 8 core. Semplicemente fantastico!

Voglio chiarire una cosa:
Zambezi sarà basato sul socket AM3 che in teoria dovrebbe essere uguale per tutti, ma la storia insegna che purtroppo non è sempre così...
La verità è che Bulldozer introduce nuove caratteristiche di alimentazione della CPU e personalmente penso che gli attuali socket AM3 non siano in grado di gestirli al meglio...
AMD non ha chiarito se questa presunta compatibilità sia paragonabile a quella già vista tra il socket AM2 e il socket AM2+, oppure sia legata al chipset, oppure sia perfettamente compatibile; quindi per il momento ci andrei piano con gli entusiasmi...

[genesi86]

Quindi se non ho capito male l'architettura Bulldozer che uscirà nel 2011 sarà compatibile con il socket AM3? Se veramente sarà cosi allora verrà ancora più facile aggiornare il sistema per tutti coloro che gia possiedono una scheda madre AM3 passando cosi direttamente ad un bel Bulldozer a 8 core. Semplicemente fantastico!

sisi, ho appena letto la news di HU ke parla proprio di questo. Pare ke non sia ancora ben kiaro se bulldozer su piattaforma am3 abbia delle limitazioni, xò amd ha confermato la retrocompatibilità dei bulldozer con am3.
Questa è veramente una notizia positivissima, oggi con 500€ ti fai un pc di fascio alta, non enthusiast, xò cmq alta e tra 2-3 anni volendo passi a bulldozer. E' una notizia ke aspettavo da mesi, in quanto a luglio feci qualke sacrificio in + per prendere un am3, nella speranza ke un domani potessi metterci un bulldozer.

[Athlon 64 3000+]

Voglio chiarire una cosa:
Zambezi sarà basato sul socket AM3 che in teoria dovrebbe essere uguale per tutti, ma la storia insegna che purtroppo non è sempre così...
La verità è che Bulldozer introduce nuove caratteristiche di alimentazione della CPU e personalmente penso che gli attuali socket AM3 non siano in grado di gestirli al meglio...
AMD non ha chiarito se questa presunta compatibilità sia paragonabile a quella già vista tra il socket AM2 e il socket AM2+, oppure sia legata al chipset, oppure sia perfettamente compatibile; quindi per il momento ci andrei piano con gli entusiasmi...

Magari le attuali scheda madre AM3 non saranno compatibili,ma magari le future schede madre AM3 con i chipset 8 series lo potrebbe essere con le sezioni di alimentazioni idonee a supportare Bulldozer.

[genesi86]

Voglio chiarire una cosa:
Zambezi sarà basato sul socket AM3 che in teoria dovrebbe essere uguale per tutti, ma la storia insegna che purtroppo non è sempre così...
La verità è che Bulldozer introduce nuove caratteristiche di alimentazione della CPU e personalmente penso che gli attuali socket AM3 non siano in grado di gestirli al meglio...
AMD non ha chiarito se questa presunta compatibilità sia paragonabile a quella già vista tra il socket AM2 e il socket AM2+, oppure sia legata al chipset, oppure sia perfettamente compatibile; quindi per il momento ci andrei piano con gli entusiasmi...

incrociamo le dita allora, xò se AMD facesse dei processori con nuove caratteristike di alimentazione, tali da renderli incompatibili con il socket am3, tanto vale fare un socket nuovo ed ottimizzato. Invece amd ha confermato di usare il normale am3. Vabbè, vedremo.

[sniperspa]

Dubito non saranno proprio compatibili...a quel punto non avrebbe più senso chiamarlo AM3 e sarebbe solo una presa per il culo...

[capitan_crasy]

Dubito non saranno proprio compatibili...a quel punto non avrebbe più senso chiamarlo AM3 e sarebbe solo una presa per il culo...

Se fosse per me, dato che si cambia architettura, metterei la parola fine al socket AM3; tuttavia se non ci fosse una compatibilità sui vecchi AM3 perchè utilizzare ancora tale socket?

[MonsterMash]

Ci possono essere due ragioni sole per cambiare socket: o è necessario per questioni tecniche, o si vuole speculare sulle nuove cpu facendogli trainare anche la vendita di nuovi chipset, IGP, etc, etc. Evidentemente se hanno deciso di mantenere la compatibilità con am3 non sussiste nessuna delle due ragioni suddette.

[capitan_crasy]

Ci possono essere due ragioni sole per cambiare socket: o è necessario per questioni tecniche, o si vuole speculare sulle nuove cpu facendogli trainare anche la vendita di nuovi chipset, IGP, etc, etc. Evidentemente se hanno deciso di mantenere la compatibilità con am3 non sussiste nessuna delle due ragioni suddette.

Avrebbe senso per la piattaforma LEO, anzi aumenterebbe le ragioni d'acquisto; tuttavia l'incognita produttori schede mamme/compatibilità lascia più di un ombra...
Con un nuovo socket si va invece sul sicuro...

[Pihippo]

Avrebbe senso per la piattaforma LEO, anzi aumenterebbe le ragioni d'acquisto; tuttavia l'incognita produttori schede mamme/compatibilità lascia più di un ombra...
Con un nuovo socket si va invece sul sicuro...

Ciao
Quoto. Basti pensare alla sfilza di mobo am2+ che non hanno ricevuto bios adatti per supportare i PhII AM3..

[mack.gar]

Ciao a tutti. Dopo aver visto qualcosa di certo su bulldozer (per quanto avaro di vere info tecniche) nelle slide AMD, un dubbio mi toglie il sonno :sofico: :le prestazioni in single thread di bulldozer.
Mettiamo da parte per un attimo le fpu shared e pensiamo alle prestazioni int.
AMD sembra che stia facendo marketing chiamando i cluster int, "cores". Chiamiamoli cluster/core. Se pensate al k7,k8,k10 hanno tutti 3+3 pipes int, bulldozer 2+2. Poichè una istruzione x86 tipo, comprende una operazione aritmetico-logica che coinvolge il contenuto di una locazione di memoria, AMD ha strutturato sin dai tempi del k7 le unità di esecuzione interi come ALU+AGU che di fatto, ugnuna di queste coppie, esegue, "produce", una instruzione x86.
Il k10 ha 3 decoder e 3 coppie alu-agu, che ne fanno una cpu 3 issue wide, cioè decodifica e ritira al massimo (al meglio dei casi) 3 istruzioni per ciclo. E bulldozer? Si direbbe che ogni cluster-core possa eseguire in parallelo max 2 istruzioni int. Quindi la domandona a tutti gli utenti del forum:Ha amd sacrificato le prestazioni in single thread a beneficio del multi?
Poi è noto che l' IPC medio di una cpu moderna è, in realtà, a seconda del codice eseguito, intorno all'unità... quindi margine di miglioramento ce nè parecchio (predittori dei salti più efficaci, loop buffer/cache o trace cache, predicazione, load store OoO, prefetcher più aggressivi, e chi più ne ha più ne metta) ... però ciò non toglie che rendere il cluster core più "narrower" ti toglie le poche volte che riesci ad estrarre un ilp decende dal codice... e tutto fa media....
Voi che ne dite?

[Pihippo]

Ciao a tutti. Dopo aver visto qualcosa di certo su bulldozer (per quanto avaro di vere info tecniche) nelle slide AMD, un dubbio mi toglie il sonno :sofico: :le prestazioni in single thread di bulldozer.
Mettiamo da parte per un attimo le fpu shared e pensiamo alle prestazioni int.
AMD sembra che stia facendo marketing chiamando i cluster int, "cores". Chiamiamoli cluster/core. Se pensate al k7,k8,k10 hanno tutti 3+3 pipes int, bulldozer 2+2. Poichè una istruzione x86 tipo, comprende una operazione aritmetico-logica che coinvolge il contenuto di una locazione di memoria, AMD ha strutturato sin dai tempi del k7 le unità di esecuzione interi come ALU+AGU che di fatto, ugnuna di queste coppie, esegue, "produce", una instruzione x86.
Il k10 ha 3 decoder e 3 coppie alu-agu, che ne fanno una cpu 3 issue wide, cioè decodifica e ritira al massimo (al meglio dei casi) 3 istruzioni per ciclo. E bulldozer? Si direbbe che ogni cluster-core possa eseguire in parallelo max 2 istruzioni int. Quindi la domandona a tutti gli utenti del forum:Ha amd sacrificato le prestazioni in single thread a beneficio del multi?
Poi è noto che l' IPC medio di una cpu moderna è, in realtà, a seconda del codice eseguito, intorno all'unità... quindi margine di miglioramento ce nè parecchio (predittori dei salti più efficaci, loop buffer/cache o trace cache, predicazione, load store OoO, prefetcher più aggressivi, e chi più ne ha più ne metta) ... però ciò non toglie che rendere il cluster core più "narrower" ti toglie le poche volte che riesci ad estrarre un ilp decende dal codice... e tutto fa media....
Voi che ne dite?

Ciao
Premetto che non sono un esperto.
Dunque il core buldozzer dovrebbe essre composto agli effetti da 2 cluster di integers= 4 int pipe + 4 Address generator unit. Quindi tecnicamente un solo core di Buldozzer dovrebbe essere 4-way-wide. Detto ciò, l'ilp è difficile estrarlo con un architettura a 3 vie, semplicemente perchè dovresti sprecare un bel pò di transistor in logica di fowarding delle istruzioni, in scheduler e R.O.B che non sbagliano mai nell'allocare negli issue slot corretti le operazioni, ed infatti l'icu del k10(che è un grosso reorder buffer in verità) sbaglia e parecchio poichè sebbene vi siano 72 entrate a livello di decoder amd si ha che una istruzione x86= una M(acro)op amd = op logica+op matematica+op memoria, quindi dividi per 3 ed ottieni 24 m(icro)op (che è il numero di operazioni che contiene lo scheduler int comunque) ora possiedi 3 pipeline int che non sono totalmente simmetriche, l'adder è in fatti presente solo sulla pipe 1 e capisci come è facile sbagliare ad smistare le operazioni (oprazioni che vanno in una pipe non corretta od una che ha una coda piena) senza contare le varie ed eventuali pipeline bubbles... Buldozzer da quanto visto nella slide ha scheduler dedicati per ogni cluster, da ciò si potrebbe dedurre che le possibilità di OoO sono maggiori poichè lo scheduler si occupa di smistare solo a 2 pipelines(e si spera siano simmetriche)
Inoltre il vero rompimento di cogl.. nell'isa x86(che un pò è stato risolto da amd con l'estensioni 86-x64) sono le operazioni di memoria e l'addressing model, esse sono onniscenti, in un giochino circa il 55% di tutte le operazioni eseguite sono Load e Store ed in caso di chache miss, un costosissimo (anche per chi ha un mem controller perchè un 80 di cicli se ne va aspettando gli operandi) DMA e richiesta alla ram (che non è fulminea), quindi il bottleneck primario di quasi tutte le cpu è proprio la memoria. Ciò si può parzialmente risolvere parallelizzando le Dma(ovvero quando parte la request alla cache conteporaneamente si cerca di far partire dma in modo di nacrondere un pò le latenze) riordinando scritture e letture (che comunque non è sempre facile metti che devi scrivere su un address già aliased da un'altra scrittura?) e comunque comporta spese di transistor in termini di logica (i penryn possono riordinare scritture che precedono letture poichè hanno un algoritmo che specula sull'aliasing degli indirizzi, i k10 sono più conservativi e spendono il ciclo di clock per calcolare prima l'indirizzo e poi riordinare).
Ed ecco qui la frittate, scusatemi di castronerie varie.

[alesc]

Complimenti per il thread, soprattutto a quelli che pur da semplici appasionati stanno facendo discorsi per nulla banali. Da ignorante, e un po' OT, vi chiedo, avete qualche testo possibilmente online e pubblico da consigliare dove si parla dell'architettura dei moderni microprocessori e che non sia troppo tecnico?
Ciao e grazie

[bs82]

Bulldozer E' retrocompatibile con AM3.

:read: :D

[genesi86]

bulldozer supporterà il dual o il triple channel?

[greeneye]

Se sarà compatibile con l'am3 (o conb una reviosione dello stesso) sicuramente dual-channel.

Probabilmente sarà quad-channel la versione server.

[Ywes]

bulldozer supporterà il dual o il triple channel?

Tanto da quanto si è visto ora con gli i7 lga1366 ed gli i7 Lga1154 la differenza tra triple o dual si vede solo nei bench sintetici, ma nella vita reale non è affatto cosi. Fare 156 FPS o 158 FPS in un videogame non cambia nulla. Stesso discorso per le ram che hanno frequenze mostruose si è visto che già le ram DDR3 a 1600 Mhz con cas 7 sono gia più di quello che serva, avere ram che vanno a 2133 o 2200 mhz non serve a nulla proprio come il trial channel.

[capitan_crasy]

Bulldozer E' retrocompatibile con AM3.

:read: :D

Corretto...

bulldozer supporterà il dual o il triple channel?

Una volta Bulldozer era previsto con configurazione a Quad channel...
Oggi sinceramente non saprei...

[bjt2]

Grande bjt2, appena ho un po di tempo ti metto in prima pagina... :winner:
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 :D)

In effetti se vedi, sono aumentate le unità integer per thread (4 contro 3, ammesso che queste pipeline integer siano del tipo ALU+AGU, e sembra di si), ma sono diminuite le unità FPU per thread: ossia 1 contro 3. C'è da dire che le 3 unità del K10 non sono generiche, e queste due del buldozer sono addirittura delle FMA (possono fare in una sola volta una fused multiply add), in più sono due unità FP per due thread, che è diverso che dire una unità FP per thread: se un thread è poco FPU intensive, l'altro thread si può pappare tutta la potenza di queste due FPU vitaminizzate (più potenti di quelle del K10 e anche del Nehalem). Quindi sulla carta la potenza FPU è diminuita, ma in pratica, essendo le unità più generiche è da vedere. E siccome in una vecchia slide AMD prometteva un incremento di potenza FPU maggiore di quella intera, posso ipotizzare che le svariate limitazioni dello scheduler FPU del K10 facevano sotto esprimere la potenza della FPU. Ora ci sono meno unità FP, ma sono generiche e più potenti: quindi la potenza di picco magari è inferiore, ma quello che conta è la potenza effettiva...

[bjt2]

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.

Io penso che queste pipeline FP possano sempre eseguire una istruzione a 128 bit per ciclo ciascuna. E penso anche una sola istruzione vecchio stampo (per dire FPU a 80 bit) per ciclo. L'unico modo per avvantaggiarsi dei 128 bit è usare le SSE, in modo da fare 2x64 o 4x32 operazioni FP per ciclo. Putroppo anche le istruzioni SSE intere nelle vecchie architetture usavano le unità FP per il semplice fatto che le vecchie istruzioni MMX usavano i registri FP per memorizzare i dati. Teoricamente le istruzioni SSE (che fanno uso di altri registri), almeno quelle intere, avrebbero potuto essere spostate verso le ALU intere, ma il problema è che i registri SSE devono poter essere acceduti anche dalla FPU. Per questo motivo si è sempre rinunciato a questa ottimizzazione: ossia tutte le istruzioni SSE, comprese quelle intere, vengono eseguite ATTUALMENTE dalle FPU. Lo svantaggio di questa architettura a cluster è che ora se si volesse fare questa ottimizzazione, sarebbe ancora più difficile, perchè tutte le unità intere di entrambi i core dovrebbero poter accedere ai registri SSE e le unità FP dovrebbero avere due banchi separati per i due cores... Se prima il dirottamento delle SSE intere era fattibile, ora non credo che sia più economicamente fattibile. Lieto di essere smentito, ovviamente, perchè le unità FP ora saranno più sotto pressione e liberarle dall'onere delle istruzioni SSEx intere sarebbe solo un vantaggio.

[bjt2]

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à...

Attualmente la cache L1 del K10 ha 2 porte da 128 bit. Aumentarle a 256 bit è possibile. Ma bisogna vedere se lo hanno fatto, perchè un load AVX da 256 bit in un solo clock è già possibile farlo con il K10. E' la scrittura che non sarebbe possibile farla nell'attuale k10. E' probabile che il bus sia rimasto 2x128 bit, ma abbiano esteso anche la scrittura a 2x128 bit. Espanderlo a 2x256 bit per poi essere sottoutilizzato nel 99% dei casi (quando non c'è un load o store a 256 bit) non mi sembra il caso... ;)

[Ren]

Nuove speculazioni dai forum indicano delle nuove unità funzionali capaci di manipolare indirizzi o calcoli aritmetici(unità ibride), quindi non più unità o porte distinte per gli indirizzi.
In breve, se ho capito bene si parla di un totale di 8-alu o 8address, NON contemporaneamente.

[Ren]

--------------------

[Ren]

Altre novità che ancora non ho letto.

Pare circoli dello scritto sulle origini del Bulldozer direttamente da uno degli ingegneri ideatori del clustered core.

Eccovi il tutto:

Andy Krazy Glew


Newsgroups: comp.arch
From: "Andy \"Krazy\" Glew" <[email protected]>
Date: Sat, 14 Nov 2009 22:50:01 -0800
Local: Sun, Nov 15 2009 7:50 am
Subject: Re: Bulldozer details + bobcat
Reply | Reply to author | Forward | Print | View thread | Show original | Report this message | Find messages by this author


> Bulldozer details + bobcat

BRIEF:

AMD's Bulldozer is an MCMT (MultiCluster MultiThreaded)
microarchitecture. That's my baby!

DETAIL:

Thursday was both a very good day and a very bad day for me. Good,
because my MCMT ideas finally seem to be going into a product. Bad,
because I ended up driving 4 hours from where I work with IV in the
Seattle area back to Portland, to my wife who was taken to a hospital
emergency room. The latter is personal. The former is, well, personal
too, but also professional.

I can't express how good it feels to see MCMT become a product. It's
been public for years, but it gets no respect until it is in a product.
It would have been better if I had stayed at Intel to see it through.
I know that I won't get any credit for it. (Except from some of the guys
who were at AMD at the time.) But it feels good nevertheless.

The only bad thing is that some guys I know at AMD say that Bulldozer is
not really all that great a product, but is shipping just because AMD
needs a model refresh. "Sometimes you just gotta ship what you got." If
this is so, and if I deserve any credit for CMT, then I also deserve
some of the blame. Although it might have been different, better, if I
had stayed.

I came up with MCMT in 1996-2000 while at the University of Wisconsin.
It became public via presentations.

I brought MCMT back to Intel in 2000, and to AMD in 2002.

I was beginning to despair of MCMT ever seeing the light of day. I
thought that when I left AMD in 2004, the MCMT ideas may have left with
me. Apparently not. I must admit that I am surprised to see that the
concept endured so many years - 5+ years after I left, 7+ years to
market. Apparently they didn't have any better ideas.

True, there were rumors. For example, Chuck Moore presented a slide
with Multicluster Multithreading on it to analysts in 2004 or 2005. But
things went quiet. There were several patents filed, with diagrams that
looked very much like the ones I drew for the K10 proposal. But, one
often sees patent applications for cancelled projects.

Of course, AMD has undoubtedly changed and evolved MCMT in many ways
since I first proposed it to them. For example, I called the set of an
integer scheduler, integer execution units, and an L1 data cache a
"cluster", and the whole thing, consisting of shared front end, shared
FP, and 2 or more clusters, a processor core. Apparently AMD is calling
my clusters their cores, and my core their cluster. It has been
suggested that this change of terminology is motivated by marketing, so
that they can say they have twice as many cores.

My original motivation for MCMT was to work around some of the
limitations of Hyperthreading on Willamette. E.g. Willamette had a very
small L0 data cache, 4K in some of the internal proposals, although it
shipped at 8K. Two threads sharing such a tiny L0 data cache thrash.
Indeed, this is one of the reasons why hyperthreading is disabled on
many systems, including many current Nhm based machines with much larger
closest-in caches.

At the time, the small L0s were a given. You couldn't build a
Willamette style "fireball" high frequency machine, and have a much
bigger cache, and still preserve the same small cache latency.

To avoid threads thrashing each other, I wanted to give each thread
their own L0. But, you can't do so, and still keep sharing the
execution units and scheduler - you can't just build a 2X larger array,
or put two arrays side by side, and expect to have the same latency.
Wires. Therefore, I had to replicate the execution units, and enough of
the scheduler so that the "critical loop" of Scheduler->Execution->Data
Cache was all isolated from the other thread/cluster. Hence, the form
of multi-cluster multi-threading you see in Bulldozer.

True, there are differences, and I am sure more will become evident as
more Bulldozer information becomes public. For example, although I came
up with MCMT to make Willamette-style threading faster, I have always
wanted to put SpMT, Speculative Multithreading, on such a substrate.
SpMT has potential to speed up a single thread of execution, by
splitting it up into separate threads and running the separate threads
on different clusters, whereas Willamette-style hyperthreading, and
Bulldizer-style MCMT (apparently), only speed up workloads that have
existing independent threads. I still want to build SpMT. My work at
Wisconsin showed that SpMT on a Willamette substrate was constrained by
Willamette's poor threading microarchitecture, so naturally I had to
first create the best explicit threading microarchitecture I could, and
then run SpT on top of it.

If I received arows in my back for MCMT, I received 10 times as many
arrows for SpMT. And yet still I have hope for it. Unfortunately, I am
not currently working on SpMT. Haitham Akkary, the father of DMT,
continues the work.

I also tried, and still continue, to explore other ways of speeding up
single threads using multiple clusters.

Although I remain an advocate of SpMT, I have always recognized the
value of MCMT as an explicit threaded microarchitecture.

Perhaps I should say here that my MCMT had a significant difference from
clustering in, say, the Alpha 21264,
http://www.hotchips.org/archives/hc10/2 ... 10.1.1.pdf
Those clusters bypass to each other: there is a fast bypass within a
cluster, and a slightly slower (+1 cycle) bypass of results between
clusters. The clusters are execution units only, and share the data
cache. This bypassing makes it easy (or at least easier) to spread a
single thread across both clusters. My MCMT clusters, on the other
hand, do NOT bypass to each other. This motivates separate threads per
cluster, whether explicit or implicit.

I have a whole taxonomy of different sorts of clustering:
* fast vs slow bypass clusters
* fully bypassed vs. partially bypassed
* mechanisms to reduce bypassing
* physical layout of clusters
* bit interleaved datapaths
* datapaths flowing in opposite directions,
with bypassing where they touch
* what's in the cluster
* execute only
* execute + data cache
* schedule + execute + data cache
* renamer + schedule + execute + datacache
...
* what gets shared between clusters
* front-end
* renamer?
* data-cache - L0? L1? L2?
* TLBs...
* MSHRs...
* FP...

Anyway: if it has an L0 or L1 data cache in the cluster, with or
without the scheduler, it's my MCMT. If no cache in the cluster, not
mine (although I have enumerated many such possibilities).

Motivated by my work to use MCMT to speed up single threads, I often
propose a shared L2 instruction scheduler, to load balance between the
clusters dynamically. Although I admit that I only really figured out
how to do that properly after I left AMD, and before I joined Intel.
How to do this is part of the Multi-star microarchitecture, M*, that is
my next step beyond MCMT.

Also, although it is natural to have a single (explicit) thread per
cluster in MCMT, I have also proposed allowing two threads per cluster.
Mainly motivated by SpMT: I could fork to a "runt thread" running in
tghe same cluster, and then migrate the run thread to a different
cluster. Intra-cluster forking is faster than inter-cluster forkng, and
does not disturb the parent thread.
But, if you are not doing SpMT, there is much less motivation for
multiple threads per cluster. I would not want to do that unless I was
also trying to build a time-switched lightweight threading system.
Which, as you can imagine if you know me, I have also proposed. In
fact, I hope to go to the SC'09 Workshop on that topic.

I will be quite interested to see whether Bulldozer's cluster-private L1
caches (in AMD's swapped terminology, core-private L1 caches) are write
through or write-back. Willamette's L0 was write-through. I leaned
towards write-back, because my goal was to isolate clusters from each
other, to reduce thrashing. Also, because write-back lends itself
better to a speculative versionong cache, useful for SpMT.

With Willamette as background, I leaned towards a relatively small, L0,
cache in the cluster. Also, such a small L0 can often be pitch-matched
with the cluster execution unit datapath. A big L1, such as Bulldozer
seems to have, nearly always has to lie out of the datapath, and
requires wire turns. Wire turns waste area. I have, from time to time,
proposed putting the alignment muxes and barrel shifters in the wire
turn area. I'm surprised that a large cluster L1 makes sense, but that's
the sort of thing that you can only really tell from layout.

Some posters have been surprised by sharing the FP. Of course, AMD's K7
design, with separate clusters for integer and FP, was already half-way
there. They only had to double the integer cluster. It would have been
harder for Intel to go MCMT, since the P6 family had shared integer and
FP. Willamette might have been easier to go MCMT, since it had separate FP.

Anyway... of course, for FP threads you might like to have
thread-private FP. But, in some ways, it is the advent of expensve FP,
like Bulldozer's 2 sets of 128 bit, 4x32 bit, FMAs, that justify integer
MCMT: the FP is so big that the overhead of replicating the integer
cluster, including the OOO logic, is a drop in the bucket.
You'd like to have per-cluster-thread FP, but such big FP workloads are
often so memory intensive that they thrash the shared-between-clusters
L2 cache: threading may be disabled anyways. As it is, you get good
integer threads via MCMT, and you get 1 integer thread and 1 FP thread.
Two FP threads may have some slowdown, although, again, if memory
intensive they may be blocking on memory, and hence allowing the other
FP thread t use the FP. But two purely computational FP threads will
almost undoubtedly block, unless the schedulers are piss-poor and can't
use all of the FP for a single thread (e.g. by being too small).

I certainly want to explore possibilities such as SpMT and other single
thread speedups. But I know that you can't build all the neat ideas in
one project. Apparently MCMT by itself was enough for AMD Bulldozer.
(Actually, I am sure that there are other new ideas in Bulldozer. Just
apparently not SpMT or spreading a single thread across clusters.) Look
at the time-lag: 10-15 years from when I came up with MCMT in
Wisconsin, 1996-2000. It is now 7-5 years from when I was at AMD,
2002-2004, and it will be another 2 years or so before Bulldozer is a
real force in the marketplace.

I don't expect to get any credit for MCMT. In fact, I'm sure I'm going
to get shit for this post. I don't care. I know. The people who were
there, who saw my presentations and read my proposals, know. But, e.g.
Chuck Moore wasn't there at start; he came in later. Even Mike Haertel,
my usual collaborator, wasn't there; he was hired in later, although
before Chuck. Besides, Mike Haertel thinks that MCMT is obvious.
That's cool, although I ask: if MCMT is obvious, then why isn't Intel
doing it? Companies like Intel and AMD need idea generating people like
me about once every 10 years. In between, they don't need new ideas.
They need new incremental improvements of existing ideas.

Anyway... It's cool to see MCMT becoming real. It gives me hope that my
follow-on to MCMT, M* may still, eventually, also become real.

[^[H3ad-Tr1p]^]

up :p

[checo]

sto qua mi sa uno col dente avvelenato.
però dice non ci sarà il reverse iperthreading, sprem di no

[mack.gar]

Ciao
Premetto che non sono un esperto.
Dunque il core buldozzer dovrebbe essre composto agli effetti da 2 cluster di integers= 4 int pipe + 4 Address generator unit. Quindi tecnicamente un solo core di Buldozzer dovrebbe essere 4-way-wide. Detto ciò, l'ilp è difficile estrarlo con un architettura a 3 vie, semplicemente perchè dovresti sprecare un bel pò di transistor in logica di fowarding delle istruzioni, in scheduler e R.O.B che non sbagliano mai nell'allocare negli issue slot corretti le operazioni, ed infatti l'icu del k10(che è un grosso reorder buffer in verità) sbaglia e parecchio poichè sebbene vi siano 72 entrate a livello di decoder amd si ha che una istruzione x86= una M(acro)op amd = op logica+op matematica+op memoria, quindi dividi per 3 ed ottieni 24 m(icro)op (che è il numero di operazioni che contiene lo scheduler int comunque) ora possiedi 3 pipeline int che non sono totalmente simmetriche, l'adder è in fatti presente solo sulla pipe 1 e capisci come è facile sbagliare ad smistare le operazioni (oprazioni che vanno in una pipe non corretta od una che ha una coda piena) senza contare le varie ed eventuali pipeline bubbles... Buldozzer da quanto visto nella slide ha scheduler dedicati per ogni cluster, da ciò si potrebbe dedurre che le possibilità di OoO sono maggiori poichè lo scheduler si occupa di smistare solo a 2 pipelines(e si spera siano simmetriche)
Inoltre il vero rompimento di cogl.. nell'isa x86(che un pò è stato risolto da amd con l'estensioni 86-x64) sono le operazioni di memoria e l'addressing model, esse sono onniscenti, in un giochino circa il 55% di tutte le operazioni eseguite sono Load e Store ed in caso di chache miss, un costosissimo (anche per chi ha un mem controller perchè un 80 di cicli se ne va aspettando gli operandi) DMA e richiesta alla ram (che non è fulminea), quindi il bottleneck primario di quasi tutte le cpu è proprio la memoria. Ciò si può parzialmente risolvere parallelizzando le Dma(ovvero quando parte la request alla cache conteporaneamente si cerca di far partire dma in modo di nacrondere un pò le latenze) riordinando scritture e letture (che comunque non è sempre facile metti che devi scrivere su un address già aliased da un'altra scrittura?) e comunque comporta spese di transistor in termini di logica (i penryn possono riordinare scritture che precedono letture poichè hanno un algoritmo che specula sull'aliasing degli indirizzi, i k10 sono più conservativi e spendono il ciclo di clock per calcolare prima l'indirizzo e poi riordinare).
Ed ecco qui la frittate, scusatemi di castronerie varie.

Ciao, nemmeno io sono un esperto, seguo l'evoluzione delle cpu da appassionato da diversi anni ormai, ed è da un pò che leggo i vari thread qui su hw, sempre molto interessanti.
Sono d'accordo in via generale con quello che dici eccetto che Bulldozzer non è 4 issue wide. O meglio ha due cluster int 2 issue wide (sempre che siano simili al k10, se no chissà...). Le cache L1d sono separate, quindi è improbabile :confused: che i due cluster int cooperino nell'esecuzione del medesimo thread ( il leggendario reverse hyperthreading).
Un'architettura a 3 vie non viene mai appieno sfruttata, come dici, tuttavia se si sono dati tanto da fare a farle (addirittura i core due sono 4-wide anche se con molti se e ma) deve esserne valsa la pena utilizzare tutti quei transistor in più. Imho AMD ha pensato che con un'architettura pesantemente multi-thread ottenga maggiori prestazioni per area utilizzata spostando il baricentro dall'ilp al tlp, almeno imho; Ciao!

[capitan_crasy]

Ricordo che AMD sta preparando il suo Turbo mode chiamato "Automatic Proccesor Overclocking" (alcune voci dicono che sarà addirittura introdotto con Thuban)
Il Multi-Threading Technology o SMT, con tutta probabilità, sarà anti HyperThreading di Intel e per ora il Reverse HyperThreading dovrebbe essere legato alle esecuzioni delle istruzioni AVX Intel

Riassunto del buon 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.

[Pihippo]

Ciao, nemmeno io sono un esperto, seguo l'evoluzione delle cpu da appassionato da diversi anni ormai, ed è da un pò che leggo i vari thread qui su hw, sempre molto interessanti.
Sono d'accordo in via generale con quello che dici eccetto che Bulldozzer non è 4 issue wide. O meglio ha due cluster int 2 issue wide (sempre che siano simili al k10, se no chissà...). Le cache L1d sono separate, quindi è improbabile :confused: che i due cluster int cooperino nell'esecuzione del medesimo thread ( il leggendario reverse hyperthreading).
Un'architettura a 3 vie non viene mai appieno sfruttata, come dici, tuttavia se si sono dati tanto da fare a farle (addirittura i core due sono 4-wide anche se con molti se e ma) deve esserne valsa la pena utilizzare tutti quei transistor in più. Imho AMD ha pensato che con un'architettura pesantemente multi-thread ottenga maggiori prestazioni per area utilizzata spostando il baricentro dall'ilp al tlp, almeno imho; Ciao!

Ciao
Le cache l1d sono separate ma la L1D è unica per ambedue i clusters, ciò a livello teorico dovrebbe implicare che nel fetch dalla L1i ambedue i clusters ricevano le stesse operazioni, ma le eseguano su operandi diversi (oppure uno esegue un pezzetto di codice ed uno un altro) ecco quindi spiegato il motivo di 2 L1D) sarebbe un ipotetico ICU a smistare le operazioni in maniera effciente ad ambedue gli scheduler distribuiti. Almeno questo è quello che ho capito io..
Riguardo all'efficienza dei core2, beh stando ad alcuni che ne capiscono più di me l'ipc medio è superiore del 10% ad i K8 http://www.realworldtech.com/page.cfm?ArticleID=RWT102808015436&p=9 ed ipoteticamente uguali ad i K10 tranne nelle applicazioni memory intensive, come mai ci sono alcune differenze lo dovresti chiedere ad i maghi del compiler...
Inoltre se vai a vedere l'ipc medio e di ambedue 1.1 1.2 istruzioni per ciclo di clock. I core2quad per spremere 4 istruzioni a ciclo richiedono di applicazioni interamente scritte per loro visto che soffrono di inefficienze di scheduler(Xbitlabs ha un articolo a proposito se non erro). Quindi i transistor spesi per una architettura 4-wide sono perfettamente, a mia opinione quindi a valore 0, inutili se si richiede programmazione ad hoc, che poi se vai a vedere il dispendio maggiore è tra cache e logica di controllo che si pappano più del 80%del die size.......

[MonsterMash]

Non so se ci sia qualcosa di nuovo, e a dire il vero non so neanche se sia reale o fake, ma ho trovato questo su un NG:

Andy Krazy Glew


Newsgroups: comp.arch
From: "Andy \"Krazy\" Glew" <[email protected]>
Date: Sat, 14 Nov 2009 22:50:01 -0800
Local: Sun, Nov 15 2009 7:50 am
Subject: Re: Bulldozer details + bobcat
Reply | Reply to author | Forward | Print | View thread | Show original |
Report this message | Find messages by this author


> Bulldozer details + bobcat

BRIEF:

AMD's Bulldozer is an MCMT (MultiCluster MultiThreaded)
microarchitecture. That's my baby!

DETAIL:

Thursday was both a very good day and a very bad day for me. Good,
because my MCMT ideas finally seem to be going into a product. Bad,
because I ended up driving 4 hours from where I work with IV in the
Seattle area back to Portland, to my wife who was taken to a hospital
emergency room. The latter is personal. The former is, well, personal
too, but also professional.

I can't express how good it feels to see MCMT become a product. It's
been public for years, but it gets no respect until it is in a product.
It would have been better if I had stayed at Intel to see it through.
I know that I won't get any credit for it. (Except from some of the guys
who were at AMD at the time.) But it feels good nevertheless.

The only bad thing is that some guys I know at AMD say that Bulldozer is
not really all that great a product, but is shipping just because AMD
needs a model refresh. "Sometimes you just gotta ship what you got." If
this is so, and if I deserve any credit for CMT, then I also deserve
some of the blame. Although it might have been different, better, if I
had stayed.

I came up with MCMT in 1996-2000 while at the University of Wisconsin.
It became public via presentations.

I brought MCMT back to Intel in 2000, and to AMD in 2002.

I was beginning to despair of MCMT ever seeing the light of day. I
thought that when I left AMD in 2004, the MCMT ideas may have left with
me. Apparently not. I must admit that I am surprised to see that the
concept endured so many years - 5+ years after I left, 7+ years to
market. Apparently they didn't have any better ideas.

True, there were rumors. For example, Chuck Moore presented a slide
with Multicluster Multithreading on it to analysts in 2004 or 2005. But
things went quiet. There were several patents filed, with diagrams that
looked very much like the ones I drew for the K10 proposal. But, one
often sees patent applications for cancelled projects.

Of course, AMD has undoubtedly changed and evolved MCMT in many ways
since I first proposed it to them. For example, I called the set of an
integer scheduler, integer execution units, and an L1 data cache a
"cluster", and the whole thing, consisting of shared front end, shared
FP, and 2 or more clusters, a processor core. Apparently AMD is calling
my clusters their cores, and my core their cluster. It has been
suggested that this change of terminology is motivated by marketing, so
that they can say they have twice as many cores.

My original motivation for MCMT was to work around some of the
limitations of Hyperthreading on Willamette. E.g. Willamette had a very
small L0 data cache, 4K in some of the internal proposals, although it
shipped at 8K. Two threads sharing such a tiny L0 data cache thrash.
Indeed, this is one of the reasons why hyperthreading is disabled on
many systems, including many current Nhm based machines with much larger
closest-in caches.

At the time, the small L0s were a given. You couldn't build a
Willamette style "fireball" high frequency machine, and have a much
bigger cache, and still preserve the same small cache latency.

To avoid threads thrashing each other, I wanted to give each thread
their own L0. But, you can't do so, and still keep sharing the
execution units and scheduler - you can't just build a 2X larger array,
or put two arrays side by side, and expect to have the same latency.
Wires. Therefore, I had to replicate the execution units, and enough of
the scheduler so that the "critical loop" of Scheduler->Execution->Data
Cache was all isolated from the other thread/cluster. Hence, the form
of multi-cluster multi-threading you see in Bulldozer.

True, there are differences, and I am sure more will become evident as
more Bulldozer information becomes public. For example, although I came
up with MCMT to make Willamette-style threading faster, I have always
wanted to put SpMT, Speculative Multithreading, on such a substrate.
SpMT has potential to speed up a single thread of execution, by
splitting it up into separate threads and running the separate threads
on different clusters, whereas Willamette-style hyperthreading, and
Bulldizer-style MCMT (apparently), only speed up workloads that have
existing independent threads. I still want to build SpMT. My work at
Wisconsin showed that SpMT on a Willamette substrate was constrained by
Willamette's poor threading microarchitecture, so naturally I had to
first create the best explicit threading microarchitecture I could, and
then run SpT on top of it.

If I received arows in my back for MCMT, I received 10 times as many
arrows for SpMT. And yet still I have hope for it. Unfortunately, I am
not currently working on SpMT. Haitham Akkary, the father of DMT,
continues the work.

I also tried, and still continue, to explore other ways of speeding up
single threads using multiple clusters.

Although I remain an advocate of SpMT, I have always recognized the
value of MCMT as an explicit threaded microarchitecture.

Perhaps I should say here that my MCMT had a significant difference from
clustering in, say, the Alpha 21264,
http://www.hotchips.org/archives/hc10/2 ... 10.1.1.pdf
Those clusters bypass to each other: there is a fast bypass within a
cluster, and a slightly slower (+1 cycle) bypass of results between
clusters. The clusters are execution units only, and share the data
cache. This bypassing makes it easy (or at least easier) to spread a
single thread across both clusters. My MCMT clusters, on the other
hand, do NOT bypass to each other. This motivates separate threads per
cluster, whether explicit or implicit.

I have a whole taxonomy of different sorts of clustering:
* fast vs slow bypass clusters
* fully bypassed vs. partially bypassed
* mechanisms to reduce bypassing
* physical layout of clusters
* bit interleaved datapaths
* datapaths flowing in opposite directions,
with bypassing where they touch
* what's in the cluster
* execute only
* execute + data cache
* schedule + execute + data cache
* renamer + schedule + execute + datacache
...
* what gets shared between clusters
* front-end
* renamer?
* data-cache - L0? L1? L2?
* TLBs...
* MSHRs...
* FP...

Anyway: if it has an L0 or L1 data cache in the cluster, with or
without the scheduler, it's my MCMT. If no cache in the cluster, not
mine (although I have enumerated many such possibilities).

Motivated by my work to use MCMT to speed up single threads, I often
propose a shared L2 instruction scheduler, to load balance between the
clusters dynamically. Although I admit that I only really figured out
how to do that properly after I left AMD, and before I joined Intel.
How to do this is part of the Multi-star microarchitecture, M*, that is
my next step beyond MCMT.

Also, although it is natural to have a single (explicit) thread per
cluster in MCMT, I have also proposed allowing two threads per cluster.
Mainly motivated by SpMT: I could fork to a "runt thread" running in
tghe same cluster, and then migrate the run thread to a different
cluster. Intra-cluster forking is faster than inter-cluster forkng, and
does not disturb the parent thread.
But, if you are not doing SpMT, there is much less motivation for
multiple threads per cluster. I would not want to do that unless I was
also trying to build a time-switched lightweight threading system.
Which, as you can imagine if you know me, I have also proposed. In
fact, I hope to go to the SC'09 Workshop on that topic.

I will be quite interested to see whether Bulldozer's cluster-private L1
caches (in AMD's swapped terminology, core-private L1 caches) are write
through or write-back. Willamette's L0 was write-through. I leaned
towards write-back, because my goal was to isolate clusters from each
other, to reduce thrashing. Also, because write-back lends itself
better to a speculative versionong cache, useful for SpMT.

With Willamette as background, I leaned towards a relatively small, L0,
cache in the cluster. Also, such a small L0 can often be pitch-matched
with the cluster execution unit datapath. A big L1, such as Bulldozer
seems to have, nearly always has to lie out of the datapath, and
requires wire turns. Wire turns waste area. I have, from time to time,
proposed putting the alignment muxes and barrel shifters in the wire
turn area. I'm surprised that a large cluster L1 makes sense, but that's
the sort of thing that you can only really tell from layout.

Some posters have been surprised by sharing the FP. Of course, AMD's K7
design, with separate clusters for integer and FP, was already half-way
there. They only had to double the integer cluster. It would have been
harder for Intel to go MCMT, since the P6 family had shared integer and
FP. Willamette might have been easier to go MCMT, since it had separate FP.

Anyway... of course, for FP threads you might like to have
thread-private FP. But, in some ways, it is the advent of expensve FP,
like Bulldozer's 2 sets of 128 bit, 4x32 bit, FMAs, that justify integer
MCMT: the FP is so big that the overhead of replicating the integer
cluster, including the OOO logic, is a drop in the bucket.
You'd like to have per-cluster-thread FP, but such big FP workloads are
often so memory intensive that they thrash the shared-between-clusters
L2 cache: threading may be disabled anyways. As it is, you get good
integer threads via MCMT, and you get 1 integer thread and 1 FP thread.
Two FP threads may have some slowdown, although, again, if memory
intensive they may be blocking on memory, and hence allowing the other
FP thread t use the FP. But two purely computational FP threads will
almost undoubtedly block, unless the schedulers are piss-poor and can't
use all of the FP for a single thread (e.g. by being too small).

I certainly want to explore possibilities such as SpMT and other single
thread speedups. But I know that you can't build all the neat ideas in
one project. Apparently MCMT by itself was enough for AMD Bulldozer.
(Actually, I am sure that there are other new ideas in Bulldozer. Just
apparently not SpMT or spreading a single thread across clusters.) Look
at the time-lag: 10-15 years from when I came up with MCMT in
Wisconsin, 1996-2000. It is now 7-5 years from when I was at AMD,
2002-2004, and it will be another 2 years or so before Bulldozer is a
real force in the marketplace.

I don't expect to get any credit for MCMT. In fact, I'm sure I'm going
to get shit for this post. I don't care. I know. The people who were
there, who saw my presentations and read my proposals, know. But, e.g.
Chuck Moore wasn't there at start; he came in later. Even Mike Haertel,
my usual collaborator, wasn't there; he was hired in later, although
before Chuck. Besides, Mike Haertel thinks that MCMT is obvious.
That's cool, although I ask: if MCMT is obvious, then why isn't Intel
doing it? Companies like Intel and AMD need idea generating people like
me about once every 10 years. In between, they don't need new ideas.
They need new incremental improvements of existing ideas.

Anyway... It's cool to see MCMT becoming real. It gives me hope that my
follow-on to MCMT, M* may still, eventually, also become real.


Il mittente dicono sia un ingegnere amd.

[kaoss]

grande thread,
interessantissimo
iscritto :asd:

[greeneye]

Non so se ci sia qualcosa di nuovo, e a dire il vero non so neanche se sia reale o fake, ma ho trovato questo su un NG:



Il mittente dicono sia un ingegnere amd.

ex ingegnere di intel prima e di amd poi.

[checo]

ex ingegnere di intel prima e di amd poi.

sti ex ing... mi ricordo i famosi ex ing. 3dfx che custodivano tecnologie aliene :D

[capitan_crasy]

Non so se ci sia qualcosa di nuovo, e a dire il vero non so neanche se sia reale o fake, ma ho trovato questo su un NG:



Il mittente dicono sia un ingegnere amd.

Già stato postato da Ren...;)
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=29711943&postcount=238)

[bjt2]

Altre novità che ancora non ho letto.

Pare circoli dello scritto sulle origini del Bulldozer direttamente da uno degli ingegneri ideatori del clustered core.

Eccovi il tutto:

Andy Krazy Glew

CUTTONE



In breve lui ha avuto l'idea del CMT nel 1996-2000, ha presentato le sue idee quando era in AMD nel 2000-2002 ed è quasi sicuro che sono state fatte aggiunte alle sue idee.

[astroimager]

Quindi... ho capito male, o la ver. desktop di Bulldozer sarà compatibile con il socket AM3?

I prossimi chipset serie 800 saranno sufficienti per supportare la nuova architettura?

[astroimager]

Penso che se così sarà ce lo diranno in tutte le salse, anche perché Bulldozer ormai è definito, quindi già lo sapranno per certo.

Beh, il max sarebbe la retrocompatibilità con la serie 700, anche con alcune limitazioni (come era per il socket AM2)... chissà se sopravviveranno le attuali AM3 di punta...

[Sensi]

Beh, il max sarebbe la retrocompatibilità con la serie 700, anche con alcune limitazioni (come era per il socket AM2)... chissà se sopravviveranno le attuali AM3 di punta...

http://www.hwupgrade.it/forum/showpost.php?p=29649729&postcount=166

[astroimager]

http://www.hwupgrade.it/forum/showpost.php?p=29649729&postcount=166

Grazie!

Un motivo in più per attendere la serie 800 prima di un aggiornamento... ;)

[capitan_crasy]

AMD’s C32 and G34 platforms will be upgradeable to the new Valencia and Interlagos CPUs which are both based on the Bulldozer core.

http://www.pctunerup.com/up//results/_200911/20091124114558_Bulldozer0.png

We will discuss this core in more detail but here are some extra tidbits we managed to find out:

• Two integer clusters share fetch and decode logic but have their own dedicated Instruction and Data cache
• Integer clusters can not be shared between threads: integer cores act like a Chip Multi Processing (CMP) CPU.
• The extra integer core (schedulers, D-cache and pipelines) adds only 5% die space
• L1-caches are similar to Barcelona/Shanghai (64 KB 2-way? Not confirmed)
• Up to 4 modules share a L3-cache and Northbridge
• Two times 4 Bulldozer modules (2 x 8 "cores" or 16 cores) are about 60 to 80% faster than the twelve core Opteron 6100 CPU in SPECInt_rate.

With Bulldozer, AMD finally seems to have designed an aggressive integer core. Since the introduction of the Intel Woodcrest in 2006, Intel’s CPUs have been offering superior integer crunching performance per core. Since integer performance determines the performance of 90-95% of the server application out there, this is a big deal.

Clicca qui... (http://it.anandtech.com/IT/showdoc.aspx?i=3681&p=3)

[capitan_crasy]

Il sito xtreview.com pubblica alcune dichiarazioni AMD, rilasciate al ISSCC 2010, sulle sue prossime CPU Magny-Cours a 45nm e delle CPU 32nm previste per il 2011.
Secondo alcuni documenti sono previste delle CPU 32nm @ 3.00Ghz con un TDP massimo di soli 25W; purtroppo non viene svelato che tipo di architettura (Bulldozer/Bobcat/Fusion) utilizzerà tale CPU...
Inoltre AMD prevede di realizzare CPU sempre a 32nm con frequenza di clock superiore ai 4.00GHz, senza specificare però il TDP previsto!
Clicca qui... (http://xtreview.com/addcomment-id-10705-view-AMD-32-nm-processor-frequency-and-TDP.html)

[astroimager]

Il sito xtreview.com pubblica alcune dichiarazioni AMD, rilasciate al ISSCC 2010, sulle sue prossime CPU Magny-Cours a 45nm e delle CPU 32nm previste per il 2011.
Secondo alcuni documenti sono previste delle CPU 32nm @ 3.00Ghz con un TDP massimo di soli 25W; purtroppo non viene svelato che tipo di architettura (Bulldozer/Bobcat/Fusion) utilizzerà tale CPU...
Inoltre AMD prevede di realizzare CPU sempre a 32nm con frequenza di clock superiore ai 4.00GHz, senza specificare però il TDP previsto!
Clicca qui... (http://xtreview.com/addcomment-id-10705-view-AMD-32-nm-processor-frequency-and-TDP.html)

Secondo me si tratta di una CPU per il mobile o comunque per sistemi in cui la dissipazione è critica.
Considerando le caratteristiche delle nuove CPU Intel, potrebbe trattarsi di un dual core con GPU integrata.

[capitan_crasy]

Secondo me si tratta di una CPU per il mobile o comunque per sistemi in cui la dissipazione è critica.
Considerando le caratteristiche delle nuove CPU Intel, potrebbe trattarsi di un dual core con GPU integrata.

Non credo che sia un dual core...
Le prime APU Bobcat saranno con un due core X86+GPU DX11 e il TDP presunto è molto più basso dei 25W...
Può darsi che sia il core "Llano" previsto con 4 core+ GPU DX11...

[pandyno]

sti ex ing... mi ricordo i famosi ex ing. 3dfx che custodivano tecnologie aliene :D

Mai sfruttate: leggi le dichiarazioni del capoccia di NVIDIA in merito :D

[capitan_crasy]

Notizia di HWupgrade del 26.11.2009

In concomitanza con la International Solid-State Circuits Conference (ISSCC), evento che aprirà i battenti il prossimo mese di Febbraio, AMD renderà pubbliche in alcune sessioni parte delle caratteristiche architetturali delle proprie future generazioni di processore attese a partire dal 2011.

Sappiamo già in parte di cosa si tratti: AMD infatti presenterà soluzioni indicate con il nome in codice di Bulldozer per le soluzioni desktop di fascia medio alta e per sistemi server. Per il segmento di mercato delle soluzioni a più basso consumo AMD ha in lavorazione una nuova architettura di processore, nota con il nome in codice di Bobcat.

Una delle sessioni ha quale titolo "a 32nm core capable of data rates above 3GHz and power consumption variable from 2.5 to 25W": è evidente come si tratti di un riferimento alle soluzioni Bobcat, sviluppate da AMD per l'utilizzo in sistemi notebook dall'elevata trasportabilità oltre che in netbook. Pare infatti poco probabile che un'architettura di elevata potenza e complessità come quella Bulldozer possa assicurare livelli di consumo massimo entro 25 Watt con una frequenza di clock di 3 GHz.

Trattandosi di una conferenza estremamente tecnica, AMD puntualizzerà alcune delle soluzioni implementate per questi progetti miranti a contenere il più possibile il consumo complessivo. Ad esempio, verrà analizzato l'utilizzo di celle memoria 8T per la cache di primo livello integrata in ogni core, così da dover utilizzare tensioni di alimentazione particolarmente contenute.

Una seconda soluzione tecnica che verrà approfondita riguarda l'utilizzo di un ring power gate, grazie al quale poter ridurre pressoché a zero il consumo di ciascun core nel momento in cui questo venga posto in idle dal sistema operativo. Un approccio di questo tipo ricorda, nel risultato, quanto implementato da Intel con le soluzioni della famiglia Nehalem.

Nella stessa occasione anche Intel anticiperà alcune delle caratteristiche architetturali delle proprie soluzioni della famiglia Westmere destinate a sistemi desktop e server di fascia alta. Si tratta di processori che rappresentano una evoluzione, con tecnologia produttiva a 32 nanometri, delle architetture Nehalem; l'elemento tecnico maggiormente di rilievo è l'integrazione di 6 core su design nativo, in abbinamento a 12 Mbytes di cache L3 unificata.

Clicca qui... (http://www.hwupgrade.it/news/cpu/cpu-a-32nm-di-intel-e-amd-anticipate-all-isscc_30887.html)

[Knukcles]

dico la mia?!
ma fare cpu 32nm sopra i 4 giga....( 4e più stock sono davvero tanti).......vuol dire o che stavolta l'architettura gli è venuta particolarmente bene e vogliono dare una prova di forza.....

oppure non è che si continua a percorrere la stessa strada di adesso?...."basso" ipc quindi corriamo ai ripari con il clock?

spero la prima......

[Vash_85]

dico la mia?!
ma fare cpu 32nm sopra i 4 giga....sopra i 4giga stock sono davvero tanti.......vuol dire o che stavolta l'architettura gli è venuta particolarmente bene e vogliono dare una prova di forza.....

oppure non è che si continua a percorrere la stessa strada di adesso?...."basso" ipc quindi corriamo ai ripari con il clock?

spero la prima......

Quoto...

[capitan_crasy]

dico la mia?!
ma fare cpu 32nm sopra i 4 giga....( 4e più stock sono davvero tanti).......vuol dire o che stavolta l'architettura gli è venuta particolarmente bene e vogliono dare una prova di forza.....

oppure non è che si continua a percorrere la stessa strada di adesso?...."basso" ipc quindi corriamo ai ripari con il clock?

spero la prima......

Qui non si parla di un K10 migliorato ma di una architettura nuova di zecca, dobbiamo cercare di entrare nell'ottica "qualcosa di nuovo" e dimenticare l'ottica "qualcosa di già visto"
Si può avere una CPU performante e alte frequenze; si sapeva già da tempo che Bulldozer alzava gli stadi delle pipeline la quale favoriscono un aumento della frequenza di clock.
Per finire non ci dimentichiamo che saranno costruiti con silicio a 32nm SOI con tecnologia High k dielectric...