[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[Lights_n_roses]

non ci sono i mezzi per competere con intel,difficile vedere cpu desktop dopo gli fx,e da questa cosa se fosse vera intel rafforzerà ancor di piu il proprio nome il vero giocatore su pc non comprerà mai AMD ,ma è pur vero che quanti ci giocano nel vero senso della parola? pochi,ma intel sarà indice di potenza vera,lo è gia adesso figuriamoci dopo,quanti 4770 o 3770 con vga potenti ci sono ora? quanti 8350 con vga potente ci sono ora? meglio non farlo questo calcolo...

ti sbagli, AMD a questo giro avrebbe avuto l'occasione, se non di pareggiare il gap, di andarci molto vicino, ecco perchè:

- haswell va più o meno come ivy bridge

- Steamroller sembra poter tappare i buchi di piledriver aggiungendo la seconda unità elaborativa in virgola fissa per ogni modulo che diventa un core vero in questo modo

- Intel non ha in programma di sostituire haswell in modo celere.

Ma tutto ciò non è più di interesse, con le vendite di pc sempre più in calo e lo spostamento d'interesse su tablet e smartphone ( e anche sui notebook ) non interessa ad AMD spendere soldi in questo settore, almeno principalmente. Stessa cosa sta facendo pure intel.

[BULL2013]

cmq di là,nel thread di haswell sò incazzati neri per via del chipset intel serie9 non compatibile con le attuali mb 1150 con chip serie 8:D

[dav1deser]

- Steamroller sembra poter tappare i buchi di piledriver aggiungendo la seconda unità elaborativa in virgola fissa per ogni modulo che diventa un core vero in questo modo

Stai facendo molta confusione: l'unità che è singola nel modulo di PD e BD è l'unità in virgola mobile, non mi pare esista nemmeno un'unità in virgola fissa (credo siano calcoli gestibili dai core int), e in SR la FPU rimarrà una sola visto che l'idea futura è addirittura di eliminarla in favore di core GPU. Quello che verrà raddoppiato è il decoder, che teoricamente permetterà di far si che il modulo sia molto più vicino ad avere il doppio della potenza elaborativa del singolo core, rispetto ad adesso dove il modulo tende a fornire prestazioni fra le 1.5 e le 1.8 volte del singolo core. In ogni caso oltre alla FPU dovrebbero rimare condivise altre parti del modulo (per esempio la L2), quindi il modulo resterà molto diverso da due core distinti.

[capitan_crasy]

cmq di là,nel thread di haswell sò incazzati neri per via del chipset intel serie9 non compatibile con le attuali mb 1150 con chip serie 8:D

si ma questo è completamente OT...

[feldvonmanstein]

Stai facendo molta confusione: l'unità che è singola nel modulo di PD e BD è l'unità in virgola mobile, non mi pare esista nemmeno un'unità in virgola fissa (credo siano calcoli gestibili dai core int), e in SR la FPU rimarrà una sola visto che l'idea futura è addirittura di eliminarla in favore di core GPU. Quello che verrà raddoppiato è il decoder, che teoricamente permetterà di far si che il modulo sia molto più vicino ad avere il doppio della potenza elaborativa del singolo core, rispetto ad adesso dove il modulo tende a fornire prestazioni fra le 1.5 e le 1.8 volte del singolo core. In ogni caso oltre alla FPU dovrebbero rimare condivise altre parti del modulo (per esempio la L2), quindi il modulo resterà molto diverso da due core distinti.

per la L2 è un bene, come lo è in jaguar

[BULL2013]

si ma questo è completamente OT...

vero Capitano,sorry...

Cap,ma secondo te,è meglio fx 4350+mb am3+ scrausa perche non OC e vga dedicata,oppure 760k oppure quelli che verrano in futuro sempre senza IGP per cosi dire e mb FM2+ piu vga dedicata


attendo tuo illustre parere

[capitan_crasy]

ti sbagli, AMD a questo giro avrebbe avuto l'occasione, se non di pareggiare il gap, di andarci molto vicino, ecco perchè:

- haswell va più o meno come ivy bridge

- Steamroller sembra poter tappare i buchi di piledriver aggiungendo la seconda unità elaborativa in virgola fissa per ogni modulo che diventa un core vero in questo modo

- Intel non ha in programma di sostituire haswell in modo celere.

Ma tutto ciò non è più di interesse, con le vendite di pc sempre più in calo e lo spostamento d'interesse su tablet e smartphone ( e anche sui notebook ) non interessa ad AMD spendere soldi in questo settore, almeno principalmente. Stessa cosa sta facendo pure intel.

Mancano ancora due punti:
Il futuro del processo produttivo dopo Kaveri e come sarà Excavator e la sua GPU.
Per quanto riguarda le CPU secondo me non ci saranno versioni FX a 28nm anche se sulla carta esiste la possibilità di creare un 8 core Kaveri senza troppo sforzi, basandoci proprio sui moduli destinati alle APU di 4 generazione.
Insomma bisogna sperare che AMD faccia APU con un numero di moduli superiori a 2 in attesa che la GPU o sue parti diventino una parte attiva nel calcolo X86-64...

[Ascarozzo]

cmq di là,nel thread di haswell sò incazzati neri per via del chipset intel serie9 non compatibile con le attuali mb 1150 con chip serie 8:D

Ma scusate, non per essere fanboy o che altro che non me ne frega nulla.. Ma amd non fa lo stesso? Oppure hanno comunicato che tra 2 anni avrete ancora lo stesso socket ? Solo per info eh... niente flame per piacere

[BULL2013]

Purtroppo non posso che quotare in toto ciò che affermi... Almeno nel breve-medio termine (tempi informatici, quindi da qui a fine 2014), ma sarei il primo ad essere contento di essere smentito... :(

io il secondo


Ma scusate, non per essere fanboy o che altro che non me ne frega nulla.. Ma amd non fa lo stesso? Oppure hanno comunicato che tra 2 anni avrete ancora lo stesso socket ? Solo per info eh... niente flame per piacere

ma come?? in questo thread ce ne sono a centinaia di post in cui si dice che l'am3+ è decrepito,fatti il conto da quanto tempo c'è,e poi cmq di nuovo sta per arrivare l'fm2+ retrocompatibile con fm2...

cioè ti rendi conto se ti sei preso un haswell su sk 1150 e chip serie 8 non potrai montare un broadwell sempre su sk 1150 perchè avranno chip serie 9 e mb dedicate

[Grizlod®]

ti sbagli, AMD a questo giro avrebbe avuto l'occasione, se non di pareggiare il gap, di andarci molto vicino, ecco perchè:

- haswell va più o meno come ivy bridge

- Steamroller sembra poter tappare i buchi di piledriver aggiungendo la seconda unità elaborativa in virgola fissa per ogni modulo che diventa un core vero in questo modo

- Intel non ha in programma di sostituire haswell in modo celere.

Ma tutto ciò non è più di interesse, con le vendite di pc sempre più in calo e lo spostamento d'interesse su tablet e smartphone ( e anche sui notebook ) non interessa ad AMD spendere soldi in questo settore, almeno principalmente. Stessa cosa sta facendo pure intel.Non ci metterei la mano sul fuoco a riguardo, basti pensare al parco server che ha AMD...mica puo abbandonarlo così, come se niente fosse...
Quindi di riflesso dovrà ricavarne CPU desktop high-end...non si scappa.

Cmq Steamroller aggiunge un decoder a modulo; la FPU resta condivisa, così come la cache di secondo livello:

http://img22.imageshack.us/img22/165/nvlh.jpg (http://img22.imageshack.us/i/nvlh.jpg/)

http://img42.imageshack.us/img42/5795/pi7j.jpg (http://img42.imageshack.us/i/pi7j.jpg/)

Promette di migliorare anche le prestazioni single threaded:

http://img716.imageshack.us/img716/4264/j9lf.jpg (http://img716.imageshack.us/i/j9lf.jpg/)

[carlottoIIx6]

:eek: non capisco come mai il phenom 1100 va così piano in questo gioco rispetto a un fx6350 :eek: e poi un fx-4100 default che batte un phenom 965 ?

probabilmente istruzione mancante.

[Ascarozzo]

cioè ti rendi conto se ti sei preso un haswell su sk 1150 e chip serie 8 non potrai montare un broadwell sempre su sk 1150 perchè avranno chip serie 9 e mb dedicate

Eh...... io adesso penso a godermi la mia nuova cpu, poi quando uscirà la nuova Broadwell ne riparleremo.

[paolo.oliva2]

Mancano ancora due punti:
Il futuro del processo produttivo dopo Kaveri e come sarà Excavator e la sua GPU.
Per quanto riguarda le CPU secondo me non ci saranno versioni FX a 28nm anche se sulla carta esiste la possibilità di creare un 8 core Kaveri senza troppo sforzi, basandoci proprio sui moduli destinati alle APU di 4 generazione.
Insomma bisogna sperare che AMD faccia APU con un numero di moduli superiori a 2 in attesa che la GPU o sue parti diventino una parte attiva nel calcolo X86-64...
Anche io condivido che AMD non farà FX/Opteron Steamroller, anche perchè un 28nm Bulk non penso possa permettere un X16 Opteron che anche su architettura Steamroller possa arrivare nei 140W ad un guadagno consistente su un Piledriver che pur con IPC inferiore comunque già ora raschia i 3GHz per 140W TDP e che con Varsavia sicuramente guadagnerà frequenze più alte.

Sarebbe possibile, ipotizzando 3 scenari differenti

Exavator APU sul 28nm Bulk
Exavator APU su una miniaturizzazione più spinta del 28nm Bulk ma sempre Bulk
Exavator APU sull'FD-SOI

In tutti e 3 i casi, qualsiasi sia stato il problema di non produrre un FX/Opteron su base Steamroller (chiaramente a parte la volontà), non ci sarebbe alcun senso a produrre un Steamroller FX/Opteron ma tutti i vantaggi per condividere il processo sia produttivo che di sviluppo degli APU... no?

[carlottoIIx6]

Anche io condivido che AMD non farà FX/Opteron Steamroller, anche perchè un 28nm Bulk non penso possa permettere un X16 Opteron che anche su architettura Steamroller possa arrivare nei 140W ad un guadagno consistente su un Piledriver che pur con IPC inferiore comunque già ora raschia i 3GHz per 140W TDP e che con Varsavia sicuramente guadagnerà frequenze più alte.

Sarebbe possibile, ipotizzando 3 scenari differenti

Exavator APU sul 28nm Bulk
Exavator APU su una miniaturizzazione più spinta del 28nm Bulk ma sempre Bulk
Exavator APU sull'FD-SOI

In tutti e 3 i casi, qualsiasi sia stato il problema di non produrre un FX/Opteron su base Steamroller (chiaramente a parte la volontà), non ci sarebbe alcun senso a produrre un Steamroller FX/Opteron ma tutti i vantaggi per condividere il processo sia produttivo che di sviluppo degli APU... no?

o c'è qualche silicio buono che arriva

[paolo.oliva2]

probabilmente istruzione mancante.
Basterebbe fare un controllo incrociato.
Gli Haswell supportano tutti i set di istruzioni tanto quanto i Piledriver... quindi se negli stessi giochi sia gli Haswell che i Piledriver hanno incrementi superiori rispetto all'incremento medio di IPC, è facile trarne le conclusioni.

Del resto, l'8150 ha più set di istruzioni rispetto al Phenom II, ma qualche cosa di meno rispetto a Piledriver, ma 2 anni fa stava sotto al Thuban in tutto tranne nell'MT dove guadagnava ma poco, mentre nelle ultime rece risulta essere davanti in qualsiasi situazione.

[digieffe]

A questo punto, resto estremamente curioso di sapere quanto guadagnerà, a parità di frequenza, la parte cpu delle nuove apu steamroller: penso e spero non meno del 15% a ciò da aggregare la variazione di frequenza in su o in giù.

invece per varsaw, hanno dichiarato +15% di efficienza tdp, che va dritto a 4.3 def. immagino su nuovo step produttivo.

[capitan_crasy]

vero Capitano,sorry...

Cap,ma secondo te,è meglio fx 4350+mb am3+ scrausa perche non OC e vga dedicata,oppure 760k oppure quelli che verrano in futuro sempre senza IGP per cosi dire e mb FM2+ piu vga dedicata


attendo tuo illustre parere

Il socket FM2+ è quello con più longevità, compatibile anche con le APU FM2...
La serie FX x4 è avvantaggiata nei giochi per via della cache L3, ma come sappiamo la sua infrastrutturaè avvolta dal limbo...
Se guardo al futuro sicuramente scheda mamma socket FM2+, se non giochi meglio un A8-6600, altrimenti un 7x0k con scheda discreta.
Tuttavia se hai bisogno di un sistema più da gioco meglio puntare sulla serie FX-6000 socket AM3+...

[capitan_crasy]

Anche io condivido che AMD non farà FX/Opteron Steamroller, anche perchè un 28nm Bulk non penso possa permettere un X16 Opteron che anche su architettura Steamroller possa arrivare nei 140W ad un guadagno consistente su un Piledriver che pur con IPC inferiore comunque già ora raschia i 3GHz per 140W TDP e che con Varsavia sicuramente guadagnerà frequenze più alte.

Sarebbe possibile, ipotizzando 3 scenari differenti

Exavator APU sul 28nm Bulk
Exavator APU su una miniaturizzazione più spinta del 28nm Bulk ma sempre Bulk
Exavator APU sull'FD-SOI

In tutti e 3 i casi, qualsiasi sia stato il problema di non produrre un FX/Opteron su base Steamroller (chiaramente a parte la volontà), non ci sarebbe alcun senso a produrre un Steamroller FX/Opteron ma tutti i vantaggi per condividere il processo sia produttivo che di sviluppo degli APU... no?

Excavator dovrebbe uscire nel 2015 quindi siamo quasi sicuri che dovremmo parlare di 20nm o giù di li, io spero sempre in APU Kaveri a tre moduli...

[Athlon 64 3000+]

hai provato altre memorie oltre alle corsair? potrebbe essere un problema di compatibiltà

al posto della corsair ho montato delle gskill,ma i problemi dei blocchi temporanei li dava lo stesso.

[digieffe]

Excavator dovrebbe uscire nel 2015 quindi siamo quasi sicuri che dovremmo parlare di 20nm o giù di li, io spero sempre in APU Kaveri a tre moduli...
ciao capitano,
devi tenere conto che (teoricamente) un 28nm consumerebbe il 75% di un 32mn, questo a parità di tipo e qualità di processo: ora stiamo paragonando un 32nm soi dei più sfortunati ad un incognito 28nm bulk.
Inoltre l'architettura steamroller consumerà di più per via del frontend potenziato.

Intuitivamente un attuale 6800 potrebbe consumare ~75W a 28nm (se questo sarà efficiente quanto il soi 32nm).
Non so quanto consumino le componenti dell'apu condivise* ~25W? in caso affermativo allora ci sarà possibilità per il terzo modulo.

Tutto dipende da quanto sarà efficiente questo PP, quanto consumerà in più il doppio decoder e quanto consumeranno le componenti condivise.


*non quelle condivise nel modulo ma quelle dell'intera apu: controller di memoria, gpu in idle, ecc.


EDIT: mi ricordo che qualcuno, credo Paolo, sapesse i consumi del singolo modulo.

[paolo.oliva2]

o c'è qualche silicio buono che arriva
Dubito.
La realizzazione di Varsavia sul 32nm SOI atteso nel 1° trimestre 2014 ed idem sul lato Bulk sempre nel 1° trimestre con Kaveri.
Il lasso di tempo commerciale canonico è 12 mesi, ed infatti Exavator APU è stato roadmappato da AMD per il 2015, quindi l'incognita sarebbe su quale silicio.

L'unica cosa che potrei ipotizzare, ma solo a fantasia, è che AMD per decollare abbia bisogno di una miniaturizzazione silicio e di una qualità silicio buona, per avere un TDP più basso possibile per avere l'opportunità o di avere frequenze idonee alle sue pipeline o comunque margine per aumentare i moduli. Quello che potrebbe offrire AMD per spronare la FAB X è quello di accorpare tutta la produzione APU e Opteron/FX (a parte la fascia bassa che è prodotta da TSMC mi sembra), da una parte per garantire il massimo volume possibile di produzione, dall'altra per abbattere il più possibile i costi con una evoluzione su carta del modulo poi trasferita sullo stesso silicio e quindi di fatto un modulo pronto per APU/Opteron/FX.

[paolo.oliva2]

ciao capitano,
devi tenere conto che (teoricamente) un 28nm consumerebbe il 75% di un 32mn, questo a parità di tipo e qualità di processo: ora stiamo paragonando un 32nm soi dei più sfortunati ad un incognito 28nm bulk.
Inoltre l'architettura steamroller consumerà di più per via del frontend potenziato.

Intuitivamente un attuale 6800 potrebbe consumare ~75W a 28nm (se questo sarà efficiente quanto il soi 32nm).
Non so quanto consumino le componenti dell'apu condivise* ~25W? in caso affermativo allora ci sarà possibilità per il terzo modulo.

Tutto dipende da quanto sarà efficiente questo PP, quanto consumerà in più il doppio decoder e quanto consumeranno le componenti condivise.

*non quelle condivise nel modulo ma quelle dell'intera apu: controller di memoria, gpu in idle, ecc.

EDIT: mi ricordo che qualcuno, credo Paolo, sapesse i consumi del singolo modulo.
Non me li ricordo... :D.
Però... secondo me, a spannella, basta vedere le frequenze di Richland X4 a 95W TDP confrontandole ad un equivalente FX X4, da qui valutare le differenze e proiettare il tutto sul confronto di un FX X6, tenendo presente che Richland ha frequenze superiori a Trinity.
Inoltre consideriamo anche il fatto che i TDP degli X4 e X6 FX sono di manica larga, sulla base di un 8300 X8 95W TDP.

Fatto questo, da una parte abbiamo un incremento di transistor di Steamroller che aumenterebbe il TDP, dall'altro un'architettura che quasi per scontato sarà più ottimizzata lato consumi, quindi sparando dati a caso, +20W TDP per il numero superiore di transistor ma che effettivamente avrà un valore inferiore... e la miniaturizzazione più spinta che dovrebbe abbassare ulteriormente il TDP.
Oltre a questo, avremmo pur sempre una condizione più favorevole del silicio.
Se IPC 100 a frequenza 4GHz producesse 400, aumentare l'IPC aumenterebbe comunque il TDP, ma a parità di potenza si avrebbe un TDP inferiore per via di frequenze operative più basse, ed un guadagno foss'anche lieve, ma pur sempre un guadagno.

Ricordiamoci che un Thuban 1100T era 3,3GHz come X6 ma aveva performances MT ben superiori ad un Phenom II 980 e perdeva 100MHz come X4... BD è molto più ottimizzato del Phenom II nella logica turbo, vedi l'8350 che rispetto ad un FX X4 perde 100MHz mi sembra, credo difficile che un Kaveri X6 possa nella condizione peggiore perdere più di 200-300MHz, quindi sempre e comunque meglio di un Thuban vs Phenom II X4, quindi, collegando il fatto delle foto kaveri 3 moduli, difficile che se AMD abbia l'intenzione, il silicio non lo possa permettere (tipo Komodo).

P.S.
Cacchio, mi sono accorto che almeno su una cosa ci avevo azzeccato... "vedremo prima un APU X6 di un FX X10".

[BULL2013]

Il socket FM2+ è quello con più longevità, compatibile anche con le APU FM2...
La serie FX x4 è avvantaggiata nei giochi per via della cache L3, ma come sappiamo la sua infrastrutturaè avvolta dal limbo...
Se guardo al futuro sicuramente scheda mamma socket FM2+, se non giochi meglio un A8-6600, altrimenti un 7x0k con scheda discreta.
Tuttavia se hai bisogno di un sistema più da gioco meglio puntare sulla serie FX-6000 socket AM3+...

diciamo che gioco.. ma voglio aspettare le apu kaveri e relativi chip con igp mancante,ho visto in rete mb fm2+ che non hanno niente da invidiare a mb 990/970... troppo toste per "semplici" chip

aspetto ,grazie Cap

[paolo.oliva2]

Zambesi e Vishera hanno un TDP massimo di Package di 234 o 237W TDP, non ricordo bene.
Non so che TDP massimo abbiano le APU... suppongo comunque inferiore a quello degli FX, ma penso che la commercializzazione a max 95W TDP non dipenda da un TDP Package risicato, visto che altrimenti non si potrebbero avere OC di APU di poco inferiori agli FX (Richland a @5,150GHz).

Collegando questo al fatto che Kaveri dovrebbe avere un socket modificato (FM2+), sia per un Kaveri X6 "striminzito" che nel caso di stasi prolungata degli FX, analizzando che le vendite APU vanno bene, un socket FMX che estenda il supporto a 125W TDP lo vedrei indispensabile ed irrinunciabile... perchè comunque allargherebbe l'offerta di APU.
Che AMD non lo faccia, per me escluderebbe parecchie cose.

[LS1987]

Zambesi e Vishera hanno un TDP massimo di Package di 234 o 237W TDP, non ricordo bene.
Non so che TDP massimo abbiano le APU... suppongo comunque inferiore a quello degli FX, ma penso che la commercializzazione a max 95W TDP non dipenda da un TDP Package risicato, visto che altrimenti non si potrebbero avere OC di APU di poco inferiori agli FX (Richland a @5,150GHz).

Collegando questo al fatto che Kaveri dovrebbe avere un socket modificato (FM2+), sia per un Kaveri X6 "striminzito" che nel caso di stasi prolungata degli FX, analizzando che le vendite APU vanno bene, un socket FMX che estenda il supporto a 125W TDP lo vedrei indispensabile ed irrinunciabile... perchè comunque allargherebbe l'offerta di APU.
Che AMD non lo faccia, per me escluderebbe parecchie cose.

Potrebbe potenziare la GPU, perché se facesse un Kaveri X 8, quasi nessuno comprerebbe più FX 4300 e 6300. Spero che in 125 W possa fare un X 6 + HD 7770 equivalente in futuro :).

[epimerasi]

...

- Steamroller sembra poter tappare i buchi di piledriver aggiungendo la seconda unità elaborativa in virgola fissa per ogni modulo che diventa un core vero in questo modo ...

:mbe:

Ma tutto ciò non è più di interesse, con le vendite di pc sempre più in calo e lo spostamento d'interesse su tablet e smartphone ( e anche sui notebook ) non interessa ad AMD spendere soldi in questo settore, almeno principalmente. Stessa cosa sta facendo pure intel.

Ma poi, il fatto che non escano più FX non vuol dire che non continuino a sviluppare CPU per server.

[epimerasi]

Non ci metterei la mano sul fuoco a riguardo, basti pensare al parco server che ha AMD...mica puo abbandonarlo così, come se niente fosse...
Quindi di riflesso dovrà ricavarne CPU desktop high-end...non si scappa....


Ma non è vero.

Ragionate ancora come se AMD avesse le sue FAB con le linee produttive da riempire a tutti i costi.

Non è così, anzi. Adesso che è fabless può pensare di separare la progettazione di CPU desktop e CPU server, che di fatto hanno esigenze di elaborazione MOOOOLTO diverse.

[BULL2013]

cut

[Grizlod®]

Ma non è vero.

Ragionate ancora come se AMD avesse le sue FAB con le linee produttive da riempire a tutti i costi.

Non è così, anzi. Adesso che è fabless può pensare di separare la progettazione di CPU desktop e CPU server, che di fatto hanno esigenze di elaborazione MOOOOLTO diverse.

Non è da adesso che AMD è fabless, l'avrebbe già attuato un piano simile...

La questione è che comunque le linee produttive le dovrà pagare e seppur per le APU possa avere una (o più) linea(e) dedicate, sarà così per i processori server/workstation. Ne consegue che (oggi più che mai...) la politica commerciale, impone di non poter buttare nulla; indi per cui è inevitabile ricavarne CPU per desktop. Risulta praticamente impossibile anche con le tecnologie litografiche odierne più all'avanguardia, ricavarne chip eccellenti per il solo settore server...

Mi auguro ed auguro ad AMD, che GloFo riesca a proporre un processo produttivo all' altezza, ma la vedo dura (per come sperano alcuni...) andare oltre l'octacore per Steamroller. Il decoder aggiuntivo per le istruzioni, consuma parecchio; non per nulla, in sede progettuale, hanno tolto una pipeline MMX, rispetto a Bulldozer/Piledriver.

[Grizlod®]

Dimenticavo...il discorso 'a parte' per le CPU server, è strettamente legato alla necessità di avere una (abbondante?) cache di terzo livello.

[paolo.oliva2]

Non è da adesso che AMD è fabless, l'avrebbe già attuato un piano simile...

La questione è che comunque le linee produttive le dovrà pagare e seppur per le APU possa avere una (o più) linea(e) dedicate, sarà così per i processori server/workstation. Ne consegue che (oggi più che mai...) la politica commerciale, impone di non poter buttare nulla; indi per cui è inevitabile ricavarne CPU per desktop. Risulta praticamente impossibile anche con le tecnologie litografiche odierne più all'avanguardia, ricavarne chip eccellenti per il solo settore server...

Mi auguro ed auguro ad AMD, che GloFo riesca a proporre un processo produttivo all' altezza, ma la vedo dura (per come sperano alcuni...) andare oltre l'octacore per Steamroller. Il decoder aggiuntivo per le istruzioni, consuma parecchio; non per nulla, in sede progettuale, hanno tolto una pipeline MMX, rispetto a Bulldozer/Piledriver.

Dimenticavo...il discorso 'a parte' per le CPU server, è strettamente legato alla necessità di avere una (abbondante?) cache di terzo livello.

L'evoluzione architetturale del modulo è consivisibile APU/FX/Opteron, che poi l'APU abbia il PCI integrato, l'IGP e una logica diversa dell'MC rispetto agli FX, come negli FX/Opteron un I/O più corposo e la L3, io vedo il tutto nella logica di un'architettura il cui cuore (modulo) è standard per tutti i modelli, ed il resto fa parte di un'insieme modulare intercambiabile a seconda del prodotto finale. Il problema verrebbe quando l'evoluzione del modulo sarebbe specificatamente per APU, ma probabilmente sarebbe arrivato il tempo di Opteron APU.

Personalmente a me piace più AMD attuale che quando aveva le FAB. Pensiamo a 10 anni (circa) in cui ha dormito sull'architettura Phenom, partendo dal Phenom I per finire al Phenom II X6... ha fatto di più ora in 3 anni... Llano, BD Zambesi, BD Piledriver con APU Trinity e Richland e FX/Opteron Vishera e Varsavia, BD Steamroller APU, Exavator APU e presumibile FX/Opteron... ed il tutto non è commercializzabile più per motivi di silicio che per sviluppo architetturale.

Ai tempi del Phenom II il vero problema era il realizzo di una nuova architettura, in quanto un Thuban anche se realizzato sul 32nm non sarebbe comunque stato al passo con i tempi... Oggi, con un BD modulare, il problema della potenza totale dipende praticamente solamente dal silicio. Un IPC ai massimi livelli di certo porta problematiche inferiori rispetto ad un IPC più basso (frequenze più alte e TDP maggiori a uguale potenza), ma se consideriamo quasi dignitoso la potenza a core di un Phenom II, comunque Piledriver stando agli ultimi confronti esprime potenze maggiori a parità di core, e Steamroller/Exavator miglioreranno ulteriormente la situazione.
In questo contesto e considerando la modularità di BD, la reale potenza massima esprimibile dipende più dal silicio che dall'architettura.

In questo momento supponendo un Kaveri X6 con una IGP potenza 100 su un 28nm, su un 20nm si avrebbe un margine TDP ben superiore, che si potrebbe utilizzare interamente a livello di IGP o X86/IGP o tutto X86 tramite frequenze maggiori e/o aumento di 1 modulo.

Qui aggiungo il mio discorso di aumento di core, devo dire che riflettendo io sono sempre partito calcolando se c'era margine di TDP sul silicio, mentre sia AMD che Intel aumentano il numero dei core solo quando lato architettura e lato silicio non c'è più margine... cioè io guardavo da destra mentre "loro" guardano da sinistra :D.
Esempio Phenom II X4.
- massima evoluzione architetturale Phenom, quindi IPC non migliorabile senza interventi profondi all'architettura.
- Il Phenom II andava in crisi verso i @4,5GHz (e con i 3,8GHz def di un 980, oramai si era al margine).
Questo porta alla condizione di non miglioramento nè lato architettura nè lato silicio, quindi = via all'aumento dei core.
Esempio BD.
Zambesi non era nè al massimo dell'architettura nè al massimo della frequenza sfruttabile dall'architettura... aumentare i core (Komodo) è chiaro che non è fattibile.
Piledriver aumenta l'IPC ma ancora non si è al massimo dell'architettura ed idem la frequenza operativa non ha raggiunto limiti architetturali (vedi OC e vedi Varsavia).
Steamroller... aumenterà l'IPC ma comunque il Bulk non va tanto d'accordo con il numero dei transistor, ed il discorso APU sia per il limite dei 95W TDP sia per tipologia, non interessa > X6.
Exavator... tutto dipende dal TDP a modulo, nel senso che se tra IPC e Frequenza operativa si arrivasse ad un TDP che moltiplicato x n moduli non si arrivasse a sfruttare completamente i 125W, non penso che AMD fermi un Exavator a 95W TDP... come del resto se 4 moduli arrivassero a sfruttarli, non ci sarebbe alcun motivo di aumentare i moduli.

[Grizlod®]

A mio parere di esempi s ne potrebbero fare a iosa, ma se non si sa quacosa di preciso sul silicio che adotteranno, IMO, qualunque esempio è aria fritta.

Posso farne uno anch'io; ammettendo che usino un pp 24 (22)nm SOI, posso ragionevolmente pensare che mantengano la stessa impostazione di massima. Ora calcolando l'aumento d'efficienza, IPC ecc. di Stramroller, potrebbero pure diminuire leggermente la sua frequenza operativa (ma sempre UNLOCKED), portare il CPU/NB a 2400 Mhz, stock freq, migliorare il DRAM controller per DDR3 a 2133 MHz (per due moduli DIMM) e portare il quantitativo di cache L3 a 12 MByte (due blocchi da 6 MByte).

Con +/- le stesse impostazioni ci ricaverebbero gli Opteron, ma in entrambi i casi, "tutta questa roba" consuma corrente e non poco IMO, per cui la vedo dura aumentare il n° di 'compute unit'.

EDIT: Riguardo le APU per server, tuttalpiù, ritengo possano interessare il campo microserver, cioè SeaMicro...

[paolo.oliva2]

A mio parere di esempi s ne potrebbero fare a iosa, ma se non si sa quacosa di preciso sul silicio che adotteranno, IMO, qualunque esempio è aria fritta.

Posso farne uno anch'io; ammettendo che usino un pp 24 (22)nm SOI, posso ragionevolmente pensare che mantengano la stessa impostazione di massima. Ora calcolando l'aumento d'efficienza, IPC ecc. di Stramroller, potrebbero pure diminuire leggermente la sua frequenza operativa (ma sempre UNLOCKED), portare il CPU/NB a 2400 Mhz, stock freq, migliorare il DRAM controller per DDR3 a 2133 MHz (per due moduli DIMM) e portare il quantitativo di cache L3 a 12 MByte (due blocchi da 6 MByte).

Con +/- le stesse impostazioni ci ricaverebbero gli Opteron, ma in entrambi i casi, "tutta questa roba" consuma corrente e non poco IMO, per cui la vedo dura aumentare il n° di 'compute unit'.

EDIT: Riguardo le APU per server, tuttalpiù, ritengo possano interessare il campo microserver, cioè SeaMicro...

Conta anche che ci sono le librerie ad alta densità... che non so se sarebbero compatibili con tutti i tipi e trattamento di silicio, ma considerando che a memoria apportavano un 30% di consumo inferiore e risparmio di susperficie, unito al passaggio dal 32nm al 22nm, non mi stupirebbe affatto che 16MB di L3 consumerebbero meno di 8MB attuali.

Tra l'altro... Steamroller riduce la L2 a seconda della necessità nel modulo... e su Exavator c'erano voci di un raddoppio degli INT ed FP... facendo 2+2. non sarebbe ipotizzabile un modulo che praticamente sarebbe un doppione rispetto all'attuale, ma teoricamente più parco di consumi (teorizzando 4MB di L2 ridimensionabile) e con il vantaggio che AMD essendosi fatta un po' le ossa con BD, una volta che la parte smistamento funzionerebbe meglio, sarebbe più idoneo al saltellamento dei TH e quant'altro.
Cioè, non dico un raddoppio dei core a procio, ma anzichè 4 moduli si avrebbe lo stesso numero di core ma con metà moduli, un "lavoro" inferiore per la comunicazione dei dati con la L3...

[Filodream]

Come lo vedete un 9590 a 350 spedito ?
Nessuno qui ne ha preso uno ? .. :p

[LurenZ87]

Come lo vedete un 9590 a 350 spedito ?
Nessuno qui ne ha preso uno ? .. :p

Na... Mmm vediamo... "Corazzata Potemkin" :asd:

No dai, ci ho comprato quasi un anno fa un i7 3930k C2 nuovo per poco di più.



Inviato dal mio Nexus 4 con Tapatalk 2

[epimerasi]

Non è da adesso che AMD è fabless, l'avrebbe già attuato un piano simile...

E sì, tira fuori architetture dal cilindro in qualche mese.

Che poi è esattamente quello che sta facendo (bulldozer + bobcat, con relative evoluzioni). Nulla le vieta di differenziarsi anche sui server, dove i tempi di sviluppo, per altro, sono molto più lunghi e si è sempre conservativi.

Comunque non sto dicendo che farà così.

Sto solo dicendo che date per scontate troppe cose che non sapete.

EDIT: Aggiungo, esempi di processori esistenti solo nel mercato server ci sono eccome, sennò POWER e SPARC che li sviluppano a fare?

[Grizlod®]

Conta anche che ci sono le librerie ad alta densità... che non so se sarebbero compatibili con tutti i tipi e trattamento di silicio, ma considerando che a memoria apportavano un 30% di consumo inferiore e risparmio di susperficie, unito al passaggio dal 32nm al 22nm, non mi stupirebbe affatto che 16MB di L3 consumerebbero meno di 8MB attuali.Vero...ben venga tale feature, purchè regga, non solo frequenze stock, ma anche overclock importanti (FX lo vedo solo Unlocked :D ). E' altresì possibile che in tali condizioni (HDL), un raddoppio della cache L3, consumi similmente agli 8 MByte attuali.

Tra l'altro... Steamroller riduce la L2 a seconda della necessità nel modulo... e su Exavator c'erano voci di un raddoppio degli INT ed FP... facendo 2+2. non sarebbe ipotizzabile un modulo che praticamente sarebbe un doppione rispetto all'attuale, ma teoricamente più parco di consumi (teorizzando 4MB di L2 ridimensionabile) e con il vantaggio che AMD essendosi fatta un po' le ossa con BD, una volta che la parte smistamento funzionerebbe meglio, sarebbe più idoneo al saltellamento dei TH e quant'altro.Non sono informato su Excavator, per cui non mi pronuncio. Tra l'altro, passerà ancora parecchio tempo prima di poterlo vedere...
Cioè, non dico un raddoppio dei core a procio, ma anzichè 4 moduli si avrebbe lo stesso numero di core ma con metà moduli, un "lavoro" inferiore per la comunicazione dei dati con la L3... :eek: Non riesco ad immaginare un'architettura simile, ma semmai, IMO, il vantaggio principale sarebbe l'interfacciamento (quindi comunicazione) con la cache L2. Penso che tu ne preveda 6 od 8 MByte condivisi, secondo i cores per modulo...mah, difficile che AMD "stravolga" così pesantemente, anche perchè ha poche risorse per eventualmente poterselo permettere IMO.

[RedPrimula]

Ciao ragazzi. Sto testando un po' la cpu in questi giorni. Tralasciando il normale utilizzo quotidiano, in ambito gaming per quanto prima con l'i3 giocavo tranquillamente a tutto e a bf3 anche nelle mappe a 64, nelle fasi più concitate c'erano quasi sempre dei cali di frame drastici. Adesso invece la gpu non si schioda dal 99% d'utilizzo, tutto a vantaggio degli fps ora stabili. Idem o quasi con crysis 3.

Sono soddisfatto anche per le temperature, le stesse che avevo con l'i3. In questi giorni di afa che ha fatto qui da me sta sui 57° in full e 36-38 in idle.

PS: per i 4.1ghz ho settato 1.38 con offset di +0,025 per compensare il lieve vdrop in fase di carico. Ho notato con cpu-z che resta stabile fino agli 1.35 circa... e penso che con una mobo con 8+2 fasi riuscirei a dargli di meno da bios, ma mi sta bene così.

[paolo.oliva2]

@Grizlod

Neanche io so nulla di Exavator... avevo solamente sentito delle voci sul raddoppio degli INT e mi sembra anche dell'FP... siccome credo improbabile al 100% progettare una tale architettura prevedendo 4 moduli, appunto perchè AMD probabilmente è possibile che possa aver pianificato ad esempio con GF l'FD-SOI a Xnm, ma certamente non può progettare una release dell'architettura BD senza prima sapere le caratteristiche del silicio...

Con tutti gli sbelinamenti che ho fatto sull'8350, a me sembra che il vero prb sia all'interno del modulo con il CMT, perchè ha un prb a smistare i dati (per dirla in un modo semplice), perchè con 1 core a modulo l'IPC se proprio non è simile al Phenom II è maggiore (con tutto il vantaggio di un 10% almeno di clock in più).

Magari dico una vaccata, però è come se il CMT nelle intenzioni doveva risparmiare un 20% di transistor per consentire un aumento dei core finali (vedi X6 Thuban - X8 Buldozer) ma comunque ottenere prestazioni simili al core Phenom II. Nella realtà, l'IPC si è rivelato più basso... e se AMD aumenta decoder e quant'altro nel modulo, aumenterebbe il numero dei transistor facendo decadere il concetto del CMT. Magari realizzando l'unione di 2 moduli, risparmierebbe tutta la circuiteria di 2 cache L2 distinte in una unificata e nel contempo, penso che una L2 che utilizza solo la ram che gli serve possa generare un TDP inferiore rispetto a 2 L2 distinte... oltre il fatto che una doppia FPU attuale, risolverebbe comunque istruzioni AVX doppie che mi sembra sarebbero un vero problema in futuro (o qualcosa di simile).
Io non mi intendo assolutamente di sto basso livello del procio... però parto dal concetto che sia più semplice realizzare 2 strade a 4 corsie che 4 strade a 2 corsie (L3 verso 2 L2 che verso 4) e nel contempo una condivisione dei dati verso i core a livello più basso della L2, cioè, ad esempio Intel i dati comunque li ha sempre nella L3 senza bisogno di andarli a cercare nelle L2 dei core, cosa che invece AMD fa di norma perdendo cicli di lavoro... ma un super-modulo di per sè eliminerebbe del 50% il saltello dei TH, cioè la L2 diventerebbe quasi una mezza L3 in fatto di ricerca dei dati, e a frequenze ben più alte della L3 e latenze più basse (la L2 viaggia allo stesso clock dei core, a def almeno 4GHz per un 8350, contro una L3 che va a 2,2GHz e con latenze ben più alte)... ma stiamo fantasticando alla grande.

[digieffe]

Ultimamente ho saputo che le cpu si degradano in overclock, fino a dover aumentare i voltaggi per stare a default ed anche peggio.

Come sono messi gli FX? e soprattutto se si degradano in quali condizioni?

[paolo.oliva2]

Per quello che ti posso dire io, credo che molto dipenda dal tipo di OC e dalle temp di funzionamento... vagamente ricordo una discussione in passato che al passaggio di corrente d'era un degradamento della pista, e che l'OC, aumentando la frequenza, aumenterebbe il degrado. Tipo se a 2GHz 20 anni, a 4GHz 10 anni (facendo una ipotesi di proporzione).
Credo che in questo però influenzi moltissimo la temp del procio... sempre per esempio, credo influisca di più 4GHz a 65° che 5GHz a 50° ad esempio.
Personalmente io non ho mai adottato DU al limite... nel senso che mi sono sempre guardato di non superare i 50° come temp massima e non ho mai notato che ho dovuto darci più core per ottenere l'RS dopo del tempo... al più è stato la classica differenza di 0,025V tra temp ambiente estive ed invernali.
Mi ricordo che a suo tempo aveva fatto notizia, mi sembra i greci con un 8150, che dopo una sessione ad azoto il procio funzionasse ancora ed era stato usato per OC "normali" con le stesse caratteristiche Vcore/frequenza precedenti... e chi faceva OC estremi azoto/liquido riportava che di solito dopo una sessione di OC estremo il procio è da buttare il più delle volte (cacchio, overvolt 1,8-1,9V).
Poi tieni presente ad esempio che un 8350 guadagna almeno 400MHz di OC a Vcore def... è difficile come giudicarlo... perchè canonicamente è un OC perchè lavora ad una frequenza superiore rispetto a def, però... per me un OC è da considerarsi come tale quando si oltre all'overclock c'è anche l'overvolt.

Poi se c'è qualcun'altro che ha esperienze in merito, ben venga (posti), perchè generalmente cambio procio ogni anno, qualche volta meno e nel caso del mio 8350 probabilmente di più (fino a si spera Varsavia FX).

[capitan_crasy]

Ultimamente ho saputo che le cpu si degradano in overclock, fino a dover aumentare i voltaggi per stare a default ed anche peggio.

Come sono messi gli FX? e soprattutto se si degradano in quali condizioni?

Ho santi numi e questa dove l'hai sentita?
Caso mai saranno le schede mamme che dopo un tal periodo di overclock possono rendere di meno a causa dei settaggi fuori specifica...

[29Leonardo]

raga per salire in oc con un fx bastano delle comuni ddr3 a 1600mhz o serve qualche modello piu spinto?

[aldogdl]

raga per salire in oc con un fx bastano delle comuni ddr3 a 1600mhz o serve qualche modello piu spinto?

agendo tramite moltiplicatore va bene qualsiasi modello.

[29Leonardo]

agendo tramite moltiplicatore va bene qualsiasi modello.

quindi con queste cpu si agisce solo via moltiplicatore? Con l'oc sono rimasto ai core duo dove si cambiava fsb e rapporto ram:fagiano:

[paolo.oliva2]

quindi con queste cpu si agisce solo via moltiplicatore? Con l'oc sono rimasto ai core duo dove si cambiava fsb e rapporto ram:fagiano:
Se uno vuole, si può agire anche solamente di bus, visto che dai 200MHz si può arrivare a 300MHz con tutta tranquillità (il mio ha problemi >335MHz), quindi si potrebbe arrivare sui 6GHz, ma però ci sono dei problemi "indiretti", come ad esempio l'aumento della frequenza NB e l'aumento della frequenza DDR3, risolvibili abbassando il settaggio nativo.
Dopo dipende dal tipo di OC, perchè uno potrebbe tenere il procio senza attivare alcuni risparmi energetici, tipo quello che quando è in idle abbassa la frequenza operativa, che in generale è il molti 7X, il quale con il bus a 200MHz equivale a 1,4GHz, ma occando il bus varia (a 300MHz sarebbe 2,1GHz). Dopo dipende dal bios della mobo... ma potrebbe crearsi il prb che per 1,4GHz il bios/procio imposta 0,9V che non è sufficiente per 2,1GHz e il sistema resetterebbe.
Un procio BE o FX aiuta nell'OC proprio perchè è interamente sbloccato, cosa che una volta implicava un aumento del prezzo... ora che lo si ottiene gratis, tantovale sfruttarlo.

[29Leonardo]

No vabbè quello che farei è un oc daily use quindi per un fx 6300 spero di raggiungere quota 4,2-4,5 ghz. Oltre non credo perchè giàa queste freq le temp immagino siano altine.

[Grizlod®]

Ultimamente ho saputo che le cpu si degradano in overclock, fino a dover aumentare i voltaggi per stare a default ed anche peggio.

Come sono messi gli FX? e soprattutto se si degradano in quali condizioni?Hmmm...diciamo che in teoria puo essere vero (vale anche per le GPU), ma con tempi (per l'informatica) "biblici". IMO a degradarsi e far sì che il processore richieda più vcore è la sezione VRM della mainboard; tant'è vero che fino a poco tempo fa era in voga la pratica del 'burn-in' per poter undervoltare le CPU, e mantenere lo stesso clock (se non un over...).

Per la poca esperienza che mi sono fatto, posso dire che gli FX sono "robusti", ma è pur vero che sono relativamente da poco tempo in commercio, perciò, bisognerebbe simulare artificialmente in laboratorio, una loro "vita" operativa.

[Ares17]

Ho (oh)santi numi e questa dove l'hai sentita?
Caso mai saranno le schede mamme che dopo un tal periodo di overclock possono rendere di meno a causa dei settaggi fuori specifica...
Purtroppo capitano è vero.
Non in un modo così esasperato (almeno non mi è mai capitato), ma con overvolt più o meno spinti si consuma letteralmente il metallo (un po come avviene nei filamenti di tungsteno delle lampade ad incandescenza, ma in misura infinitesimale).
Onestamente non mi è mai capitato di arrivare a quel punto, piuttosto di dover alzare di uno step il voltaggio, o abbassare la frequenza.
Ma mai un cpu non mi ha funzionato a def (e la colpa nei miei casi non erano da imputare alle mb dato che riscontravo la stessa cosa con mobo identiche nuove.
Ps ho avuto cpu che mi hanno funzionato per 3 anni di fila in oc senza nessun problema (opteron 146 2ghz-2,9 ghz con +0,025 volt), mentre un 165 dopo 1 anno per il 2700 (da 1800) mi richiedeva + 0.02 volt anche su sli dr nuova.

[blindwrite]

Ho santi numi e questa dove l'hai sentita?


manuale d'elettronica, pagina 2?

[paolo.oliva2]

Per la legge di Moore, cioè la capacità di raddoppiare ogni due anni il numero di transistor presenti in un chip di silicio a patto che si passi ad una miniaturizzazione più spinta ogni 2 anni, tutto filerebbe liscio fino al 2020 in concomitanza con il nodo 7nm.
http://www.businessmagazine.it/news/anno-2020-la-fine-della-legge-di-moore_48407.html
Certo è che un periodo di 3 anni per passare da 32nm a 28nm non è che rispetti la tempistica di Moore, anche se di certo un Kaveri X6 non può avere il doppio dei transistor di un Richland X4.
A mio parere uscire nel 2014 con una miniaturizzazione 28nm vuol dire essere enormemente indietro con i tempi, ma questo rassicurerebbe sul fronte FX/Opteron, perchè se nella migliore delle ipotesi si dovrà aspettare almeno 1 anno, dall'altra sarebbe pressochè scontato che non sarà un 28nm.
Per la legge di Moore, in 4 anni si avrebbe il quadruplo dei transistor, e da un 8150 al successore, ci sarebbero 4 anni almeno.
Che poi risulti poco probabile perchè ci vorrebbero 2 salti di miniaturizzazione, completamente d'accordo, ma è altrettanto vero che sarebbe più di 1 salto... giudicando ad esempio che da 32nm a 28nm non sarebbe un vero e proprio salto, da 32nm a 22nm lo sarebbe, da 32nm a 20nm (tipo) lo sarebbe certamente di più.

Quello che non capisco, anche se un pelo OT... le librerie ad alta densità mi sembra siano usate nelle VGA... perchè non applicarla alle APU? L'impossibilità di realizzare un APU con potenze IGP simili ad una discreta è legata unicamente ai margini TDP risicati, ma valutando che Richland ha incrementato del 50% su Trinity a parità di miniaturizzazione e quindi solamente per evoluzione architetturale, una IGP Kaveri avrebbe il plus del 28nm sul 32nm, aggiungendoci l'incremento delle librerie ad alta densità, insomma, sarebbe un salto bello corposo.

[digieffe]

Ho santi numi e questa dove l'hai sentita?
Caso mai saranno le schede mamme che dopo un tal periodo di overclock possono rendere di meno a causa dei settaggi fuori specifica...

ehm.... ummm... come te lo spiego senza incendiare il thread?

diciamo che ho avuto la conferma (da un utente che ritengo affidabile) che su alcuni processi a 32nm (non soi), overcloccando le cpu dopo un tempo (mesi o poco più di un annno) queste per reggere in idle avevano bisogno di uno step di corrente in più ecc, ecc. Ora col 22mn i problemi si sono ridotti, forse anche perchè salgono di meno?

Ora però fate i seri, non iniziate a dire che alcuni processi p. sono migliori di altri che alcune cpu costano meno di altre e non si usurano all'overclock, ok?
Tanto già sappiamo le cose come stanno.


Se ne vogliamo discutere, parliamone vedendo solo in casa amd, cosa succede altrove discutiamolo in altri thread, grazie.

Un pensiero mi viene se AMD ha fatto il 9590, non dovrebbe avere problemi di usura fino a 4.7.

[digieffe]

Quello che non capisco, anche se un pelo OT... le librerie ad alta densità mi sembra siano usate nelle VGA... perchè non applicarla alle APU? L'impossibilità di realizzare un APU con potenze IGP simili ad una discreta è legata unicamente ai margini TDP risicati, ma valutando che Richland ha incrementato del 50% su Trinity a parità di miniaturizzazione e quindi solamente per evoluzione architetturale, una IGP Kaveri avrebbe il plus del 28nm sul 32nm, aggiungendoci l'incremento delle librerie ad alta densità, insomma, sarebbe un salto bello corposo.

Tieni presente che tra una gpu integrata nell'apu (384sp) ed una identica discreta con gddr5 c'è quasi un raddoppio di prestazioni, anche se infilassero 1024 SP nell'apu il problema sarebbe tutto nella banda della ram.

per curiosità, qualcuno sa se si può realizzare un chip metà con librerie ad alta densità (gpu) e metà con librerie normali? (@blindwrite ne sai nulla?)

[blindwrite]

Tieni presente che tra una gpu integrata nell'apu (384sp) ed una identica discreta con gddr5 c'è quasi un raddoppio di prestazioni, anche se infilassero 1024 SP nell'apu il problema sarebbe tutto nella banda della ram.

per curiosità, qualcuno sa se si può realizzare un chip metà con librerie ad alta densità (gpu) e metà con librerie normali? (@blindwrite ne sai nulla?)

ovviamente si, normalmente ci sono decine di librerie diverse per scopi diversi.

[dav1deser]

Sarà che non si deve farne un caso hai ragione, ma una cosa è certa, il Bulk non è fatto per alte frequenze rispetto al SoI e secondo me anche per questo accadeva oltre una certa soglia, oltre una certa frequenza...

cut

scommetto che col SoI questo degrado se c'è è molto ridotto, se non quasi nullo...

Se ho capito bene il problema di cui parlate, cioè dovuto allo spostamento degli atomi metallici a causa della tensione, credo non centri nulla con SOI o bulk, questi ultimi sono trattamenti del silicio e influenzano il desing dei transistor, mentre questo problema agisce sulle interconnessioni metalliche che si trovano al di sopra del silicio, e che quindi non sono necessariamente fatte in maniera diversa a seconda dei trattamenti del silicio. I fattori che possono influire su questo problema direi che sono tensione applicata, dimensione delle interconnesioni, e temperatura. E' possibile che le interconnessioni di AMD siano progettate più grandi proprio per sostenere meglio tensioni e frequenze più elevate.

Sempre che adesso non sia il gate metallico (HKMG) ad essere affetto da questo problema...

[paolo.oliva2]

Purtroppo capitano è vero.
Non in un modo così esasperato (almeno non mi è mai capitato), ma con overvolt più o meno spinti si consuma letteralmente il metallo (un po come avviene nei filamenti di tungsteno delle lampade ad incandescenza, ma in misura infinitesimale).
Onestamente non mi è mai capitato di arrivare a quel punto, piuttosto di dover alzare di uno step il voltaggio, o abbassare la frequenza.
Ma mai un cpu non mi ha funzionato a def (e la colpa nei miei casi non erano da imputare alle mb dato che riscontravo la stessa cosa con mobo identiche nuove.
Ps ho avuto cpu che mi hanno funzionato per 3 anni di fila in oc senza nessun problema (opteron 146 2ghz-2,9 ghz con +0,025 volt), mentre un 165 dopo 1 anno per il 2700 (da 1800) mi richiedeva + 0.02 volt anche su sli dr nuova.
Per me è proprio nella logica dell'OC... si era partiti che si acquistava il modello base ed occandolo si ottenevano prestazioni simili se non superiori al modello top che di norma costava più del doppio... quindi comunque se nella sfiga il procio moriva, il secondo era comunque gratis.

Una volta era sicuramente peggio, in primis perchè il sistema lo si teneva più a lungo e nel contempo le frequenze massime def erano già tirate di loro (la corsa a chi arrivava prima ad 1GHz chi se la ricorda?), inoltre i produttori creavano ostacoli appositi per impedire l'OC.

Oggi invece è diventato il cavallo di battaglia ed onestamente anche se compare la classica dicitura dei produttori che se occhi lo fai a tuo rischio e pericolo, alla fine comunque dei margini li devi applicare, altrimenti i resi lieviterebbero e sarebbe sempre un danno, di immagine se non li sostituisci, di money se li sostituisci. Gli FX hanno un package progettato per TDP quasi doppi rispetto a quelli def, va bene che non sarebbe una relazione stretta, ma probabilmente una mobo progettata per l'OC terrebbe in considerazione il massimo TDP del package e non certamente il nominale, e di conseguenza qualche accorgimento da parte di AMD per fare il procio più robusto mi sembrerebbe plausibile. Del resto altrimenti gli FX 9XXX non potrebbero esistere, ed hanno Vcore def più corposi.

Poi onestamente non lo vedrei molto alterato chi dopo 2-3 anni ha tirato il collo all'impossibile al suo Phenom II X4 965 e si ritrova che nella sua mobo AM3+ può arrivare ad un raddoppio (e più) delle prestazioni con un 8320 e cifre sotto i 150€.

[capitan_crasy]

ehm.... ummm... come te lo spiego senza incendiare il thread?

diciamo che ho avuto la conferma (da un utente che ritengo affidabile) che su alcuni processi a 32nm (non soi), overcloccando le cpu dopo un tempo (mesi o poco più di un annno) queste per reggere in idle avevano bisogno di uno step di corrente in più ecc, ecc. Ora col 22mn i problemi si sono ridotti, forse anche perchè salgono di meno?

Ora però fate i seri, non iniziate a dire che alcuni processi p. sono migliori di altri che alcune cpu costano meno di altre e non si usurano all'overclock, ok?
Tanto già sappiamo le cose come stanno.


Se ne vogliamo discutere, parliamone vedendo solo in casa amd, cosa succede altrove discutiamolo in altri thread, grazie.

Un pensiero mi viene se AMD ha fatto il 9590, non dovrebbe avere problemi di usura fino a 4.7.

Rispondo solo a te così evitiamo il multi quote:;)
Cerchiamo un momento di essere pratici dato che ognuno qua dentro in generale ha esperienze in overclok più o meno spinti.
Il modo in cui hai posto la domanda lascia intendere che sempre e in tutti i casi le CPU poste a overclock si rovinano a tal punto da non restare più neanche stabili a default.
La possibile "usura" dei materiali di una CPU avviene anche a default e può avvenire dopo pochi giorni o dopo molti anni di utilizzo al 100%.
Rimane il fatto che il fattore tempo sull'usura non è calcolabile o meglio non esistono tempi certi, anzi in termini di elementi usati in un PC come schede mamme e alimentatori ci sono componenti più soggetti a mal funzionare nel corso del tempo.
Nei miei post precedenti per stabilire la stabilità di una CPU in overclock bastava un ora (o anche meno) con programmi stile prime95, stressare per ore e ore il processore oltre che essere inutile, si fa un tentato omicidio di primo grado sulla CPU.
Personalmente fino a 3 mesi fa, causa morte della scheda mamma, il mio glorioso K8 5000+ (preso nell'anno della sua uscita) era in overclock @ 3.10Ghz e parliamo di una CPU uscita nel 2007 e mai stata a default...
Altro esempio il mio vecchio 720+ montato sul muletto è sempre stato a 3.30Ghz dal giorno del suo acquisto; anzi ti dirò che con l'attuale scheda mamma e alimentatore nuovo ero stabile @ 3.80Ghz (1.47v) cosa che con la vecchia scheda non partiva neanche windows.
Usura è la parola giusta, il quando è un argomento che nessuno neanche i vari "manuali d'elettronica" possono stabilire.
Non voglio neanche pensare che i vari produttori abbiano introdotto "l'obsolescenza programmata" per quanto riguarda il mercato delle CPU/GPU, ma in questo caso si può stabilire la durata di un processore come se fosse una lampadina...

[Phenomenale]

Forse quello di cui parla Digieffe è la breve vita di alcune cpu Sandybridge (della concorrenza quindi qui non in topic) sottoposte a pesante overvolt ed overclock. Bisogna ricordare come ragionano gli overclocker per inquadrare il problema: magari ti scrivono sui forum "la mia cpu l'ho tenuta ad overvolt ragionevoli e si è degradata lo stesso" ma parlano solo del daily... non ricordano delle ore ed ore passate a farla arrostire a 80°/90° con linx e prime95 a voltaggi elevati alla ricerca della stabilità... magari il degrado è cominciato proprio da lì. E' il degrado del silicio per effetto dell' elettromigrazione.
Tutto questo ricordiamoci vale solo per i 32nm bulk della concorrenza.

Sugli FX AMD non ricordo di aver letto mai nulla di cpu degradate dopo qualche mese od un anno di overclock... IMHO risentono meno/nulla del problema.
Di sicuro io un FX non mi preoccuperei di overcloccarlo a dovere! :D

[capitan_crasy]

Forse quello di cui parla Digieffe è la breve vita di alcune cpu Sandybridge (della concorrenza quindi qui non in topic) sottoposte a pesante overvolt ed overclock. Bisogna ricordare come ragionano gli overclocker per inquadrare il problema: magari ti scrivono sui forum "la mia cpu l'ho tenuta ad overvolt ragionevoli e si è degradata lo stesso" ma parlano solo del daily... non ricordano delle ore ed ore passate a farla arrostire a 80°/90° con linx e prime95 a voltaggi elevati alla ricerca della stabilità... magari il degrado è cominciato proprio da lì.
Tutto questo ricordiamoci vale solo per i 32nm bulk della concorrenza.

Sugli FX AMD non ricordo di aver letto mai nulla di cpu degradate dopo qualche mese od un anno di overclock... IMHO risentono meno/nulla del problema.
Di sicuro io un FX non mi preoccuperei di overcloccarlo a dovere! :D

Se esistono problemi di usura su CPU Intel a breve termine allora, come hai fatto notare, siamo OT.
Per quanto riguarda AMD invece si può anche discutere di eventuali problemi di usura legati all'utilizzo in overclock (sia chiaro per i K10 ce il thread apposito) e se esiste un argomento si può anche aprire un thread dedicato...;)

[paolo.oliva2]

Sarà che non si deve farne un caso hai ragione, ma una cosa è certa, il Bulk non è fatto per alte frequenze rispetto al SoI e secondo me anche per questo accadeva oltre una certa soglia, oltre una certa frequenza...

non è un discorso di partito, ma tecnico...

secondo me ora col 22 Bulk gli hanno messo la pasta anche per quello, per limitarlo nell'OC, ma non per sport, ma ci saranno motivi tecnici, legato anche al trigate magari o alla difficoltà di non rovinare il die saldandolo... negli ivy-e metteranno una via di mezzo, una colla che si solidifica assomigliando ad una pasta non ricordo come si chiama tecnicamente

scommetto che col SoI questo degrado se c'è è molto ridotto, se non quasi nullo...

che poi vadano di più le cpu Intel e consumino meno a certe frequenze non c'entra, non è un discorso di partito ripeto, ma di sicuro regge meno il Bulk del SoI...
Poi bisogna anche considerare che a Vcore def iniziale molto diversi, andrebbe considerato un valore % di overvolt, perchè sparando dati così, su 1,5V il 10% è 0,15V, mentre su 1V la stessa percentuale darebbe 0,1V, quindi anche se fosse lo stesso tipo di silicio, non si potrebbero applicare lo stesso incremento di overvolt, quindi in parte su questo, bulk o soi non sarebbe la differenza.
Completamente d'accordo :D, poi bisogna anche considerare che Intel ha speso fiumi di soldi per portare al massimo dell'efficienza il Bulk, quindi ciò che c'è in commercio non riflette (per me) la reale differenza che ci sarebbe tra i 2 tipi di silicio, senza contare poi che l'affinamento architetturale incide nei consumi ed un tot.
Immagina teorizzare dei valori di differenza di silicio sulla base di Zambesi e un procio Intel 32nm... e poi fare la stessa cosa con Vishera... e se AMD rispetterà quanto dichiarato con Varsavia, niente di sbalorditivo che un attuale 9370 possa diventare un 125W TDP effettivo con Varsavia.

[digieffe]

ps. bisognerebbe spulciare la rete e vedere se si trovano notizie sul deterioramento magari anche dei zambezi che sono da 2 anni sul mercato... ma comunque non credo che ne siano affetti, tanto meno i vishera

Hai centrato il punto: indipendentemente dalle cause, volevo proprio capire come erano messe le "statistiche" degli amd a partire dal k10 o anche k8 (era soi?).
Per intel non ho problemi poiché mi sono fermato al 45nm, però ho rischiato grosso, in quanto se l'avessi acquistato (nuovo) l'avrei tenuto in OC ed in full per molte ore al giorno, e probabilmente avrei preso un 3930k.

Dovendo valutare un acquisto, per intel dovrei pensare ad un 22nm lievemente OC (max@4.1) o stock (e a questo punto prenderei uno xeon), per amd se non ci sono "statistiche" negative potrei pensare ad un FX@4.7.

[paolo.oliva2]

Hai centrato il punto: indipendentemente dalle cause, volevo proprio capire come erano messe le "statistiche" degli amd a partire dal k10 o anche k8 (era soi?).
Per intel non ho problemi poiché mi sono fermato al 45nm, però ho rischiato grosso, in quanto se l'avessi acquistato (nuovo) l'avrei tenuto in OC ed in full per molte ore al giorno, e probabilmente avrei preso un 3930k.

Dovendo valutare un acquisto, per intel dovrei pensare ad un 22nm lievemente OC (max@4.1) o stock (e a questo punto prenderei uno xeon), per amd se non ci sono "statistiche" negative potrei pensare ad un FX@4.7.
AMD è stato sempre SOI :)
Un 8350 @4,7GHz, considerando 1,38V def che arriva già a 4,4GHz almeno, per i 4,7GHz 1,45V dovrebbero bastare in media, e +0,07V non è che sia un gran overvolt.
A mio parere l'8350 è soddisfacente a def e un +10% con un OC a chius'occhi a @4,4GHz senza overvolt.
Occhio però... perchè se lo stracarichi, scalda un tot ed in generale vole un Vcore più corposo. A liquido @5GHz con i giochi e 4,8GHz con 1 applicazione intensiva 8TH sono possibilissimi 24h/24, ma se lo stracarichi non pensare che @4,7GHz siano così facili da tenere in DU... io avevo scelto @4,6GHz proprio per questo... temp mai >50° ed un RS granitico.

[plainsong]

Quoto paolo, inoltre se non sbaglio l'FX8350 è impostato a stock per richiedere 1.4 e 1.425 di voltaggio rispettivamente per il turbo a 4.1 e 4.2 Ghz pertanto fino a 1.425 non parlerei nemmeno propriamente di overvolt.

[RedPrimula]

Quoto paolo, inoltre se non sbaglio l'FX8350 è impostato a stock per richiedere 1.4 e 1.425 di voltaggio rispettivamente per il turbo a 4.1 e 4.2 Ghz pertanto fino a 1.425 non parlerei nemmeno propriamente di overvolt.

Per i 4.1 sul mio 8320 devo impostare da bios gli 1.38 stock con un +0,025 di offset, ma solo per stare tranquillo e compensare il lieve vdrop che ho riscontrato con cpu-z. Di fatto resta stabile fino a 1.35/1.36. In ogni caso non penso si possa definire un oc da overvolt vero e proprio il mio... Magari con una 8+2 fasi potrei lasciare il vcore a default.

Una domanda: coretemp mi segnala un tj max di 90°. E' sballato o è un esemplare il mio che regge temp più alte di quelli per i quali il tj max risulta 70°?

[digieffe]

Quoto paolo, inoltre se non sbaglio l'FX8350 è impostato a stock per richiedere 1.4 e 1.425 di voltaggio rispettivamente per il turbo a 4.1 e 4.2 Ghz pertanto fino a 1.425 non parlerei nemmeno propriamente di overvolt.

sotto carico pesante e duraturo, ben raffreddato ad aria, a quanto arriverebbe con 1.38, 1.4 ed 1.425?

cambierebbe qualcosa con la serie 9xxx?

[isomen]

Hai centrato il punto: indipendentemente dalle cause, volevo proprio capire come erano messe le "statistiche" degli amd a partire dal k10 o anche k8 (era soi?).
Per intel non ho problemi poiché mi sono fermato al 45nm, però ho rischiato grosso, in quanto se l'avessi acquistato (nuovo) l'avrei tenuto in OC ed in full per molte ore al giorno, e probabilmente avrei preso un 3930k.

Dovendo valutare un acquisto, per intel dovrei pensare ad un 22nm lievemente OC (max@4.1) o stock (e a questo punto prenderei uno xeon), per amd se non ci sono "statistiche" negative potrei pensare ad un FX@4.7.

Statistiche nn sono in grado di fartele, ma occo su amd dai tempi dei K6 II e nonostante qualche morto l'abbia avuto (quasi tutti per errori miei) credo che l'unico defunto per oc sia stato un barton 2600 (volevo farlo arrivare dove nn riusciva :muro: )... gli altri sono ancora vivi, parlando di FX i miei nn sono mai stati a default ma nessuno dei 3 (4100-6300-8350) da segni di squilibrio. Sento parlare di elettromigrazione da quando ho iniziato con l'oc... ma se tieni sotto controllo la temp e nn esageri con il vcore é un problema inesitente.

;) ciauz

[paolo.oliva2]

Bisogna dividere il concetto di OC raggiungibile da OC bilanciato, ma per questo non voler intendere il bilanciato con il massimo tenibile per motivi di bandiera.
Fino a 1,45V il procio è molto lineare nell'aumento delle temp e le temp massime per non pregiudicare l'RS non differiscono da quelle def.
Fino a 1,525-1,55V il procio può funzionare tranquillamente, ma deve essere raffreddato molto bene e le temp massime, per garantire l'RS, sono inferiori di 10° rispetto a quelle di un OC a 1,45V.
L'OC max benchabile è 1,6V, io sono arrivato a 1,625V, ma in generale guadagni poco (almeno il mio 8350) rispetto a 1,55V, ma qui, avendo solo 1 applicazione attiva, a liquido non si hanno prb a non superare i 50°

Non esiste un limite preciso all'RS legato alla frequenza, ma unicamente alle temp raggiunte. Per chiarire il concetto, se si prende un 8350 e si lascia il dissi stock e poi lo si overclocca a 1,45V 4,6GHz, è chiaro che non sarà RS, ma non lo è esclusivamente per le temp, non per il Vcore nè per la frequenza. Idem a 1,525V, se il liquido non supera i 20° e quindi il procio non supera i 50° di temp max (se stracaricato i 15° liquido max per non superare i 50°) architettura e Vcore non c'entrano nulla sull'RS.

La differenza, chiaramente, è nella convenienza... l'8350 @4,6GHz a liquido, potevo spegnere tutte le ventole ed utilizzare solamente i 20 litri del serbatoio come raffreddamento... ed accendere 1 ventola su 3 in caso di stracarico. Per 400MHz in più (@5GHz al posto di @4,6GHz) equivalenti ad un +9% scarso, le ventole dovevano essere tutte accese e se stracaricato dovevo pure accendere il WC (impostato sui 15° temp liquido) per non superare i 50° di temp procio, e quando ho fatto questi test era dicembre in Italia e qui all'equatore con 32° ambiente non supero i @4,6GHz:doh: (la differenza reale non sono i 32° perchè in Italia si raggiungono anche superiori, ma qui è sempre sui 32° anche la notte).

@Digieffe
Collegando questo discorso agli FX 9XXX, è per questo che non riesco a collegare il mio 8350 con un impianto a liquido 20 litri, 2 radiatori doppi, 4 ventole 12cm doppia altezza 3000 rpm con l'aggiunta di WC max 3°, e poi vedere un 9590 4,7GHz def 5GHz turbo (che a differenza dell'8350 il turbo è su 8 core) che nelle varie rece al massimo ha avuto un kit liquido interno scrauso con 1 litro di serbatoio, 1 radiatore ed 1 pompa inferiore certamente alla mia e fare meglio senza prb. A me non frega una tozza il discorso di bandiera... ed il prb della selezione o meno ed in che misura aveva una importanza NULLA quando un 9590 costava 800€, ma adesso che è calato a 350€, seppur sempre con un costo/prestazioni sfavorevole (ci scappano 2 8350), è comunque allettante per chi, come me, ha prb di massime frequenze DU.

Per 1,425V sicuramente i @4,5GHz li prendi a chiusocchi in qualsiasi condizione di carico senza nessun prb di temp. Contando che gli ultimi 8350 richiedono un Vcore inferiore alla stessa frequenza, credo probabile @4,6GHz.
Gli FX 9XXX dovrebbero richiedere un Vcore inferiore alla stessa frequenza, quindi la tua domanda è simile al mio problema... cioè un Vcore inferiore per le stesse frequenze = DU più alto.

[LurenZ87]

Guarda Paolo, anche se l'FX-9590 è sceso sui 335€ non vedo proprio il motivo di preferirlo ad un FX-8350. Cioè non parliamo di poche decine di euro in più come con l'FX-8320, ma del doppio per un processore che alla fine è identico agli altri due e imho sono convinto che non ci sia differenza in oc con un impianto a liquido serio.

Inviato dal mio Nexus 4 con Tapatalk 2

[PaulGuru]

Guarda Paolo, anche se l'FX-9590 è sceso sui 335€ non vedo proprio il motivo di preferirlo ad un FX-8350. Cioè non parliamo di poche decine di euro in più come con l'FX-8320, ma del doppio per un processore che alla fine è identico agli altri due e imho sono convinto che non ci sia differenza in oc con un impianto a liquido serio.

Inviato dal mio Nexus 4 con Tapatalk 2

Dove ? in quale shop ?

[LurenZ87]

Dove ? in quale shop ?

Tecnocomputer.it

Inviato dal mio Nexus 4 con Tapatalk 2

[PaulGuru]

Grazie Laurez

[aldogdl]

Per i 4.1 sul mio 8320 devo impostare da bios gli 1.38 stock con un +0,025 di offset, ma solo per stare tranquillo e compensare il lieve vdrop che ho riscontrato con cpu-z. Di fatto resta stabile fino a 1.35/1.36. In ogni caso non penso si possa definire un oc da overvolt vero e proprio il mio... Magari con una 8+2 fasi potrei lasciare il vcore a default.

Una domanda: coretemp mi segnala un tj max di 90°. E' sballato o è un esemplare il mio che regge temp più alte di quelli per i quali il tj max risulta 70°?

piu' fasi di alimentazioni meno overvolt ?

[RedPrimula]

piu' fasi di alimentazioni meno overvolt ?

[cut]
nel senso che se stabilizzi il vdrop hai bisogno di meno overvolt da bios per tenerlo stabile già che appunto avrai meno cali di tensione sotto carico... spiegato grezzamente

Una sabertooth non avrebbe problemi penso a tenermi gli 1.38 stabilmente (impostati da bios) a 4.1ghz sotto carico, intendevo appunto in questo senso. E magari potrei dargli pure meno di 1.38, ma con una 4+2 fasi non posso sapere quanto sia più o meno fortunato il mio se da bios devo impostare un vcore tendenzialmente più alto di quello che gli basterebbe. In ogni caso non ho dovuto applicare un offset esagerato e sotto windows il vcore max registrato è esattamente lo stesso di quello ottenuto con la cpu a def, quindi mi sta bene così.

[OPP]

Guarda Paolo, anche se l'FX-9590 è sceso sui 335€ non vedo proprio il motivo di preferirlo ad un FX-8350. Cioè non parliamo di poche decine di euro in più come con l'FX-8320, ma del doppio per un processore che alla fine è identico agli altri due e imho sono convinto che non ci sia differenza in oc con un impianto a liquido serio.

Inviato dal mio Nexus 4 con Tapatalk 2

lo volevo prendere ma quei soldi per un fx sono davvero troppi :(

[vincenzo2008]

Una sabertooth non avrebbe problemi penso a tenermi gli 1.38 stabilmente (impostati da bios) a 4.1ghz sotto carico, intendevo appunto in questo senso. E magari potrei dargli pure meno di 1.38, ma con una 4+2 fasi non posso sapere quanto sia più o meno fortunato il mio se da bios devo impostare un vcore tendenzialmente più alto di quello che gli basterebbe. In ogni caso non ho dovuto applicare un offset esagerato e sotto windows il vcore max registrato è esattamente lo stesso di quello ottenuto con la cpu a def, quindi mi sta bene così.

ti basta attivare il llc e puoi tenere anche tu il vcore default.

[RedPrimula]

ti basta attivare il llc e puoi tenere anche tu il vcore default.

Per carità... se lo lascio a def mi spara 1.45... fa solo danni in mobo di questa fascia e posso solo attivarlo/disattivarlo. Preferisco impostarlo manualmente a questo punto.

[vincenzo2008]

Per carità... se lo lascio a def mi spara 1.45... fa solo danni in mobo di questa fascia e posso solo attivarlo/disattivarlo. Preferisco impostarlo manualmente a questo punto.

cmq non c'è bisogno del top asus per overclockare, bastava la versione evo , e si può regolare il llc in tutti i modi che si vuole, nel mio caso non si muove di un mv la tensione

[raffaele1978]

Scusate, ma per verificare se la CPU va in throttling cosa devo fare esattamente?

Inviato dal mio GT-I9505 con Tapatalk 2

[vincenzo2008]

Scusate, ma per verificare se la CPU va in throttling cosa devo fare esattamente?

Inviato dal mio GT-I9505 con Tapatalk 2

fai stress con occt e vedi se la frequenza della cpu si abbassa ;)

[paolo.oliva2]

Guarda Paolo, anche se l'FX-9590 è sceso sui 335€ non vedo proprio il motivo di preferirlo ad un FX-8350. Cioè non parliamo di poche decine di euro in più come con l'FX-8320, ma del doppio per un processore che alla fine è identico agli altri due e imho sono convinto che non ci sia differenza in oc con un impianto a liquido serio.
Completamente d'accordo... ma con un WC accoppiato all'impianto a liquido c'è poco da migliorare. Il problema non è l'OC da bench, tanto foss'anche un 9990 non riuscirei mai a fare più di un 8350 in Italia, ma per il DU potrebbe essere diverso.

il doppio per anche fosse +200mhz in RS/DU è uno spreco assurdo, ma lo è ancora di più in rapporto ad un 3930k che ne costa 500€... costa +50% e va il 50% in più... in rapporto al 8350 è troppo, costa il triplo, ma in rapporto al 9590 è la scelta migliore
Per me con tutta sincerità esiste l'AM3+ con gli FX fino all'8350 dopodichè esiste il socket 2011 con il 3930K (e meglio ancora il 4930K), altre scelte non valgono la candela.

Nella mia situazione, per l'hardware che ho e per quello che si prospetta nel 2014, lato AMD ci sarà unicamente Varsavia Opteron, ma il non annuncio versione FX è probabilmente per vendere i 9XXX, perchè se la dichiarazione ufficiale di un +15% di potenza a parità di consumi equivarrebbe a dire che un 8350 risulterebbe 4,6GHz def per 125W TDP contro i 4,7GHz a più TDP di un 9590, quindi sarebbe impensabile che AMD rimanesse per tutto il 2014 sull'offerta Vishera, producendoli, con un Varsavia che garantirebbe utili maggiori. Dall'altra aspetto perchè di un Varsavia che possa arrivare a 4,6GHz nei 125W TDP ci posso credere sulle basi che un 8350 allo stesso Vcore (e quindi allo stesso TDP) già arriverebbe a 4,4GHz, ma che un Varsavia a 4,6GHz consentirebbe margini di OC senza Overvolt come l'8350, significherebbero 5GHz a 125W TDP, il che onestamente lo reputerei irreale, perchè quel +15% potrebbe essere valido sino a certe frequenze e certi Vcore. Quindi la barzelletta di selezione o meno sarebbe un aspetto, più o meno vero, ma il fatto del calo dei prezzi dei 9XXX, notevole, mi sembra finalizzato proprio alla conferma di un Varsavia FX, cioè pulire tutto il prodotto Vishera in attesa di Varsavia.

In ogni caso nel mio caso prenderei un 9370 o 9590 semplicemente per metterlo al posto dell'8350, l'8350 al posto dell'8150 e probabile, se decido di tenere la N68C (che ha 2 porte PATA per me importanti per riciclare DVD PATA vecchi), il 1090T o 8150 settato a 95W TDP tanto sarebbe un sistema muletto per leggere DVD. L'unica fregatura sarebbe un 9590 Varsavia ad un costo inferiore e a un TDP inferiore....
E' chiaro che la potenza 2011 AMD non la potrà mai offrire con Varsavia e visto che Steamroller FX non ci sarà, con Kaveri APU che è un Steamroller si potranno fare tutte le congetture per ipotizzare cosa potrà offrire Exavator, ma comunque non prima del 2015.

Quindi... o prendo un altro 8350 che magari mi permetterebbe DU migliori, ma avrebbe senso nei confronti di un 9370 o 9590? Tutto vero per il socket 2011, ma converrebbe prendere un 3930K ora con un 4930K a fine anno?
Quindi o mi tengo tutto com'è (a parte l'acquisto di mobo AM3+ "serie" :)), o faccio la "cazzata" di un FX 9XXX, oppure aspetto gennaio-febbraio per un 4930K + Varsavia upgrade.

[RedPrimula]

cmq non c'è bisogno del top asus per overclockare, bastava la versione evo , e si può regolare il llc in tutti i modi che si vuole, nel mio caso non si muove di un mv la tensione

Si ho nominato la sabertooth giusto per usarla come esempio "estremo". In ogni caso con la liscia mi sto trovando bene per ora e non ho intenzione di fare oc più spinti. Ho trovato l'equilibrio che cercavo e speravo di raggiungere e mi fermo qui.

[digieffe]

Nella mia situazione, per l'hardware che ho e per quello che si prospetta nel 2014, lato AMD ci sarà unicamente Varsavia Opteron, ma il non annuncio versione FX è probabilmente per vendere i 9XXX, perchè se la dichiarazione ufficiale di un +15% di potenza a parità di consumi equivarrebbe a dire che un 8350 risulterebbe 4,6GHz def per 125W TDP contro i 4,7GHz a più TDP di un 9590, quindi sarebbe impensabile che AMD rimanesse per tutto il 2014 sull'offerta Vishera, producendoli, con un Varsavia che garantirebbe utili maggiori. Dall'altra aspetto perchè di un Varsavia che possa arrivare a 4,6GHz nei 125W TDP ci posso credere sulle basi che un 8350 allo stesso Vcore (e quindi allo stesso TDP) già arriverebbe a 4,4GHz, ma che un Varsavia a 4,6GHz consentirebbe margini di OC senza Overvolt come l'8350, significherebbero 5GHz a 125W TDP, il che onestamente lo reputerei irreale, perchè quel +15% potrebbe essere valido sino a certe frequenze e certi Vcore. Quindi la barzelletta di selezione o meno sarebbe un aspetto, più o meno vero, ma il fatto del calo dei prezzi dei 9XXX, notevole, mi sembra finalizzato proprio alla conferma di un Varsavia FX, cioè pulire tutto il prodotto Vishera in attesa di Varsavia.
La dichiarazione non era +15% di efficienza TDP?
perchè +15% di efficienza tdp corrisponde ad un equivalente 8350 @4.3ghz e NON @4.6. Ciò sempre con i margini di fabbrica e non con quello degli utenti.


EDIT: a quanto arriva il voltaggio del 9590 quando è a 5.0 ghz?

[digieffe]

4ghz*1.15= 4.6ghz in chiave FX...
non ho mai fatto ingegneria quindi di elettronica ne so ben poco, ma il calcolo dovrebbe essere questo:

4ghz* SQRT(1.15) = 4.29ghz

[paolo.oliva2]

La dichiarazione non era +15% di efficienza TDP?
perchè +15% di efficienza tdp corrisponde ad un equivalente 8350 @4.3ghz e NON @4.6. Ciò sempre con i margini di fabbrica e non con quello degli utenti.
Infatti è l'interpretabilità che porta a considerazioni finali ben diverse, ed è chiaro che certe dichiarazioni non possono essere false ma comunque rilevate nel migliore dei casi.
Ad esempio, tralasciando l'incremento di IPC, Vishera risulterebbe avere un +11,11% di efficienza a def rispetto a Zambesi (4GHz vs 3,6GHz), ma se guardiamo un 8150 @5GHz, l'8350 dovrebbe arrivare a @5,550GHz (tanto sappiamo che architetturalmente potrebbe reggere anche @6GHz), il che non è reale. Questo per dire che l'incremento che riporta AMD dovrebbe essere il più alto in tutto il range delle frequenze, tra l'altro quelle Opteron e non quelle FX.
Però se non altro un miglioramento dell'efficienza vuol dire TDP inferiori per le stesse frequenze, perchè se ipoteticamente AMD giocasse sporco, un 8350 con gli stessi identici margini di fabbrica di un 8150, risulterebbe alla grande 4,3GHz def, quindi si potrebbe avere un miglioramento dell'8% sulla frequenza def ma... sul nulla.


EDIT: a quanto arriva il voltaggio del 9590 quando è a 5.0 ghz?
E' qui il problema.
Se vai nel sito Asrock, dove propongono le loro mobo certificate FX 9590, riportano 1,4V per 5GHz con un 9590, praticamente portando il procio a 25X anzichè 23,5X e disabilitando il turbo, con un Vcore def NB di 1,125V contro 1,165V def di un 8350.
http://www.asrock.com/mb/AMD/990FX%20Extreme9/
In USA è legale la pubblicità comparativa, ma se riporti dati non ricreabili e quindi falsi, meglio che ti sotterri. Il punto è che 1,4V a @5GHz se screen sono una cosa, se con OCCT tutt'altra.
In qualsiasi modo li abbiano rilevati, anche il più fortunello 8350 per uno screen a 5GHz dubito possa scendere a meno di 1,48V.
E' chiaro che spendere il doppio di un 8350 per +200MHz di frequenza DU, è una cosa, ma se un 8350 1,38V def è 125W TDP, 1,4V a sparare al max sarebbero 130W, quindi equivarrebbe a dire che un 9590 starebbe a 5GHz con il dissi stock di un 8350... e per quanto possa essere ottimista lo vedo alla grande irreale... (magari hanno truccato la mobo per riportare Vcore inferiori :)) ma è chiaro che se fosse realtà, 335€ al posto di 180€, sarebbe l'86% in più, ma con un +25% di frequenza, un money-bench lo riporterebbe al 50% più costoso di un 8350, il che lo metterebbe sotto tutt'altra luce.

[digieffe]

io ritengo impossibile sempre sui 32nm esempio D0 un aumento nei 125w di 600mhz, ma comunque si parlava di opteron e non FX e sarebbe considerando il massimo esponente piledriver "abu-dhabi", il "6386 SE" da 2.8ghz(16c)/3.5ghz(8c) per 140w;
2.8(3.5)ghz*1.15= 3.2ghz(16c)/4ghz(8c) oppure frequenza leggermente superiore esempio 3.0ghz(16c)/3.8(8c) in 125w, ma non credo abbassino il tdp...

comunque non mi pare abbiano dichiarato di quanto aumentino le prestazioni per watt(efficienza) con in warsaw, solo che aumenta...
http://www.amd.com/us/press-releases/Pages/amd-unveils-2013june18.aspx


EDIT: 2.8(3.5)ghz * SQRT(1.15) = 3.0ghz(16c)/3.75ghz(8c) per 140w;

[digieffe]

guarda, io ne so meno di te :D

ma perchè radice quadrata (square root) ?

perché da quanto ho letto nel thread da gente preparata, i w (in generale) aumentano col quadrato della frequenza.
Io ho solo riportato quanto saputo, gli "elettronici" ti sapranno dare tutte le spiegazioni del caso.

[digieffe]

invece io reputo interessante questo:

"Berlin
Strengthening our x86 business after the successful launch of “Kyoto” – the world’s first server APU – we announced “Berlin,”geared toward high performance and power efficiency. It is available both as a CPU and APU. The processor boasts four next generation “Steamroller” cores and will offer almost 8X the gigaflops per-watt compared to current AMD Opteron™ 6386SE. It will be the first APU built on AMD’s revolutionary Heterogeneous System Architecture (HSA), which enables uniform memory access for the CPU and GPU and makes programming as easy as C++. With extraordinary compute per-watt, it enables massive rack density. Check it out in the first half of 2014."
D'accordo ma non sarà altro che un "opterino" con un mega coprocessore matematico (gpu), sarà necessario valutare quanto sarà competitivo (in tutti i sensi) rispetto alle soluzioni con gpu discreta.

[digieffe]

Infatti è l'interpretabilità che porta a considerazioni finali ben diverse, ed è chiaro che certe dichiarazioni non possono essere false ma comunque rilevate nel migliore dei casi.Basta prendere la dichiarazione originale, che non so dov'è (io ho letto da te questa cosa), e tradurla correttamente.


EDIT:
"Warsaw
Last, as compute needs grow more complex, AMD has the solution with “Warsaw,” our next-generation 2P/4P offering. It delivers unparalleled cost of ownership for two and four-socket servers. It offers improved performance per-watt while enabling seamless migration from the Opteron™ 6300 Series family. It will be available the first quarter of 2014."
link:http://community.amd.com/community/amd-blogs/business/amd-operon/blog/2013/06/17/amd-reveals-plans-and-products-to-shake-up-the-enterprise-market-in-2014

Qui parla solo di efficienza per watt e come diceva gridracedriver non specifica quanto, questo 15% non è per caso quello tra una generazione ed un altra? perché questa generazione non era prevista, quindi dubito che ci possa essere quel 15% (che poi erano di performance e non di efficienza)

[plainsong]

ricordo che avrà gli stessi moduli e core di kaveri, ma non si sa quale parte igpu e soprattutto avrà in più la cache L3 che in kaveri manca...
Da quanto ho letto purtroppo non risulta che il core Berlin sarà dotato di cache lv3.

[paolo.oliva2]

Basta prendere la dichiarazione originale, che non so dov'è (io ho letto da te questa cosa), e tradurla correttamente.

EDIT:
"Warsaw
Last, as compute needs grow more complex, AMD has the solution with “Warsaw,” our next-generation 2P/4P offering. It delivers unparalleled cost of ownership for two and four-socket servers. It offers improved performance per-watt while enabling seamless migration from the Opteron™ 6300 Series family. It will be available the first quarter of 2014."
link:http://community.amd.com/community/amd-blogs/business/amd-operon/blog/2013/06/17/amd-reveals-plans-and-products-to-shake-up-the-enterprise-market-in-2014

Qui parla solo di efficienza per watt e come diceva gridracedriver non specifica quanto, questo 15% non è per caso quello tra una generazione ed un altra? perché questa generazione non era prevista, quindi dubito che ci possa essere quel 15% (che poi erano di performance e non di efficienza)
Quella dichiarazione è datata giugno 2013, il valore preciso lo si saprebbe l'ultimo giorno prima del via alla produzione in volumi, ed essendo il prodotto dichiarato disponibile nel 1° trimestre 2014, 7-10 mesi prima sarebbe impossibile.
Onestamente io ho letto più dichiarazioni, quella era la prima, poi è scappata una nuova con "un marcato incremento prestazionale" e poi da qualche parte ho letto +15%, poi con tutte le cavolate che scrivono in rete può essere benissimo che potrebbe essere stata fraintesa, però ragioniamo su dei fatti e non ipotesi:
Varsavia su Vishera potrebbe essere una fotocopia di quanto AMD ha fatto da Trinity a Richland. Quanto ha guadagnato Richland su Trinity? 100-200MHz? Non mi ricordo... ma non è importante la cifra esatta, tanto avendo Richland potenziato mi sembra fino al 50% la parte IGP, sicuramente una parte del guadagno è andato all'IGP e sottratto alla parte X86.
Però sappiamo che Richland è sullo stesso PP di Trinity, mentre Varsavia hanno riportato "sulla stessa architettura" il che non escluderebbe un nuovo PP silicio, sempre 32nm HKMG ULK ma migliore.
---
Consideriamo che il periodo di produzione di Richland è 8 mesi, dopo ci sarebbe Kaveri basato su Steamroller e sul 28nm Bulk mentre Varsavia rimarrà in produzione almeno fino a Exavator (visto che Steamroller Opteron non è previsto), il che lo porterebbe al 2015 (come è stato annunciato), e fra che gli APU usciranno prima degli FX Opteron e altre menate, metà 2015 almeno come data più vicina credo non si possa avere.
Per ammortizzare un PP nuovo ci vogliono 12 mesi... sull'intenzione di AMD/GF non sappiamo nulla, ma non possiamo confrontare un prodotto Richland sul mercato per 8 mesi (e quindi un PP nuovo commercialmente non ammortizzabile) ed un prodotto Varsavia che al minimo resterebbe per 18 mesi, che oltre ad essere più che ammortizzabile, dovrebbe pure soddisfare un'esigenza di offerta di mercato per molto più tempo.
----
Oltre a queste considerazioni, è incontestabile che un 8350 4GHz 125W prodotto a novembre 2012 avrà un TDP/frequenza peggiore dello stesso modello 8350 ma prodotto oggi.

Unendo il tutto... prendendo solamente il +5% di Richland su Trinity avremmo un 8350 a 4,2GHz anzichè 4GHz, più un X% non quantificabile che in Richland è stato destinato a potenziare l'IGP di un 50%, più il margine sullo stesso PP dovuto all'affinamento di 1 anno e passa di produzione oppure le migliorie di un PP nuovo... saremmo tanto distanti dai 4,4GHz? Che poi, tradotto, sarebbe un 9370 a 125W TDP.

Premetto, per evitare discussioni, sono aspettative (secondo me) non esagerate, ma credo più improbabile un guadagno solamente di 300MHz di quanto, invece, si possa sperare in qualcosa di più dei 4,4GHz.

[digieffe]

Quanto ha guadagnato Richland su Trinity? 100-200MHz? Non mi ricordo... ma non è importante la cifra esatta, tanto avendo Richland potenziato mi sembra fino al 50% la parte IGP, sicuramente una parte del guadagno è andato all'IGP e sottratto alla parte X86.
Mi risulta che l'IGP di Richland sia sostanzialmente quella di Trinity, fatto salvo qualche mhz (pochi punti percentuali)

[epimerasi]

D'accordo ma non sarà altro che un "opterino" con un mega coprocessore matematico (gpu), sarà necessario valutare quanto sarà competitivo (in tutti i sensi) rispetto alle soluzioni con gpu discreta.

Quella dichiarazione la devi leggere in chiave HSA.

http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/

Ha poco senso compararlo ad un sistema CPU+GPU discreta

[paolo.oliva2]

Mi risulta che l'IGP di Richland sia sostanzialmente quella di Trinity, fatto salvo qualche mhz (pochi punti percentuali)
Bah, io non seguo la parte APU, però avevo visto "fino a un +50% sulla parte grafica" e ricordo dei commenti tipo "meglio che incrementavano la parte X86 invece dell'IGP che tanto era già la migliore sul mercato" e Haswell non era certo un problema.
Comunque nulla toglie a quanto scritto sopra... il SOI ha sempre portato a circa +200MHz nell'affinamento da inizio produzione alla fine, e arriveremmo sui 4,2GHz, aggiungici il guadagno di Richland su Trinity (non mi ricordo se 100 o 200MHz), 300-400MHz sarebbero già serviti anche senza cambio PP e altro.
La frequenza def è relativa... io onestamente preferirei 4,3GHz def con margini OC stile 8350 (+400MHz con lo stesso Vcore def) che 4,5GHz e margini stile 8150 (+150MHz), tanto gli FX sono per l'OC e chi ci smanetta a def non lo tiene, quindi una frequenza def più bassa ma con un margine del 10% ed una frequenza più alta ma con margine del 5% porterebbero comunque alla stessa frequenza in OC finale allo stesso Vcore.

Edit P.S.
in fin dei conti il succo del discorso è più sulla diatriba che il nuovo Piledriver Varsavia possa essere 4,2GHz 125W o 4,4GHz, ma il classico guadagno di +200MHz del SOI è sbagliato riportarlo in frequenza ma bensì in percentuale. Ai tempi del PHenom II, c'era si quel guadagno di 200MHz, ma su 3GHz 200MHz rappresentano un 6-7%. Ora che siamo sui 4GHz, un 6-7% rappresenterebbe 240/280MHz e non 200MHz. Poi possiamo discutere che da un silicio a 3GHz c'era più margine rispetto ad un silicio a 4GHz, e quant'altro... però, non è che voglio che per forza esista un 4,4GHz X8 per 125W TDP, ma tra tutte le combinazioni possibili:
- affinamento silicio
- nuovo PP
- affinamento architetturale (stile Trinity-Richland)
per i 4,2GHz basterebbe una delle 3 voci
Per i 4,4GHz 2 condizioni a scelta tra le 3
Per i 4,6GHz tutte le 3 condizioni.

L'affinamento architetturale ci sarà perchè si intende nel modulo dell'architettura Piledriver, con Richland che ne è la prova su Trinity, quindi non vedo alcuna controindicazione per Varsavia.
L'affinamento del silicio c'è perchè il SOI lo garantisce infornata dopo infornata e di infornate in 1 anno e più ce ne sono state.

La terza sarebbe un nuovo PP, ma qui è buio completo... però bisognerebbe considerare che Varsavia ricalcherebbe l'ottimizzazione architetturale di Richland a livello del modulo, mi rimane incomprensibile il perchè di uno slittamento di 7-8 mesi, visto che Richland è sempre sul 32nm SOI HKMG ULK e con frequenze massime simili, non penso sia nemmeno necessario un riposizionamento dei transistor... quindi a livello di realizzo, sarebbe bastato prendere il modulo ottimizzato Piledriver di Richland e metterlo al posto del modulo Piledriver Vishera lasciando invariato tutto il resto.
Può darsi, ma è fantasia, che abbino combinato le modifiche Trinity-Richland con la gestione Turbo FX 8350-9370/9590, ma a quel punto, PP nuovo o invariato, comunque si avrebbe sempre un miglioramento delle frequenze massime migliore rispetto all'incremento della frequenza def, tipo 8350 +200MHz tra def/Turbo e Varsavia +300MHz.

[digieffe]

Quella dichiarazione la devi leggere in chiave HSA.

http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/

Ha poco senso compararlo ad un sistema CPU+GPU discreta

Grazie per i link, è dall'uscita della GCN che non mi aggiornavo sull'argomento.

Questo però non toglie che non c'è differenza tra la igp integrata e la gpu discreta con lo stesso tipo di core.

[carlottoIIx6]

Quella dichiarazione la devi leggere in chiave HSA.

http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/

Ha poco senso compararlo ad un sistema CPU+GPU discreta

http://image.slidesharecdn.com/hsaintrohotchips2013final-130826090053-phpapp02/95/slide-3-638.jpg?1377525892

[carlottoIIx6]

Bah, io non seguo la parte APU, però avevo visto "fino a un +50% sulla parte grafica" e ricordo dei commenti tipo "meglio che incrementavano la parte X86 invece dell'IGP
cUT.
c'è stato un notevole miglioramente sulla parte mobile.
sulla parte desktop più contenuto, forse perchè la gestione del consumo si fa sentire piu sul mobile.
penso che un po migliorerà per via dei bios acerbi.


ps piledriver è andato bene, più affinarsi ancora, ma la cosa che dobbiamo chiederci che fine ha fatto steam che esiste giù apu?

[digieffe]

La terza sarebbe un nuovo PP, ma qui è buio completo... però bisognerebbe considerare che Varsavia ricalcherebbe l'ottimizzazione architetturale di Richland a livello del modulo, mi rimane incomprensibile il perchè di uno slittamento di 7-8 mesi, visto che Richland è sempre sul 32nm SOI HKMG ULK e con frequenze massime simili, non penso sia nemmeno necessario un riposizionamento dei transistor... quindi a livello di realizzo, sarebbe bastato prendere il modulo ottimizzato Piledriver di Richland e metterlo al posto del modulo Piledriver Vishera lasciando invariato tutto il resto.
Può darsi, ma è fantasia, che abbino combinato le modifiche Trinity-Richland con la gestione Turbo FX 8350-9370/9590, ma a quel punto, PP nuovo o invariato, comunque si avrebbe sempre un miglioramento delle frequenze massime migliore rispetto all'incremento della frequenza def, tipo 8350 +200MHz tra def/Turbo e Varsavia +300MHz.
da ciò che sto imparando dagli elettronici, penso che si sarebbe dovuto riscrivere grossa parte della cpu, in quanto le librerie soi dovrebbero essere diverse dalle bulk.

in ogni caso chiedo conferma agli esperti.

[paolo.oliva2]

da ciò che sto imparando dagli elettronici, penso che si sarebbe dovuto riscrivere grossa parte della cpu, in quanto le librerie soi dovrebbero essere diverse dalle bulk.

in ogni caso chiedo conferma agli esperti.

Si, ma questo sarebbe nel caso da Kaveri Steamroller 28nm Bulk a Steamroller FX/Opteron 32nm SOI, ma implementare Richland Piledriver modulo "versione B" 32nm SOI a Varsavia, in quanto sempre Piledriver e sempre 32nm SOI, il lavoro sarebbe pressochè nullo... sempre considerando che l'APU è composta da 2 moduli Piledriver "versione b" che poi non ci sia la L3, ci sia l'IGP, cambi l'I/O e che l'MC lavori in modo diverso... vedo il modulo come un motore da autovettura, in cui lo stesso motore possa essere montato su una coupè, una berlina e una decappottabile senza di certo cambi di parti del motore ma al limite, come nelle vetture, una gestione differente da parte della centralina per modificare coppia/CV in quanto telai differenti, robustezze differenti.

[paolo.oliva2]

c'è stato un notevole miglioramente sulla parte mobile.
sulla parte desktop più contenuto, forse perchè la gestione del consumo si fa sentire piu sul mobile.
penso che un po migliorerà per via dei bios acerbi.


ps piledriver è andato bene, più affinarsi ancora, ma la cosa che dobbiamo chiederci che fine ha fatto steam che esiste giù apu?

Io rimango dell'idea che sarebbe costato troppi soldi e troppo tempo per portarlo da Bulk a SOI.
Anzichè un aumento prezzi su Vishera e un tempo obbligatoriamente più lungo di produzione per riprendere i soldi spesi, avrebbe una sua logica rinunciare a più potenza a favore di Varsavia il quale potrebbe avere un ulteriore calo di prezzi per poi poter lanciare Exavator APU e FX/Opteron in contemporanea, ammesso e concesso che AMD abbandoni il Bulk per gli APU e riunisca tutto all'FD-SOI.
Considera anche la situazione commerciale di AMD... per qualsiasi money-bench un FX dovrebbe essere il best-buy del momento, eppure... dispiace dirlo, ma AMD vende solamente se deprezzato alla grande.
Se ci fai caso, l'8150 era stato fatto apparire un cesso, poi dopo 2 anni non era quel cesso che era stato descritto nei confronti del Thuban... ma sono stati 2 anni in cui di Zambesi AMD ne ha venduti pochi, idem l'8350, se non ricordo male all'uscita sembrava che non raggiungeva manco un 2600K, poi ci ritroviamo dopo 1 anno che è praticamente a braccetto con il 3770K e poco distante da un 4770K, ma, come con l'8150, di certo giudizi diversi e sempre più negativi del reale, ne hanno condizionato le vendite e solamente ora qualcuno se nìè accorto. Il passaggio da Piledriver a Steamroller dovrebbe portare incrementi almeno del 10-15%, quindi tanto basterebbe ad annullare le differenze, ma visto quanto successo prima con Zambesi e Piledriver, credi cambierebbe qualche cosa con Steamroller? Ci sarebbe il via alla solita barzelletta della differenza consumi enfatizzata, alla solita focalizzazione sull'IPC ignorando tutto il resto e quant'altro, con evidenti ripercussioni sulle vendite. Teorizzando un Exavator nel 2015, con annessa e connessa evoluzione architetturale sia in termini prestazionali che nei consumi, e visto il largo margine di tempo, compatibile su un FD-SOI con una miniaturizzazione sul 20nm almeno, mi sembra praticamente impossibile che la fascia FX non si riavvicini alla fascia 2011 Intell, di certo non cambierà l'atteggiamento delle varie rece, ma a meno che non facciano test unicamente ST e basati sull'ecologia, mi sembra plausibile che il confronto lo si farà vs gli X6 Intel.

[digieffe]

Si, ma questo sarebbe nel caso da Kaveri Steamroller 28nm Bulk a Steamroller FX/Opteron 32nm SOI, ma implementare Richland Piledriver modulo "versione B" 32nm SOI a Varsavia, in quanto sempre Piledriver e sempre 32nm SOI, il lavoro sarebbe pressochè nullo... sempre considerando che l'APU è composta da 2 moduli Piledriver "versione b" che poi non ci sia la L3, ci sia l'IGP, cambi l'I/O e che l'MC lavori in modo diverso...
Avevo capito male: Kaveri -> Varsaws
Nel caso Richland -> Varsaw il lavoro da fare sarebbe poco. Non capisco perché non dovrebbero farlo...

[carlottoIIx6]

Io rimango dell'idea che sarebbe costato troppi soldi e troppo tempo per portarlo da Bulk a SOI.
Anzichè un aumento prezzi su Vishera e un tempo obbligatoriamente più lungo di produzione per riprendere i soldi spesi, avrebbe una sua logica rinunciare a più potenza a favore di Varsavia il quale potrebbe avere un ulteriore calo di prezzi per poi poter lanciare Exavator APU e FX/Opteron in contemporanea, ammesso e concesso che AMD abbandoni il Bulk per gli APU e riunisca tutto all'FD-SOI.

questo ragionamento è corretto, io mio chiedevo se ci fosse altro che non sappiamo.

Considera anche la situazione commerciale di AMD... per qualsiasi money-bench un FX dovrebbe essere il best-buy del momento, eppure... dispiace dirlo, ma AMD vende solamente se deprezzato alla grande.
Se ci fai caso, l'8150 era stato fatto apparire un cesso, poi dopo 2 anni non era quel cesso che era stato descritto nei confronti del Thuban... ma sono stati 2 anni in cui di Zambesi AMD ne ha venduti pochi, idem l'8350, se non ricordo male all'uscita sembrava che non raggiungeva manco un 2600K, poi ci ritroviamo dopo 1 anno che è praticamente a braccetto con il 3770K e poco distante da un 4770K, ma, come con l'8150, di certo giudizi diversi e sempre più negativi del reale, ne hanno condizionato le vendite e solamente ora qualcuno se nìè accorto. Il passaggio da Piledriver a Steamroller dovrebbe portare incrementi almeno del 10-15%, quindi tanto basterebbe ad annullare le differenze, ma visto quanto successo prima con Zambesi e Piledriver, credi cambierebbe qualche cosa con Steamroller?

steam necessita di una maggiore miniutirizzazione per me.

Ci sarebbe il via alla solita barzelletta della differenza consumi enfatizzata, alla solita focalizzazione sull'IPC ignorando tutto il resto e quant'altro, con evidenti ripercussioni sulle vendite. Teorizzando un Exavator nel 2015, con annessa e connessa evoluzione architetturale sia in termini prestazionali che nei consumi, e visto il largo margine di tempo, compatibile su un FD-SOI con una miniaturizzazione sul 20nm almeno, mi sembra praticamente impossibile che la fascia FX non si riavvicini alla fascia 2011 Intell, di certo non cambierà l'atteggiamento delle varie rece, ma a meno che non facciano test unicamente ST e basati sull'ecologia, mi sembra plausibile che il confronto lo si farà vs gli X6 Intel.
pile ottimizzato ancora ragiungera il 4770k imo

[paolo.oliva2]

Comunque di sicuro AMD deve ottimizzare l'architettura BD perchè è ancora acerba... e il confronto con Intel lato numero di transistor/potenza è impietoso, ma di certo avere più transistor e poi pure una miniaturizzazione meno spinta raddoppia il prb, senza contare anche gli altri vantaggi, tipo che ad un abbassamento TDP per una miniaturizzazione di spinta consentirebbe un 9590 nei 125W TDP a parità di frequenze massime raggiungibili, altrimenti, nel caso di un silicio che non gradisse le frequenze alte, per sfruttare tutti i 125W TDP l'unico modo sarebbe quello di aumentare i core, ma in un modo o nell'altro si avrebbe comunque più potenza a parità di architettura ed un consumo/prestazioni indubbiamente molto più basso.

Secondo me è tutta qui la situazione AMD... o ottimizzare l'architettura per ovviare i limiti di una miniaturizzazione peggiore, ma sarebbe un lavoro esponenziale, in quanto anche supponendo un pareggio di affinamento architetturale, il gap della miniaturizzazione porterebbe comunque un svataggio, oppure disporre di un silicio con miniaturizzazione uguale o vicinissima a quella Intel che da solo risolverebbe un buon 50% dei problemi.

[epimerasi]

http://image.slidesharecdn.com/hsaintrohotchips2013final-130826090053-phpapp02/95/slide-3-638.jpg?1377525892

E quindi?

[epimerasi]

Grazie per i link, è dall'uscita della GCN che non mi aggiornavo sull'argomento.

Questo però non toglie che non c'è differenza tra la igp integrata e la gpu discreta con lo stesso tipo di core.

Quell'APU (basata su Steamroller) avrà nuova GPU e hUMA, quindi dovrebbe essere pronta per questa tecnologia.

[Athlon]

Comunque di sicuro AMD deve ottimizzare l'architettura BD perchè è ancora acerba... e il confronto con Intel lato numero di transistor/potenza è impietoso, ma di certo avere più transistor e poi pure una miniaturizzazione meno spinta raddoppia il prb, senza contare anche gli altri vantaggi, tipo che ad un abbassamento TDP per una miniaturizzazione di spinta consentirebbe un 9590 nei 125W TDP a parità di frequenze massime raggiungibili, altrimenti, nel caso di un silicio che non gradisse le frequenze alte, per sfruttare tutti i 125W TDP l'unico modo sarebbe quello di aumentare i core, ma in un modo o nell'altro si avrebbe comunque più potenza a parità di architettura ed un consumo/prestazioni indubbiamente molto più basso.

Secondo me è tutta qui la situazione AMD... o ottimizzare l'architettura per ovviare i limiti di una miniaturizzazione peggiore, ma sarebbe un lavoro esponenziale, in quanto anche supponendo un pareggio di affinamento architetturale, il gap della miniaturizzazione porterebbe comunque un svataggio, oppure disporre di un silicio con miniaturizzazione uguale o vicinissima a quella Intel che da solo risolverebbe un buon 50% dei problemi.


e ragionando al contrario questo penso sia stato uno dei motivi che hanno fatto abortire l'architettura Bulldozer su miniaturizzazione 45nm e obbligato alla creazione di Thuban riciclando i vecchi core

[isomen]

e ragionando al contrario questo penso sia stato uno dei motivi che hanno fatto abortire l'architettura Bulldozer su miniaturizzazione 45nm e obbligato alla creazione di Thuban riciclando i vecchi core

:ave:
éra da tanto che nn mi capitava di leggere un tuo post

ragionando ancora in un altro modo, sarebbe stato interessante anche vedere cosa avrebbe potuto fare thuban sul 32nm... magari saltando zambezi e iniziando l'avventura bd con vishera.

;) ciauz

[carlottoIIx6]

E quindi?

ci sono tutti i marchi più importanti su questo proggetto.

[paolo.oliva2]

:ave:
éra da tanto che nn mi capitava di leggere un tuo post
ragionando ancora in un altro modo, sarebbe stato interessante anche vedere cosa avrebbe potuto fare thuban sul 32nm... magari saltando zambezi e iniziando l'avventura bd con vishera.
;) ciauz
A guardare Llano che per 100W TDP sul 32nm HKMG ULK faceva fatica in OC ad uguagliare un Phenom II X4 95W... il 32nm sembrerebbe un cesso.

Però ricordo i discorsi iniziali sulle frequenze di Zambesi in cui nel TH i più davano già difficile frequenze alla pari del Thuban... ed un Zambesi, pur con un affinamento architetturale indecente già era 3,6GHz, un piccolo affinamento e si è arrivati a 4GHz e Varsavia impossibile che non arrivi almeno a 4,2GHz, quindi portare 1,2 miliardi di transistor a +1GHz rispetto ad un 1090T, non è cosa da poco.
Io non mi intendo di silicio nè tantomeno di affinamento architetturale... però il 45nm SOI, con il Phenom II, ha guadagnato 800MHz dal 940 3GHz al 980 3,8GHz in 3 anni (o più?), e a detti di tutti il 45nm SOI era un gran bel silicio, sto 32nm ne ha guadagnati 400MHz in 1 anno (Vishera da Zambesi) e in 3 anni con Varsavia su Zambesi arriverà certamente a +600MHz almeno se non a +800MHz arrivando poco meno o uguagliando il 45nm in miglioramento frequenza, tra l'altro a frequenze che il 99% della gente reputava impossibile per un X8 già superare i 3,5GHz.

A me viene da riflettere su una cosa... non è strano che AMD abbia lavorato la bellezza di 5 anni sull'architettura BD arrivando al prodotto Zambesi immaturo sotto tutti gli aspetti, ed in 2-3 anni sia riuscito a creare Piledriver, Steamroller già pronto ad essere prodotto ed Exavator già nel cassetto e almeno su carta pressochè pronto? Tra l'altro con i magri incassi di Zambesi?
Ha fatto più in 3 anni che negli ultimi 12 anni... :doh:

[Phenomenale]

sarebbe stato interessante anche vedere cosa avrebbe potuto fare thuban sul 32nm...
Guardare a Llano penso possa dare un idea del core K10 messo su 32nm...

[isomen]

A guardare Llano che per 100W TDP sul 32nm HKMG ULK faceva fatica in OC ad uguagliare un Phenom II X4 95W... il 32nm sembrerebbe un cesso.

Però ricordo i discorsi iniziali sulle frequenze di Zambesi in cui nel TH i più davano già difficile frequenze alla pari del Thuban... ed un Zambesi, pur con un affinamento architetturale indecente già era 3,6GHz, un piccolo affinamento e si è arrivati a 4GHz e Varsavia impossibile che non arrivi almeno a 4,2GHz, quindi portare 1,2 miliardi di transistor a +1GHz rispetto ad un 1090T, non è cosa da poco.
Io non mi intendo di silicio nè tantomeno di affinamento architetturale... però il 45nm SOI, con il Phenom II, ha guadagnato 800MHz dal 940 3GHz al 980 3,8GHz in 3 anni (o più?), e a detti di tutti il 45nm SOI era un gran bel silicio, sto 32nm ne ha guadagnati 400MHz in 1 anno (Vishera da Zambesi) e in 3 anni con Varsavia su Zambesi arriverà certamente a +600MHz almeno se non a +800MHz arrivando poco meno o uguagliando il 45nm in miglioramento frequenza, tra l'altro a frequenze che il 99% della gente reputava impossibile per un X8 già superare i 3,5GHz.

A me viene da riflettere su una cosa... non è strano che AMD abbia lavorato la bellezza di 5 anni sull'architettura BD arrivando al prodotto Zambesi immaturo sotto tutti gli aspetti, ed in 2-3 anni sia riuscito a creare Piledriver, Steamroller già pronto ad essere prodotto ed Exavator già nel cassetto e almeno su carta pressochè pronto? Tra l'altro con i magri incassi di Zambesi?
Ha fatto più in 3 anni che negli ultimi 12 anni... :doh:

Guardare a Llano penso possa dare un idea del core K10 messo su 32nm...

Nn mi sono mai interessato alle apu, ma il confronto nn mi sembra molto appropriato... visto che un 4100 é almeno alla pari con il top fm1 e a parità di frequenza un thuban polverizza qualsiasi 61xx... nn credo che thuban sul pur pessimo 32nm avrebbe fatto rimpiangere zambezi, anche se nn avesse concesso i 2 core in più degli 81xx... poteva evitare una cattiva partenza a bd.

;) ciauz

[feldvonmanstein]

A guardare Llano che per 100W TDP sul 32nm HKMG ULK faceva fatica in OC ad uguagliare un Phenom II X4 95W... il 32nm sembrerebbe un cesso.

Però ricordo i discorsi iniziali sulle frequenze di Zambesi in cui nel TH i più davano già difficile frequenze alla pari del Thuban... ed un Zambesi, pur con un affinamento architetturale indecente già era 3,6GHz, un piccolo affinamento e si è arrivati a 4GHz e Varsavia impossibile che non arrivi almeno a 4,2GHz, quindi portare 1,2 miliardi di transistor a +1GHz rispetto ad un 1090T, non è cosa da poco.
Io non mi intendo di silicio nè tantomeno di affinamento architetturale... però il 45nm SOI, con il Phenom II, ha guadagnato 800MHz dal 940 3GHz al 980 3,8GHz in 3 anni (o più?), e a detti di tutti il 45nm SOI era un gran bel silicio, sto 32nm ne ha guadagnati 400MHz in 1 anno (Vishera da Zambesi) e in 3 anni con Varsavia su Zambesi arriverà certamente a +600MHz almeno se non a +800MHz arrivando poco meno o uguagliando il 45nm in miglioramento frequenza, tra l'altro a frequenze che il 99% della gente reputava impossibile per un X8 già superare i 3,5GHz.

A me viene da riflettere su una cosa... non è strano che AMD abbia lavorato la bellezza di 5 anni sull'architettura BD arrivando al prodotto Zambesi immaturo sotto tutti gli aspetti, ed in 2-3 anni sia riuscito a creare Piledriver, Steamroller già pronto ad essere prodotto ed Exavator già nel cassetto e almeno su carta pressochè pronto? Tra l'altro con i magri incassi di Zambesi?
Ha fatto più in 3 anni che negli ultimi 12 anni... :doh:

il 980 è 3,7 GHZ nn 3,8

[paolo.oliva2]

il 980 è 3,7 GHZ nn 3,8

Mi sbaglio sempre... comunque meglio ancora. Il 45nm ha guadagnato 700MHz da inizio produzione alla fine, il 32nm ne ha guadagnati 400MHz in 1 anno e con tutta probabilità arrivare ad eguagliare se con superare l'incremento del 45nm... difficile dire che sia peggiore.

[paolo.oliva2]

Vi faccio vedere una cosa scioccante :D di come cacchio influisce la temp ambiente.

8350 1,2V - 3,2GHz - sotto i 95W TDP - dissi stock 140W TDP 8350.

OCCT 48TH - temp 55° nello screen, ma sono arrivato nel proseguo a 60°.

http://uptiki.altervista.org/_altervista_ht/yoj780e2pinlkhfmw7a_thumb.jpg (http://uptiki.altervista.org/viewer.php?file=yoj780e2pinlkhfmw7a.jpg)

Indubbiamente il mio impianto a liquido mi aiuta tantissimo, visto che arrivo a temp simili con un Vcore 1,425V da 1,2V, e +0,225V sono una vita... ma evidentemente non può fare miracoli.

[digieffe]

Quell'APU (basata su Steamroller) avrà nuova GPU e hUMA, quindi dovrebbe essere pronta per questa tecnologia.

Ho studiato le slide hUMA, come tecnologia è la più facile da utilizzare che ho visto fin ora, ma l'utilizzo è sempre come unità a se stante e non direttamente dalla cpu e cosa più importante i programmi vanno adattati.
Ciò significa che ci vorranno anni perché venga utilizzata (vedi passaggio 32 bit -> 64 bit).
Cosa diversa sarebbe stata se fosse stato in grado di eseguire per es. istruzioni avx o altre (opportunamente decodificate ed adattate via hardware).

[plainsong]

Chiedo venia qualora fosse già stato postato, è una comparativa interessante: http://www.tomshw.it/cont/articolo/piu-core-e-overclock-le-cpu-amd-nella-fascia-bassa-si-fanno-valere/48548/1.html

[jinkky]

Ragazzi attualmente ho un and 960t x4 con una GPU sapphire 9750 oc 3gb.
Lo vorrei sostituire con un fx 8350. Dite che ne vale la pena? Avrei dei miglioramenti palesi ingame?

[epimerasi]

ci sono tutti i marchi più importanti su questo proggetto.

In realtà, credo che perchè ci sia una svolta vera e propria manca il marchio più importante: Intel.

Immagino starà alla porta e poi si muoverà col solito scambio di licenze con AMD che fanno ogni tot anni.

[epimerasi]

Ho studiato le slide hUMA, come tecnologia è la più facile da utilizzare che ho visto fin ora, ma l'utilizzo è sempre come unità a se stante e non direttamente dalla cpu e cosa più importante i programmi vanno adattati.
Ciò significa che ci vorranno anni perché venga utilizzata (vedi passaggio 32 bit -> 64 bit).
Cosa diversa sarebbe stata se fosse stato in grado di eseguire per es. istruzioni avx o altre (opportunamente decodificate ed adattate via hardware).

Sicuramente ci vorrà un po' di tempo perché venga adottata.

Il punto principale però è che, a differenza delle tecnologie fin qui proposte (principalmente Cuda, OpenCL e DirectCompute), scarica (FINALMENTE) la maggior parte dell'onere di adattamento del codice sui produttori di hardware e non sul programmatore.

La filosofia è +o- (ma direi che è una "generalizzazione") quella di Java.

I programmatori possono utilizzare i linguaggi con cui si trovano meglio e rispettive librerie (Java, C/C++&OpenCL/Cuda, C++/C#&DirectX, Python&binding, etc...), sta a chi sviluppa i linguaggi implementare compilatori e interpreti per il lingauaggio intermedio (HSAIL) e ai produttori di hardware fornire i driver adeguati a supportarlo.

Certo, se Intel si desse una svegliata sarebbe meglio per tutti.

[capitan_crasy]

Ragazzi attualmente ho un and 960t x4 con una GPU sapphire 9750 oc 3gb.
Lo vorrei sostituire con un fx 8350. Dite che ne vale la pena? Avrei dei miglioramenti palesi ingame?

direi proprio di si...

media
http://i.imgur.com/31aKLTH.jpg

scheda usata Asus HD7970-DC2T-3GD5 DirectCU II TOP
(1920x1080)
Assassin 's Creed 3
Battlefield 3
Borderlands 2
Call of Duty: Black Ops II
Crysis 3
F1 2012
Metro Last Light
The Elder Scrolls V: Skyrim

Clicca qui... (http://www.computerbase.de/artikel/prozessoren/2013/amd-fx-9590-prozessor-im-test/35/)

[AceGranger]

In realtà, credo che perchè ci sia una svolta vera e propria manca il marchio più importante: Intel.

Immagino starà alla porta e poi si muoverà col solito scambio di licenze con AMD che fanno ogni tot anni.

se per quello mancano pure IBM e nVidia... il primo vero prodotto HSA arrivera quando ? almeno nel 2016 se non piu tardi, per quella data vedremo cosa effettivamente faranno gli altri player.

Ho studiato le slide hUMA, come tecnologia è la più facile da utilizzare che ho visto fin ora, ma l'utilizzo è sempre come unità a se stante e non direttamente dalla cpu e cosa più importante i programmi vanno adattati.
Ciò significa che ci vorranno anni perché venga utilizzata (vedi passaggio 32 bit -> 64 bit).
Cosa diversa sarebbe stata se fosse stato in grado di eseguire per es. istruzioni avx o altre (opportunamente decodificate ed adattate via hardware).

piu che il quando, vorrei capire quali programmi verranno adattati... non mi pare di vedere molti programmi consumer che usano OpenCL, è gia difficile trovare quelli professionali.

[LurenZ87]

Ragazzi toglietemi una curiosità... Siccome sto per costruirsi un muletto con socket FM2, mi stava venendo la malsana idea di utilizzare il dissipatore originale del FX-8350 su un apu... In sostanza, monta pure sul FM2???

PS: la settimana prossima si inizia con una nuova missione...

Trascendere il limite del Super FX-8350 :sofico:

Inviato dal mio Nexus 4 con Tapatalk 2

[digieffe]

se per quello mancano pure IBM e nVidia... il primo vero prodotto HSA arrivera quando ? almeno nel 2016 se non piu tardi, per quella data vedremo cosa effettivamente faranno gli altri player.

piu che il quando, vorrei capire quali programmi verranno adattati... non mi pare di vedere molti programmi consumer che usano OpenCL, è gia difficile trovare quelli professionali.

Se non fanno alcuna conversione via hardware (es: avx ->hsa) potrebbero farla via software come in uno dei tanti scenari descritti (ricompilazione dei file intermedi delle classi di java), ricompilare i file obj x86 in codice per hsa, però non non saprei quali vantaggi possa portare.

[AceGranger]

Se non fanno alcuna conversione via hardware (es: avx ->hsa) potrebbero farla via software come in uno dei tanti scenari descritti (ricompilazione dei file intermedi delle classi di java), ricompilare i file obj x86 in codice per hsa, però non non saprei quali vantaggi possa portare.

hUMA verra sfruttato da qui programmi che gia oggi usano la GPU, se un software non usa la GPU che ci sia hUMA o meno non cambia.

i giochi presumo che qualche fps guadagneranno, riusciranno meglio a saturare la GPU, ma come software OpenCL non vedo molto; vedremo nei prossimi anni.

[digieffe]

hUMA verra sfruttato da qui programmi che gia oggi usano la GPU, se un software non usa la GPU che ci sia hUMA o meno non cambia.

i giochi presumo che qualche fps guadagneranno, riusciranno meglio a saturare la GPU, ma come software OpenCL non vedo molto; vedremo nei prossimi anni.

sicuramente sarà utilizzato in ambiti specifici, leggevo anche della possibilità di utilizzo general purpose.
Dalle slide parlavano di algoritmi di ordinamento e ricerca via gpu, il problema che vanno riscritti gli algoritmi (non utilizzerebbe il quick sort, o quel che sia degli ordinamenti per confronto, ma ad es: il radix sort basato su operazioni aritmetiche ed una quantità di confronti irrisoria)

insomma anche se il programma utente non passa per né il S.O. né per i driver e può parlare con la igp, deve comunque caricare un job, preparando un data set ed "attivandolo" tramite un record di 64 byte: tutt'altro che trasparente... (questo sempre che il compilatore prepari in automatico un kernel per la igp)

come dici tu ci sono diversi anni d'avanti vedremo come andrà a finire

Imho se non rendono più vicino all'x86 la cosa (con un decoder x86->huma, hardware o software), resterà per lungo tempo un utilizzo di nicchia.

[Phenomenale]

Imho se non rendono più vicino all'x86 la cosa....., resterà per lungo tempo un utilizzo di nicchia.
Ma huma è una feature di nicchia; ci saranno quei pochi software dedicati ad usarla e stop.

[feldvonmanstein]

Ragazzi attualmente ho un and 960t x4 con una GPU sapphire 9750 oc 3gb.
Lo vorrei sostituire con un fx 8350. Dite che ne vale la pena? Avrei dei miglioramenti palesi ingame?

il 960t è overcloccato? direi che se confrontati a default la differenza si possa notare, invece se lo tieni già con oc a 3,7\4 ghz la differenza la noteresti solo nei giochi più recenti. poi al di fuori dei giochi chiaramente nn c'è partita , l'8350 vince di misura


alcuni esempi con il 980 3,7 ghz :
http://cdn.overclock.net/6/68/6850444d_Gaming_02.png
http://techreport.com/r.x/amd-fx-8350/skyrim-fps.gif
http://www.bjorn3d.com/wp-content/uploads/2012/10/LostPlanet_1920_2.jpg
http://www.sweclockers.com/image/diagram/3836?k=3118bb6589e836e419f39dc2c3fd8536
http://i.imgur.com/dTPrN.jpg
http://cdn.overclock.net/4/41/900x900px-LL-414adfdd_CPU1.png

[paolo.oliva2]

direi proprio di si...

media
http://i.imgur.com/31aKLTH.jpg

scheda usata Asus HD7970-DC2T-3GD5 DirectCU II TOP
(1920x1080)
Assassin 's Creed 3
Battlefield 3
Borderlands 2
Call of Duty: Black Ops II
Crysis 3
F1 2012
Metro Last Light
The Elder Scrolls V: Skyrim

Clicca qui... (http://www.computerbase.de/artikel/prozessoren/2013/amd-fx-9590-prozessor-im-test/35/)

Una curiosità... possibile che un 9590, a fronte di una frequenza superiore del 17,5% def e del 19% turbo, guadagni solamente il 3,9% sull'8350?
Edit: è proporzionato all'incremento dell'A10-6800K che a 4,1GHz guadagna il 2% con +300MHz/+7,8% di frequenza sull'A8-5800K, sono sempre Piledriver, ed occhio e croce il guadagno è 1/4 rispetto all'incremento di frequenza. +7,8% frequenza, +2% prestazioni... +~18% frequenza 9590, /4 = 4,5...
Questo è OT perchè è su Intel... ma un 4770 ed un 4770K la differenza è la K, cioè procio dedicato all'OC, ma il resto penso uguale (ma non li conosco i proci Intel). Perchè con -100MHz def (3,4GHz contro 3,5GHz) al posto che fare meno fa addirittura di più?
Tra parentesi... ma a risoluzioni 1920x1080 non dovrebbe dipendere tutto dalla VGA ed il procio avere una importanza quasi nulla?

[dav1deser]

Una curiosità... possibile che un 9590, a fronte di una frequenza superiore del 17,5% def e del 19% turbo, guadagni solamente il 3,9% sull'8350? Non ci sono colli di bottiglia...
Questo è OT perchè è su Intel... ma un 4770 ed un 4770K la differenza è la K, cioè procio dedicato all'OC, ma il resto penso uguale (ma non li conosco i proci Intel). Perchè con -100MHz def (3,4GHz contro 3,5GHz) al posto che fare meno fa addirittura di più?

Perchè il test è fatto in Full HD e probabilmente spesso la situazione era GPU-limited.

[LurenZ87]

Una curiosità... possibile che un 9590, a fronte di una frequenza superiore del 17,5% def e del 19% turbo, guadagni solamente il 3,9% sull'8350?
Questo è OT perchè è su Intel... ma un 4770 ed un 4770K la differenza è la K, cioè procio dedicato all'OC, ma il resto penso uguale (ma non li conosco i proci Intel). Perchè con -100MHz def (3,4GHz contro 3,5GHz) al posto che fare meno fa addirittura di più?
Tra parentesi... ma a risoluzioni 1920x1080 non dovrebbe dipendere tutto dalla VGA ed il procio avere una importanza quasi nulla?

In FullHD tranne particolari casi, è la vga che la fa da padrona ed il procio diventa quasi inutile... Ad esempio a 2560x1440 che sarebbe la mia risoluzione, avere un FX-8350, un i7 4770k o un futuro i7 4930k non cambierebbe una mazza.

Inviato dal mio Nexus 4 con Tapatalk 2

[feldvonmanstein]

ma infatti per giocare va bene un phenom II ,poca spesa, tanta resa; ormai sono pochi a farlo a risoluzioni inferiori al full hd, si investono meglio i propri soldi in una vga più potente o per chi nn ce l'ha in un monitor a risoluzione superiore appunto.
Poi chiaro che per chi nn usa il pc solo per giocare il discorso cambia.

[Il nabbo di turno]

ma infatti per giocare va bene un phenom II ,poca spesa, tanta resa; ormai sono pochi a farlo a risoluzioni inferiori al full hd, si investono meglio i propri soldi in una vga più potente o per chi nn ce l'ha in un monitor a risoluzione superiore appunto.
Poi chiaro che per chi nn usa il pc solo per giocare il discorso cambia.

Il phenom ormai ha dato, le scorte stanno finendo(il phenom ii x6 ormai è estinto) e per il 4 poco ci manca...
Poca spesa e molta resa è l'athlon ii x4 750k, 65 euro lo si porta su a 4.6 ghz con poco e a questa frequenza è un fx 4300/i3 2100/a10 6800k.

[isomen]

Ragazzi attualmente ho un and 960t x4 con una GPU sapphire 9750 oc 3gb.
Lo vorrei sostituire con un fx 8350. Dite che ne vale la pena? Avrei dei miglioramenti palesi ingame?

In parte dipende dai giochi, ma molto dipende se alla tua cpu si sbloccano i 2 core spenti e se fai oc, il mio 960T @ X6 overclockato a 3,8ghz con uno sli di 560 nn se la cava male:
http://img94.imageshack.us/img94/7811/4csu.jpg (http://imageshack.us/photo/my-images/94/4csu.jpg/) Uploaded with ImageShack.us (http://imageshack.us)
...così la differenza con un 8350 a default é abbastanza limitata e con i giochi che nn sfruttano più di 4 core é ancora meno (anche nel caso i core spenti nn si riattivassero).

;) ciauz

[feldvonmanstein]

Il phenom ormai ha dato, le scorte stanno finendo(il phenom ii x6 ormai è estinto) e per il 4 poco ci manca...
Poca spesa e molta resa è l'athlon ii x4 750k, 65 euro lo si porta su a 4.6 ghz con poco e a questa frequenza è un fx 4300/i3 2100/a10 6800k.

sto discorso lo facevo per chi ha già un phenom II e vuole sapere se upgradando ha migliorie consistenti nei giochi, la risposta è che se si gioca in full hd è meglio puntare sulla vga e tenersi stretto il procio.

[Il nabbo di turno]

sto discorso lo facevo per chi ha già un phenom II e vuole sapere se upgradando ha migliorie consistenti nei giochi, la risposta è che se si gioca in full hd è meglio puntare sulla vga e tenersi stretto il procio.
Sono d'accordo.

[Randa71]

sicuramente sarà utilizzato in ambiti specifici, leggevo anche della possibilità di utilizzo general purpose.
Dalle slide parlavano di algoritmi di ordinamento e ricerca via gpu, il problema che vanno riscritti gli algoritmi (non utilizzerebbe il quick sort, o quel che sia degli ordinamenti per confronto, ma ad es: il radix sort basato su operazioni aritmetiche ed una quantità di confronti irrisoria)

insomma anche se il programma utente non passa per né il S.O. né per i driver e può parlare con la igp, deve comunque caricare un job, preparando un data set ed "attivandolo" tramite un record di 64 byte: tutt'altro che trasparente... (questo sempre che il compilatore prepari in automatico un kernel per la igp)

come dici tu ci sono diversi anni d'avanti vedremo come andrà a finire

Imho se non rendono più vicino all'x86 la cosa (con un decoder x86->huma, hardware o software), resterà per lungo tempo un utilizzo di nicchia.

d'accordissimo con te....se alla fine le istruzioni non vengono eseguite direttamente in hw ma cmq devono sempre passare attraverso uno strato software intermedio per darle in pasto alle unità delle gpu, significa che o riscrivi tutto o ti attacchi.....diverso sarebbe stato se la cosa avvenisse all'interno direttamente nella cpu tramite decoder da passare in pasto alle unità vettoriali....
quindi:
1) fpu rimarrà sempre quella che di fatto eseguirà il codice fp x86;
2) hsa potrà essere sfruttate solo in certi ambiti;
3) ci sarà sempre uno strato sw in mezzo che alla fine penalizzerà le perf;
4) non ci saranno benefici con le app di adesso;
5) se la la fpu è debole continuerà ad essere debole non potendo sfruttare le unità della gpu;
6) fpu cmq non sarà sostituita dalla gpu...

in soldoni non mi sembra nulla di eccezionale questo hsa...ma d'altronde forse non potevano fare altrimenti...se vuoi eseguire nativamente istruzioni devo costruire circuiteria apposita che esegua nativamente quel codice.....ed evidentemente la compatibilità binaria tra le fp x86 e le unità delle gpu è pura fantascienza....
la cosa che mi piace poco è che anche quando si scrivi codice opencl non è che scrivi codice lo compili e fine delle trasmissioni: perché cmq poi si attacca sempre al driver come le schede normali...cioè penso che senza installare il driver non funziona un piffero....diverso sarebbe stato se ad esempio con hsa avessero creato 50 nuove istruzioni (la sto sparando) le quali una volta adattato il compilatore vengono eseguite direttamente..così mi sembra un po' un accrocchio
alla fine tutto risiede sullo stesso die ma sono pere con patate...unico vantaggio vero è che non hai il bus pci di mezzo....
secondo me Intel non è ancora intervenuta seriamente in questo mercato perché non gliene può fregare di meno: fanno già CPU che sono dei missili...quindi

[davideb97]

Ciao a tutti vorrei prendere un Amd fx8320 abbinandolo ad una gtx760. Ora mi chiedo, ma il rumore che fa questo processore, o anzi il suo dissipatore stock, è così elevato? Sapete dirmi dove viene misurato in Db? Perchè quei 30€ di dissipatore after adesso non li posso spendere e non voglio avere un jet nel case lol

[paolo.oliva2]

d'accordissimo con te....se alla fine le istruzioni non vengono eseguite direttamente in hw ma cmq devono sempre passare attraverso uno strato software intermedio per darle in pasto alle unità delle gpu, significa che o riscrivi tutto o ti attacchi.....diverso sarebbe stato se la cosa avvenisse all'interno direttamente nella cpu tramite decoder da passare in pasto alle unità vettoriali....
quindi:
1) fpu rimarrà sempre quella che di fatto eseguirà il codice fp x86;
2) hsa potrà essere sfruttate solo in certi ambiti;
3) ci sarà sempre uno strato sw in mezzo che alla fine penalizzerà le perf;
4) non ci saranno benefici con le app di adesso;
5) se la la fpu è debole continuerà ad essere debole non potendo sfruttare le unità della gpu;
6) fpu cmq non sarà sostituita dalla gpu...

in soldoni non mi sembra nulla di eccezionale questo hsa...ma d'altronde forse non potevano fare altrimenti...se vuoi eseguire nativamente istruzioni devo costruire circuiteria apposita che esegua nativamente quel codice.....ed evidentemente la compatibilità binaria tra le fp x86 e le unità delle gpu è pura fantascienza....

Ti volevo chiedere una cosa... ma cerca di spiegarti bene perchè io il software non lo digerisco e chiedo scusa se razionalizzo (magari sbagliando) per esporre meglio quello che penso teorizzando su quello che hai scritto.

Partendo dal fatto che hai scritto "la compatibilità binaria tra le FX X86 e unità logiche gpu", cosa intendi?
Quello che vorrei dire... ad esempio un Phenom II non può eseguire nativamente istruzioni AVX, però le può eseguire in emulazione.
Una IGP (non so una mazza delle IGP e magari sparo stronzate), ha un set di istruzioni proprie dedicate esclusivamente al lavoro che deve svolgere... quindi ad esempio una istruzione X86 non la può eseguire semplicemente perchè non la riconosce.
SE al suo interno venissero implementati i vari set di istruzioni X86 FP, non sarebbe in grado di risolverli perchè è strutturata in modo completamente differente? Al limite si potrebbe realizzare un CMT unendo una FP X86 e una IGP?
Ti chiedo questo perchè noi ragioniamo sempre con l'hardware di oggi, cioè guardiamo una FP X86 e la giudichiamo completamente diversa da una IGP e, giustamente, diciamo che una non può fare il lavoro dell'altra... ma era ad esempio la stessa cosa quando un procio era unicamente INT ed il coprocessore matematico era esterno al procio, poi è diventato tutt'uno, non lo potrebbe essere anche per una FP X86/IGP in futuro?
Perchè se così fosse, come un procio odierno riesce ad eseguire istruzioni a lunghezza bit variabile smistando operazioni INT e FP alle parti dedicate, potrebbe essere in futuro INT, FP e IGP, dove quelle FP, se risolvibili dall'IGP, verrebbero date all'IGP.
Un altro punto... in emulazione. Un Itanium, un'Amiga, un Atari, possono risolvere istruzioni X86 semplicemente emulandole, con una perdita enorme di potenza elaborativa, però è possibile. La perdita di potenza però bisognerebbe inquadrarla, perchè ad esempio il mio Atari ST1024 con 68000 8MHz poteva emulare il dos con performances da 8086, chiaro, ma dobbiamo anche partire dal punto che una IGP ha un potere elaborativo di gran lunga superiore a qualsiasi procio, quindi anche se perdesse un 70% della sua potenza, risulterebbe sempre e comunque più veloce.
Cioè, quello che alla fine vorrei dire, o unendo una FP X86 e IGP oppure facendo in modo che l'IGP emuli una FP X86, la cosa diventerebbe trasparente per chi realizza il software, ed anche se scritto in assembler, basterebbe una tabella di conversione puntatori (tipo come aveva fatto Commodore dal C64 al Plus 4, dove cambiava la ROM ed i vari indirizzi ma comunque poteva girare lo stesso software scritto sia per C64 che per plus 4 (ma non viceversa) semplicemente perchè quando veniva assegnato un determinato indirizzo valido sul C64 ma non sul Plus 4, veniva "convertito".
AMD è l'unica ditta che unisce sapere ed esperienza proci X86 e sapere ed esperienza VGA tramite l'acquisizione di ATI, quindi sarebbe l'unica a poter realizzare (sempre se possibile) un CMT tra una FP X86 ed una IGP... non sottovaluterei questo aspetto... anche perchè, alla fine, senza uno scopo futuro, un APU non sarebbe altro che un procio con una VGA sullo stesso die... e se guardiamo la cosa dal punto di vista commerciale, avrebbe l'unico scopo di rendere una mobo più piccola, ma onestamente non vedo un gran senso di sviluppo per spenderci i soldi... anzi, nel caso AMD che vende le VGA discrete, tutto l'opposto, magari con Intel sarebbe diverso... Alla fine avrebbe comunque un senso solo per telefonini/tablet ed ultrasottili, ma di certo desktop fascia medio-alta e server non avrebbe alcun senso.... a fantasticare sarebbe più utile un 200GB di memoria così si farebbe a meno degli HD esterni e con un tot in più di velocità... magari accorpando più layer sopra al die dentro il package...

[digieffe]

d'accordissimo con te....se alla fine le istruzioni non vengono eseguite direttamente in hw ma cmq devono sempre passare attraverso uno strato software intermedio per darle in pasto alle unità delle gpu, significa che o riscrivi tutto o ti attacchi.....diverso sarebbe stato se la cosa avvenisse all'interno direttamente nella cpu tramite decoder da passare in pasto alle unità vettoriali....
quindi:
1) fpu rimarrà sempre quella che di fatto eseguirà il codice fp x86;
2) hsa potrà essere sfruttate solo in certi ambiti;
3) ci sarà sempre uno strato sw in mezzo che alla fine penalizzerà le perf;
4) non ci saranno benefici con le app di adesso;
5) se la la fpu è debole continuerà ad essere debole non potendo sfruttare le unità della gpu;
6) fpu cmq non sarà sostituita dalla gpu...

in soldoni non mi sembra nulla di eccezionale questo hsa...ma d'altronde forse non potevano fare altrimenti...se vuoi eseguire nativamente istruzioni devo costruire circuiteria apposita che esegua nativamente quel codice.....ed evidentemente la compatibilità binaria tra le fp x86 e le unità delle gpu è pura fantascienza....
ti rispondo in base alle slide :) :
- o riscrivi tutto o ti attacchi: in alcune condizioni i compilatori (futuri) saranno in grado di generare codice misto x86+huma, ma solo per quei tipi di algoritmi che non richiedano cambiamento della logica.
1 - si
2 - ? : oltre che utilizzarlo come unità simd separata, si possono fare anche ricerche ed ordinamenti, ma con algoritmi diversi da quelli utilizzati normalmente per le cpu, implica riscrittura del codice.
3 - ? : lo strato software è al limite dell'inesistente, per es: l'applicazione carica in ram (unificata) i dati dal disco, carica un kernel (igp) di esecuzione, carica in una locazione un job descriptor di 64 byte, lancia un irq (mi sembra), fa qualcos'altro mentre attende che siano pronti i risultati. Tutto sommato credo che gli impatti siano marginali.
4 - si, forse neanche per quelle tra 3 anni, a meno che non riescano, come scrivono loro, a ricompilare sorgenti già esistenti senza modifiche: imho però con vantaggi ridotti rispetto scrivere appositi algoritmi.
5 - si
6 - ad oggi sembra che stiano così le cose, non so se con excavator o successivi cambi qualcosa.
7 - Pur divenendo compatibile nativamente con opencl 2.0, java8 e c++11 i due maggiori concorrenti Nvidia ed Intel vanno per la loro strada.

come unità di calcolo aggiuntiva forse non si poteva fare di meglio.
Per quanto riguarda l'esecuzione di istruzioni simd x86 (sse, avx, ecc solo quelle supportate dalle CU), i decoders avrebbero potuto generare delle mops dirette alle CU (compute units) che con un kernel standard in firmware avrebbero eseguito lasciando il risultato nei registri.
Queste ultime sono solo mie speculazioni, io non sono né un "elettronico" né tantomeno conosco i dettagli del progetto.

[Randa71]

ti rispondo in base alle slide :) :
- o riscrivi tutto o ti attacchi: in alcune condizioni i compilatori (futuri) saranno in grado di generare codice misto x86+huma, ma solo per quei tipi di algoritmi che non richiedano cambiamento della logica.
1 - si
2 - ? : oltre che utilizzarlo come unità simd separata, si possono fare anche ricerche ed ordinamenti, ma con algoritmi diversi da quelli utilizzati normalmente per le cpu, implica riscrittura del codice.
3 - ? : lo strato software è al limite dell'inesistente, per es: l'applicazione carica in ram (unificata) i dati dal disco, carica un kernel (igp) di esecuzione, carica in una locazione un job descriptor di 64 byte, lancia un irq (mi sembra), fa qualcos'altro mentre attende che siano pronti i risultati. Tutto sommato credo che gli impatti siano marginali.
4 - si, forse neanche per quelle tra 3 anni, a meno che non riescano, come scrivono loro, a ricompilare sorgenti già esistenti senza modifiche: imho però con vantaggi ridotti rispetto scrivere appositi algoritmi.
5 - si
6 - ad oggi sembra che stiano così le cose, non so se con excavator o successivi cambi qualcosa.
7 - Pur divenendo compatibile nativamente con opencl 2.0, java8 e c++11 i due maggiori concorrenti Nvidia ed Intel vanno per la loro strada.

come unità di calcolo aggiuntiva forse non si poteva fare di meglio.
Per quanto riguarda l'esecuzione di istruzioni simd x86 (sse, avx, ecc solo quelle supportate dalle CU), i decoders avrebbero potuto generare delle mops dirette alle CU (compute units) che con un kernel standard in firmware avrebbero eseguito lasciando il risultato nei registri.
Queste ultime sono solo mie speculazioni, io non sono né un "elettronico" né tantomeno conosco i dettagli del progetto.

grazie....andrò a farmi un giro anche io :)

[digieffe]

Provo a rispondere FRETTOLOSAMENTE ad alcune delle domande (senza togliere nulla a Randa :))

Partendo dal fatto che hai scritto "la compatibilità binaria tra le FX (Fp) X86 e unità logiche gpu", cosa intendi?quando in ram c'è un programma scritto in Fp x86 (numeri in virgola mobile (anche sse, avx)) questo non è direttamente eseguibile dalla gpu, perchè non lo comprenderebbe, hanno istruzioni diverse.

Quello che vorrei dire... ad esempio un Phenom II non può eseguire nativamente istruzioni AVX, però le può eseguire in emulazione.significa che per ogni istruzione AVX c'è un intero (sotto)programma che con istruzioni native te ne emula la funzione sul Phemon II.

Una IGP (non so una mazza delle IGP e magari sparo stronzate), ha un set di istruzioni proprie dedicate esclusivamente al lavoro che deve svolgere... quindi ad esempio una istruzione X86 non la può eseguire semplicemente perchè non la riconosce.
esatto huma ha ~136 istruzioni che può eseguire diverse da x86.

SE al suo interno venissero implementati i vari set di istruzioni X86 FP, non sarebbe in grado di risolverli perchè è strutturata in modo completamente differente?non è detto potrebbe eseguirne la maggior parte (ho verificato che le CU eseguono interi a 32 e 64 bit, Fp a 16, 32 e 64 bit anche con FMA) quasi sicuramente non potrebbe eseguire tutte le istruzioni, ma molte matematiche si ed anche alcune logiche.

Al limite si potrebbe realizzare un CMT unendo una FP X86 e una IGP?imho lasciare la parte della Fp X86 con le funzioni che non ci sono nella CU (es BMI bit manipulation) e per il resto affidarsi alla CU.

Ti chiedo questo perchè noi ragioniamo sempre con l'hardware di oggi, cioè guardiamo una FP X86 e la giudichiamo completamente diversa da una IGP e, giustamente, diciamo che una non può fare il lavoro dell'altra...imho una Fp X86 moderna con avx ecc, non è molto differente da una CU, le funzioni principali sono sovrapponibili.

ma era ad esempio la stessa cosa quando un procio era unicamente INT ed il coprocessore matematico era esterno al procio, poi è diventato tutt'uno, non lo potrebbe essere anche per una FP X86/IGP in futuro?quel funzionamento era un po' più semplice e diretto 386 + 387. L'integrazione era ciò che mi auguravo nelle ultime righe del mio post.

Perchè se così fosse, come un procio odierno riesce ad eseguire istruzioni a lunghezza bit variabile smistando operazioni INT e FP alle parti dedicate, potrebbe essere in futuro INT, FP e IGP, dove quelle FP, se risolvibili dall'IGP, verrebbero date all'IGP.la suddivisione potrebbe essere diversa: tutto ciò che fa la igp (sia int che Fp) alla stessa, il resto alle solite unità.

Un altro punto... in emulazione. Un Itanium, un'Amiga, un Atari, possono risolvere istruzioni X86 semplicemente emulandole, con una perdita enorme di potenza elaborativa, però è possibile. La perdita di potenza però bisognerebbe inquadrarla, perchè ad esempio il mio Atari ST1024 con 68000 8MHz poteva emulare il dos con performances da 8086, chiaro, ma dobbiamo anche partire dal punto che una IGP ha un potere elaborativo di gran lunga superiore a qualsiasi procio, quindi anche se perdesse un 70% della sua potenza, risulterebbe sempre e comunque più veloce.praticamente penseresti di mettere un kernel nella igp che permetta di emulare la Fp. In linea teorica va bene, in linea pratica non è proprio così, perché le latenze (introdotte dalla emulazione) sono alte ed allora se hai da elaborare pochi dati, la cpu resta in attesa della igp, se invece hai una montagna di dati CONSECUTIVI da elaborare senza nessuna istruzione che ti vincoli l'ordine (es un salto) allora potrebbe funzionare. Quanti sono questi casi?

Cioè, quello che alla fine vorrei dire, o unendo una FP X86 e IGP oppure facendo in modo che l'IGP emuli una FP X86, la cosa diventerebbe trasparente per chi realizza il software, ed anche se scritto in assembler, basterebbe una tabella di conversione puntatori (tipo come aveva fatto Commodore dal C64 al Plus 4, dove cambiava la ROM ed i vari indirizzi ma comunque poteva girare lo stesso software scritto sia per C64 che per plus 4 (ma non viceversa) semplicemente perchè quando veniva assegnato un determinato indirizzo valido sul C64 ma non sul Plus 4, veniva "convertito".non servirebbe neanche la conversione dei puntatori, huma, a partire da steamroller, ha unificato i puntatori x86 con quelli igp.
Diventerebbe trasparente ma per le prestazioni vedi punto precedente.
l'unico modo per non penalizzare e rendere trasparente sono decoder hardware (quelli del raddoppio in steamroller) o predecoder software che convertono (per quanto possibile) il file .exe prima che venga eseguito.

AMD è l'unica ditta che unisce sapere ed esperienza proci X86 e sapere ed esperienza VGA tramite l'acquisizione di ATI, quindi sarebbe l'unica a poter realizzare (sempre se possibile) un CMT tra una FP X86 ed una IGP... non sottovaluterei questo aspetto... anche perchè, alla fine, senza uno scopo futuro, un APU non sarebbe altro che un procio con una VGA sullo stesso die...era ciò che sparavamo un po' tutti, allo stadio di sviluppo di steamroller sono una CPU+VGA ottimamente integrate e basta, purtroppo.

[Randa71]

Ti volevo chiedere una cosa... ma cerca di spiegarti bene perchè io il software non lo digerisco e chiedo scusa se razionalizzo (magari sbagliando) per esporre meglio quello che penso teorizzando su quello che hai scritto.

Partendo dal fatto che hai scritto "la compatibilità binaria tra le FX X86 e unità logiche gpu", cosa intendi?
Quello che vorrei dire... ad esempio un Phenom II non può eseguire nativamente istruzioni AVX, però le può eseguire in emulazione.
NON PENSO CHE UN PHENOM 2 POSSA ESEGUIRE LE AVX IN EMULAZIONE...IMMAGINO IL PROGRAMMA TESTERA' I FLAG DELLA CPU E SE GLI RITORNA CHE NON HA LE AVX ESEGUIRA' IL CODICE CONE LE SSE DISPONIBILI.
Una IGP (non so una mazza delle IGP e magari sparo stronzate), ha un set di istruzioni proprie dedicate esclusivamente al lavoro che deve svolgere... quindi ad esempio una istruzione X86 non la può eseguire semplicemente perchè non la riconosce.
ESATTO
SE al suo interno venissero implementati i vari set di istruzioni X86 FP, non sarebbe in grado di risolverli perchè è strutturata in modo completamente differente? DICIAMO DI SI
Al limite si potrebbe realizzare un CMT unendo una FP X86 e una IGP? SI POTREBBE MA RIMARREBBE SEMPRE IL PROBLEMA DELL'ESECUZIONE.
Ti chiedo questo perchè noi ragioniamo sempre con l'hardware di oggi, cioè guardiamo una FP X86 e la giudichiamo completamente diversa da una IGP e, giustamente, diciamo che una non può fare il lavoro dell'altra... ma era ad esempio la stessa cosa quando un procio era unicamente INT ed il coprocessore matematico era esterno al procio, poi è diventato tutt'uno, non lo potrebbe essere anche per una FP X86/IGP in futuro?
NO NON E' LA STESSA COSA XCHE' LA DIFFERENZA FONDAMENTALE E' CHE QUANDO E' STATO CREATO X87 HANNO CREATO CMQ UN SET DI ISTRUZIONI STANDARD, PASSAMI IL TERMINE...DI FATTO LE X87 ERANO DELLE ESTENSIONI DELLE ISTRUZIONI X86 PER FP....CON LE GPU DI FATTO NON E' STATO CREATO UNO STANDARD..MA OGNUNO FA QUEL CHE VUOLE (NVIDIA-AMD)...PERCHE' HW E' ESTREMAMENTE DIVERSO TRA I COMPETITOR.....POTRA' ESSERE UN TUTT'UNO FISICAMENTE MA FP E IGP LOGICAMENTE AVRANNO FUNZIONI DISTINTE PERCHE' UNA NON PUO' ESEGUIRE IL CODICE DELL'ALTRA ALMENO AD OGGI

Perchè se così fosse, come un procio odierno riesce ad eseguire istruzioni a lunghezza bit variabile smistando operazioni INT e FP alle parti dedicate, potrebbe essere in futuro INT, FP e IGP, dove quelle FP, se risolvibili dall'IGP, verrebbero date all'IGP. POTREBBE MA AD OGGI DA QUELLO CHE HO CAPITO NON E' COSI.


Un altro punto... in emulazione. Un Itanium, un'Amiga, un Atari, possono risolvere istruzioni X86 semplicemente emulandole, con una perdita enorme di potenza elaborativa, però è possibile. La perdita di potenza però bisognerebbe inquadrarla, perchè ad esempio il mio Atari ST1024 con 68000 8MHz poteva emulare il dos con performances da 8086, chiaro, ma dobbiamo anche partire dal punto che una IGP ha un potere elaborativo di gran lunga superiore a qualsiasi procio, quindi anche se perdesse un 70% della sua potenza, risulterebbe sempre e comunque più veloce.
Cioè, quello che alla fine vorrei dire, o unendo una FP X86 e IGP oppure facendo in modo che l'IGP emuli una FP X86, la cosa diventerebbe trasparente per chi realizza il software, ed anche se scritto in assembler, basterebbe una tabella di conversione puntatori (tipo come aveva fatto Commodore dal C64 al Plus 4, dove cambiava la ROM ed i vari indirizzi ma comunque poteva girare lo stesso software scritto sia per C64 che per plus 4 (ma non viceversa) semplicemente perchè quando veniva assegnato un determinato indirizzo valido sul C64 ma non sul Plus 4, veniva "convertito".
AMD è l'unica ditta che unisce sapere ed esperienza proci X86 e sapere ed esperienza VGA tramite l'acquisizione di ATI, quindi sarebbe l'unica a poter realizzare (sempre se possibile) un CMT tra una FP X86 ed una IGP... non sottovaluterei questo aspetto
DICIAMO CHE UN CONTO E' FARE UN MODULO CON INT,FP E IGP (COSA PENSO POSSIBILISSIMA) UN CONTO E' FARLI INTERAGIRE TRA LORO.

SUL DISCORSO ASSEMBLY UN CONTO E' CONVERTIRE I PUNTATORI ALLA MEMORIA UN CONTO E' MANDARE UN CODICE OPERATIVO DIFFERENTE ALLA CPU (FPU - IGP)...QUANDO NELLA CPU ARRIVA UNA SEQUENZA BINARIA (UN'ISTRUZIONE) QUESTA ATTIVA DETERMINATI CIRCUITI PIUTTOSTO CHE ALTRI (VECCHI RICORDI SULL'ALU DELLO ZILOG Z80) ...MA SE IL CODICE OPERATIVO NON RISPETTA LA CIRCUITERIA INTERNA TI ATTACCHI....
http://it.wikipedia.org/wiki/MOS_7501
DI FATTO LA CPU DEL C64 E QUELLA DEL PLUS 4 ERANO COMPATBILI A LIVELLO DI MICROCODICE...MENTRE LA FPU CON IGP NO.

E QUI MI AGGANCIO AL DISCORSO EMULAZIONE...SE TI STAI INVENTANDO EX NOVO UN QUALCOSA (HSA) L'APPROCCIO EMULAZIONE NON MI SEMBRA IL MASSIMO...I SERVER ITANIUM CHE ABBIAMO IN SALA MACCHINE HANNO HP-UX COME S.O. E IMMAGINO CHE HP UX NON GIRI IN EMULAZIONE X86, MA SIA NATIVO IA-64 (CMQ MI RISERVO DI VERIFICARLO DOMANI)....NON SOTTOVALUTO L'ESPERIENZA DI AMD NELLE CPU E GPU MA DI FATTO SONO DUE COSE MOLTO DIVERSE...E LE SINERGIE TRA LE DUE MI SEMBRANO POCO MATURE



ho scritto le mie risp in neretto.e maiuscolo (ma non per urlare solo per una maggiore leggibilità)..vado a nanna e spero di non aver scritto troppe stupidate vista l'ora :) nel caso approfondiamo e continuiamo domani

[epimerasi]

se per quello mancano pure IBM e nVidia... il primo vero prodotto HSA arrivera quando ? almeno nel 2016 se non piu tardi, per quella data vedremo cosa effettivamente faranno gli altri player.

E perche` dovrebbe contribuire nVidia? Per farsi concorrenza in un mercato in cui per ora ha il monopolio?


piu che il quando, vorrei capire quali programmi verranno adattati... non mi pare di vedere molti programmi consumer che usano OpenCL, è gia difficile trovare quelli professionali.

Che intendi per programmi consumer?

E poi e` un argomento circolare, se fosse cosi` pratico usare OpenCL/CUDA allora non ci sarebbe stato bisogno di HSA.

[epimerasi]

hUMA verra sfruttato da qui programmi che gia oggi usano la GPU, se un software non usa la GPU che ci sia hUMA o meno non cambia.

i giochi presumo che qualche fps guadagneranno, riusciranno meglio a saturare la GPU, ma come software OpenCL non vedo molto; vedremo nei prossimi anni.

Non e` cosi`.
Forse non ti e` ben chiaro come funziona.

Ecco un esempio

http://www.computer.org/portal/web/computingnow/software%20engineering/content?g=53319&type=article&urlTitle=hsail%3A-write-once-run-everywhere-for-heterogeneous-systems

http://www.extremetech.com/gaming/164817-setting-hsail-amd-cpu-gpu-cooperation

[paolo.oliva2]

Grazie ad entrambi per le spiegazioni (Digieffe e Randa71).
Mi sembra che la cosa sia molto complessa e la fattibilità o meno non sia tanto nel realizzare il funzionamento, quanto nei vantaggi che possano coinvolgere più o meno fette di mercato... più sarebbero i vantaggi, più sviluppatori, hardware e clienti entrerebbero, più movimento di soldi, più investimenti.

C'è una cosa però che mi fa riflettere... ma non la dico per farla grossa ma unicamente per evidenziarla: l'architettura BD si può giudicare più o meno valida, ma Zambesi, a tutti gli effetti, ha evidenziato i limiti di AMD, cioè quello di avere una indubbia creatività, ma una "forza" di fondo "piccola" per ottimizzare il progetto... principalmente si può sintetizzare in pochi money.
Per quanto avete spiegato, può AMD che ha trovato immensi problemi solamente nella condivisione nel modulo (quindi tutto X86), ipotizzare una condivisione tra X86 e IGP, ben più difficile? Sarebbe un disastro... e sulla base Zambesi per quanto abbia speso e per quanto incassato, non dovrebbe/potrebbe manco avere i fondi per realizzare Steamroller, ed invece galoppa nell'evoluzione BD come se avesse le casse stracolme.
Leghiamo pure un'altra considerazione... quando IBM disse no ad una miniaturizzazione successiva al 32nm SOI, sembrava che tutto il consorzio SOI si fosse come fermato... ed anche AMD fermò l'evoluzione Zambesi, in quanto le roadmap al dopo Zambesi assegnavano Steamroller... Piledriver è nato con lo scopo di spendere il meno possibile per ottimizzare Zambesi, e questo è perfettamente in linea con la situazione AMD del dopo lancio Zambesi, con l'aggravante che addirittura sembrava che non ci fosse più un successore SOI al 32nm.
Poi tutto ad un tratto, da un mercato che sembrava indifferente alla situazione AMD, di colpo è cambiato tutto, i fondi per le APU sembrano illimitati, riesce a concludere contratti (console giochi) che di solito in passato sarebbero stati impossibili per 1000 ostruzionismi, galoppa con l'evoluzione architetturale di BD (Steamroller/Exavator), e il settore Server, per quanto in molti dicano che AMD intenda lasciare, ha invece proposto 2 modelli alternativi per server con tipologie diverse... insomma, a me viene da ipotizzare che in questo non ci possa essere AMD da sola, ma qualcuno che ha visto che ci potrebbe essere un ritorno tangibile, e quel qualcuno non ha il minimo interesse per gli APU tablet/trasportabili o mini-desktop, ma per aumentare le prestazioni massime di un procio... e a me quel qualcuno, che possa condizionare lo sviluppo del silicio, che possa aiutare con money AMD, che possa aprire le strade per la realizzazione di software specifici e pure di indirizzare le richieste del mercato in una certa direzione, avrebbe un nome specifico... IBM.

P.S. Edit.
Aggiungo che non vorrei legare questo discorso specificatamente ad AMD, ma alla situazione che si creerebbe. L'impossibile di oggi è il fattibile di domani e il realizzabile del domani-l'altro. Ogni cosa oggi è legata al costo rispetto al guadagno, e una innovazione a chi pesterebbe i piedi levando i guadagni di oggi. Ad esempio, la dipendenza al petrolio c'è perchè conviene a molti, a troppi... altrimenti tutto sarebbe già cambiato da tempo. Leggendo i post sopra, si parla di ditte che non hanno interessi in comune, ma che comunque avrebbero interessi a proporre qualcosa di nuovo che sia alternativo in primis, se poi migliore, meglio ancora.
Non parleremmo di una nuova architettura X86, perchè per quanto possa fare scalpore, i guadagni sarebbero pur sempre minimi, ma di un qualcosa che se portata al massimo sfruttamento equivarrebbe alla differenza tra un floppy-disk ed un hard-disk, con ritorni commerciali fantascientifici... ma per realizzare il tutto ci vorrebbero molti money ed un supporto commerciale forte per imporre il prodotto ed un supporto software che sfrutti immediatamente tutti i vantaggi.
Ad esempio... un 8350 può avere prestazioni nei giochi diverse a seconda di come è impostato il motore del gioco, ma è pur sempre un motore che deve andare su 2 marche di proci, quindi deve rendere in entrambi e non sarà mai una esclusiva per uno. Nelle console-game avremo una prova, a breve, di quanto può incidere la realizzazione di un gioco pensato esclusivamente per un'architettura di un procio e quindi di sfruttarne tutte le peculiarità. Il problema X86 di oggi è la retro-compatibilità e con la miriade di ditte che hanno interessi, ha l'effetto opposto, cioè più che avere investimenti maggiori e crescite esponenziali, tutto si ferma al guadagno odierno e un rallentamento penoso all'evoluzione.

[carlottoIIx6]

hmmm secondo me il processo di huma sarà veloce per un motivo, il mobile ne ha bisogno.
arm si muove nella stessa direzione.
non può che essereci una convergenaa ed uno sposalizio.

[carlottoIIx6]

come volevasi dimostrare. :D
http://www.tomshw.it/cont/news/hsa-abbatte-le-barriere-tra-cpu-e-gpu-futuro-eterogeneo/48717/1.html

hanno postato la stessa immagine che avevo postato io, o ci leggono o ha una sua logica che ho intuito.
inoltre l'accelerazione serve per tante cose
http://www.tomshw.it/cont/news/motion-capture-accelerato-dalle-apu-amd-punta-su-mixamo/48703/1.html

[paolo.oliva2]

Edit doppio post, un evidente bug tra il CMT "modifica" e "rispondi"... :D

[paolo.oliva2]

hmmm secondo me il processo di huma sarà veloce per un motivo, il mobile ne ha bisogno.
arm si muove nella stessa direzione.
non può che essereci una convergenaa ed uno sposalizio.
Corcordo, ma ci sono priorità differenti... che al momento non precludono nè escludono finalità future.
A parte sigle che mi confondono, un APU può essere visto in miriadi di aspetti, come può essere nel settore telefonia un notevole passo avanti in consumi e costi del prodotto finito inferiori, nel mobile idem con un obiettivo di una IGP nel procio equivalente in potenza ad una discreta integrata nella mobo, nel desktop ad un abbassamento dei costi globali del sistema a chi non cerca le prestazioni grafiche di un certo livello ma usa il PC per altri scopi... e sino a qui si può dire che addirittura un APU odierno sia già arrivato al traguardo... però ci sono cose un attimo differenti nella logica in cui lavora un APU desktop.
Facendo un esempio, un APU potrebbe anche essere realizzato in modo molto più semplice (se l'effettivo traguardo fosse una semplificazione costruttiva della mobo ed una riduzione dei costi), cioè avere nel die la parte X86 "classica" e poi una replica semplificata e rimpicciolita dei collegamenti PCI che ha una mobo, con inglobato l'NB, e poi da un'altra parte del die l'IGP ipotizzabile addirittura con un suo MC e tanto di DDR5 o qualsivoglia.
Invece vediamo un inglobamento del tutto... e per quanto ne possa capire poco, mi sembra evidente che complicare tutto avrebbe poco senso per come è concepito un APU ora.
Ad esempio la condivisione degli indirizzi... il fine non mi sembra quello di accelerare l'IGP, perchè basterebbe che l'IGP abbia un suo MC e sue DDR e l'ostacolo sarebbe al limite il TDP, perchè volendo potrebbe avere qualsiasi potenza. Quindi se da una parte potrebbe essere giudicata come un CMT tra 2 MC e 2 tipi di DDR (massimizzando), il vero scopo finale, per me, è che se si vuole arrivare ad un discorso di integrazione computazionale tra X86 e IGP, è chiaro che i dati non possono essere distinti ma unicamente condivisibili.
Se collegassimo il tutto all'annuncio a suo tempo di Next-generations di AMD, a prescindere dalla discussione sulla validità o meno, è scontato che con obiettivi diversi debba avere requisiti diversi, ed infatti AMD ha una gestione APU con visione sviluppo totalmente differente e molto più a basso livello di quanto stiano facendo altri.

[carlottoIIx6]

Corcordo, ma ci sono priorità differenti... che al momento non precludono nè escludono finalità future.


il problema è che per fare un cambiamento devono essere tutti d'accordo e li ci sono tutti.


A parte sigle che mi confondono, un APU può essere visto in miriadi di aspetti, come può essere nel settore telefonia un notevole passo avanti in consumi e costi del prodotto finito inferiori, nel mobile idem con un obiettivo di una IGP nel procio equivalente in potenza ad una discreta integrata nella mobo, nel desktop ad un abbassamento dei costi globali del sistema a chi non cerca le prestazioni grafiche di un certo livello ma usa il PC per altri scopi... e sino a qui si può dire che addirittura un APU odierno sia già arrivato al traguardo... però ci sono cose un attimo differenti nella logica in cui lavora un APU desktop.


non perdere di vista che il vero problema è la riscrittura dei software.



Facendo un esempio, un APU potrebbe anche essere realizzato in modo molto più semplice (se l'effettivo traguardo fosse una semplificazione costruttiva della mobo ed una riduzione dei costi), cioè avere nel die la parte X86 "classica" e poi una replica semplificata e rimpicciolita dei collegamenti PCI che ha una mobo, con inglobato l'NB, e poi da un'altra parte del die l'IGP ipotizzabile addirittura con un suo MC e tanto di DDR5 o qualsivoglia.
Invece vediamo un inglobamento del tutto... e per quanto ne possa capire poco, mi sembra evidente che complicare tutto avrebbe poco senso per come è concepito un APU ora.

non si complica per complicare, ma per semplificare.

Ad esempio la condivisione degli indirizzi... il fine non mi sembra quello di accelerare l'IGP, perchè basterebbe che l'IGP abbia un suo MC e sue DDR e l'ostacolo sarebbe al limite il TDP, perchè volendo potrebbe avere qualsiasi potenza. Quindi se da una parte potrebbe essere giudicata come un CMT tra 2 MC e 2 tipi di DDR (massimizzando), il vero scopo finale, per me, è che se si vuole arrivare ad un discorso di integrazione computazionale tra X86 e IGP, è chiaro che i dati non possono essere distinti ma unicamente condivisibili.
lo scopo è che 1+1>2, che sommando le cose si ottenga una velocità maggiore. questo è possibile perche le due cose non hanno mai lavorato assieme su una cosa, ma sempre su cose diverse.

[digieffe]

secondo me il processo di huma sarà veloce per un motivo, il mobile ne ha bisogno. arm si muove nella stessa direzione.l'idea è buona ma ancora in stato embrionale, forse i primi risultati si vedranno nel 2016 ed è da capire se riusciranno, falliranno, verrà accettato da tutti.
Non capisco questa necessità particolare del mobile, se me la spieghi ti ringrazio.

il problema è che per fare un cambiamento devono essere tutti d'accordo e li ci sono tutti.a me sembra che manchino i due colossi reali concorrenti: Nvidia e Intel.

non perdere di vista che il vero problema è la riscrittura dei software.se nel 2016 sarà pronta la piattaforma il software sarà pronto nel 2020.

non si complica per complicare, ma per semplificare.
lo scopo è che 1+1>2, che sommando le cose si ottenga una velocità maggiore. questo è possibile perche le due cose non hanno mai lavorato assieme su una cosa, ma sempre su cose diverse.io direi 1+1 <= 2, in questo caso il concetto di sinergia non lo vedo proprio.

[carlottoIIx6]

l'idea è buona ma ancora in stato embrionale, forse i primi risultati si vedranno nel 2016 ed è da capire se riusciranno, falliranno, verrà accettato da tutti.
Non capisco questa necessità particolare del mobile, se me la spieghi ti ringrazio.


semplice, il mobile non può contare su una potenza grossa per via dei watt, ma ha cpu e gpu che regogno open cl e open gl.
mi sembra evidente, se il mobile vuole far girare applicati che richiedono grossa potenza di calcolo ha bisogno di sfruttare l'hardware la massimo.
ce la tendezza di fare del mobile i pc dif ascia medio bassa attuale.


a me sembra che manchino i due colossi reali concorrenti: Nvidia e Intel.

arm, Samsung, Lg, Qualcomm, sony ... fanno impallidire intel a mio avviso.
senza contare che la cosa include apple e google



se nel 2016 sarà pronta la piattaforma il software sarà pronto nel 2020.

io direi 1+1 <= 2, in questo caso il concetto di sinergia non lo vedo proprio.
eh?
forse tu al vedi come potenza uno più potenza uno minore ugulae potenza due?

in realtà una cpu fa cose gpu lentamente e vieversa. quindi usanto entrambe al massimo si ha una velocetà possible maggiore delle due sommate.

[paolo.oliva2]

APU e mobile, però, al momento si sposano bene solo per il fatto della diminuzione dei consumi e nella semplificazione delle mobo con tanto di ritorno nelle dimensioni e pesi, nel momento in cui un APU aumenterebbe la potenza del procio, lo sfionderebbero immediatamente nei server e proci desktop fascia alta.

[AceGranger]

Non e` cosi`.
Forse non ti e` ben chiaro come funziona.

Ecco un esempio

http://www.computer.org/portal/web/computingnow/software%20engineering/content?g=53319&type=article&urlTitle=hsail%3A-write-once-run-everywhere-for-heterogeneous-systems

http://www.extremetech.com/gaming/164817-setting-hsail-amd-cpu-gpu-cooperation

hUMA non è HSA... hUMA semplicemente è l'accesso diretto ai dati della CPU da parte della GPU e della GPU ai dai della CPU, ed è la stessa cosa che proporra nVidia con Maxwell.

quindi se il programma sfrutta la GPU bene seno ciccia.

[gi0v3]

ciao a tutti, dopo anni di assenza torno a rompere le scatole :D
e porto un nuovo amico arrivato or ora dalla corea del sud:

https://dl.dropboxusercontent.com/u/6901145/fx8300.jpg

nei prossimi giorni lo provo, mi sa che farò una comparsata anche nel thread dell'overclock :D

[touchy]

quanto lo hai pagato?

[paolo.oliva2]

Questo è interessante: (già postato da CarlottoII) :D
http://www.tomshw.it/cont/news/hsa-abbatte-le-barriere-tra-cpu-e-gpu-futuro-eterogeneo/48717/1.html

Heterogeneous System Architecture, meglio conosciuto come HSA, è un nuovo modo d'intendere i chip e la programmazione. Non più una CPU e una GPU distinte, ma sistemi che collaborano tra loro per svolgere al meglio un'attività. Se un determinato carico di lavoro ha al suo interno alcune istruzioni che girano meglio sulla CPU e altre che possono essere svolte più rapidamente dalla GPU, l'HSA è quell'infrastruttura che permette che il tutto si svolga al meglio, con il massimo dell'efficienza.

L'idea, per facilitare il compito agli sviluppatori, è che si possa scrivere codice in un linguaggio come C++, AMP, OpenCL, Java o Python, per poi compilarlo nel modo giusto così che giri il tutto giri senza badare alla GPU integrata nel sistema. Il vantaggio di HSAIL secondo AMD e i membri della fondazione è che non richiede ai programmatori di imparare nuovi linguaggi.

In pratica, come evidenziato in rosso, non è il programma che decide se utilizzare o meno la GPU, ma una volta ricompilato "nel modo giusto", sarebbe l'HSA che deciderebbe quale parte del sistema è più idonea all'elaborazione del dato.

http://www.tomshw.it/cont/news/motion-capture-accelerato-dalle-apu-amd-punta-su-mixamo/48703/1.html (sempre postato da CarlottoII)

...HSA Foundation ha fatto il punto della situazione, in previsione delle specifiche HSA che saranno completate metà 2014... definire la direzione da prendere e le specifiche dello standard.
Nel campo dei computer tradizionali è AMD la massima esponente dell'HSA, e una generazione di APU dopo l'altra, lo sta facendo vedere. La caratteristica hUMA che vedremo nella futura APU Kaveri è un ottimo esempio.

Quindi se ho ben capito... HSA è un progetto che ottimizza l'elaborazione dei dati di un X programma (X86 + VGA), scritto con qualsiasi linguaggio, con l'unica condizione che sia compilato nel modo corretto.
Quello che non ho capito perfettamente, è se HSA lavorerebbe anche con proci X86 tradizionali + VGA discreta, solo con APU oppure solo con APU che abbiano determinate caratteristiche, quali hUMA Kaveri.
Come riporta l'articolo, "Nel campo dei computer tradizionali è AMD la massima esponente dell'HSA, e una generazione di APU dopo l'altra, lo sta facendo vedere"... quindi se AMD con gli APU sta implementando ciò che con i proci X86 non fa, quello che mi verrebbe da supporre è che se il programma sfrutti o meno la VGA ad HSA non fregherebbe una mazza perchè sarebbe l'HSA a decidere (se ricompilato) e non viceversa, ma che l'HSA lavorerebbe unicamente con proci APU con determinate caratteristiche, ed essendo AMD il massimo esponente di HSA nei computer tradizionali, non credo che spenda i soldi che poi altri possano sfruttare gratis, ma spingerà in modo che il tutto funzioni meglio sui suoi proci o, perlomeno, che venda le licenze su ciò che ha sviluppato.

Non è che la situazione AMD la si voglia vedere come bicchiere vuoto? Metà 2014 si definiranno gli standard HSA... e Kaveri sarebbe già in commercio. Nel 2015 ci sarebbe Exavator APU che con tutta probabilità conterrà altro supporto all'HSA... ipotizzando che il progetto HSA proponga almeno una prima release disponibile alla massa nel 2015, reputerei possibile che già Exavator Opteron/FX possa essere APU.

[paolo.oliva2]

ciao a tutti, dopo anni di assenza torno a rompere le scatole :D
e porto un nuovo amico arrivato or ora dalla corea del sud:

https://dl.dropboxusercontent.com/u/6901145/fx8300.jpg

nei prossimi giorni lo provo, mi sa che farò una comparsata anche nel thread dell'overclock :D

Ciao :), bentornato.

Aspetto i tuoi test/overclock, perchè a suo tempo c'erano abbastanza analogie con gli 8300 e gli FX-9XXX attuali... se confermati i Vcore, mi sa che il tuo procio sia almeno un 9370.

[digieffe]

semplice, il mobile non può contare su una potenza grossa per via dei watt, ma ha cpu e gpu che regogno open cl e open gl.
mi sembra evidente, se il mobile vuole far girare applicati che richiedono grossa potenza di calcolo ha bisogno di sfruttare l'hardware la massimo.si ma la igp (che consuma e non poco) non so quanto sia più efficiente della cpu nei sistemi mobili... (va a finire che la batteria dura 4 ore)

arm, Samsung, Lg, Qualcomm, sony ... fanno impallidire intel a mio avviso.
senza contare che la cosa include apple e googleforse a livello economico ma non ne sarei così sicuro.
Invece a livello tecnologico sui chip complessi e/o compilatori? brevetti, esperienza, know-how, team di lavoro, tecnologie e strutture produttive (e mi fermo qui) non mi risulta che questi altri siano al livello... dovrebbero comprarsela unitamente a Nvidia così forse...

eh?
forse tu al vedi come potenza uno più potenza uno minore ugulae potenza due?mbe? anche se minimo c'è sempre un overhead, insomma anche se leggono la stessa memoria nello stesso modo sono 2 "chip" separati!
Se fossero realmente integrati (senza vedere nel die la separazione tra parte cpu e igp, condividendo registri, caches di ogni libello, ecc) forse entrerebbe in gioco la sinergia ossia 1 + 1 > 2, fino a quel momento sarà per forza di cose 1+1 <= 2.

in realtà una cpu fa cose gpu lentamente e vieversa. quindi usanto entrambe al massimo si ha una velocetà possible maggiore delle due sommate.in verità non è neanche così, la cpu è sempre più veloce della gpu, la gpu esegue lentamente molti più calcoli in parallelo. Quest'ultimo è uno dei motivi per cui 1 + 1 <= 2.

Aggiungo per i più tecnici che per sapere se la gpu ha terminato il lavoro, attualmente si sono affidati al metodo del "polling", "ottimo direi", speriamo che cambino metodo.

Se non ti fidi dai una occhiata alla documentazione (non gli articoli ipersemplificati di tommy il bugiardo) e ne riparliamo...


we! :) sia chiaro che non c'è l'ho con te. E' che questo thread lo leggono in molti ed allora su un argomento nuovo come questo cerco di dare i miei 2 cent per non creare confusione... ok? (poi posso sbagliare pure io :D)

[LurenZ87]

ciao a tutti, dopo anni di assenza torno a rompere le scatole :D
e porto un nuovo amico arrivato or ora dalla corea del sud:

https://dl.dropboxusercontent.com/u/6901145/fx8300.jpg

nei prossimi giorni lo provo, mi sa che farò una comparsata anche nel thread dell'overclock :D

FX-8300??? :stordita:

Inviato dal mio Nexus 4 con Tapatalk 2

[digieffe]

Quindi se ho ben capito... HSA è un progetto che ottimizza l'elaborazione dei dati di un X programma (X86 + VGA), scritto con qualsiasi linguaggio, con l'unica condizione che sia compilato nel modo corretto.questo è ciò che affermano loro nascondendo un discorso più complesso che si trova nelle slide:
1 - quando parlano dei linguaggi esistenti si riferiscono a java, c++ ecc oppure anche a tecnologie come opencl, amp, openmp ecc? perché se si riferiscono solo ai primi dubito che si possano avere vantaggi "seri" (loro vorrebbero prendere un codice sequenziale e con un "supercompilatore" trasformarlo in parallelo, imho sicuramente in alcuni punti del programma ci saranno dei lievi vantaggi), se come nel secondo caso il programma è già scritto in "modo parallelo" allora la cosa è semplice.
Domanda: quanti programmi sono e saranno (nei prossimi anni) scritti in modo parallelo? quanto tempo è servito per passare da x86 alla sua estensione x86_64? (eppure ci sono ancora una marea di programmi a 32 bit in giro...) dandovi le risposte a queste domande vi sarete risposti sul tempo minimo che serve perché queste tecnologie prendano piede (se non falliscono).
2 - loro parlano anche di librerie scritte in parallelo che il programmatore dovrebbe utilizzare, ok. Le scrivono loro? si, si chiama Bolt, siamo sicuri che sarà utilizzata?

Quello che non ho capito perfettamente, è se HSA lavorerebbe anche con proci X86 tradizionali + VGA discreta, solo con APU oppure solo con APU che abbiano determinate caratteristiche, quali hUMA Kaveri.diciamo che tramite i loro compilatori ed il linguaggio intermedio HSAil lo farebbero per qualsiasi CPU e GPU: praticamente non viene caricato sulla macchina un eseguibile binario, ma come in alcuni ambiti java tramite un compilatore jit qui chiamato "finalizer", verrebbe ricompilato al lancio dell'applicazione.

Come riporta l'articolo, "Nel campo dei computer tradizionali è AMD la massima esponente dell'HSA, e una generazione di APU dopo l'altra, lo sta facendo vedere"... quindi se AMD con gli APU sta implementando ciò che con i proci X86 non fa, quello che mi verrebbe da supporre è che se il programma sfrutti o meno la VGA ad HSA non fregherebbe una mazza perchè sarebbe l'HSA a decidere (se ricompilato) e non viceversa, ma che l'HSA lavorerebbe unicamente con proci APU con determinate caratteristiche, ed essendo AMD il massimo esponente di HSA nei computer tradizionali, non credo che spenda i soldi che poi altri possano sfruttare gratis, ma spingerà in modo che il tutto funzioni meglio sui suoi proci o, perlomeno, che venda le licenze su ciò che ha sviluppato.appunto se... e con quali prestazioni con la sola compilazione (senza un adattamento ottimizzato)
Ho già precisato che funzionerebbe con qualsiasi cpu e gpu.

Non è che la situazione AMD la si voglia vedere come bicchiere vuoto? Metà 2014 si definiranno gli standard HSA... e Kaveri sarebbe già in commercio. Nel 2015 ci sarebbe Exavator APU che con tutta probabilità conterrà altro supporto all'HSA... ipotizzando che il progetto HSA proponga almeno una prima release disponibile alla massa nel 2015, reputerei possibile che già Exavator Opteron/FX possa essere APU.no, non è mezzo vuoto, come dici tu vediamo come la integrano meglio in excavator.


forse questa slide può chiarire: edit ho rimosso la slide in quanto il link era a tutte le slide non a quella specifica.


EDIT: "Delivered via royalty free standards", le specifiche e le api gratuite i tools non so.

[wafa]

ciao a tutti, dopo anni di assenza torno a rompere le scatole :D
e porto un nuovo amico arrivato or ora dalla corea del sud:

https://dl.dropboxusercontent.com/u/6901145/fx8300.jpg

nei prossimi giorni lo provo, mi sa che farò una comparsata anche nel thread dell'overclock :D

bel processore, buon batch:)

[digieffe]

Ho fatto una selezione delle slide più significative ed anche più semplici per chi è meno esperto questo è l'indirizzo: http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/
- in alto a sx le slide n. 3, 25, 26, 28;
- in alto a dx la 23;
- in basso a sx la 7, 8, 12 (se non è una ripetizione);
- in basso a dx 2, 3, 7, 15, per chi ne sa di più 16, 17 ...

se qualcuno vuol fare un opera buona potrebbe anche incollarle nel thread ;), almeno fino alla 15 del 4° gruppo.


mi sono accorto che con la stanchezza della notte ho scritto delle imprecisioni:
- 136 sono le istruzioni della rappresentazione intermedia HSAil e non le istruzioni della gpu
- gli interi 64 bit ed Fp16 bit sono di HSAil e non della gpu, che io sappia GCN tratta solo int32, fp32, fp 64.
- aggiungo che ci sono anche dei dati simd a 128 bit ma è da capire chi poi li elaborerà (avx o CU)

[epimerasi]

hUMA non è HSA... hUMA semplicemente è l'accesso diretto ai dati della CPU da parte della GPU e della GPU ai dai della CPU, ed è la stessa cosa che proporra nVidia con Maxwell.

quindi se il programma sfrutta la GPU bene seno ciccia.

hUMA serve per HSA, altrimenti non ha senso

[feldvonmanstein]

si ma la igp (che consuma e non poco) non so quanto sia più efficiente della cpu nei sistemi mobili... (va a finire che la batteria dura 4 ore)



un confronto serio sui consumi viene fatto quando si tiene conto anche del tempo di elaborazione; se con la gpu ci metti molto meno finisci per consumare meno della cpu anche se ha un tdp nominale superiore.

[digieffe]

hUMA serve per HSA, altrimenti non ha sensociao epimerasi, scusa se mi intrometto, di certo AceGranger non ha bisogno del mio supporto, ma te lo semplifico così slide n.10 primo gruppo http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/

quindi hUMA non è necessario per hsa.


Se qualcuno postasse le slide che ho elencato molte domande non ci sarebbero neppure:
- in alto a sx le slide n. 3, 25, 26, 28;
- in alto a dx la 23;
- in basso a sx la 7, 8, 12 (se non è una ripetizione);
- in basso a dx 2, 3, 7, 15

[capitan_crasy]

ciao a tutti, dopo anni di assenza torno a rompere le scatole :D
e porto un nuovo amico arrivato or ora dalla corea del sud:

https://dl.dropboxusercontent.com/u/6901145/fx8300.jpg

nei prossimi giorni lo provo, mi sa che farò una comparsata anche nel thread dell'overclock :D

gi0v3:eek: :eek: :eek:
Ben tornato!!!!!
http://i.imgur.com/NSOHQfy.gif

[AceGranger]

hUMA serve per HSA, altrimenti non ha senso

hUMA non serve a nulla per l'HSA, è un "escamotage" per far lavorare meglio 2 entita separate, andando ad agire su uno dei colli di bottiglia che è la comunicazione fra le 2 entita, e il senso ce l'ha eccome, visto che permette prestazioni superiori e migliore efficienza.
Oltre a questo permettera anche di superare il limite della memoria on-board, che se nelle APU ( visto i ltarget ) è inifluente, nel caso delle VGA discrete sara una grossa innovazione, visto che andra a colmare uno dei limiti piu grossi del GPGPU, ed è per questo che anche nVidia sta puntando sulla memoria unificata, nome diverso ma stessa identica cosa, e di certo non pensa di fare CPU X86HSA.

Presumo che a breve AMD introdurra al pari delle sue APU e delle prossime VGA di nVidia, la memoria unificata anche per le proprie VGA discrete.

[gefri]

hUMA non serve a nulla per l'HSA, è un "escamotage" per far lavorare meglio 2 entita separate, andando ad agire su uno dei colli di bottiglia che è la comunicazione fra le 2 entita, e il senso ce l'ha eccome, visto che permette prestazioni superiori e migliore efficienza.
Oltre a questo permettera anche di superare il limite della memoria on-board, che se nelle APU ( visto i ltarget ) è inifluente, nel caso delle VGA discrete sara una grossa innovazione, visto che andra a colmare uno dei limiti piu grossi del GPGPU, ed è per questo che anche nVidia sta puntando sulla memoria unificata, nome diverso ma stessa identica cosa, e di certo non pensa di fare CPU X86HSA.

Presumo che a breve AMD introdurra al pari delle sue APU e delle prossime VGA di nVidia, la memoria unificata anche per le proprie VGA discrete.

scusate l'ot, ma ce la faresti in un reply a spiegarmi cosa significa? in un futuro le vga nvidia riusciranno ad usare la ram di sistema per cuda? ma non crolleranno le prestazioni? si sa quando è prevista questa tecnologia?

[Ludus]

fx 9370 250€
fx 9590 350€

prezzi visti ora nel mio shop abituale.
bè molto meglio del previsto i prezzi. se li limano di 50€ l'uno sono interessantissimi, consumo a parte.

[AceGranger]

scusate l'ot, ma ce la faresti in un reply a spiegarmi cosa significa? in un futuro le vga nvidia riusciranno ad usare la ram di sistema per cuda? ma non crolleranno le prestazioni? si sa quando è prevista questa tecnologia?

attualmente nel GPGPU, sia che si tratti di APU o di discrete, in alcuni software, come ad esempio alcuni motori di render, la scena o il dato, devono essere interamente caricati nella ram della VGA, perchè la GPU puo leggere solo la sua ram e deve avere disponibili tutti i dati; ( e comuque dara benefici anche nei software che non hanno questo limite, perchè comunque si risparmieranno una riscrittura del dato nella ram della VGA )
con hUMA e con la Unified Virtual Memory di nVidia, ci sara un "livello superiore" che creera una grossa memoria virtuale e la GPU riuscira ad accedere ai dati della ram di sistema, senza doverli copiare tutti nella sua ram, la vedra come "sua" ram, visto che potra accedervi direttamente;
sicuramente non sara veloce quanto la vram perchè si dovra passare dal PCI-EX, ma credo che in questo tipo di calcoli il collo di bottiglia sia comunque sempre la capacita di calcolo della GPU e non la ram, non credo che il PCI-EX sia piu di tanto limitante, anche perchè, il PCI-EX 3.0 ha aumentato la banda e ridotto la latenza.
Nel caso di nVidia la Unified Virtual Memory è il "cavallo di battaglia" di Maxwell, quindi dovremmo averla fra pochi mesi; nel caso di AMD la avremo con le APU anche lei fra pochi mesi e, non ho letto nulla in merito, ma non credo che tardera a proporla con le sue VGA discrete.

http://www.theinquirer.net/inquirer/news/2255921/nvidias-maxwell-gpu-architecture-will-access-system-ram

"However the firm's next generation Maxwell GPU architecture will allow the GPU to access main memory, reminiscent of AMD's unified memory architecture."

[paolo.oliva2]

@digieffe
io mi perdo... e se mi perdo ci metto la fantasia e dopo sono problemi :)

Ma il discorso della parallelizzazione è diverso dal discorso dell'elaborazione dei dati a seconda di dove si risolverebbero più facilmente (FP-IGP). Cioè... se un programma non sfrutta la parallelizzazione perchè non realizzato in un determinato modo o perchè non si può, è penalizzato in primis perchè non sfrutta il multicore dei proci odierni, ma comunque potrebbe sfruttare l'IGP per risolverli, quindi HSA porterebbe comunque un vantaggio in qualsiasi caso.

Poi non sono d'accordo che non sia parallelizzabile quello che non si può parallelizzare... da sempre il processore è alla rincorsa di emulazione del cervello umano, il quale è un esempio massimo di parallelizzazione. Non è che il cervello umano possa vedere un Film parallelizzato, ma comunque una cosa non parallelizzabile è comunque parallelizzata con altre.

[paolo.oliva2]

fx 9370 250€
fx 9590 350€

prezzi visti ora nel mio shop abituale.
bè molto meglio del previsto i prezzi. se li limano di 50€ l'uno sono interessantissimi, consumo a parte.

Per un giudizio più esatto bisognerebbe avere una media del Vcore necessario per una determinata frequenza, perchè è impossibile quantificare un costo/prestazioni e il relativo consumo senza avere almeno una media dei Vcore.

Ad esempio... uno del TH aveva acquistato un 9370 e secondo i suoi test con 1,4V terrebbe i 4,7GHz... ma non so in quale situazione. Quello che voglio dire, per fare un esempio, che se con 1,38V tenesse i 4,7GHz con OCCT, vorrebbe dire +200/300MHz a parità di Vcore con l'8350, ma siccome è il Vcore che aumenta i consumi, a Vcore uguale i consumi se non gli stessi sarebbero simili... quindi si avrebbe un 9370 @4,7GHz che consumerebbe tanto quanto un 8350 @4,4GHz.

Figurati che nel sito di Asrock addirittura riportano 1,4V per un 9590 @5GHz... 1 9590 costa quasi quanto 2 8350... ma se fosse vero @5GHz a 1,4V, varrebbe la pena.

[Ludus]

Il consumo a parte è riferito alle controparti Intel, non al 8350. Ora i prezzi di questi due processori sono allineati al 4670k e 4770k.

[paolo.oliva2]

Comunque io ci vedo qualche cosa di più nello sviluppo in un APU della memoria unificata solo per prestazioni superiori lato IGP integrata.

Cioè, se HSA lavora e la IGP dell'APU con hUMA permette una banda maggiore, questo vorrebbe dire IGP on die di potenza maggiore, ma una IGP di potenza maggiore non vuol dire solamente nella grafica, perchè nel momento che HSA lavorerebbe su quell'APU, avrebbe comunque prestazioni superiori perchè l'FP dell'IGP avrà potenze maggiori.

Inoltre bisogna vedere anche 2 altri aspetti.
Attualmente il vero limite di un APU e la sua IGP non è nella banda ma nella miniaturizzazione silicio che comunque non permetterebbe una IGP di potenza maggiore.
Allora perchè AMD si è concentrata su hUMA con Kavery visto che il 28nm Bulk non permetterà chissà quale guadagno in TDP sul 32nm SOI e di conseguenza l'IGP integrata non soffrirebbe di banda mentre quello sforzo se concentrato sull'architettura X86 avrebbe potuto portare più avanti di Steamroller magari accorpando qualche cosa di Exavator?

Se colleghiamo questo al discorso di APU Opteron, scapperebbe fuori un altro scenario... perchè indubbiamente in qualsiasi caso HSA garantirebbe più potenza con un X86 + discreta che con un APU... ma sarebbe la stessa cosa tra un APU in CF con discreta e X86 + discreta (un guadagno maggiore rispetto all'aumento FP in CF), magari perchè un APU garantirebbe uno smistamento dati più fluido con hUMA che senza?

[paolo.oliva2]

Il consumo a parte è riferito alle controparti Intel, non al 8350. Ora i prezzi di questi due processori sono allineati al 4670k e 4770k.

Se parliamo di consumo, bisogna considerare molti aspetti.

In primis l'architettura AMD non è affinata quanto quella Intel, quindi comunque a parità di prestazioni e miniaturizzazione silicio quella AMD consumerebbe di più, inoltre il consumo è inferiore più la miniaturizzazione del silicio è spinta, e AMD sul 32nm contro Intel sul 22nm accentua la differenza dei consumi, quindi qualsiasi FX prendiamo in considerazione, consumerà sempre più di un Intel.

Se inglobi il consumo in un discorso di costi inferiori di utilizzo, dipende quanto tempo utilizzi il procio al giorno e quale carico gli dai, e rapportando quanto risparmi al costo superiore degli Intel.

Con un uso 24h/24 365 giorni all'anno e stracaricato, condizione evidentemente impossibile, un Intel risparmierebbe sulla bolletta circa 70€, il che porterebbe ad un pareggio in circa 2 anni. Con un uso di 8h al giorno di cui 4 stracaricato, tutti i giorni dell'anno, e già sarebbe molto di più dell'uso normale, il risparmio si tradurrebbe in circa 20€, al che occorrerebbe un tempo superiore rispetto alla normale vita del sistema per pareggiare.

In poche parole, se la scelta dell'uno o dell'altro è legata solamente ai consumi, di certo un risparmio non lo offrirebbe un 3770K/4770K, se poi vista la domanda sei "sensibile" ai costi, prendi qualsiasi money-bench e vedresti i rapporti effettivi prestazioni/prezzo, ricalcolalo immaginando di accorpare anche il discorso consumi, e tira le somme.

Da parte mia, un 8350 è preferibile ad un 3770K/4770K perchè ha un costo/prestazioni di gran lunga favorevole... e la diffirenza di consumi nell'uso normale non cambierebbe granchè. Un 9370/9590 incide molto di più nel money-bench che nei consumi... per me un 9370 anche se con un money/bench peggiore dell'8350, dovrebbe risultare ancora favorevole nei confronti 3770K/4770K, ho i miei dubbi per un 9590... ma si discuterebbe sul nulla, perchè se per un 10% di prestazioni massime in più uno preferirebbe spendere 150€ in più in un 4770K al posto di un 8350, un 9590 risulterebbe avere quasi un 20% in più di potenza di un 8350, quindi quei 150€ sarebbero a parti invertite, e dividendo quella somma per i consumi/anno superiori, quanto potrebbe essere? 4-5 anni? 2€ in più o in meno al mese non sono nemmeno quantificabili come risparmio, perchè già inciderebbe di più quale VGA ci monterei...

[mtk]

scusate l ot,secondo voi l fx in oc senza liquido messo qui dentro

http://imageshack.us/f/713/ov9a.jpg/

http://imageshack.us/f/585/kxyw.jpg/

è fattibile?
sto facendo un po' di bricolage :asd:

[capitan_crasy]

scusate l ot,secondo voi l fx in oc senza liquido messo qui dentro

http://imageshack.us/f/713/ov9a.jpg/

http://imageshack.us/f/585/kxyw.jpg/

è fattibile?
sto facendo un po' di bricolage :asd:

http://i.imgur.com/Lr1ytnW.gif

[dobermann77]

Globalfoundries sta programmando una nuova fabbrica.

http://www.businessmagazine.it/news/globalfoundries-ottiene-l-approvazione-per-costruire-una-nuova-fabbrica_48482.html

[mtk]

In che senso senza liquido? e che tipo di OC?

comunque, hai la mia più profonda ammirazione :ave:

:D

attualmente l fx viaggia a 4,8 con raffreddamento a liquido nel suo bel case,pensavo di finire la postazione da gioco che uso per gtr2 e prossimamente per assetto corsa con un case in stile corsaiolo,ma le dimensioni per alloggiare l hardware sono limitate e dovrò usare molto la parte posteriore della lamiera che fissa la mobo per il fissaggio Dell alimentatore e non ho spazio per mettere anche i radiatori....
Ho circa 7 cm utili per un dissipatore ad aria...anche se stavo pensando di usare una canalizzazione orizzontale che sigillerebbe un dissipatore in rame isolandolo dal resto dell hardware,aspirerebbe dal canale del cerchio a sinistra e soffierebbe a destra sempre attraverso il canale,pero avrei bisogno di sapere quanta massa dissipante mettere oppure comprare un dissi e poi farlo a pezzi e usare quello che mi serve...
la,cosa che mi frena Nell attuare il trapianto dal case tradizionale al cerchio,sono le temperature degli altri componenti...
se qualcuno lo usa su un banchetto senza raffreddamenti aggiuntivi,potrebbe darmi qualche dritta :)

[epimerasi]

hUMA non serve a nulla per l'HSA, è un "escamotage" per far lavorare meglio 2 entita separate, andando ad agire su uno dei colli di bottiglia che è la comunicazione fra le 2 entita, e il senso ce l'ha eccome, visto che permette prestazioni superiori e migliore efficienza.
Oltre a questo permettera anche di superare il limite della memoria on-board, che se nelle APU ( visto i ltarget ) è inifluente, nel caso delle VGA discrete sara una grossa innovazione, visto che andra a colmare uno dei limiti piu grossi del GPGPU, ed è per questo che anche nVidia sta puntando sulla memoria unificata, nome diverso ma stessa identica cosa, e di certo non pensa di fare CPU X86HSA.

Presumo che a breve AMD introdurra al pari delle sue APU e delle prossime VGA di nVidia, la memoria unificata anche per le proprie VGA discrete.

...:rolleyes:

Non ha senso HSA se non hai uno spazio di memoria unificato...

[AceGranger]

...:rolleyes:

Non ha senso HSA se non hai uno spazio di memoria unificato...

Non ha senso parlare di spazio di memoria unificato quando il CHIP è un'entita unica.
L'HSA sara un chip monolitico, la parte VGA diventera come ora sopno le parti della cpu che decodificano in hardware i video.
Se AMD domani avesse presentato l'HSA la dicitura "memoria unificata" non l'avresti nemmeno sentita nominare.

[paolo.oliva2]

:D

attualmente l fx viaggia a 4,8 con raffreddamento a liquido nel suo bel case,pensavo di finire la postazione da gioco che uso per gtr2 e prossimamente per assetto corsa con un case in stile corsaiolo,ma le dimensioni per alloggiare l hardware sono limitate e dovrò usare molto la parte posteriore della lamiera che fissa la mobo per il fissaggio Dell alimentatore e non ho spazio per mettere anche i radiatori....
Ho circa 7 cm utili per un dissipatore ad aria...anche se stavo pensando di usare una canalizzazione orizzontale che sigillerebbe un dissipatore in rame isolandolo dal resto dell hardware,aspirerebbe dal canale del cerchio a sinistra e soffierebbe a destra sempre attraverso il canale,pero avrei bisogno di sapere quanta massa dissipante mettere oppure comprare un dissi e poi farlo a pezzi e usare quello che mi serve...
la,cosa che mi frena Nell attuare il trapianto dal case tradizionale al cerchio,sono le temperature degli altri componenti...
se qualcuno lo usa su un banchetto senza raffreddamenti aggiuntivi,potrebbe darmi qualche dritta :)
Complementi per la bellezza del tuo banchetto, ma non ho capito bene se sarebbe sempre a liquido o ad aria.

Comunque l'ALI ha la ventola di suo... se il procio lo raffreddi a liquido l'unica cosa da guardare è la parte ali della mobo, ma con una ventolina uso cacchio va più che bene... (e quella del dissi stock del procio sarebbe sovradimensionata). Siccome io uso intensamente l'SB, ho notato che raffreddare solamente la parte ALI della mobo non raffreddava a sufficienza l'SB950, quindi ho messo una ventola pure lì (sempre quella del dissi stock che ne ho in gran numero) che a sua volta permette temp più basse pure al NB.
Io metterei una ventolina pure agli HD... non fa mai male.

[paolo.oliva2]

@epimerasi
Ci sono dei punti che non capisco.
HSA ha lo scopo di utilizzare la VGA come aiuto all'FP del procio, e fin qui ci siamo.

Quello che non comprendo, è che se si parlasse di chip monolitico a quel punto o tutti i produttori solamente di VGA si metterebbero a produrre APU (situazione improbabile) o verrebbero tagliati fuori (vedendo il tot di patner al progetto HSA, presumo che il progetto non parta con l'intenzione di escludere produttori ma di inglobarne il più possibile, quindi a maggior ragione di non escludere i soli produttori di VGA).

Ora... è indubbio che HSA per lavorare abbia bisogno di memoria unificata, ma a quel punto si escluderebbero tutti gli X86 e idem gli APU che non avrebbero la memoria unificata, oppure HSA a livello software la emulerebbe e/o potrebbe essere inglobata sulla VGA discreta?

[carlottoIIx6]

si ma la igp (che consuma e non poco) non so quanto sia più efficiente della cpu nei sistemi mobili... (va a finire che la batteria dura 4 ore)


nel mobile hanno già le loro gpu.


forse a livello economico ma non ne sarei così sicuro.
Invece a livello tecnologico sui chip complessi e/o compilatori? brevetti, esperienza, know-how, team di lavoro, tecnologie e strutture produttive (e mi fermo qui) non mi risulta che questi altri siano al livello... dovrebbero comprarsela unitamente a Nvidia così forse...

non devono fare le cpu, ma dare i soldi :D e ne ahnno tanti. a fare le cpu ci pensano amd arm ecc


mbe? anche se minimo c'è sempre un overhead, insomma anche se leggono la stessa memoria nello stesso modo sono 2 "chip" separati!
Se fossero realmente integrati (senza vedere nel die la separazione tra parte cpu e igp, condividendo registri, caches di ogni libello, ecc) forse entrerebbe in gioco la sinergia ossia 1 + 1 > 2, fino a quel momento sarà per forza di cose 1+1 <= 2.

in verità non è neanche così, la cpu è sempre più veloce della gpu, la gpu esegue lentamente molti più calcoli in parallelo. Quest'ultimo è uno dei motivi per cui 1 + 1 <= 2.


la gpu è lenta ma fa molte cose contemporaneamente.


Aggiungo per i più tecnici che per sapere se la gpu ha terminato il lavoro, attualmente si sono affidati al metodo del "polling", "ottimo direi", speriamo che cambino metodo.

Se non ti fidi dai una occhiata alla documentazione (non gli articoli ipersemplificati di tommy il bugiardo) e ne riparliamo...


we! :) sia chiaro che non c'è l'ho con te. E' che questo thread lo leggono in molti ed allora su un argomento nuovo come questo cerco di dare i miei 2 cent per non creare confusione... ok? (poi posso sbagliare pure io :D)
;)

[epimerasi]

ciao epimerasi, scusa se mi intrometto, di certo AceGranger non ha bisogno del mio supporto, ma te lo semplifico così slide n.10 primo gruppo http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/

quindi hUMA non è necessario per hsa.


Se qualcuno postasse le slide che ho elencato molte domande non ci sarebbero neppure:
- in alto a sx le slide n. 3, 25, 26, 28;
- in alto a dx la 23;
- in basso a sx la 7, 8, 12 (se non è una ripetizione);
- in basso a dx 2, 3, 7, 15

Alto a sx:
Slide 3: quella è la situazione attuale, non HSA. Il grafico esemplifica il traffico che c'è attualmente da gestire quando si fa un programma che usa CPU+GPU. HSA serve -teoricamente- proprio per semplificare questo workflow.

Dalla slide 5 in poi: è esattamnete quello che sto cercando di dirvi. Leggi attentamente la slide 9.

hUMA non è nient'altro che l'implementazione del modello descritto in quelle slide.

Basso a dx:
Slide 2: "Emerging solution", HSA Hardware: leggi cosa c'è scritto.
Slide successive: il compilatore a run time prende HSAIL e lo trasforma in binario. Se lo spazio di indirizzamento non fosse condiviso, il programmatore dovrebbe prendersi in carico di gestire tutto il traffico fra CPU e GPU, ovvero quello che già si fa attualmente. Non avresti risolto nulla. Si perderebbe il senso di usare lo strato software intermedio.

[epimerasi]

Non ha senso parlare di spazio di memoria unificato quando il CHIP è un'entita unica.
L'HSA sara un chip monolitico, la parte VGA diventera come ora sopno le parti della cpu che decodificano in hardware i video.
Se AMD domani avesse presentato l'HSA la dicitura "memoria unificata" non l'avresti nemmeno sentita nominare.

Quando stai parlando di HSA non stai parlando di hardware, ma di software. Perchè funzioni questo paradigma HAI BISOGNO di uno spazio di memoria unificato.

Dovresti leggere quelle slide.

[epimerasi]

@epimerasi
Ci sono dei punti che non capisco.
HSA ha lo scopo di utilizzare la VGA come aiuto all'FP del procio, e fin qui ci siamo.

Quello che non comprendo, è che se si parlasse di chip monolitico a quel punto o tutti i produttori solamente di VGA si metterebbero a produrre APU (situazione improbabile) o verrebbero tagliati fuori (vedendo il tot di patner al progetto HSA, presumo che il progetto non parta con l'intenzione di escludere produttori ma di inglobarne il più possibile, quindi a maggior ragione di non escludere i soli produttori di VGA).

Ora... è indubbio che HSA per lavorare abbia bisogno di memoria unificata, ma a quel punto si escluderebbero tutti gli X86 e idem gli APU che non avrebbero la memoria unificata, oppure HSA a livello software la emulerebbe e/o potrebbe essere inglobata sulla VGA discreta?

Allora, qui si sta facendo confusione fra hardware e software.

HSA è la proposta per un modello di programmazione che dovrebbe semplificare l'approccio alla scrittura di programmi che vogliono fare uso delle unità GPU (discrete o integrate nelle APU che siano).

Detta in maniera brutale: ora i programmatori usano principalmente due cose C e openCL oppure C e CUDA. OpenCL e CUDA non sono nient'altro che API standard, ovvero io (gruppo Khronos) decido quello che devono fare le GPU per ogni generazione e stabilisco uno standard che i programmi devono seguire per accedere alle funzioni della GPU. È più o meno quello che fa OpenGL o directX.

Il punto è che un'API di questo livello (per quanto migliorino di generazione in generazione):
1) è più di alto livello rispetto al linguaggio macchina ma lascia completamente al programmatore la gestione del traffico dati fra CPU/GPU e la gestione della memoria della GPU.
2) mi vincola nella scrittura dei kernel che devono girare sulla GPU (è molto difficile fare qualcosa che giri bene su tutto, spesso devo fare compromessi)

QUando parliamo di programmi per GPU parliamo di programmi altamente paralleli, ovvero di sequenze di istruzioni che vengono eseguite su tanti dati parallelamente. Per kernel in questo caso si intende il pezzetto di programma che viene applicato su tanti dati parallelamente.

HSA si pone come interfaccia fra programmatore e hardware.

Il parallelo più semplice da fare è quello di Java: la Java virtual machine si mette come livello intermedio fra programmatore (che scrive il programma in un linguaggio solo) e l'hardware/sistema operativo (che può essere molto diverso: x86, power, arm, windows, linux etc...). Sta a produttore di hardware/di sistemi operativi/sviluppatore del linguaggio sfornare le virtual machine per far andare lo stesso programma java sulle varie piattaforme, alleggerendo il lavoro del programmatore.

Nel caso di HSA, HSA permetterebbe la scrittura dei kernel nel linguaggio preferito dal programmatore (senza che debba impararsi un nuovo linguaggio o una nuova API appositamente). Il kernel viene interpretato in linguaggio intermedio (HSAIL). Sta poi ai diversi produttori di hardware fornire dei driver che permettano alla CPU/GPU/APU eseguire il codice HSAIL (con un compilatore just-in-time).

[AceGranger]

Quando stai parlando di HSA non stai parlando di hardware, ma di software. Perchè funzioni questo paradigma HAI BISOGNO di uno spazio di memoria unificato.
Dovresti leggere quelle slide.

HSA non è la parte Hardware Hardware Heterogeneous System Architecture, e HSAIL HSA Intermediate Language la parte software ?

[paolo.oliva2]

Allora, qui si sta facendo confusione fra hardware e software.

HSA è la proposta per un modello di programmazione che dovrebbe semplificare l'approccio alla scrittura di programmi che vogliono fare uso delle unità GPU (discrete o integrate nelle APU che siano).

Detta in maniera brutale: ora i programmatori usano principalmente due cose C e openCL oppure C e CUDA. OpenCL e CUDA non sono nient'altro che API standard, ovvero io (gruppo Khronos) decido quello che devono fare le GPU per ogni generazione e stabilisco uno standard che i programmi devono seguire per accedere alle funzioni della GPU. È più o meno quello che fa OpenGL o directX.

Il punto è che un'API di questo livello (per quanto migliorino di generazione in generazione):
1) è più di alto livello rispetto al linguaggio macchina ma lascia completamente al programmatore la gestione del traffico dati fra CPU/GPU e la gestione della memoria della GPU.
2) mi vincola nella scrittura dei kernel che devono girare sulla GPU (è molto difficile fare qualcosa che giri bene su tutto, spesso devo fare compromessi)

QUando parliamo di programmi per GPU parliamo di programmi altamente paralleli, ovvero di sequenze di istruzioni che vengono eseguite su tanti dati parallelamente. Per kernel in questo caso si intende il pezzetto di programma che viene applicato su tanti dati parallelamente.

HSA si pone come interfaccia fra programmatore e hardware.

Il parallelo più semplice da fare è quello di Java: la Java virtual machine si mette come livello intermedio fra programmatore (che scrive il programma in un linguaggio solo) e l'hardware/sistema operativo (che può essere molto diverso: x86, power, arm, windows, linux etc...). Sta a produttore di hardware/di sistemi operativi/sviluppatore del linguaggio sfornare le virtual machine per far andare lo stesso programma java sulle varie piattaforme, alleggerendo il lavoro del programmatore.

Nel caso di HSA, HSA permetterebbe la scrittura dei kernel nel linguaggio preferito dal programmatore (senza che debba impararsi un nuovo linguaggio o una nuova API appositamente). Il kernel viene interpretato in linguaggio intermedio (HSAIL). Sta poi ai diversi produttori di hardware fornire dei driver che permettano alla CPU/GPU/APU eseguire il codice HSAIL (con un compilatore just-in-time).
Si, quello che non capisco è la parte in neretto.
Praticamente il driver è per far sì che il software possa riconoscere l'hardware e quindi che si possa utilizzarlo.
Ora... prendiamo un 8350, un Trinity ed un Kaveri. I primi 2 non hanno nulla di supporto hardware per la memoria unificata, Kaveri si.
Ora... che AMD con Kaveri rilasci un driver per supporto codice HSAIL (quindi HSA) è scontato (altrimenti per cosa avrebbe fatto hUMA?), ma con Trinity e 8350... ammesso e concesso che AMD abbia la volontà di realizzare il driver, lo potrebbe fare ugualmente o l'assenza di hUMA renderebbe la cosa impossibile?

Premetto che essendo tutto in alto-mare, probabilmente è difficile sapere alcune cose con certezza, ma più che altro era per capire la posizione di AMD, perchè chi non è competente (come me), non riesce a discernere un annuncio stile "primo APU con supporto memoria unificata" se commerciale o di grande importanza hardware.
Cioè... che hUMA serva a Kavery per i vantaggi con l'IGP on-die al di fuori di HSA, è un fatto a parte, ma che poi rappresenti il 1° APU al mondo che potrebbe già supportare HSA a tutti gli effetti, non sarebbe di poco conto, perchè AMD tramite Kaveri e le sue VGA, potrebbe offrire HSA (a patto che il software venga ricompilato correttamente, cosa che comunque AMD potrebbe forse richiedere direttamente alle ditti produttrici di software) senza comunque aspettare che sia definito uno standard HSA.

[epimerasi]

HSA non è la parte Hardware Hardware Heterogeneous System Architecture, e HSAIL HSA Intermediate Language la parte software ?

EDIT: H non sta per Hardware.

HSA indica tutta la piattaforma su cui si basa questo approccio di interpretazione/compilazione (in quelle diapositive viene descritta nel dettaglio: scopo, progettazione, modello della memoria, etc...)

HSAIL è un componente di HSA, in particolare è un linguaggio intermedio fra i linguaggi di programmazione (e relative librerie) e l'hardware target su cui devono girare i programmi.

http://www.slideshare.net/hsafoundation/hsa-intro-hot-chips2013-final?ref=http://hsafoundation.com/hot-chips-2013-hsa-foundation-presented-deeper-detail-hsa-hsail/

In particolare vai nella slide 12 in cui si vede in parallelo qual è lo stack delle applicazioni che usano l'hardware grafico e quale sarà lo stack secondo HSA.

Nella slide 39 c'è una comparazione: ignora le prime 3 colonne, (che indicano le linee di codice necessarie a implementare quel programma su CPU). Nelle altre vedi che utilizzare HSA ti fa risparmiare molto tempo rispetto ad usare C&OPenCL, C++&OpenCl, C++&AMP (una libreria per il calcolo parallelo), con prestazioni simili.

[gyonny]

Salve ragazzi, vorrei farvi una domandina:

posseggo un FX-6300 e sto testando la stabilità del mio sistema con CPU momentaneamente @default, l'unica cosa che ho attiva da bios è il Cool&Quiet e il resto dei valori sono tutti alle impostazioni di fabbrica. Sapreste dirmi perchè durante le fasi di stress-test si verificano dei frequenti cali di frequenza da 3516Mhz a 1406Mhz nonostante il task manager di Windows indichi il 100% di carico su tutti e 6 i core?
E' normale questa situazione? Lo fa anche a voi sui vostri FX? Il Cool&Quiet c'entra qualcosa con questi frequenti cali di frequenze sotto massimo carico di lavoro? Grazie

[epimerasi]

Si, quello che non capisco è la parte in neretto.
Praticamente il driver è per far sì che il software possa riconoscere l'hardware e quindi che si possa utilizzarlo.
Ora... prendiamo un 8350, un Trinity ed un Kaveri. I primi 2 non hanno nulla di supporto hardware per la memoria unificata, Kaveri si.
Ora... che AMD con Kaveri rilasci un driver per supporto codice HSAIL (quindi HSA) è scontato (altrimenti per cosa avrebbe fatto hUMA?), ma con Trinity e 8350... ammesso e concesso che AMD abbia la volontà di realizzare il driver, lo potrebbe fare ugualmente o l'assenza di hUMA renderebbe la cosa impossibile?


Questa è una domanda a cui non posso risponderti con certezza.

Posso risponderti teoricamente: nulla vieta al codice tradotto in HSAIL di essere compilato ed eseguito sulla CPU. Quindi il compilatore JIT lo tradurrebbe al volo e andrebbe normalmente. Tutto sta, appunto, nelle capacità del compilatore.

[plainsong]

Salve ragazzi, vorrei farvi una domandina:

posseggo un FX-6300 e sto testando la stabilità del mio sistema con CPU momentaneamente @default, l'unica cosa che ho attiva da bios è il Cool&Quiet e il resto dei valori sono tutti alle impostazioni di fabbrica. Sapreste dirmi perchè durante le fasi di stress-test si verificano dei frequenti cali di frequenza da 3516Mhz a 1406Mhz nonostante il task manager di Windows indichi il 100% di carico su tutti e 6 i core?
E' normale questa situazione? Lo fa anche a voi sui vostri FX? Il Cool&Quiet c'entra qualcosa con questi frequenti cali di frequenze sotto massimo carico di lavoro? Grazie

Normale non è...come sono le temperature quando si verificano i cali ("throttling") della frequenza?

[gyonny]

Normale non è...come sono le temperature quando si verificano i cali ("throttling") della frequenza?

Grazie per aver risposto.

Le temperature sono 52C° > 48°C (il dissipatore non è quello di stock)

Forse sarà un problema della mobo? Conviene disabilitare l'opzione "CPU Thermal Throttling" e riprovare?

[paolo.oliva2]

Normale non è...come sono le temperature quando si verificano i cali ("throttling") della frequenza?

Se posso essere d'aiuto, come ti ha postato io guarderei le temp e se tutto nella norma disabilita se possibile da bios.

Comunque la cosa a me sembra che non dipenda dal procio, almeno sulla base del mio 8350, perchè è impossibile un throttling su un procio 125W TDP a TDP inferiore di 95W, per giunta a me lo faceva a 52°... disabilitato da bios e tutto a posto.

Edit:
Ho risposto senza aver letto la tua risposta... anche a te a 52°... guarda a caso.

[plainsong]

Di che mobo si tratta? Il bios è aggiornato?

[gyonny]

Se posso essere d'aiuto, come ti ha postato io guarderei le temp e se tutto nella norma disabilita se possibile da bios.

Comunque la cosa a me sembra che non dipenda dal procio, almeno sulla base del mio 8350, perchè è impossibile un throttling su un procio 125W TDP a TDP inferiore di 95W, per giunta a me lo faceva a 52°... disabilitato da bios e tutto a posto.

Grazie per il consiglio! Farò proprio questo e vi farò sapere.

[gyonny]

Di che mobo si tratta? Il bios è aggiornato?

Si il bios è aggiornato :)

Probabilmente il problema dipende dalla mia mobo di fascia bassa.
La Asrock N68C-GSFX è una scheda madre polifunzionale nel senso che è anche compatibile con ram DDR2 e addirittura processori Athlon x64.

Ma per quello che ci devo fare mi basta.

[DanieleRC5]

:fagiano: Sapevo che ci sarei caduto...... Le info sulle nuove cpu come al solito non sono ben chiare (giustamente...) ed il rispetto dei planning presentati al pubblico da Amd per un motivo o per l'altro vanno sempre a farsi friggere...... così ho ordinato sto benedetto FX-9590 :sofico:

[DanieleRC5]

Si il bios è aggiornato :)

Probabilmente il problema dipende dalla mia mobo di fascia bassa.
La Asrock N68C-GSFX è una scheda madre polifunzionale nel senso che è anche compatibile con ram DDR2 e addirittura processori Athlon x64.

Ma per quello che ci devo fare mi basta.

Probabilmente va in throttling quando, sotto elevato carico i mosfet si surriscaldano (anche perchè non hanno nemmeno un dissipatore sopra ).
Se piazzi una ventola che soffia sulla sezione di alimentazione della mainboard il problema si ripete?

[dobermann77]

così ho ordinato sto benedetto FX-9590 :sofico:

Complimenti per l'acquisto, facci sapere come va!

[gyonny]

Normale non è...come sono le temperature quando si verificano i cali ("throttling") della frequenza?

Se posso essere d'aiuto, come ti ha postato io guarderei le temp e se tutto nella norma disabilita se possibile da bios.

Comunque la cosa a me sembra che non dipenda dal procio, almeno sulla base del mio 8350, perchè è impossibile un throttling su un procio 125W TDP a TDP inferiore di 95W, per giunta a me lo faceva a 52°... disabilitato da bios e tutto a posto.

Edit:
Ho risposto senza aver letto la tua risposta... anche a te a 52°... guarda a caso.

Di che mobo si tratta? Il bios è aggiornato?

Ragazzi vi dico che ho risolto il problema disattivando il thermal throttling da bios, e ora non scendo più di frequenza :)

Ora le temperature mi sono arrivate a 58°C durante i primi minuti di stress test.

Provate a fare uno stress-test con LINX per AMD (http://www.mediafire.com/download/kna2w379ggxr7hz/LinX+%2811.0.1.005%29_Intel_AMD.rar) per testare la vostra stabilità (io personalmente consiglirei di iniziare questo test con CPU@Default)

[LurenZ87]

Posto una recensione, uno scontro diretto tra il futuro top di gamma di Intel, l'i7 4960x ed il top di gamma di AMD, l'FX-9590 :)

http://vr-zone.com/articles/ivy-bridge-e-i7-4960x-vs-amd-fx-9590-battle-2013-flagships/54295.html

buona lettura e non scatenate una guerra inutile, mi raccomando ;)

[plainsong]

Si il bios è aggiornato :)

Probabilmente il problema dipende dalla mia mobo di fascia bassa.
La Asrock N68C-GSFX è una scheda madre polifunzionale nel senso che è anche compatibile con ram DDR2 e addirittura processori Athlon x64.

Ma per quello che ci devo fare mi basta.

Effettivamente benchè sul sito Asrock l'N68C- GS FX venga definita come genericamente compatibile con "cpu 8-core", atre fonti la specificano limitata al supporto cpu con tdp di 95w. Magari un downvolt disabilitando il turbo e fissando la frequenza a 4.0 Ghz potrebbe risolvere il problema.

[gyonny]

Effettivamente benchè sul sito Asrock l'N68C- GS FX venga definita come genericamente compatibile con "cpu 8-core", atre fonti la specificano limitata al supporto cpu con tdp di 95w. Magari un downvolt disabilitando il turbo e fissando la frequenza a 4.0 Ghz potrebbe risolvere il problema.

Grazie per il consiglio :) Comunque con questa mobo sono limitato per overclock.

Se avrei intenzione di overcloccare a livelli più alti sarebbe opportuna una sostituzione della mobo con una di fascia più alta.

[DanieleRC5]

Posto una recensione, uno scontro diretto tra il futuro top di gamma di Intel, l'i7 4960x ed il top di gamma di AMD, l'FX-9590 :)

http://vr-zone.com/articles/ivy-bridge-e-i7-4960x-vs-amd-fx-9590-battle-2013-flagships/54295.html

buona lettura e non scatenate una guerra inutile, mi raccomando ;)

Già c'è un errore, non mi risulta proprio che il 9590 supporti le ddr3 2133, hanno scambiato i valori di frequernza ddr3 supportata.
Interessante il risultato in Maya del 9590.
Nei giochi a risoluzione 1080 o superiore la differenza è relativa ma in ogni caso la potenza del 4930 è davvero notevole :)
Tra l'altro scopro adesso dell'esistenza del "ROG Real Bench", provo a scaricarlo. :-O

[plainsong]

Grazie per il consiglio :) Comunque con questa mobo sono limitato per overclock.

Se avrei intenzione di overcloccare a livelli più alti sarebbe opportuna una sostituzione della mobo con una di fascia più alta.

Effettivamente trattandosi di un FX6300 (mi ero confuso credevo usassi un FX83xx) il tdp è già di 95w e pertanto almeno formalmente compatibile con la tua mb. Tenterei comunque un downvolt con ≤ 1.3v(con frequenze inizialmente conservative per garantire stabilità, successivamente da limare se il throttling è risolto)per vedere cosa succede e circoscrivere il problema.

[gyonny]

Probabilmente va in throttling quando, sotto elevato carico i mosfet si surriscaldano (anche perchè non hanno nemmeno un dissipatore sopra )...

Scusa se rispondo in ritardo, sicuramente anche questa è una cosa tenere in considerazione :)

[gyonny]

Effettivamente trattandosi di un FX6300 (mi ero confuso credevo usassi un FX83xx) il tdp è già di 95w e pertanto almeno formalmente compatibile con la tua mb. Tenterei comunque un downvolt con ≤ 1.3v(con frequenze inizialmente conservative per garantire stabilità, successivamente da limare se il throttling è risolto)per vedere cosa succede e circoscrivere il problema.

Il voltaggio che possiedo attualmente è quello dato di default 1.352V, quindi proverò ad andare indietro di uno step sulle impostazioni del bios, mi sembra che prima di questo valore ci sia un qualcosa tipo 1.280V, non ricordo bene, comunque proverò con questa operazione di downvolt tenendo la frequenza @Default e vedrò se risolvo il throttling...

[paolo.oliva2]

:fagiano: Sapevo che ci sarei caduto...... Le info sulle nuove cpu come al solito non sono ben chiare (giustamente...) ed il rispetto dei planning presentati al pubblico da Amd per un motivo o per l'altro vanno sempre a farsi friggere...... così ho ordinato sto benedetto FX-9590 :sofico:
OTTIMO.
Hai una CF V-z, penso che avrai prb nel funzionamento a def per il turbo +300MHz, perchè non so ora ma Asus non ha reso disponibile un aggiornamento bios per gli FX 9XXX, in OC nessun prb perchè tanto il turbo si disabilita :).
Se ti posso chiedere un favore, partendo dal presupposto che lo monteresti al posto dell'8350, puoi verificare la differenza di Vcore alle stesse frequenze? Magari con un bel OCCT anche per solo 2 minuti?
Anche io sto pensando ad un upgrade del mio 8350, un 9370 non è certamente esoso, ma 100€ in più se il 9590 garantisse Vcore inferiori non mi dispiacerebbe (tanto per non rimanere con il nodo alla gola).

[paolo.oliva2]

Posto una recensione, uno scontro diretto tra il futuro top di gamma di Intel, l'i7 4960x ed il top di gamma di AMD, l'FX-9590 :)

http://vr-zone.com/articles/ivy-bridge-e-i7-4960x-vs-amd-fx-9590-battle-2013-flagships/54295.html

buona lettura e non scatenate una guerra inutile, mi raccomando ;)

Avrei preferito una rece del 9590 con il 4930K, ma non dovrebbe cambiare di molto... comunque è già buono che il confronto lo si faccia con il 2011 più che con il 1155/1150 :D.
Io ho poco da commentare... non ho nulla in contrario nè vs il 9590 nè contro il 4960X... io guardo il 4960X in veste di 4930K, ma non reputo una pazzia l'acquisto di un 4960X, la pazzia vera era un 9590 a 800€ :doh:.

[gefri]

attualmente nel GPGPU, sia che si tratti di APU o di discrete, in alcuni software, come ad esempio alcuni motori di render, la scena o il dato, devono essere interamente caricati nella ram della VGA, perchè la GPU puo leggere solo la sua ram e deve avere disponibili tutti i dati; ( e comuque dara benefici anche nei software che non hanno questo limite, perchè comunque si risparmieranno una riscrittura del dato nella ram della VGA )
con hUMA e con la Unified Virtual Memory di nVidia, ci sara un "livello superiore" che creera una grossa memoria virtuale e la GPU riuscira ad accedere ai dati della ram di sistema, senza doverli copiare tutti nella sua ram, la vedra come "sua" ram, visto che potra accedervi direttamente;
sicuramente non sara veloce quanto la vram perchè si dovra passare dal PCI-EX, ma credo che in questo tipo di calcoli il collo di bottiglia sia comunque sempre la capacita di calcolo della GPU e non la ram, non credo che il PCI-EX sia piu di tanto limitante, anche perchè, il PCI-EX 3.0 ha aumentato la banda e ridotto la latenza.
Nel caso di nVidia la Unified Virtual Memory è il "cavallo di battaglia" di Maxwell, quindi dovremmo averla fra pochi mesi; nel caso di AMD la avremo con le APU anche lei fra pochi mesi e, non ho letto nulla in merito, ma non credo che tardera a proporla con le sue VGA discrete.

http://www.theinquirer.net/inquirer/news/2255921/nvidias-maxwell-gpu-architecture-will-access-system-ram

"However the firm's next generation Maxwell GPU architecture will allow the GPU to access main memory, reminiscent of AMD's unified memory architecture."

grazie mille,volevo comprare una 760 per octane ma avevo molta paura per il discorso ram, attendo maxwell!

[gyonny]

Il voltaggio che possiedo attualmente è quello dato di default 1.352V, quindi proverò ad andare indietro di uno step sulle impostazioni del bios, mi sembra che prima di questo valore ci sia un qualcosa tipo 1.280V, non ricordo bene, comunque proverò con questa operazione di downvolt tenendo la frequenza @Default e vedrò se risolvo il throttling...

Ho abbassato i voltaggi di default da 1.352V a 1.3V (che poi sotto stress scendono naturalmente a 1.280V - mi sembra che questo si chiami il fenomeno vdroop) e con frequenza @default mi matengo a 49/50°C sotto stress quindi non entro in thermal throttling. Il thermal throttling nel mio caso se attivato scatta a 52°C e io arrivo a 50°C, diciamo che sono in bilico sul filo del rasoio :D

[DanieleRC5]

OTTIMO.
Hai una CF V-z, penso che avrai prb nel funzionamento a def per il turbo +300MHz, perchè non so ora ma Asus non ha reso disponibile un aggiornamento bios per gli FX 9XXX, in OC nessun prb perchè tanto il turbo si disabilita :).
Se ti posso chiedere un favore, partendo dal presupposto che lo monteresti al posto dell'8350, puoi verificare la differenza di Vcore alle stesse frequenze? Magari con un bel OCCT anche per solo 2 minuti?
Anche io sto pensando ad un upgrade del mio 8350, un 9370 non è certamente esoso, ma 100€ in più se il 9590 garantisse Vcore inferiori non mi dispiacerebbe (tanto per non rimanere con il nodo alla gola).

No problem si puo' fare, se interessa anche qualche altro test, basta che definiamo prima cosa interessa.
Possiamo aprire un thread dedicato per parlarne!

Inviato dal mio GT-I9300 usando Tapatalk 4

[plainsong]

Ho abbassato i voltaggi di default da 1.352V a 1.3V (che poi sotto stress scendono naturalmente a 1.280V - mi sembra che questo si chiami il fenomeno vdroop) e con frequenza @default mi matengo a 49/50°C sotto stress quindi non entro in thermal throttling. Il thermal throttling nel mio caso se attivato scatta a 52°C e io arrivo a 50°C, diciamo che sono in bilico sul filo del rasoio :D

Beh ma se hai già appurato che il throttling delle frequenze è dovuto alle temperature e non al reparto alimentazione mobo puoi limitarti a disattivare la funzione di thermal throttling da bios (o a modificarne i parametri termici, bios permettendo) e goderti la cpu almeno a frequenze stock. 52°C mi sembra davvero un limite troppo conservativo per un FX Piledriver, nei tuoi panni mi accerterei semplicemente che con uno stress test la cpu non superi di molto i 60 °C.

[LurenZ87]

Ragazzi mi serve una mano, ieri sera ho smontato la piattaforma X79 ed ho installato la CVF-Z con l'FX-8350 però non riesco ad entrare nel bios, infatti non boota e mi da errore 50 (ram non riconosciute) e mi chiedevo (ho delle RipJaws X a 2133Mhz) se con il ROG Connect tramite l'upgrade del bios potevo risolvere, grazie.

Inviato dal mio Nexus 4 con Tapatalk 2

[DanieleRC5]

Dovresti poter fare l'upgrade del bios senza necessita' di fare il boot mettendo il bios su una chiavetta usb ma nin ricordo la procedura.
Se riesco do una occhiatina ma sono di corsa perche' devo andare al lavoro!

Inviato dal mio GT-I9300 usando Tapatalk 4

[capitan_crasy]

Asus annuncia il supporto alla serie FX-9000 sulle schede mamme Crosshair V Formula-Z, Sabertooth 990FX R2.0, M5A99FX Pro R2.0!

Clicca qui... (http://www.techpowerup.com/190059/asus-offers-full-support-for-amd-fx-9000-series-cpus-with-existing-990fx-boards.html)

[paolo.oliva2]

Ragazzi mi serve una mano, ieri sera ho smontato la piattaforma X79 ed ho installato la CVF-Z con l'FX-8350 però non riesco ad entrare nel bios, infatti non boota e mi da errore 50 (ram non riconosciute) e mi chiedevo (ho delle RipJaws X a 2133Mhz) se con il ROG Connect tramite l'upgrade del bios potevo risolvere, grazie.

Inviato dal mio Nexus 4 con Tapatalk 2
Anche io ho avuto dei problemi simili con la CF V-z. Penso che il problema sia nel Vcore richiesto dalle DDR3 alle varie frequenze, precisamente nel salto da 1,5V a 1,65V e dall'impostazione a 1866GHz, che magari viene impostata a 1,5V mentre le DDR3 richiederebbero un Vcore superiore.
A suo tempo avevo trovato il modo di bypassare l'errore mettendo un solo banco di DDR3 nel canale B (cosa che addirittura esclude ogni manuale), scavalcando l'errore 50 ed entrando nel bios bastava impostare 1,65V le DDR3 e 1,25V per l'NB (le mie DDR3 2,4GHz per un corretto funzionamento volevano l'MC a 1,25V almeno) oppure settando le a 1333 lasciando il resto invariato.
Fatto questo sposti il banco DDR3 nel canale A, e rifai il boot, oppure, saltando un passo, metti tutti i 2 banchi nel canale A e imposti Vcore DDR3/Vcore NB e frequenze a piacere.

[paolo.oliva2]

No problem si puo' fare, se interessa anche qualche altro test, basta che definiamo prima cosa interessa.
Possiamo aprire un thread dedicato per parlarne!
Inviato dal mio GT-I9300 usando Tapatalk 4
Da parte mia, ho dei problemi seri per un DU sostenuto per via delle temp ambiente elevate, ed un Vcore inferiore a quello di un 8350 aiuterebbe e non poco.
Delle rece mi fido poco, vuoi per la fretta, vuoi per inesperienza, vuoi per hardware inadatto, vuoi per bandiera, non è che sia difficile far apparire un 9590 tanto quanto un 8350 o decidere di quanto lo sia di più.
Quello che si trova in rete da appassionati è ancora peggio... potrebbero far passare un Vcore screen come RS... basterebbe un 2 minuti con OCCT ad una X frequenza con il Vcore minimo possibile e si risolverebbe ogni dubbio, anche se poi non sarebbe da escludere 9590 "fortunelli" ma ad una differenza di Vcore più o meno corposa, sicuramente si accompagnerebbe pure una selezione almeno minima.
Nell'OC massimo benchabile, non credo ci possano essere migliorie >100-200MHz, altrimenti in ambito internazionale, con un 9590 a 350€, si dovrebbe riscontrare un vero carosello di bench, quando era uscito l'8350 era tutto un susseguirsi di record... se non c'è lo stesso entusiasmo da gente di un certo livello, avranno fatto le loro valutazioni.
Insomma, a me basterebbe un Vcore ~1,4V e vedere dove si arriva con il 9590... l'8350 va da 4,4GHz a 4,5GHz, qualcuno arriverebbe anche a 4,6GHz/4,7GHz ma :ciapet: a randa... per me un 9590 che assicuri 1,4V/4,7GHz sarebbe già soddisfacente per 350€... altrimenti opterei per un 9370.

[gyonny]

Beh ma se hai già appurato che il throttling delle frequenze è dovuto alle temperature e non al reparto alimentazione mobo puoi limitarti a disattivare la funzione di thermal throttling da bios (o a modificarne i parametri termici, bios permettendo) e goderti la cpu almeno a frequenze stock. 52°C mi sembra davvero un limite troppo conservativo per un FX Piledriver, nei tuoi panni mi accerterei semplicemente che con uno stress test la cpu non superi di molto i 60 °C.

Quello in realtà, siccome avevo fretta era stato un test veloce di 5min circa (con CPU thermal throttling disattivato).
Ho rifatto il test per benino, e dopo mezz'ora circa sono arrivato a 60°C con CPU@Default (3516Mhz) 1.3V e dissipatore a torre con ventola da120mm (montato bene e con un'ottima pasta termica) :eek:!!
Premetto anche che le impostazioni del bios sono tutte alle impostazioni di fabbrica, ho solamente disattivato 2 opzioni, Turbo Frequency e CPU Thermal Throttling.

Perchè tutto questo surriscaldamento di questa CPU? O forse questo mio FX-6300 in realtà fa parte di una partita poco fortunata?

[LurenZ87]

Dovresti poter fare l'upgrade del bios senza necessita' di fare il boot mettendo il bios su una chiavetta usb ma nin ricordo la procedura.
Se riesco do una occhiatina ma sono di corsa perche' devo andare al lavoro!

Inviato dal mio GT-I9300 usando Tapatalk 4

Anche io ho avuto dei problemi simili con la CF V-z. Penso che il problema sia nel Vcore richiesto dalle DDR3 alle varie frequenze, precisamente nel salto da 1,5V a 1,65V e dall'impostazione a 1866GHz, che magari viene impostata a 1,5V mentre le DDR3 richiederebbero un Vcore superiore.
A suo tempo avevo trovato il modo di bypassare l'errore mettendo un solo banco di DDR3 nel canale B (cosa che addirittura esclude ogni manuale), scavalcando l'errore 50 ed entrando nel bios bastava impostare 1,65V le DDR3 e 1,25V per l'NB (le mie DDR3 2,4GHz per un corretto funzionamento volevano l'MC a 1,25V almeno) oppure settando le a 1333 lasciando il resto invariato.
Fatto questo sposti il banco DDR3 nel canale A, e rifai il boot, oppure, saltando un passo, metti tutti i 2 banchi nel canale A e imposti Vcore DDR3/Vcore NB e frequenze a piacere.

Grazie ragazzi :), proverò entrambe le soluzioni sperando di risolvere senza problemi...

Inviato dal mio Nexus 4 con Tapatalk 2

[plainsong]

Quello in realtà, siccome avevo fretta era stato un test veloce di 5min circa (con CPU thermal throttling disattivato).
Ho rifatto il test per benino, e dopo mezz'ora circa sono arrivato a 60°C con CPU@Default (3516Mhz) 1.3V e dissipatore a torre con ventola da120mm (montato bene e con un'ottima pasta termica) :eek:!!
Premetto anche che le impostazioni del bios sono tutte alle impostazioni di fabbrica, ho solamente disattivato 2 opzioni, Turbo Frequency e CPU Thermal Throttling.

Perchè tutto questo surriscaldamento di questa CPU? O forse questo mio FX-6300 in realtà fa parte di una partita poco fortunata?

Visto il voltaggio e la frequenza quelle temperature sono un pò troppo alte. Che dissipatore stai usando? Il case è ben ventilato?

[gyonny]

Visto il voltaggio e la frequenza quelle temperature sono un pò troppo alte. Che dissipatore stai usando? Il case è ben ventilato?

Il dissipatore è uno Xigmatek HDT S1283 e il case (un CM 690II) possiede 2 ventole, tra l'altro non ci sono nemmeno cavi disordinati che intralciano i flussi d'aria.

Premetto anche che in questi ultimi giorni nella mia zona sta facendo molto caldo, e la temperatura ambientale è di 30°C circa.
Questi problemi si sono presentati d'estate mentre in inverno non c'erano di questi problemi di surriscaldamento della CPU.

Proverò a smontare il dissipatore e stendere la pasta termica con maggiore cura, ma se non risolvo a questo punto mi ci vorrà un dissipatore più performante :)

[winebar]

Fanciulli mi è arrivato l'8320. :P
Ho solo avuto il tempo di montarlo prima di uscire per venire al lavoro, appena torno lo stresso per bene. :D

Giusto per sapere, il BIOS appena ho provato ad avviare mi ha dato un errore sul USB overcurrent, che causa uno shutdown automatico entro 15 secondi. Anche senza periferiche USB (e non) collegate. Dite che magari il BIOS tiene in memoria delle cose relative al vecchio 955? Un CMOS reset dovrebbe bastare vero?


PS: come da manuale, con la fortuna che mi ritrovo, mentre mettevo via il 955 mi è caduto e ha fatto una brutta fine. Per la precisione si sono stortati una 40ina di di pin. Addio alla vendita. :(

Inviato dal mio GT-I9000 con Tapatalk 4

[MaRtH]

Fanciulli mi è arrivato l'8320. :P
Ho solo avuto il tempo di montarlo prima di uscire per venire al lavoro, appena torno lo stresso per bene. :D

Giusto per sapere, il BIOS appena ho provato ad avviare mi ha dato un errore sul USB overcurrent, che causa uno shutdown automatico entro 15 secondi. Anche senza periferiche USB (e non) collegate. Dite che magari il BIOS tiene in memoria delle cose relative al vecchio 955? Un CMOS reset dovrebbe bastare vero?


PS: come da manuale, con la fortuna che mi ritrovo, mentre mettevo via il 955 mi è caduto e ha fatto una brutta fine. Per la precisione si sono stortati una 40ina di di pin. Addio alla vendita. :(

Inviato dal mio GT-I9000 con Tapatalk 4

Mi disp, sfiga veramente :(, comunque diciamo che clear cmos + update bios all'ultimo ufficiale e sei a posto...

[isomen]

Fanciulli mi è arrivato l'8320. :P
Ho solo avuto il tempo di montarlo prima di uscire per venire al lavoro, appena torno lo stresso per bene. :D

Giusto per sapere, il BIOS appena ho provato ad avviare mi ha dato un errore sul USB overcurrent, che causa uno shutdown automatico entro 15 secondi. Anche senza periferiche USB (e non) collegate. Dite che magari il BIOS tiene in memoria delle cose relative al vecchio 955? Un CMOS reset dovrebbe bastare vero?


PS: come da manuale, con la fortuna che mi ritrovo, mentre mettevo via il 955 mi è caduto e ha fatto una brutta fine. Per la precisione si sono stortati una 40ina di di pin. Addio alla vendita. :(

Inviato dal mio GT-I9000 con Tapatalk 4

Ti auguro di risolvere, io ho 2 mobo am2 identiche con questo problema e nn sono mai riuscito a risolverlo... però a volte partono e funzionano correttamente :boh:

PS
con uno spillo e... tanta pazienza puoi farlo tornare come nuovo, dopo aver tirato su quelli più piegati allinei una fila per volta con la lama di un coltello

;) ciauz

[Sgogetal4]

Ragazzi mi serve una mano, ieri sera ho smontato la piattaforma X79 ed ho installato la CVF-Z con l'FX-8350 però non riesco ad entrare nel bios, infatti non boota e mi da errore 50 (ram non riconosciute) e mi chiedevo (ho delle RipJaws X a 2133Mhz) se con il ROG Connect tramite l'upgrade del bios potevo risolvere, grazie.

Inviato dal mio Nexus 4 con Tapatalk 2

Anch'io monto le ripjaws x a 2133 sulla saber. PRima di accendere il pc ho caricato tramite il portatile l'ultimo bios disponibile della scheda su una chiavetta usb (non ricordo se formattata in fat 32) l'ho inserita nella porta usb contornata di bianco sotto al tasto per bios flashback e poi smepre da pc spento ho premuto il tasto per tre secondi ho aspettato che il tastino finisse di lampeggiare che segnala la fine del processo di update del bios e ho fatto partire il pc. Le ram non le rilevava 2133 ma a frequenza base mi pare 1333 ho modificato tutti i parametri compresi timing e voltaggio e funzionano perfettamente a 2133 con 1,65 e timing certificati g.skill. Quindi se funzionano sulla saber penso proprio che smanettando devono funzionare anche sulla cvf-z.

[winebar]

Problema, risolto! [Cit. Chicco d'Oliva]

la Saber 990FX è salva (e intanto si avvicina a quasi 2 anni di onorato servizio).

Ti auguro di risolvere, io ho 2 mobo am2 identiche con questo problema e nn sono mai riuscito a risolverlo... però a volte partono e funzionano correttamente :boh:

Guarda, a me il problema si è risolto trovando la vite che interrompeva il circuito. In pratica lo standoff non era ben avvitato alla mono e quindi dava problemi. :(


con uno spillo e... tanta pazienza puoi farlo tornare come nuovo, dopo aver tirato su quelli più piegati allinei una fila per volta con la lama di un coltello

Si lo so, ma non lo venderei mai. Al massimo se riesco a recuperare una mobo AM3+ (magari microATX) riesco a farci un HTPC a scopo temporaneo e aspettare direttmanete APU Excavator (volevo farlo con una APU steamroller).

Fine OT.

Sto finendo di installare Windows 8 e poi passo a stressarlo per bene. :D

Inviato dal mio GT-I9000 con Tapatalk 4

[LurenZ87]

Anch'io monto le ripjaws x a 2133 sulla saber. PRima di accendere il pc ho caricato tramite il portatile l'ultimo bios disponibile della scheda su una chiavetta usb (non ricordo se formattata in fat 32) l'ho inserita nella porta usb contornata di bianco sotto al tasto per bios flashback e poi smepre da pc spento ho premuto il tasto per tre secondi ho aspettato che il tastino finisse di lampeggiare che segnala la fine del processo di update del bios e ho fatto partire il pc. Le ram non le rilevava 2133 ma a frequenza base mi pare 1333 ho modificato tutti i parametri compresi timing e voltaggio e funzionano perfettamente a 2133 con 1,65 e timing certificati g.skill. Quindi se funzionano sulla saber penso proprio che smanettando devono funzionare anche sulla cvf-z.

Ciao, ho risolto non con l'ultimo bios ma tramite il metodo di paolo, ossia mettendo un solo banchetto di ram (ne ho 4x4Gb) nello slot b2 (l'ultimo in sostanza) e facendolo avviare... Alla fine le ha riconosciute e settate a 1600Mhz a 1,5v, adesso sto installando tutto e lo lascio così, poi devo reinserire i parametri dei timing e dei volts, oltre a spremere come un limone la cpu :asd:.

Inviato dal mio Nexus 4 con Tapatalk 2

[paolo.oliva2]

Ciao, ho risolto non con l'ultimo bios ma tramite il metodo di paolo, ossia mettendo un solo banchetto di ram (ne ho 4x4Gb) nello slot b2 (l'ultimo in sostanza) e facendolo avviare... Alla fine le ha riconosciute e settate a 1600Mhz a 1,5v, adesso sto installando tutto e lo lascio così, poi devo reinserire i parametri dei timing e dei volts, oltre a spremere come un limone la cpu :asd:.
Inviato dal mio Nexus 4 con Tapatalk 2
Perfetto, felice di esserti stato d'aiuto.

[LurenZ87]

Perfetto, felice di esserti stato d'aiuto.

Grazie ancora :)

Una domanda, ma a voi core temp vi vede la cpu come un esacore??? :stordita:

PS: ho fatto partire cinebench ed effettivamente la cpu mi risulta come un esacore, tant'è che ha fatto solamente 5,11... Che balle...

Inviato dal mio Nexus 4 con Tapatalk 2

[DanieleRC5]

Eh no a me la vede correttamente come 8 core!
Da bios risulta tutto ok?

Inviato dal mio GT-I9300 usando Tapatalk 4

[LurenZ87]

Eh no a me la vede correttamente come 8 core!
Da bios risulta tutto ok?

Inviato dal mio GT-I9300 usando Tapatalk 4

Il bios sta settato tutto a default tranne le ram, la cosa strana è che sia core temp che cinebench mi vedono la cpu come un esacore, mentre dal AI Suite di Asus me la vede come un octacore... Dio che nervi, non capisco per quale motivo si comporti così...

Inviato dal mio Nexus 4 con Tapatalk 2

[vincenzo2008]

Il bios sta settato tutto a default tranne le ram, la cosa strana è che sia core temp che cinebench mi vedono la cpu come un esacore, mentre dal AI Suite di Asus me la vede come un octacore... Dio che nervi, non capisco per quale motivo si comporti così...

Inviato dal mio Nexus 4 con Tapatalk 2

nel task manager o in cpu z come ti compare ?

[paolo.oliva2]

nel task manager o in cpu z come ti compare ?
Quoto.
Comunque buffo... non è che per caso hai caricato l'ultimo bios quello per gli FX 9XXX che forse con l'8350 ha prb?
Cinebench puoi ovviare assegnandogli 8TH, poi magari dal risultato vedresti se sono su 8 core fisici... :)... idem provare AOD di AMD... giusto per contro-test.

[winebar]

Grazie ancora :)

Una domanda, ma a voi core temp vi vede la cpu come un esacore??? :stordita:

PS: ho fatto partire cinebench ed effettivamente la cpu mi risulta come un esacore, tant'è che ha fatto solamente 5,11... Che balle...

Giusto per sapere, hai formattato Windows?
Da me Windows 8 quando ho montato l'8320 me lo ha visto come un processore a 8 core con 2 core e 8 thread, e infatti a Cinebench ha fatto uno scempio che non hai idea (roba tipo 2,6) e CB sfruttava solo 4 core.
Appena ho formattato i risultati sono tornati in linea (6.08 con un 8320 stock).

[LurenZ87]

Ieri notte ho lasciato il pc acceso per fargli fare qualche aggiornamento... Stamattina lo controllo ed i core si sono moltiplicati :asd:...

Misteri della fede...

Inviato dal mio Nexus 4 con Tapatalk 2

[gyonny]

Probabilmente va in throttling quando, sotto elevato carico i mosfet si surriscaldano (anche perchè non hanno nemmeno un dissipatore sopra ).
Se piazzi una ventola che soffia sulla sezione di alimentazione della mainboard il problema si ripete?

Come promesso prima ho tenuto seriamente in considerazione questo tuo ottimo suggerimento:

Dopo aver eseguito ripetuti test sembrerebbe che il mio FX-6300 sia a posto, e il surriscaldamento di cui parlavo nei post precedenti dipendeva in buona parte dalla elevata temperatura ambientale di 30°C durante il pomeriggio (abito in Sicilia), infatti ho rieseguito il test di notte con temperature ambientali più basse e ho ottenuto 57°C dopo un'ora circa di Prime95.
Dopo un'ora e mezza di Prime95, con temperatura CPU di 57°C si era presentato lo spegnimento automatico del computer:( e credo proprio che ha questo punto lo spegnimento automatico fosse dovuto ad un surriscaldamento dei mofset della mobo.

Con questi programmi di stress-test vengono fuori man mano tutti i difetti di un computer, e nel mio caso è successo proprio ciò che speravo non succedesse: questa mobo di fascia bassa non è particolarmente indicata per contenere un FX-6300, quindi è richiesto aggiornamento hardware :(

***** *****

A questo punto mi viene istintivo pensare: ma se con un dissipatore a torre che monta ventola da 120mm riesco a malapena a tenere a bada sto FX-6300, che succedeva allora se montavo quel ridicolo giocattolino del dissipatore stock fornito nella confezione della CPU? :mbe:

[paolo.oliva2]

@Per quelli che hanno mobo con il supporto agli FX 9XXX.

In passato avevo fatto delle prove per vedere come si poteva far convivere l'OC conservando la funzione degli stati turbo.
Come ho postato più volte, le temp del procio dipendono dal carico, e tra funzionamento al 100% con 1 programma e sempre al 100% con più programmi contemporaneamente, variano.
Ad esempio, il mio 8350 l'avevo a 4,4-4,5GHz stracaricato ma 4,6GHz caricato normalmente e probabilmente anche 4,7GHz nei giochi, ma ovviamente l'ho dovuto settare in base al carico maggiore e quindi 4,4/4,5GHz

In pratica con i bios per gli FX 9XXX, si potrebbe/dovrebbe far lavorare un 8350 come se fosse un 9370/9590, e sfruttando che il turbo entrerebbe in funzione in base alle temp, nella mia condizione dovrei arrivare alla situazione di un 8350 a 4,4/4,5GHz con una escursione fino a 4,7/4,8GHz (+300MHz) in base al carico, ovviando ad un OC fisso più basso a seconda del carico.

Dal punto di vista hardware, un 8350 ed un 9370/9590 sono identici, quindi il bios dovrebbe essere interscambiabile (sempre se il bios non escluda il funzionamento se il procio non venisse riconosciuto come 9XXX).
Altro punto... potrebbe essere un valore di Vcore per lo stato turbo non modificabile, ma anche qui sarebbe da vedere, perchè AOD permette qualsiasi modifica dove il bios non arriva.

Il tutto lo dico per 2 motivi... il 1° per far funzionare meglio un 8350, il 2° perchè il funzionamento turbo "diverso" potrebbe essere valido unicamente con i 9XXX e non 8XXX, quindi un 9370 potrebbe realmente offrire una condizione di utilizzo molto migliore che varrebbe i 70€ in più rispetto all'8350.
Inoltre qualsiasi cosa possa impedire il bios, un 9370 con bus a 235MHz anzichè 200MHz copierebbe in pieno il funzionamento di un 9590 con un 9370, ammesso e concesso che i Vcore siano simili... e qui mi verrebbe da pensare che un procio selezionato come 8350, cioè con Vcore 1,38V def e 1,415V/1,425V per un turbo di 100-200MHz applichi un +0,035V... senza testare se poi per 50MHz in più richieda un botto in più di Vcore, cosa assolutamente diversa negli FX 9XXX in cui la differenza deve supportare +300MHz (quindi un Vcore più lineare) ed a frequenze dove un 8350 può comunque presentare picchi.

Per chiarire meglio... l'8350 prevederebbe 3 stati distinti di Turbo:
4GHz def X8 -->4,1GHz X8 -->4,2GHz X4.
Il 9350 parte da 4,4GHz def, il 9590 da 4,7GHz def, ma entrambi hanno un turbo su tutti e 8 i core e di +300MHz.
Quindi un 8350 (impostandolo come se fosse un 9XXX), in OC lo si dovrebbe impostare ad una frequenza "base" che non sia superiore alla massima DU, ma con un margine di 300MHz turbo sfruttabile a seconda del margine temp istantaneo del procio... ciò vorrebbe dire che un OC-DU non sarebbe fisso ad una frequenza, ma a quella frequenza ed un range di +300MHz sfruttabile a seconda dei casi... nel mio esempio 4,5GHz stracaricato ma fino a 4,8GHz possibilissimi nei giochi.

[paolo.oliva2]

Come promesso prima ho tenuto seriamente in considerazione questo tuo ottimo suggerimento:

Dopo aver eseguito ripetuti test sembrerebbe che il mio FX-6300 sia a posto, e il surriscaldamento di cui parlavo nei post precedenti dipendeva in buona parte dalla elevata temperatura ambientale di 30°C durante il pomeriggio (abito in Sicilia), infatti ho rieseguito il test di notte con temperature ambientali più basse e ho ottenuto 57°C dopo un'ora circa di Prime95.
Dopo un'ora e mezza di Prime95, con temperatura CPU di 57°C si era presentato lo spegnimento automatico del computer:( e credo proprio che ha questo punto lo spegnimento automatico fosse dovuto ad un surriscaldamento dei mofset della mobo.

Con questi programmi di stress-test vengono fuori man mano tutti i difetti di un computer, e nel mio caso è successo proprio ciò che speravo non succedesse: questa mobo di fascia bassa non è particolarmente indicata per contenere un FX-6300, quindi è richiesto aggiornamento hardware :(

***** *****

A questo punto mi viene istintivo pensare: ma se con un dissipatore a torre che monta ventola da 120mm riesco a malapena a tenere a bada sto FX-6300, che succedeva allora se montavo quel ridicolo giocattolino del dissipatore stock fornito nella confezione della CPU? :mbe:
Ti riesco a capire perfettamente... penso che i dissi stock di tutte le case permettano il funzionamento garantito a patto di temperature ambientali entro certi limiti.
Del resto io sono passato da una condizione di 8350@4,6GHz 1,450V con temp massime <50° (presso Rimini, Italia) a 8350@4,5GHz 1,425V con >60° all'equatore... ed un 8150 portato a 3,4GHz (da 3,6GHz) con undervolt e dissi stock.

Il lato positivo, è che i test OC massimi fatti con l'8350 all'uscita erano con temp ambiente invernali, e il confronto con l'OC dei 9XXX li stiamo facendo con temp estive... mi pare evidente che questa situazione penalizzerebbe i 9XXX almeno di 100-200MHz in DU rispetto a quello che potrebbero fare tra 1-2 mesi.

[f_tallillo]

Ciao a tutti, volevo fare una domanda, montando una CPU AMD FX-6300 (Vishera-Piledriver) su una mobo gigabyte GA-78LMT-USB3 socket AM3+ chipset AMD 760G devo montare anche la scheda video dedicata o funziona quella integrata?

Grazie infinite per la disponibilità e buona giornata.

Francesco.

[gyonny]

Ti riesco a capire perfettamente... penso che i dissi stock di tutte le case permettano il funzionamento garantito a patto di temperature ambientali entro certi limiti.
Del resto io sono passato da una condizione di 8350@4,6GHz 1,450V con temp massime <50° (presso Rimini, Italia) a 8350@4,5GHz 1,425V con >60° all'equatore... ed un 8150 portato a 3,4GHz (da 3,6GHz) con undervolt e dissi stock.

Il lato positivo, è che i test OC massimi fatti con l'8350 all'uscita erano con temp ambiente invernali, e il confronto con l'OC dei 9XXX li stiamo facendo con temp estive...mi pare evidente che questa situazione penalizzerebbe i 9XXX almeno di 100-200MHz in DU rispetto a quello che potrebbero fare tra 1-2 mesi.

Grazie per l'ottimo chiarimento ;)

[gyonny]

Ciao a tutti, volevo fare una domanda, montando una CPU AMD FX-6300 (Vishera-Piledriver) su una mobo gigabyte GA-78LMT-USB3 socket AM3+ chipset AMD 760G devo montare anche la scheda video dedicata o funziona quella integrata?...

Posso dirti solamente che quando acquistai la mia Asrock N68C-GS-FX ero ancora privo della mia attuale scheda video dedicata e quindi come soluzione temporanea usavo la vecchia scheda grafica dedicata che poi mi ero venduto, ma prima di togliere la vecchia scheda grafica avevo prima di tutto modificato un parametro dal bios per far funzionare poi la grafica integrata > "Primary VideoAdapter = Onboard" e quindi collegato il relativo connettore VGA del monitor sull'interfaccia VGA della scheda madre.
La modesta grafica integrata "NVIDIA GeForce 7025" (che si mangiava 250MB di ram) della mia Asrock funzionava perfettamente con il mio FX-6300, quindi molto probabilmente lo stesso discorso varrà anche per la tua Gigabyte che monta grafica integrata ATI Radeon HD 3000.

[paolo.oliva2]

@gyonny.
Ma il 6300 l'hai montato sulla N68C-GS-FX?
Perchè anche io ho quella mobo con sopra l'8350... ma non supporta proci >95W TDP (per il discorso di abbassamento frequenze).

Io riesco a far funzionare l'8350 a 3,2GHz 1,2V X8 e come X4 (con 1 core disabilitato a modulo) sui 3,8GHz (entrambi testati con OCCT) e con il dissi standard, stando sotto i 95W TDP, perchè altrimenti la mobo va in crisi...

[isomen]

Ciao a tutti, volevo fare una domanda, montando una CPU AMD FX-6300 (Vishera-Piledriver) su una mobo gigabyte GA-78LMT-USB3 socket AM3+ chipset AMD 760G devo montare anche la scheda video dedicata o funziona quella integrata?

Grazie infinite per la disponibilità e buona giornata.

Francesco.

Certo che l'integrata funziona, fa quello che può (come la mobo)... ma funziona.

;) ciauz

[LurenZ87]

primo giretto con questo FX-8350... tralasciando le varie impostazioni della mobo che non sto quì a riportare, ho impostato 1,50v e 5000Mhz, su Cinebench ho ottenuto 8,46 punti, dovrei essere in linea :)

[isomen]

primo giretto con questo FX-8350... tralasciando le varie impostazioni della mobo che non sto quì a riportare, ho impostato 1,50v e 5000Mhz, su Cinebench ho ottenuto 8,46 punti, dovrei essere in linea :)

Niente male per essere il primo giro :cool:

@ te e a chiunque voglia darmi un'opinione:

ho quasi deciso di prendere un 9370... ma nessuna delle mie mobo lo supporta, sabertooth 990FX rev1, GA-990FXA-UD3 rev. 1.2, 990FXA-GD65, 970 Extreme4 (questa nn é neanche da considerare)... riuscirò a farlo funzionare degnamente (compreso l'oc) o dovrò acquistarne un'altra :confused:
in questo momento spendere per entrambi sarebbe sopra le mie possibilità :mc:

;) ciauz

[Nforce Ultra]

Ciao Iso,
secondo me la sabertooth lo gestirebbe senza nessun problema, alla fine è solo un 8350 oc

[LurenZ87]

Niente male per essere il primo giro :cool:

@ te e a chiunque voglia darmi un'opinione:

ho quasi deciso di prendere un 9370... ma nessuna delle mie mobo lo supporta, sabertooth 990FX rev1, GA-990FXA-UD3 rev. 1.2, 990FXA-GD65, 970 Extreme4 (questa nn é neanche da considerare)... riuscirò a farlo funzionare degnamente (compreso l'oc) o dovrò acquistarne un'altra :confused:
in questo momento spendere per entrambi sarebbe sopra le mie possibilità :mc:

;) ciauz

Ho provato 5,2Ghz a 1,55v, boota e tutto ma con Cinebench dopo un pò crasha :asd:... Forse farò altre prove, ma siccome devo foldarci credo che dovrò impostare sui 4,8Ghz se non meno per via delle temperature (max erano 65°C giusto???).

Se fossi in te non li spenderei quei soldi senza una mobo adeguata, poi a te la scelta...

Inviato dal mio Nexus 4 con Tapatalk 2