[Thread Ufficiale] Aspettando ZEN

[capitan_crasy]

Originariamente inviato da stefanonweb

Scusate, una domanda molto pratica: Io vorrei solo una mobo AM4 decente ed un APU con la grafica simile a quella di un A10-7800 ma il lato x86 grossomodo al livello di un Intel Sandy Bridge 2500K (Roba di 5 anni fa)... Pensate sia possibile già con Bristol Ridge? Oppure NO? La potenza di calcolo di un 2500k pensate si possa raggiungere con un 4 core? O bisogna andare di APU 8x ecc...??? In pratica una CPU con una grafica decente ed una potenza di calcolo "normale" quando potrebbe essere disponibile? Grazie a tutti... Spero in una risposta semplice e chiara...

Per esempio questa APU potrebbe competere con un 2500k?

TBD 4 3.6/4.0 GHz 2 MB 8 CUs 512 SPs 948 MHz DDR4-2400 65W/45W

Non si ha ancora informazioni sulle APU ZEN (e ancora troppo presto), quindi niente di nuovo compresi i rumors; per Bristol Ridge dovrebbero mancare poco più di un paio di mesi all'uscita...

[Piedone1113]

Originariamente inviato da stefanonweb

Asfaltare, con un 4x... Ma allora se state parlando di 8x, 16x ecc...
Verosimilmente una APU/CPU attorno ai 200/250€ che prestazioni x86 potrebbe avere? Paragonata ad un Intel attuale intendo? Grazie...

Dovrebbe essere comparabile come ipc alle ultime soluzioni Intel (dal 5 al 7% in meno circa) ma con frequenze maggiori.
Non sappiamo di preciso le frequenze (intorno ai 3,8-4.0 ghz per l'8 core con ht attivo come clock base, si presume) ma un 2500 dovrebbe essere ampiamente superato da un'apu x4 top (ma sicuramente ci saranno modelli sempre x4 con freq più basse che potrebbero andare meno, anche se ne dubito)

[Free Gordon]

http://www.overclock.net/t/1604585/o...#post_25309361

Quì un altro utente ipotizza una situazione del genere..

[paolo.oliva2]

Originariamente inviato da dav1deser

2.4 e 5 effettivamente sono GHz...ma quelli del modulo wifi della scheda:

Lol. Al wij-fi della mono non ci avevo pensato.

Quindi la descrizione è tutta nei primi codici, ed essendo un ES con molti libero il codice non ha alcun riscontro con le frequenze.

Aspettiamo i bench, allora.

[paolo.oliva2]

Originariamente inviato da Free Gordon

http://www.overclock.net/t/1604585/o...#post_25309361

Quì un altro utente ipotizza una situazione del genere..

Comunque la tua "nasata" di prima botta ha molto senso. AMD ha puntato sul prezzo/prestazioni, se ci pensiamo, meglio il prezzo che ha e qualche Watt in più che 50$ in più e qualche Watt def in meno.

Anche con Zen probabilmente farà così... 2 modelli X8, uno sui 3,3GHz e l'altro sui 4GHz, con Vcore def taglia XL.

[cdimauro]

Originariamente inviato da george_p

Ah ok. Mi viene da pensare che questo faccia parte dei piani HSA di amd e consorzio.

Non m'ero accorto che prima mi avevi scritto, ma lo faccio ora.

HSA serve ad altro. Qui, invece, parliamo di caratteristiche di un processore che si adatta più o meno bene a gestire compiti "generici", e dunque non strettamente funzionali al rendering del frame di un videogioco.

Originariamente inviato da bjt2

Da poco più di 2 anni abbiamo comprato un sistema socket 2011 in un rack 19" con 2 GTX 690 in SLI, viste come 4 GPU. Le usiamo per il GPGPU e mi sono studiato l'architettura. Anche li (e che io sappia anche in architetture precedenti) c'è una unità scalare, mi pare 4 ogni 192. Sono usate anche per le funzioni trascendenti. Il filtro Non Local Mean che abbiamo implementato, usa exp e mi ero fatto il calcolo per vedere se eravamo limitati da quello. Purtroppo siamo limitati dalla banda L1 (neanche da quella RAM) perchè l'algoritmo è abbastanza semplice (ma non troppo semplice da essere limitati dalla banda RAM).

In questo caso potete provare a inventarvi un'altra implementazione, oppure cercare di intervallare quel calcolo con un altro (che ovviamente non stressi così la L1).

Interessante! Se 6 wide vuol dire che ha 6 decoder, è una ottima notizia...

In genere è proprio questo che s'intende.

Daltronde un modulo XV ne ha 8 per 2 thread, ma 4+4, quindi 6 decoder, magari unificati, per la teoria delle code non è tanto peggio di un 4+4!

Dipende sempre dal tipo di codice. A parità di "sportelli" a disposizione, è meglio che a servirli sia una sola coda, in modo da evitare che alcuni sportelli rimangano vuoti pur avendo una coda per gli altri.

E' il motivo per cui BD si è rivelato fallimentare, con le sue macro ALU intere accessibili soltanto dallo specifico, dedicato, thread hardware.

Originariamente inviato da tuttodigitale

nelle patch i decoder risultato 4.. in effetti se si riferissero al wide-dispatch sarebbe molto più stretta di quello che siamo pensati a pensare.

per wide in letteratura si può intendere qualsiasi cosa....per quel che ne sappiamo potrebbe essere un 6 wide-issue OoO e la cosa avrebbe anche il suo senso...

Come dicevo, per issue in genere s'intende quello. Anche dal tuo primo post:

"4 wide decoders
That makes z ten pipelines with a general four wide design."

aggiungo un dato: il fattore di scaling dai 28 ai 14nm per le gpu AMD è pari a solo a 1,7x...se questo fosse vero anche per la CPU il die ZEN sarebbe grande 251mmq.

Immagino che 1,7x sia riferito a una sola dimensione, per cui bidimensionalmente dovrebbe essere 2,89x.

Originariamente inviato da tuttodigitale

non capisco è troppa o troppo poca. Alla fine sono 2MB vs 2,5MB degli XEON Intel...non vedo sta grande differenza.

No, infatti. La soluzione a 32 core, con 64MB di cache L3, è certamente competitiva da questo punto di vista.

E' l'APU che, dalle slide del CERN, avrebbe soltanto 8MB per 16 core, che fanno appunto 512KB per core. Considerato che sono "inclusive", e che ci sono sempre 512KB di L2 per core, IMO non ha senso aver integrato questa scarsa quantità di cache L3.

Se invece ti riferisci alle dimensioni della L2, potrebbe anche essere dovuta ad algoritmi non infallibili per la predizione dei rami, a pensar male..

La dimensione della cache L2 è ragionevole/normale.

auspichi un ritorno al vliw?

No, IMO passando al paradigma SIMD hanno fatto benissimo, perché si presta meglio per carichi di lavoro abbastanza simili, come quelli che servono in ambito grafico.

Ma aver aggiunto logica e funzionalità "più da CPU", hanno complicato i core, e sprecato transistor.

Come già detto, AMD dovrebbe pensare principalmente all'ambito videoludico, mentre se vuole supportare anche il settore GPGPU computing dovrebbe offrire soluzioni appositamente potenziate da questo punto di vista.

Con gli shader processor attuali prova a coprire entrambi i settori, ma ci rimette proprio in quello per lei più importante: quello videoludico.

l'esperto sei tu, ma non penso che sia così determinante il quantitativo di l2...comunque sono 64-128KB per CU a seconda della GPU.

Come ho già detto altre volte, non sono un esperto di microarchitetture: a me piace studiarmi le architetture.

Poi per le GPU generalmente non sono disponibili molte informazioni sulle microarchitetture, e molto peggio per l'architettura, che in genere non è pubblica.

Per quanto detto, e riguardo alla cache L2, non ho quindi idea se vada bene oppure no.

AMD parla di modulo ZEN, quindi sono in parte tentato a pensare che la l3 sarà sempre presente...

Questo dice la slide del CERN.

pare proprio di si. Anzi credo che il fine ultimo dello sviluppo delle HBM sia proprio il mercato server.

In ambito server serve, però, parecchia memoria, e AMD non ne può certo integrare un grosso quantitativo.

Probabilmente sarà utile alla GPU, visto che dovrebbe essere questo l'elemento centrale dell'APU.

Se e come l'HBM potrà essere usata dai core Zen è tutto da vedere, e non mi pare di aver letto informazioni in merito.

Originariamente inviato da Free Gordon

Dati i risultati finanziari, mi sa che hai ragione..

[bjt2]

Originariamente inviato da cdimauro

In questo caso potete provare a inventarvi un'altra implementazione, oppure cercare di intervallare quel calcolo con un altro (che ovviamente non stressi così la L1).

Il filtro è tipo convolutivo e per ogni pixel fa la media pesata dell'intorno, con i pesi funzione complessa. Facendo fare al compilatore CUDA il disassemblato del codice, abbiamo confrontato varie implementazioni, scendendo da 25 ops (flop+int op) a 7 ops per ciclo per pixel (arrivando ad usare un vettore intero per gli offset in 3D, per trasformare l'indicizzazione 3D in una 1D) senza scendere di tempo di esecuzione. Overcloccando o undercloccando la ram non succede niente o quasi, invece le prestazioni sono proporzionali al clock degli SP. Le SP si stanno sempre a girare i pollici aspettando i dati della L1, o forse no, perchè di quelle 7 o 25 ops, una è una exp, che deve essere fatta nella unità scalare, di cui ce ne sono 1/32 delle SP e resta da vedere la latenza... Non ho ritenuto approfondire ulteriormente...

Originariamente inviato da cdimauro

In genere è proprio questo che s'intende.

Dipende sempre dal tipo di codice. A parità di "sportelli" a disposizione, è meglio che a servirli sia una sola coda, in modo da evitare che alcuni sportelli rimangano vuoti pur avendo una coda per gli altri.

E' il motivo per cui BD si è rivelato fallimentare, con le sue macro ALU intere accessibili soltanto dallo specifico, dedicato, thread hardware.

Ricordi di teoria delle code dall'università... Se ne sono accorte anche le poste che sono passate alla coda unica da una decina di anni almeno...

[george_p]

Originariamente inviato da cdimauro

Non m'ero accorto che prima mi avevi scritto, ma lo faccio ora.
HSA serve ad altro. Qui, invece, parliamo di caratteristiche di un processore che si adatta più o meno bene a gestire compiti "generici", e dunque non strettamente funzionali al rendering del frame di un videogioco.

Ma HSA mica nasce per svolgere solo rendering di videogames.

[paolo.oliva2]

@Capitano

Ho visto che hai postato disponibilità BR a settembre.

Io continuo a non capire il ruolo di BR... Un conto era un BR a giugno e un Zen APU 4-5 mesi dopo Zen X86 ( che se posizionassimo Zen X86 verso fine anno, BR avrebbe avuto circa 1 anno commerciale), ma a me sembra che Zen abbia le carte in tavola per essere commercializzato a settembre, quindi mi sembra che per paradosso uscirebbe prima Zen di BR... e questo indubbiamente accorcerebbe considerevolmente i tempi commerciali di BR, perché secondo me 6 mesi di tempo da Zen X86 a Zen APU sarebbero giusti per vedere commercializzato Zen APU.

Produrre BR e produrre Zen APU in termini di costo la differenza secondo me è esigua, ma è ovvio che prezzare Zen X4+4 APU concederebbe margini superiori rispetto a BR.
Io mi rifiuto di ipotizzare un Zen QPU a settembre 2017, non avrebbe senso il ritardo.

Io ho ipotizzato 3 motivi, il 1° un problema di TDP di contenere nei 15W un Zen X4+4 APU, la 2′ una differenziazione di prezzi e la 3a inquadrare Zen APU come X8 APU.

La prima cade perché guardando un X32+32 a 55W, farebbe 7W per X4+4 con L3, quindi come APU ci sguazzerebbe.
La seconda ci potrebbe anche stare, se BR viene sui 150$, un Zen X4+4 APU a 250$ ci può stare, però alzerebbe il prezzo di Zen X86 X8+8 almeno a 400$ e non vedo convenienza per AMD, nel senso che fino a disponibilità commerciale Zen X4 APU AMD non avrebbe il prezzo per competere con la fascia 1155 Intel e questo comporterebbe un volume almeno 20/30 volte inferiore.
La terza giustificherebbe in parte la seconda, perché vorrebbe dire che AMD prezzerebbe 8 core tanto quanto oggi Intel prezza i 4 core, ed ovviamente un BR a 150$ come massimo il suo spazio l'avrebbe.

Cosa ne pensi? Se ti va FI rispondere (ti faccio sbilanciare)

[paolo.oliva2]

Originariamente inviato da george_p

Ma HSA mica nasce per svolgere solo rendering di videogames.

Io penso che si debba valutate una cosa... HSA vuole la condivisione memoria video e X86, e già da Kaveti AMD offre il supporto nativamente.
Quindi se ciò vale per una L3 X86 utilizzabile dall'iGPU, non vedo che differenza ci sia se la iGPU usa le HBM in condivisione con i core X86.

Tra l'altro mi sembra che Zen APU abbia una HBM di 16GB che equivarrebbe ai 16GB che avrebbe Zen X16 X86, ma ovviamente essendo la HBM più veloce.
Aggiungo, ma non mi intendo, in BD l'interfacciamento era lFSB, in Zen si passa a 150GB/s, in BD quanto era? 15GB/s? L'ossatura di tutto l'I/O a me sembra più in veste X86/iGPU che X86 e stop, anche perché Intel ha un 4 channel su un X22 e AMD si ritroverebbe un 8 channel (+100%) con poco meno di +50% di core...

[capitan_crasy]

Originariamente inviato da paolo.oliva2

@Capitano

Ho visto che hai postato disponibilità BR a settembre.

Io continuo a non capire il ruolo di BR... Un conto era un BR a giugno e un Zen APU 4-5 mesi dopo Zen X86 ( che se posizionassimo Zen X86 verso fine anno, BR avrebbe avuto circa 1 anno commerciale), ma a me sembra che Zen abbia le carte in tavola per essere commercializzato a settembre, quindi mi sembra che per paradosso uscirebbe prima Zen di BR... e questo indubbiamente accorcerebbe considerevolmente i tempi commerciali di BR, perché secondo me 6 mesi di tempo da Zen X86 a Zen APU sarebbero giusti per vedere commercializzato Zen APU.

Produrre BR e produrre Zen APU in termini di costo la differenza secondo me è esigua, ma è ovvio che prezzare Zen X4+4 APU concederebbe margini superiori rispetto a BR.
Io mi rifiuto di ipotizzare un Zen QPU a settembre 2017, non avrebbe senso il ritardo.

Io ho ipotizzato 3 motivi, il 1° un problema di TDP di contenere nei 15W un Zen X4+4 APU, la 2′ una differenziazione di prezzi e la 3a inquadrare Zen APU come X8 APU.

La prima cade perché guardando un X32+32 a 55W, farebbe 7W per X4+4 con L3, quindi come APU ci sguazzerebbe.
La seconda ci potrebbe anche stare, se BR viene sui 150$, un Zen X4+4 APU a 250$ ci può stare, però alzerebbe il prezzo di Zen X86 X8+8 almeno a 400$ e non vedo convenienza per AMD, nel senso che fino a disponibilità commerciale Zen X4 APU AMD non avrebbe il prezzo per competere con la fascia 1155 Intel e questo comporterebbe un volume almeno 20/30 volte inferiore.
La terza giustificherebbe in parte la seconda, perché vorrebbe dire che AMD prezzerebbe 8 core tanto quanto oggi Intel prezza i 4 core, ed ovviamente un BR a 150$ come massimo il suo spazio l'avrebbe.

Cosa ne pensi? Se ti va FI rispondere (ti faccio sbilanciare)

Non entro nelle danze sui numeri del teorico TDP, ne tanto meno sulle presunte frequenze di Zen...
BR è pronto, HP e forse altri partner hanno già in mano le versioni APU "definitive" (si sono viste al Computex).
Il fatto che escano a settembre può significare che la resa produttiva non sia "eccezionale", quindi AMD si porta avanti per avere un buon numero sia per il mercato OEM, sia per quello (si spera) Retail.
Zen non esce a settembre (tranne miracoli), nel mese di luglio/agosto dovrebbero essere distribuiti ES per lo sviluppo delle schede AM4.
All'uscita di quest'ultimi dovrebbe cominciare la fase finale prima della produzioni in volumi e se tutto va bene fine anno dovremmo avere le versioni definitive.

[tuttodigitale]

Originariamente inviato da cdimauro

HSA serve ad altro. Qui, invece, parliamo di caratteristiche di un processore che si adatta più o meno bene a gestire compiti "generici", e dunque non strettamente funzionali al rendering del frame di un videogioco.

HSA serve proprio per i calcoli generici.

Originariamente inviato da cdimauro

Immagino che 1,7x sia riferito a una sola dimensione, per cui bidimensionalmente dovrebbe essere 2,89x

no è proprio 1,7x
14nm 5,7 miliardi transistor 232mmq
28nm 6,2 miliardi transistor 438mmq

lo stesso vale per nvidia. passando da maxwell (28nm) a Pascal (16nm)

Originariamente inviato da cdimauro

E' l'APU che, dalle slide del CERN, avrebbe soltanto 8MB per 16 core, che fanno appunto 512KB per core. Considerato che sono "inclusive", e che ci sono sempre 512KB di L2 per core, IMO non ha senso aver integrato questa scarsa quantità di cache L3.

in quel sito c'è scritto che le caratteristiche dell'apu sono basate su rumors...e ad essere sincero è la prima volta che lo leggo...le indiscrezioni che venga usato sempre lo stesso die si fanno sempre più insistenti. Tutto è possibile, ma una l3 da 8MB per 16 core non è possibile dai..

Originariamente inviato da cdimauro

No, IMO passando al paradigma SIMD hanno fatto benissimo, perché si presta meglio per carichi di lavoro abbastanza simili, come quelli che servono in ambito grafico.

direi proprio di no...hanno perso un pò in efficienza. Alla fine nel vliw avevi a parità di transistor avevi circa il 30% di ALU in più, e a detta di AMD nei giochi si sfruttavano mediamente 85%...ma era troppo condizionato dal compilatore e secondo me un ostacolo in più al calcolo eterogeneo.

Originariamente inviato da cdimauro

In ambito server serve, però, parecchia memoria, e AMD non ne può certo integrare un grosso quantitativo.

aspetta un attimo....se parliamo di VRAM, AMD ne può integrare 16GB, se utilizzeranno 2 die HBM per singolo package...questa quantità può sembrare poca, ma non dimenticare che la GPU può comunque comunicare con le DDR4 in configurazione quad channel, avendo accesso diretto allo spazio di indirizzamento della cpu..

Originariamente inviato da cdimauro

Se e come l'HBM potrà essere usata dai core Zen è tutto da vedere, e non mi pare di aver letto informazioni in merito.

questo non saprei dirtelo. Penso di si.

[tuttodigitale]

Originariamente inviato da paolo.oliva2

@Capitano

Ho visto che hai postato disponibilità BR a settembre.

Io continuo a non capire il ruolo di BR... Un conto era un BR a giugno e un Zen APU 4-5 mesi dopo Zen X86 ( che se posizionassimo Zen X86 verso fine anno, BR avrebbe avuto circa 1 anno commerciale), ma a me sembra che Zen abbia le carte in tavola per essere commercializzato a settembre, quindi mi sembra che per paradosso uscirebbe prima Zen di BR... e questo indubbiamente accorcerebbe considerevolmente i tempi commerciali di BR, perché secondo me 6 mesi di tempo da Zen X86 a Zen APU sarebbero giusti per vedere commercializzato Zen APU.

ma quel rumors sui problemi del chipset sono veri oppure è una montatura? Potrebbe essere questa la causa del ritardo....il ruolo è quello di vendere qualche prodotto a 100 euro...comunque qualcosa di aggiornato, soprattutto lato igp, che contrasti gli i3 ci vuole...un prezzo concorrenziale è un conto, svendere ZEN, è l'ultimo dei desideri di AMD....

PS se ZENx4 è un processorone da gioco, una igp da 1000sp, o quanto saranno, AMD se la farà pagare, puntando sul multi gpu esplicito offerto dai motori grafici dx12 (funziona anche con le gpu discrete della concorrenza), ne sono certo...

[cdimauro]

Originariamente inviato da bjt2

Il filtro è tipo convolutivo e per ogni pixel fa la media pesata dell'intorno, con i pesi funzione complessa. Facendo fare al compilatore CUDA il disassemblato del codice, abbiamo confrontato varie implementazioni, scendendo da 25 ops (flop+int op) a 7 ops per ciclo per pixel (arrivando ad usare un vettore intero per gli offset in 3D, per trasformare l'indicizzazione 3D in una 1D) senza scendere di tempo di esecuzione. Overcloccando o undercloccando la ram non succede niente o quasi, invece le prestazioni sono proporzionali al clock degli SP. Le SP si stanno sempre a girare i pollici aspettando i dati della L1, o forse no, perchè di quelle 7 o 25 ops, una è una exp, che deve essere fatta nella unità scalare, di cui ce ne sono 1/32 delle SP e resta da vedere la latenza... Non ho ritenuto approfondire ulteriormente...

Un buon profiler dovrebbe aiutare a chiarire questi problemi.

Originariamente inviato da george_p

Ma HSA mica nasce per svolgere solo rendering di videogames.

Ma infatti qui mi riferivo ai singoli core, e non all'HSA.

L'HSA nasce per facilitare la condivisione di risorse, ad esempio eliminando la necessità di copie di buffer di memoria fra CPU e GPU, e questa funzionalità è trasversale: serve sia per calcolare il determinante di una matrice (calcolo "general purpose") sia per renderizzare grafica (la CPU può "immediatamente" condividere un buffer che la GPU deve elaborare).

Mentre le funzionalità "general purpose" introdotte negli shader processor sono utili nel primo caso, e non nel secondo.

Spero che sia chiaro adesso.

Originariamente inviato da tuttodigitale

HSA serve proprio per i calcoli generici.

Ho spiegato meglio sopra.

no è proprio 1,7x
14nm 5,7 miliardi transistor 232mmq
28nm 6,2 miliardi transistor 438mmq

lo stesso vale per nvidia. passando da maxwell (28nm) a Pascal (16nm)

Non mi pare un gran risultato. Sappiamo che i 14nm di Samsung e i 16nm di TSMC non sono "veri", ma con questi numeri è come se il processo fosse un 20-22nm.

in quel sito c'è scritto che le caratteristiche dell'apu sono basate su rumors...e ad essere sincero è la prima volta che lo leggo...le indiscrezioni che venga usato sempre lo stesso die si fanno sempre più insistenti. Tutto è possibile, ma una l3 da 8MB per 16 core non è possibile dai..

Beh, è proprio quel che dico da quando ho letto quel dato.

Per cui tenderei a prender con le pinze i dati del CERN, considerato che parla pure di core 6-wide, e probabilmente nemmeno i 64KB+64KB di cache saranno veri (mentre 64KB di cache codice L1 sono plausibili per K12, similmente ad altri ARMv8, perché la densità del codice è inferiore a quella di x86/x64).

direi proprio di no...hanno perso un pò in efficienza. Alla fine nel vliw avevi a parità di transistor avevi circa il 30% di ALU in più, e a detta di AMD nei giochi si sfruttavano mediamente 85%...ma era troppo condizionato dal compilatore e secondo me un ostacolo in più al calcolo eterogeneo.

Strano, perché con un design SIMD puoi realizzare un decoder molto più semplice di uno VLIW, visto che ti basta decodificare una sola istruzione e replicare l'operazione n volte.

Però bisogna anche vedere anche cos'hanno aggiunto (in termini di funzionalità) nei core SIMD, rispetto a quelli VLIW.

Comunque non avendo documentazione su nessuna delle due architetture, non si può fare alcuna analisi.

aspetta un attimo....se parliamo di VRAM, AMD ne può integrare 16GB, se utilizzeranno 2 die HBM per singolo package...questa quantità può sembrare poca, ma non dimenticare che la GPU può comunque comunicare con le DDR4 in configurazione quad channel, avendo accesso diretto allo spazio di indirizzamento della cpu..

Quindi fino a 8GB di HBM per die. Mi sembra una quantità adeguata.

[tuttodigitale]

Originariamente inviato da cdimauro

Dipende sempre dal tipo di codice. A parità di "sportelli" a disposizione, è meglio che a servirli sia una sola coda, in modo da evitare che alcuni sportelli rimangano vuoti pur avendo una coda per gli altri.

E' il motivo per cui BD si è rivelato fallimentare, con le sue macro ALU intere accessibili soltanto dallo specifico, dedicato, thread hardware.

quello che si perde in efficienza computazionale si guadagna in efficienza energetica, non è un caso se esistono cpu da 32 core e non core da 32 thread..

[cdimauro]

Ma è roba da server, non da desktop o mobile.

[Free Gordon]

Originariamente inviato da cdimauro

Strano, perché con un design SIMD puoi realizzare un decoder molto più semplice di uno VLIW, visto che ti basta decodificare una sola istruzione e replicare l'operazione n volte.

Però bisogna anche vedere anche cos'hanno aggiunto (in termini di funzionalità) nei core SIMD, rispetto a quelli VLIW.

Comunque non avendo documentazione su nessuna delle due architetture, non si può fare alcuna analisi.

http://amd-dev.wpengine.netdna-cdn.c...chitecture.pdf

Questa è GCN1.2 (ora con Polaris sono alla terza revision)

Quindi fino a 8GB di HBM per die. Mi sembra una quantità adeguata.

Scorpio (l'unica APU Zen di cui abbiano notizia certa oggi), ha un bus a 384 bit che accede a 12 moduli di GDDR5. Stessa cosa per PS4 e PS4 Neo (tutte con controller per GDDR5).
Quindi per ora non si sa se faranno APU solo dotate di HBM o no..

[Free Gordon]

http://amd-dev.wpengine.netdna-cdn.c...aper-FINAL.pdf

Questo il pdf sui tanto chiacchierati ACE..

Nvidia imho non li implementa perchè nella sua architettura non porterebbero giovamento...tutto quì.

Non è che Maxwell e Pascal mancano di ACE per una ragione tecnica, mancano di ACE perchè gli sp di queste due architetture sono già abbastanza impegnati già ora.

[capitan_crasy]

Originariamente inviato da Free Gordon

Scorpio (l'unica APU Zen di cui abbiano notizia certa oggi), ha un bus a 384 bit che accede a 12 moduli di GDDR5. Stessa cosa per PS4 e PS4 Neo (tutte con controller per GDDR5).
Quindi per ora non si sa se faranno APU solo dotate di HBM o no..

Di certo su scorpio sappiamo che si tratta di una APU semi-custom con una potenza complessiva (?) di 6 TFLOPs.
Tutto il resto compreso che sia composta da core X86 ZEN, GPU Polaris o quant'altro sono solo rumors!

[tuttodigitale]

Originariamente inviato da cdimauro

Strano, perché con un design SIMD puoi realizzare un decoder molto più semplice di uno VLIW, visto che ti basta decodificare una sola istruzione e replicare l'operazione n volte.

le architetture VLIW di AMD non rinunciavano mica al design SIMD.

Originariamente inviato da cdimauro

Ma infatti qui mi riferivo ai singoli core, e non all'HSA.

L'HSA nasce per facilitare la condivisione di risorse, ad esempio eliminando la necessità di copie di buffer di memoria fra CPU e GPU, e questa funzionalità è trasversale: serve sia per calcolare il determinante di una matrice (calcolo "general purpose") sia per renderizzare grafica (la CPU può "immediatamente" condividere un buffer che la GPU deve elaborare).

Mentre le funzionalità "general purpose" introdotte negli shader processor sono utili nel primo caso, e non nel secondo.

Spero che sia chiaro adesso.

per la verità non è molto chiaro....
è vero che HSA sarebbe utile anche nei giochi, ma al più è stato pubblicizzato solo come acceleratore della fisica....con l'apu che diventa una sorta di CELL.
l'intento teorico, è quello di far lavorare CPU e GPU in perfetta sinergia tra loro, anche se in effetti stanno snaturando la seconda...

le funzionalità general purpose del chip va proprio in ottica HSA, perchè con questo paradigma AMD si è prefissato l'obiettivo di poter sfruttare i vantaggi offerti dalla potenza offerta dalle GPU, su un numero crescente di applicazioni