[Thread Ufficiale] Aspettando ZEN

[tuttodigitale]

Originariamente inviato da stefanonweb

ma il socket FM2+ che fine dovrebbe fare?

Soccombere.
In questo momento in commercio c'è un solo prodotto basato sui core excavator. Una delle tante ipotesi è che si possa avere prodotti AM4, di questo tipo, compatibili con FM2+.

le soluzioni ZEN sono tagliate fuori dal discorso compatibilità, perchè il MC non sarebbe in grado di lavorare con le ddr3.

[paolo.oliva2]

Domanda banale...

Io ancora non ho capito una cosa... il socket AM4 AMD lo ha dato per compatibile sia con gli APU che con Zen.

Visto che gli APU e Zen avranno il PCI integrato e simili, l'unica differenza è che un APU avrebbe la VGA integrata e Zen, per quanto si sa, non sarebbe APU.

Quello che mi viene da riflettere, è che un APU con l'opzione di disabilitare l'IGP, risulterebbe un normale procio. Però AMD ha di fatto integrato negli APU l'IGP con HSA e Huma e di fatto praticamente l'IGP non è disattivabile perchè altrimenti non funzionerebbe il procio. Ora... un socket che supporti gli APU con tali caratteristiche, come può un X86 (Zen) essere compatibile? HSA/Huma come fanno a funzionare su un socket che poi lo stesso socket prevederebbe un procio con caratteristiche diversissime? Va bene che può essere risolto tutto da bios, tramite riconoscimento modello procio e quindi attivazione o meno di parti di bios, ma così facendo, non sarebbe un lavoro disumano? Si raddoppierebbero le release di aggiornamento e comunque la complessità del tutto... e questo a che pro? Non riesco a trovarne la logica...

Non voglio alzare sabbia su un nulla... ma se Zen uscirebbe ad ottobre 2016 e nella pessimistica ai primi del 2017, qualsiasi sia l'opinione personale, comunque AMD comunque DEVE avere il progetto carta/silicio di come sarà Zen, o X86 o APU, le cose che possono variare, sono in base al PP finale del 14nm, tipo quale frequenza avrà, quale TDP, quanti core nel max TDP, ecc...

[bjt2]

Originariamente inviato da tuttodigitale

che poi è la definizione che insegnano a scuola per distinguere le 2 grandi famiglie. Ma le micro-ops di Intel sono in grado di eseguire operazioni memory to register, inevitabile conseguenza quando si fondono due micro-ops.
Non volgio dire che io abbia ragione, ma si ho ragione

il link, è molto interessante.

Mi pare che le istruzioni fondibili sono solo cmp e successiva jmp condizionale... Ma deve essere immediata e non indiretta... Quindi nessuno calcolo+accesso in memoria... Anche perchè solo le unità di load store hanno accesso alla memoria (l1 dati)... Se ci sono altri casi allora sono rimasto indietro...

[bjt2]

Originariamente inviato da paolo.oliva2

Domanda banale...

Io ancora non ho capito una cosa... il socket AM4 AMD lo ha dato per compatibile sia con gli APU che con Zen.

Visto che gli APU e Zen avranno il PCI integrato e simili, l'unica differenza è che un APU avrebbe la VGA integrata e Zen, per quanto si sa, non sarebbe APU.

Quello che mi viene da riflettere, è che un APU con l'opzione di disabilitare l'IGP, risulterebbe un normale procio. Però AMD ha di fatto integrato negli APU l'IGP con HSA e Huma e di fatto praticamente l'IGP non è disattivabile perchè altrimenti non funzionerebbe il procio. Ora... un socket che supporti gli APU con tali caratteristiche, come può un X86 (Zen) essere compatibile? HSA/Huma come fanno a funzionare su un socket che poi lo stesso socket prevederebbe un procio con caratteristiche diversissime? Va bene che può essere risolto tutto da bios, tramite riconoscimento modello procio e quindi attivazione o meno di parti di bios, ma così facendo, non sarebbe un lavoro disumano? Si raddoppierebbero le release di aggiornamento e comunque la complessità del tutto... e questo a che pro? Non riesco a trovarne la logica...

Non voglio alzare sabbia su un nulla... ma se Zen uscirebbe ad ottobre 2016 e nella pessimistica ai primi del 2017, qualsiasi sia l'opinione personale, comunque AMD comunque DEVE avere il progetto carta/silicio di come sarà Zen, o X86 o APU, le cose che possono variare, sono in base al PP finale del 14nm, tipo quale frequenza avrà, quale TDP, quanti core nel max TDP, ecc...

Che io sappia esistono anche APU low end senza IGP... Ovviamente serve per forza una scheda video...

[Ren]

Originariamente inviato da Free Gordon

Puma è identico a livello di architettura?

A parte le migliorie legate al processo produttivo, minor leakage ecc..

Stessa architettura, ma hanno ridotto i consumi di parecchio(25w VS 15w) passando ad un layout con più parti full custom su silicio GF28HP.
La prima versione di jaguar aveva solo due parti custom per velocizzare il time-to-market e la portabilità verso altre fab.


ps. dimenticavo il nuovo turbo con sensore di temperatura.

[tuttodigitale]

Originariamente inviato da bjt2

Mi pare che le istruzioni fondibili sono solo cmp e successiva jmp condizionale...

ti sbagli.
tutte le istruzioni del tipo load-op possono essere fuse nelle CPU INTEL.
In più, le macro ops di AMD permettono di eseguire dei load-op-store, allo stesso indirizzo.

Originariamente inviato da Ren

Stessa architettura, ma hanno ridotto i consumi di parecchio(25w VS 15w) passando ad un layout con più parti full custom su silicio GF28HP.

il TDP è ridotto di parecchio, il consumo molto meno, ma era già estremamente competitivo. A dispetto del TDP il consumo delle APU Kabini era assai ridotto:

L'IB in questione è una soluzione da 17W, l'apu jaguar 15W. Anandtech aveva registrato consumi per l'intera piattaforma addirittura inferiori ai 20, con CPU a pieno carico l'intero sistema consumava appena 12W...
http://www.anandtech.com/show/6981/t...s-latest-apu/2

Originariamente inviato da Anand Lal Shimpi

meaning SoC power consumption is far lower, likely sub-10W

[bjt2]

Originariamente inviato da tuttodigitale

ti sbagli.
tutte le istruzioni del tipo load-op possono essere fuse nelle CPU INTEL.
In più, le macro ops di AMD permettono di eseguire dei load-op-store, allo stesso indirizzo.

Ah ok... Allora non sono più uop ma sono delle macroop... Immagino che le uop load op faranno 2 passaggi, uno nella AGU+LSU e uno nell'unità di esecuzione... Come le MOP AMD... Quindi hanno copiato da AMD... Perchè nei diagrammi delle CPU INTEL le AGU, le LSU e le unità di esecuzione normali, sono separate e su porte separate... Quindi giocoforza una load - op deve passare prima per la LSU+AGU in un registro e poi per l'unità di esecuzione... Proprio come fa AMD: c'è un calderone per le MOP e le uop componenti, nell'ordine giusto, vengono eseguite nelle varie unità e solo alla fine la MOP può essere ritirata...

Le load op store sono istruzioni CISC, hai ragione. Non ci avevo pensato. E mi viene in mente che le MOP AMD sono del tipo op, load-op, load-op-store o op-store, quindi a rigore, tranne la prima, sono tutte CISC... Chiedo venia... Immagino che tutto questo ben di dio sia stato brevettato e che lo abbia fatto AMD, visto che le MOP ci sono dal K7... Com'è che INTEL usa un meccanismo simile, anzi quasi uguale?

[Ren]

Originariamente inviato da tuttodigitale

il TDP è ridotto di parecchio, il consumo molto meno, ma era già estremamente competitivo. A dispetto del TDP il consumo delle APU Kabini era assai ridotto:

L'IB in questione è una soluzione da 17W, l'apu jaguar 15W. Anandtech aveva registrato consumi per l'intera piattaforma addirittura inferiori ai 20, con CPU a pieno carico l'intero sistema consumava appena 12W...
http://www.anandtech.com/show/6981/t...s-latest-apu/2

Se cerci il beema da 15w vedrai che il clock è salito a 1.8ghz (jaguar 1.5), in più in turbo mode si ha una frequenza di 2.4ghz. Un bel miglioramento se pensi che è frutto del layout migliorato.

[tuttodigitale]

@bjt2, anche i migliori sbagliano . Sui brevetti boh, non saprei. Come ti dicevo Intel non le chiama macro-ops, anche se sono effettivamente più lunghe delle uop ordinarie...mi pare di ricordare che siano state introdotto addirittura con il pentium M.

Originariamente inviato da Ren

Se cerci il beema da 15w vedrai che il clock è salito a 1.8ghz (jaguar 1.5), in più in turbo mode si ha una frequenza di 2.4ghz. Un bel miglioramento se pensi che è frutto del layout migliorato.

Nessuno lo nega. Ma capisci anche che se uno legge 25W->15W, 2->2,4GHz non pensa ad un miracolo di AMD, ma che kabini abbia una scarsa efficienza, cosa assolutamente errata.
http://www.anandtech.com/show/7974/a...ance-preview/2

[Ren]

Purtroppo con l'introduzione del turbo il marketing ci sguazza...

[tuttodigitale]

Originariamente inviato da Ren

Purtroppo con l'introduzione del turbo il marketing ci sguazza...

Adesso, non fare l'errore contrario di sminuirli. Il passo in avanti è consistente..

La differenza di efficienza NOMINALE è di 3x, anche ammettendo che il 63% è dovuto alla maggiore temperatura abbiamo un solido 1,8x (credo che non si sbagli ad ipotizzare un tdp reale per l'a4-5000 di 8W)

[Ren]

Peccato non ne esistano varianti desktop per farne un analisi completa senza turbo...


ps. i bench in giro sono pochi o mi sbaglio ?

[Free Gordon]

Originariamente inviato da Ren

Stessa architettura, ma hanno ridotto i consumi di parecchio(25w VS 15w) passando ad un layout con più parti full custom su silicio GF28HP.
La prima versione di jaguar aveva solo due parti custom per velocizzare il time-to-market e la portabilità verso altre fab.
ps. dimenticavo il nuovo turbo con sensore di temperatura.

Ma quindi perchè non fare delle APU desktop per sistemi vesa10x10 da piazzare negli HTPC low cost? Ho notato che con le vecchie APU (e450 e simili), Netflix ad esempio si vede a scatti... o setti la qualità in low, oppure scatta..

Con apu del genere si potrebbe avere dei bei sistemini HTPC entro i 200 euro. Credo che molti opterebbero per AMD, potendo spendere un 50-70 in meno rispetto ad Intel..

[Free Gordon]

E poi un'altra cosa che non ho mai capito è questa..

Avendo Jaguar in cantiere dal 2012...(presente tra l'altro in tutte e due le console dal 2013...) perchè in AMD non hanno evoluto quell'architettura per portarla attorno ai 3-3.5ghz, dato che dal principio si era capito che fosse certamente più efficiente di BD in ambito desktop?

A quest'ora l'eventuale "Zen" sarebbe già fuori...magari non avrebbe le prestazioni di uno skylake ma perlomeno AMD non si troverebbe in questa situazione di mercato catastrofica.. mi gioco il proverbiale nichelino..

[unnilennium]

L'efficienza r una cosa, la potenza e un'altra... Come potenza jaguar non e che sia nulla di che, gia all'uscita, su desktop poi... Il ritardo nello sviluppo di tecnologia del processo produttivo e stato il maggior problema di amd, e lo stanno ancora subendo, meno male che almeno le console vanno bene, qualche soldo in tasca entra

Inviato dal mio PLK-L01 utilizzando Tapatalk

[bjt2]

Originariamente inviato da Free Gordon

E poi un'altra cosa che non ho mai capito è questa..

Avendo Jaguar in cantiere dal 2012...(presente tra l'altro in tutte e due le console dal 2013...) perchè in AMD non hanno evoluto quell'architettura per portarla attorno ai 3-3.5ghz, dato che dal principio si era capito che fosse certamente più efficiente di BD in ambito desktop?

A quest'ora l'eventuale "Zen" sarebbe già fuori...magari non avrebbe le prestazioni di uno skylake ma perlomeno AMD non si troverebbe in questa situazione di mercato catastrofica.. mi gioco il proverbiale nichelino..

L'IPC di jaguar non poteva aumentare tanto perchè ha meno unità di BD e più semplici... Ha incidentalmente un buon IPC per l'ottimo predittore dei salti. Infatti l'hanno inserito in excavator ed ha fatto il salto di qualità... L'evoluzione di jaguar si può a tutti gli effetti considerare Carrizo.... E ora sta arrivando sul desktop... Per essere competitivo, jaguar avrebbe dovuto avere un clock troppo alto.

[riuzasan]

Originariamente inviato da paolo.oliva2

Domanda banale...

Io ancora non ho capito una cosa... il socket AM4 AMD lo ha dato per compatibile sia con gli APU che con Zen.

Visto che gli APU e Zen avranno il PCI integrato e simili, l'unica differenza è che un APU avrebbe la VGA integrata e Zen, per quanto si sa, non sarebbe APU.

Quello che mi viene da riflettere, è che un APU con l'opzione di disabilitare l'IGP, risulterebbe un normale procio. Però AMD ha di fatto integrato negli APU l'IGP con HSA e Huma e di fatto praticamente l'IGP non è disattivabile perchè altrimenti non funzionerebbe il procio. Ora... un socket che supporti gli APU con tali caratteristiche, come può un X86 (Zen) essere compatibile? HSA/Huma come fanno a funzionare su un socket che poi lo stesso socket prevederebbe un procio con caratteristiche diversissime? Va bene che può essere risolto tutto da bios, tramite riconoscimento modello procio e quindi attivazione o meno di parti di bios, ma così facendo, non sarebbe un lavoro disumano? Si raddoppierebbero le release di aggiornamento e comunque la complessità del tutto... e questo a che pro? Non riesco a trovarne la logica...

Non voglio alzare sabbia su un nulla... ma se Zen uscirebbe ad ottobre 2016 e nella pessimistica ai primi del 2017, qualsiasi sia l'opinione personale, comunque AMD comunque DEVE avere il progetto carta/silicio di come sarà Zen, o X86 o APU, le cose che possono variare, sono in base al PP finale del 14nm, tipo quale frequenza avrà, quale TDP, quanti core nel max TDP, ecc...

Na, la complessità globale alla fine è di poco superiore e il vantaggio commerciale verso i produttori esponenzialmente più alto rispetto alla vecchia idea dei due Socket (del resto Intel docet).
Piuttosto se le caratteristiche globali sono quelle sviscerate fino ad ora, Zen sarà un passo in avanti netto (con tutti gli scongiuri del caso), ma rimarrà un prodotto paragonabile alla ATTUALE generazione Intel Broadwell, già vecchia a fine 2016/inizi 2017.

Comunque (sempre incrociando le dita) sarebbero un'alternativa valida soprattutto se lato gestione SATA, Network, USb supereranno tutti quei piccoli bug/problemi della generazione attuale AMD

[Free Gordon]

Originariamente inviato da unnilennium

L'efficienza r una cosa, la potenza e un'altra...

Dicevo efficienza in ambito desktop inteso proprio come IPC
Jaguar rispetto alla sua frequenza di funzionamento era decisamente veloce. Ecco anche perchè l'hanno inserito nelle console.

Originariamente inviato da bjt2

L'IPC di jaguar non poteva aumentare tanto perchè ha meno unità di BD e più semplici... Ha incidentalmente un buon IPC per l'ottimo predittore dei salti. Infatti l'hanno inserito in excavator ed ha fatto il salto di qualità...L'evoluzione di jaguar si può a tutti gli effetti considerare Carrizo....E ora sta arrivando sul desktop...Per essere competitivo, jaguar avrebbe dovuto avere un clock troppo alto.

Perchè dici "incidentalmente"?

Seguendo i primi leak sulle console, avevo letto delle difficoltà di far salire di frequenze gli 8 core Jaguar all'interno dell'APU oltre gli 1.6ghz prestabiliti..

Al di là dell'inserimento all'interno di un'APU (con tutti i maggiori problemi di calore e leakage intrinsechi ecc ecc), c'è qualche ragione per cui non avrebbero potuto produrre un'architettura Jaguar 2° con clock molto più alti?

Considerando la resa a 1.5ghz...un Jaguar/Puma al doppio del clock (ma consumi molto più alti degli attuali 25W ovviamente..) che valori potrebbe restituire?

[tuttodigitale]

Originariamente inviato da bjt2

L'IPC di jaguar non poteva aumentare tanto perchè ha meno unità di BD e più semplici... Ha incidentalmente un buon IPC per l'ottimo predittore dei salti. Infatti l'hanno inserito in excavator ed ha fatto il salto di qualità... L'evoluzione di jaguar si può a tutti gli effetti considerare Carrizo.... E ora sta arrivando sul desktop... Per essere competitivo, jaguar avrebbe dovuto avere un clock troppo alto.

basti pensare che le HDL, che sono state il principale artefice del salto qualitativo di bulldozer, sono state impiegate anche da kabini.
L'ipc di SR nel MT, penalizzato dal CMT, era già superiore a quello di Jaguar. Sul buon ipc di Kabini (siamo sotto a PD nel ST, è meglio essere chiari) la pipeline molto più corta (indicativamente 15 vs 22 stadi) gioca un ruolo fondamentale.

[tuttodigitale]

Originariamente inviato da Free Gordon

Dicevo efficienza in ambito desktop inteso proprio come IPC
Jaguar per rispetto alla sua frequenza di funzionamento era decisamente veloce. Ecco anche perchè l'hanno inserito nelle console.

ma quello dell'ipc superiore di jaguar/puma, è una leggenda...

queste sono le prestazioni MT,

EDIT
ho tolto i riferimenti al MT, poichè in quei test ci potrebbero essere anche riferimenti a prestazioni ST, anche se visto l'ampio gap tra SR e PD lo escluderei.

edit2
in definitiva adottare soluzioni jaguar nelle console aveva due vanntaggi:
1) prestazioni per watt superiori rispetto ai core steamroller
2) prestazioni per mmq, molto superiori

Mentre il primo punto, per un TDP di 15W, le soluzioni excavator sono in netto vantaggio (ma le console sarebbero dovute uscire quest'anno), sul secondo, nonostante la cura dimagrante delle HDL (-30%), le dimensioni di un modulo, privo di l2, è di 14,8mmq contro gli appena 6,2mmq (3,1 a core) di Jaguar.. Nello stesso spazio di 2 core PD/SR (19mmq) ce ne vanno 6 di Jaguar...