AMD A10-7800: la APU Kaveri a basso consumo

[manga81]

Per portatili?

[tuttodigitale]

Originariamente inviato da Pat77

Perchè HSA dovrebbe lavorare in alleanza con la CPU e superare la separazione di compiti. Quindi quanto sia efficiente questo approccio lo trovo veramente interessante.

Qui ti sbagli.
Oggi, con i benchmark odierni, non viene sfruttato HSA.
Il software è ignaro del fatto che lo spazio degli indirizzi tra gpu e cpu sia unificato. Quindi la gpu chiederà sempre un inizializzazione delle variabili, inutile perchè la gpu è in grado di prelevare il dato così come elaborato dalla cpu oltre ad essere molto dispendiosa sul piano computazionale.
HSA, richiede la riscrittura del codice sorgente, solo per non fare inutili copia di variabili. Ma attenzione proprio in virtù della drastica riduzione dell'overhead, è possibile implementare algoritmi, diversi, che se su un apu kaveri possono risultare efficaci su una cpu e una gpu discreta (o un apu con il tradizionale approccio nUMA) possono compromettere in maniera grave le prestazioni.

[Pat77]

Originariamente inviato da tuttodigitale

Qui ti sbagli.
Oggi, con i benchmark odierni, non viene sfruttato HSA.
Il software è ignaro del fatto che lo spazio degli indirizzi tra gpu e cpu sia unificato. Quindi la gpu chiederà sempre un inizializzazione delle variabili, inutile perchè la gpu è in grado di prelevare il dato così come elaborato dalla cpu oltre ad essere molto dispendiosa sul piano computazionale.
HSA, richiede la riscrittura del codice sorgente, solo per non fare inutili copia di variabili. Ma attenzione proprio in virtù della drastica riduzione dell'overhead, è possibile implementare algoritmi, diversi, che se su un apu kaveri possono risultare efficaci su una cpu e una gpu discreta (o un apu con il tradizionale approccio nUMA) possono compromettere in maniera grave le prestazioni.

Grazie della risposta, molto interessante.
Quindi in pratica mi stai dicendo che con una compilazione per uno schema cpu-gpu non si sfrutta hsa, mentre se si sfrutta hsa si hanno gravi ripercussioni in fatto di performance su un tradizionale schema cpu-gpu.
Andiamo bene, ma quale delle due modalita' alla fine e' piu' performante? Questo e' il punto focale.

[tuttodigitale]

Originariamente inviato da Pat77

Grazie della risposta, molto interessante.
Quindi in pratica mi stai dicendo che con una compilazione per uno schema cpu-gpu non si sfrutta hsa, mentre se si sfrutta hsa si hanno gravi ripercussioni in fatto di performance su un tradizionale schema cpu-gpu.
Andiamo bene, ma quale delle due modalita' alla fine e' piu' performante? Questo e' il punto focale.

Non proprio.
il codice che sfrutta HSA può girare solo su apu hsa-capable.
Un 'apu HSA può fa girare software in cui le gpu e cpu sono trattate come unità distanti, anche se questo approccio abbatte le prestazioni.
E questo avviene con praticamente tutti i software esistenti.
A parità di potenza l'approccio migliore è quello HSA. Il programmatore con gpu discreta deve usare un numero maggiore di variabili, la cui inizializzazione ha un costo, sia in termini di tempo che di spazio. Quando la gpu (cpu) chiede un dato (o un insieme di dati) utilizzati in precedenza dalla cpu(gpu), deve inizializzare e/o copiare il contenuto informativo. In questo frangente la cpu(gpu) deve attendere la gpu(cpu), operazione molto dispendiosa anche per la relativa lentezza della gpu.
L'ottimizzazione del software con HSA viene sgravato in parte sul compilatore.
Sul guadagno prestazionale, AMD parla di un 5x, ma è un valore che da solo non dice niente, in virtù del fatto i software non sono tutti uguali. C'è calc dove l'apu migliora di 7x rispetto a cpu e gpu discrete (in realtà si tratta dello stesso kaveri con software non ottimizzato).
Le premesse per una RIVOLUZIONE ci sono tutte compreso l'utilizzo di HSA per accelerare la fisica nei giochi. Purtroppo manca il software e in questo momento investire in kaveri solo per HSA non ha senso.

Le gpu discrete d'altro canto possono contare su una potenza maggiore, ma un approccio tipo HSA, è comunque il benvenuto poichè le cpu comunque sono importantissime al fine della prestazione.
E comunque nessuno vieta di fare un silicio dove la gpu fa la parte da leone (vedi le console), anche se secondo me, si dovrebbe usare il socket e i relativi collegamenti QPI e Hypertrasport, in teoria di gran lunga più efficaci del pci express. In poche parole fare quello che sta facendo Intel.

[devilred]

evvaiiiiiiiiii!! adesso con i kadaveri amd cambiera' rotta, si! affonda una volta per tutte.

[maxmax80]

ottimo il contenimento dei consumi a questo giro!!

finalmente direi che per il mio prossimi ITX daily (con un po' di PP fotografica) posso passare ad AMD

[Pat77]

Originariamente inviato da tuttodigitale

Non proprio.
il codice che sfrutta HSA può girare solo su apu hsa-capable.
Un 'apu HSA può fa girare software in cui le gpu e cpu sono trattate come unità distanti, anche se questo approccio abbatte le prestazioni.
E questo avviene con praticamente tutti i software esistenti.
A parità di potenza l'approccio migliore è quello HSA. Il programmatore con gpu discreta deve usare un numero maggiore di variabili, la cui inizializzazione ha un costo, sia in termini di tempo che di spazio. Quando la gpu (cpu) chiede un dato (o un insieme di dati) utilizzati in precedenza dalla cpu(gpu), deve inizializzare e/o copiare il contenuto informativo. In questo frangente la cpu(gpu) deve attendere la gpu(cpu), operazione molto dispendiosa anche per la relativa lentezza della gpu.
L'ottimizzazione del software con HSA viene sgravato in parte sul compilatore.
Sul guadagno prestazionale, AMD parla di un 5x, ma è un valore che da solo non dice niente, in virtù del fatto i software non sono tutti uguali. C'è calc dove l'apu migliora di 7x rispetto a cpu e gpu discrete (in realtà si tratta dello stesso kaveri con software non ottimizzato).
Le premesse per una RIVOLUZIONE ci sono tutte compreso l'utilizzo di HSA per accelerare la fisica nei giochi. Purtroppo manca il software e in questo momento investire in kaveri solo per HSA non ha senso.

Le gpu discrete d'altro canto possono contare su una potenza maggiore, ma un approccio tipo HSA, è comunque il benvenuto poichè le cpu comunque sono importantissime al fine della prestazione.
E comunque nessuno vieta di fare un silicio dove la gpu fa la parte da leone (vedi le console), anche se secondo me, si dovrebbe usare il socket e i relativi collegamenti QPI e Hypertrasport, in teoria di gran lunga più efficaci del pci express. In poche parole fare quello che sta facendo Intel.

Appunto cerco evidenza reale che vi siano vantaggi tangibili a usare questo approccio, un software che presenti supporto sia per cpu+gpu e HSA credo che prima o poi uscira' e si capira' meglio.
Alle rivoluzioni del 5-7x non credo sinceramente.

[Pier2204]

Originariamente inviato da carlottoIIx6

la foto all'ultima paggina dice tutto
http://www.hwupgrade.it/articoli/cpu...a_mini_itx.jpg

Ecco, quella è una cosa molto interessante. Ci stavo pensando da un po per sostituire il mio "cassone" in qualcosa che può stare anche sulla scrivania o in un angolo sotto.

[tuttodigitale]

Originariamente inviato da Pat77

Appunto cerco evidenza reale che vi siano vantaggi tangibili a usare questo approccio, un software che presenti supporto sia per cpu+gpu e HSA credo che prima o poi uscira' e si capira' meglio.
Alle rivoluzioni del 5-7xnon credo sinceramente.

in realtà la vera rivoluzione è che si passerà da circa 200 applicazioni che traggono beneficio della gpu ad oltre 100.000, proprio in virtù dell'azzeramento del costo copia, che rende conveniente anche indirizzare piccoli lavori alla gpu.
Moltissimi software oggi, non hanno la possibilità di usare l'accelerazione gpu, perché significherebbe abbassare le prestazioni.
Quindi nel prossimo futuro il 99,9% dei confronti si potranno fare solo cpu vs hsa, sapendo che la cpu da sola va più forte di un approccio ibrido tradizionale.
E' proprio questo fatto che ha spinto il mondo mobile a creare HSA foundation. AMD, dopo i mila miliardi spesi per l'acquisto di ATI e di GCN, che considero oggi la miglior architettura, ha solo da guadagnarci.

[Sghizz]

AMD Kadaveri... Troppo lenta

[Vash_85]

Originariamente inviato da gridracedriver

certo che siete tutti cosi originali con le battute su kaveri, mamma mia che simpaticoni... -.- no hope... ahahhh

Effettivamente è un po da deficienti la battuta kaveri-->kadaveri....

Però se certa gente si scompiscia con tanto è da compatire dai

Poveracci più di quello non arrivano

[MaxFabio93]

Originariamente inviato da Vash_85

Effettivamente è un po da deficienti la battuta kaveri-->kadaveri....

Però se certa gente si scompiscia con tanto è da compatire dai

Poveracci più di quello non arrivano

Tu non ridere Hans Gruber! Ci sei tu dietro tutto questo?

AMD, una grande azienda con una storia fantastica alle spalle viene trattata peggio di non so cosa...

[bobafetthotmail]

Qui c'è un bench con HSA abilitato http://wccftech.com/amd-kaveri-i5467...features-test/
qui un'altro http://www.extremetech.com/computing...geneous-chip/5
(un i5 le prende! Spettacolo.)

Avevo sentito in giro che HSA e OpenCL 2.0 diventavano più collegati di adesso, ma non ho trovato nulla di decente a supporto.

[carlottoIIx6]

Originariamente inviato da bobafetthotmail

Qui c'è un bench con HSA abilitato http://wccftech.com/amd-kaveri-i5467...features-test/
qui un'altro http://www.extremetech.com/computing...geneous-chip/5
(un i5 le prende! Spettacolo.)

si conoscevano, il problema sono le applicazioni di uso reale che sfruttano hsa.

Avevo sentito in giro che HSA e OpenCL 2.0 diventavano più collegati di adesso, ma non ho trovato nulla di decente a supporto.

sicuramente visto che open cl usa la cpu e la gpu avere huma gli è comodo.

[bobafetthotmail]

Originariamente inviato da carlottoIIx6

si conoscevano, il problema sono le applicazioni di uso reale che sfruttano hsa.

Beh, AMD ha aggiunto il supporto openCL a Libreoffice calc dalla versione 4.2 in poi per il calcolo delle formule più ostiche. http://techenablement.com/libreoffic...u-performance/
e qui a pag 37 https://people.gnome.org/~michael/da...ibreoffice.pdf
Che è certamente una mossa carina da parte loro.
E stranamente dicono che gira meglio sulle APU della AMD, quindi suppongo che ci sia anche HSA di mezzo.

[carlottoIIx6]

Originariamente inviato da bobafetthotmail

Beh, AMD ha aggiunto il supporto openCL a Libreoffice calc dalla versione 4.2 in poi per il calcolo delle formule più ostiche. http://techenablement.com/libreoffic...u-performance/
e qui a pag 37 https://people.gnome.org/~michael/da...ibreoffice.pdf
Che è certamente una mossa carina da parte loro.
E stranamente dicono che gira meglio sulle APU della AMD, quindi suppongo che ci sia anche HSA di mezzo.

open cl è supportato bene dalle buove apu, e raggiunge prestazioni notevoli.
comunque sia non sono questi i programmi che segnano un cambio di rotta epocale. penso alla suite adobe per esempio, a qualche compressore o convertitore. programmi di grafica 3d ecc,m L'adattamento dei sistemi operativi e i giochi ad esempio.