Da AMD un approccio alternativo a CUDA per il calcolo parallelo con GPU

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/skvideo...gpu_59595.html

Grazie alla Boltzmann Initiative AMD punta a rendere le schede FirePro degli strumenti sempre più nelle mani di chi fa calcolo parallelo ad alte prestazioni. Tutto questo cambiando radicalmente la propria base software

Click sul link per visualizzare la notizia.

[AceGranger]

Originariamente inviato da Bivvoz

Io continuo a credere che HSA possa veramente diventare qualcosa di vincente per AMD, ma se non raggiunge la massa critica servirà a poco.

io continuo a vedere HSA per quello che è, OpenlCL con la memoria condivisa della GPU dell'APU e stop, e ora con HSA+ hanno aggiunto il supporto alla memoria condivisa delle GPU discrete con questo nuovo tool, cosa che nVidia ha iniziato a introdurre nel 2013 con CUDA 6.0 e che si concretizzera con il supporto Hardware di Pascal; presumo quindi che anche le nuove GPU AMD avranno il supporto alla memoria condivisa in hardware, direi che sono obbligati a metterla seno sara gia una partita persa.

[Tedturb0]

non farebbero prima a rellare estensioni per opencl invece di inventarsi un'altra cosa proprietaria che in questo caso non usera veramente nessuno?

[tuttodigitale]

Originariamente inviato da AceGranger

io continuo a vedere HSA per quello che è, OpenlCL con la memoria condivisa della GPU dell'APU e stop, e ora con HSA+ hanno aggiunto il supporto alla memoria condivisa delle GPU discrete con questo nuovo tool, cosa che nVidia ha iniziato a introdurre nel 2013 con CUDA 6.0 e che si concretizzera con il supporto Hardware di Pascal; presumo quindi che anche le nuove GPU AMD avranno il supporto alla memoria condivisa in hardware, direi che sono obbligati a metterla seno sara gia una partita persa.

E' la gpu che ha subito modifiche in questi anni proprio per adattarsi alle esigenze del calcolo eterogeneo, è questa il cuore di HSA. Comunque faccio notare che Intel ha una soluzione del genere da anni. Dall'alto della mia ignoranza, la GPU non agisce direttamente sulla RAM di sistema, ma piuttosto ci sarà una esecuzione runtime che ha il compito di sincronizzare opportunamente le letture e scritture tra cpu e gpu, in modo da mantenere coerenti i dati condivisi. Quindi c'è sempre una copia dei dati usando il PCI-Express, ma è totalmente trasparente all'applicazione.

E' un HSA "finto"..in pratica agevola solo la programmazione al programmatore, ma si capisce bene che un algoritmo HSA+ e HSA ha costi differenti e per tanto è consigliabile, quantomeno una compilazione ad hoc.

Serve ad AMD per consentire di sfruttare HSA anche sulle sue APU, anche con codici che non sono espressamente progettate per le APU (ricordo che un'applicazione HSA è incompatibile a livello di codice sorgente).

[CrapaDiLegno]

AMD è sempre stata persa nel mondo del GPGPU. Non ha mai avuto una strategia che potesse essere considerata semi decente.
Dall'uso dell'architettura VLIW che non era adatta al GPGPU al passaggio a GCN lato HW non è corrisposto alcuna evoluzione sul piano del supporto SW né della strategia stessa.
E infatti si sono visti i risultati e i tentativi di correzione al volo.

AMD è partita con capacità DP stratosferiche sulle proprie GPU. Peccato che lato professionale non offra alcun supporto al loro utilizzo. Quindi alla fine hanno capito che è silicio e corrente sprecati. All'aumento di dimensioni del die, quindi a fascia di appartenenza superiore, ogni revisione di GCN ha rimosso le capacità DP. Si è partiti con Tahiti e 1/4, Hawaii è scesa a 1/8, Tonga a 1/16 e Fiji a 1/24.
Per assurdo le GPU destinate al migliore mercato che avrebbe potuto sfruttare le capacità DP sono quelle che sono state maggiormente penalizzate. Rendedndo le GPU di fascia media inutilmente più costose da produrre per il solo scopo di far girare i videogiochi.
Questo va in contrasto con la strategia nvidia che è la stessa da sempre: capacità DP nulle sulle schede low end, ovvero tutto quello che è più piccolo della mattonella, mentre unità DP apposite aggiunte su quest'ultima. Quindi GPU da gioco meno costose (per lei) e GPU professionali a costo elevato ma con la sicurezza di poterle vendere con margine altissimo lo stesso.
Le due strategie HW vanno in direzioni opposte, e non si capisce davvero dove porti quella di AMD. Si vede che in India si studia economia al rovescio.
Se aggiungiamo che AMD non ha mai investito seriamente nel supporto SW delle proprie architetture, la frittata è bella che fatta.

Ora se ne esce con un tool di conversione tra le applicazioni CUDA e il suo nuovo OpenCL con nuovi entusiasmanti acronimi, manco che convertire la sintassi equivalesse a poter usare tutte le librerie che nvidia mette a disposizione con CUDA.
Diciamo pure che è in alto mare e non sembra capace di portarsi verso riva. E non sembra nemmeno che si stia sforzando poi molto per farlo. Con una frazione di quello che è stato investito per trasformare GCN1.0 in GCN1.2 senza davvero aver migliorato di alcunché la sua situazione (anzi peggiorandola lato professionale), avrebbero benissimo potuto cercare (quantomeno cercare) di dare maggior supporto al proprio HW invece di affidarsi, come ormai le è di abitudine, che siano altri a fare il lavoro per conto suo.
Ma con meno del 20% del mercato, ormai sta perdendo anche il supporto degli irriducibili. E recuperarlo quando si è così indietro, diventerà molto ma molto difficile.

@tuttodigitale
HSA non è programmazione su APU. La APU è una implementazione di HSA. Ma non è HSA.
Avere la memoria condivisa o meno non cambia il modo di lavorare. E' un vantaggio che può (e deve ) essere sfruttato, ma un algoritmo può essere scritto benissimo per girare (con diverse prestazioni) indipendentemente dal fatto che la memoria sia condivisa o meno sullo stesso MC.
Se il framework n cui si lavora estrae la configurazione della memoria in maniera completa, l'algoritmo è trasparente alla configurazione fisica. Quest'ultima influenza solo le prestazioni. nvidia con Pascal introdurrà l'nvlink, che non sarà come avere la memoria condivisa tramite lo stesso MC come con le APU, ma non sarà neanche come usare il PCI-e per fare i dovuti trasferimenti tra i vari buffer.
Mentre AMD è e sarà limitata ad avere alta efficienza solo con le APU, nvidia aumenterà la sua efficienza con le schede discrete destinate al mercato dove l'nvlink farà la differenza. Ancora una volta una bella differenza tra le due strategie.

Poi ovviamente, come da prassi da diversi anni, tra qualche mese AMD se ne uscirà su un foglio di carta con la proposta "open" di una specifica nuova per un nuovo bus di interconnessione CPU-GPU ad alte prestazioni, da far realizzare agli altri ovviamente, facendo ancora una volta la figura di quella che crea tecnologia "aperta" e non proprietaria.

[CrapaDiLegno]

...
Doppio

[marchigiano]

farà la fine di mantle...

[tuttodigitale]

Originariamente inviato da CrapaDiLegno

Si è partiti con Tahiti e 1/4, Hawaii è salito a 1/2, Tonga a 1/16 e Fiji a 1/24.

@crapadilegno gli algoritmi si sviluppano in base all'hardware c'è sotto: tra HSA in forma discreta e quella in forma integrata cambia una vita.
E comunque un bus ad alte prestazioni per la GPU, AMD già ce l'ha già e si chiama HyperTrasport.

Tutto il resto sono sciocchezze, inclusa il fatto che HSA(+) non facilita la programmazione:

Originariamente inviato da HSA Technical Review

Memory regions shared between the LCU and TCU are coherent. This simplifies programming by
eliminating the need for explicit cache coherency management primitives, and it also enables finergrained
offload and more efficient producer/consumer interaction. The major benefit from coherent
memory comes from eliminating explicit data movement and eliminating the need for explicit heavyweight
synchronization (flushing or cache invalidation). The support of existing programming models that
already use flushing and cache invalidation can also be supported, if needed.

Io non ne so molto, ma tu mi batti.

[tuttodigitale]

Originariamente inviato da OptimusAl

lui è un appassionato di amd, sa tutto di amd e non solo, commenta solo le news di amd e soprattutto compra solo amd indi per cui ha comunque ragione.

in pratica, lui è come me all'ennesima potenza.

[cdimauro]

Originariamente inviato da tuttodigitale

E' la gpu che ha subito modifiche in questi anni proprio per adattarsi alle esigenze del calcolo eterogeneo, è questa il cuore di HSA. Comunque faccio notare che Intel ha una soluzione del genere da anni. Dall'alto della mia ignoranza, la GPU non agisce direttamente sulla RAM di sistema, ma piuttosto ci sarà una esecuzione runtime che ha il compito di sincronizzare opportunamente le letture e scritture tra cpu e gpu, in modo da mantenere coerenti i dati condivisi. Quindi c'è sempre una copia dei dati usando il PCI-Express, ma è totalmente trasparente all'applicazione.

Intel utilizza la cache L3 allo scopo, che è condivisa fra CPU e GPU. In questo modo si mantiene automaticamente, ed efficientemente, la coerenza dei dati fra i due componenti, e fra questi e la memoria. Non c'è copia dei dati su PCI-Express, perché la GPU integrata lavora sulla memoria di sistema.

Originariamente inviato da CrapaDiLegno

Ora se ne esce con un tool di conversione tra le applicazioni CUDA e il suo nuovo OpenCL con nuovi entusiasmanti acronimi, manco che convertire la sintassi equivalesse a poter usare tutte le librerie che nvidia mette a disposizione con CUDA.

Le librerie si possono riscrivere per sfruttare direttamente HSA, mantenendo la stessa interfaccia (o comunque facendo sì che il traduttore si occupi anche di quest'aspetto).

Comunque il tool di conversione è una buona trovata per agevolare la conversione/porting del codice che già usa CUDA, che non è certo poco (visto che nVidia è stata pioniera).

Sarebbe interessante sapere se questo tool sarà open source, o comunque sia in grado di generare codice OpenCL sufficientemente generico da poter essere utilizzato anche su soluzioni diverse dalle sue. Intel è il leader di mercato riguardo alle GPU, e i suoi utenti potrebbe trarne grande beneficio.

Avere la memoria condivisa o meno non cambia il modo di lavorare. E' un vantaggio che può (e deve ) essere sfruttato, ma un algoritmo può essere scritto benissimo per girare (con diverse prestazioni) indipendentemente dal fatto che la memoria sia condivisa o meno sullo stesso MC.
Se il framework n cui si lavora estrae la configurazione della memoria in maniera completa, l'algoritmo è trasparente alla configurazione fisica. Quest'ultima influenza solo le prestazioni. nvidia con Pascal introdurrà l'nvlink, che non sarà come avere la memoria condivisa tramite lo stesso MC come con le APU, ma non sarà neanche come usare il PCI-e per fare i dovuti trasferimenti tra i vari buffer.

Come ha già fatto notare tuttodigitale, non è affatto così. Scrivere un algoritmo che utilizza una GPU integrata o una discreta produce risultati ben diversi, a causa delle enorme differenze che ci sono in termini di latenza e banda di memoria. Se poi ci mettiamo pure la presenza di cache L3 condivisa e/o L4 (eDRAM), come avviene nelle soluzioni Intel (l'eDRAM solo con le Iris Pro), ci troviamo di fronte a ulteriori, notevoli, differenze.

Questo non vuol dire che non si possa scrivere codice generico che giri su qualunque di queste GPU, però i risultati non saranno sicuramente ottimali (a volte decisamente sub-ottimali).

Per sfruttare al meglio un dispositivo di massiccio calcolo parallelo, per il programmatore è necessario conoscere anche questi dettagli.

Poi se ci si accontenta di una prima bozza di soluzione, perché "tanto va già molto meglio rispetto alla CPU", è un altro paio di maniche.

Mentre AMD è e sarà limitata ad avere alta efficienza solo con le APU, nvidia aumenterà la sua efficienza con le schede discrete destinate al mercato dove l'nvlink farà la differenza. Ancora una volta una bella differenza tra le due strategie.

Poi ovviamente, come da prassi da diversi anni, tra qualche mese AMD se ne uscirà su un foglio di carta con la proposta "open" di una specifica nuova per un nuovo bus di interconnessione CPU-GPU ad alte prestazioni, da far realizzare agli altri ovviamente, facendo ancora una volta la figura di quella che crea tecnologia "aperta" e non proprietaria.

Ha già Hypertransport, come ha detto tuttodigitale, e Intel ha appena presentato la sua tecnologia a questo scopo.

[marchigiano]

Originariamente inviato da Bivvoz

Gli cambieranno nome e lo useranno tutti quindi?

ancora co sta storia che dx12 è mantle?

[PaulGuru]

Originariamente inviato da Bivvoz

Io continuo a credere che HSA possa veramente diventare qualcosa di vincente per AMD, ma se non raggiunge la massa critica servirà a poco.

HSA di certo non ha come settore di punta il desktop.
E penso che sarà la analoga implementazione di Nvidia e Intel a ingranare, ma più su altri settori.

[PaulGuru]

Originariamente inviato da Bivvoz

È come dire che una ferrari non va forte in pista se non gli metti le gomme da neve
HSA serve con le integrate, con le dedicate cambia ben poco da openCL.

Integrate che le cpu di punta non hanno.
E soprattutto hai detto bene .... lavorano con le integrate, quindi dà anche un senso di spreco enorme di potenziale avendo le discrete installate, contrariamente invece al settore mobile.

[cdimauro]

Originariamente inviato da OptimusAl

del resto quando si scende così tanto verso l'hardware è normale (penso) che il linguaggio di programmazione si livella

Impossibile non notare l'evidente plagio. Chissà chi dei due ha copiato...

[PaulGuru]

Originariamente inviato da Bivvoz

In effetti la strategia di AMD è poco comprensibile, secondo me l'obbiettivo era di spostarsi tutto su APU anche per quel la fascia alta, ma poi quando hanno visto che HSA non se l'è filato nessuno hanno cambiato idea.

Non avrebbe senso fare delle della APU con una iGPU enorme, deve svolgere operazioni di calcolo eterogeneo in ambito consumer, non far girare gta5 in 4k.
Se devi far girare gta5 ci pensa la dedicata mentre l'integrata accelera quello che normalmente fa la cpu, uno volta ho trovato anche una slide (tra le milioni che produce AMD) che parlava di questa configurazione.

Ma per ZEN parlano di solo CPU quindi mi sa che è tutto finito alle ortiche, almeno in ambito consumer, per i server invece parlano di APU ciccione, sperem.

Non mi riferisco ai giochi.

Velocizzare la parte FPU utilizzando la GPU è ok, ma il dover utilizzare l'integrata quando si ha qualcosa di fascia alza installato fa ridere.
E' come avere un ottica tecnologia fisicamente handicappata.

Per quanto riguarda la potenza di calcolo non esiste un limite dove qualcuno può dire che la iGPU è in qualche modo tarata rispetto alla CPU secondo l'ottica HSA, perchè non è vero.

[cdimauro]

Originariamente inviato da Bivvoz

E se non avesse copiato nessuno?
AMD mi pare abbia dichiarato di lasciar perdere mantle in quanto soddisfatta dalle dx12 (o una cosa simile) come ho già scritto poco fa, proprio mentre amd e ms cooperavano per xbox1.

Sì, ma qualcuno l'avrà pur scritto il primo documento con quel testo...

[cdimauro]

Originariamente inviato da PaulGuru

Velocizzare la parte FPU utilizzando la GPU è ok

Non si può usare la GPU per velocizzare l'FPU, ma per sostituirla.

[tuttodigitale]

Originariamente inviato da cdimauro

Intel utilizza la cache L3 allo scopo, che è condivisa fra CPU e GPU. In questo modo si mantiene automaticamente, ed efficientemente, la coerenza dei dati fra i due componenti, e fra questi e la memoria. Non c'è copia dei dati su PCI-Express, perché la GPU integrata lavora sulla memoria di sistema.

Mi riferivo al dialogo tra le soluzioni Xeon x86 e le soluzioni pci express Xeon Phi. Credo che l'implementazioni di AMD descritta nella news sia la medesima.

Precisato questo, quoto non solo ogni singola parola, ma anche la punteggiatura.

[cdimauro]

Allora avevo capito male io. Siamo perfettamente d'accordo.

[tuttodigitale]

Originariamente inviato da PaulGuru

Non mi riferisco ai giochi.

Velocizzare la parte FPU utilizzando la GPU è ok, ma il dover utilizzare l'integrata quando si ha qualcosa di fascia alza installato fa ridere.
E' come avere un ottica tecnologia fisicamente handicappata.

Per quanto riguarda la potenza di calcolo non esiste un limite dove qualcuno può dire che la iGPU è in qualche modo tarata rispetto alla CPU secondo l'ottica HSA, perchè non è vero.

questo è vero sempre, ad esempio, ci sono compiti in cui non è richiesta la FPu, e una cpu priva di questo elemento potrebbe garantire un'efficienza più elevata.
.
La differenza te l'ha detta cdimauro. Questo significa che una soluzione integrata può permettersi un dialogo più intenso tra cpu e gpu: laddove in una soluzione discreta, la cpu e la gpu sono costretti, in misura maggiore, a eseguire parte di codice dove un processore è molto peggio dell'altro.
Questo è dovuto proprio al passaggio dei dati (poco conta se la copia non è esplicita). In pratica il processore1 potrà eseguire il compito più velocemente (una ditta con numerosi operai), peccato che esiste una certa latenza, MOLTO maggiore nelle soluzioni discrete (la cosiddetta burocrazia), tanto che è più vantaggioso appoggiarsi al lentissimo processore2, (l'amico nel tempo libero): il risultato è che il lavoro può effettivamente terminare prima facendo eseguire una sequenza di istruzioni ad un processore meno adatto.

La cpu e la fpu si scambiano il ruolo di processore1 e processore2, dell'esempio precedente, in base al codice che devono eseguire.

HSA, o comunque le soluzioni integrate, possono aprire orizzonti nuovi. Ci vuole del tempo. Forse il 2017 HSA sarà sfruttato a dovere, proprio nel mercato HPC.

Originariamente inviato da Bivvoz

In effetti la strategia di AMD è poco comprensibile, secondo me l'obbiettivo era di spostarsi tutto su APU anche per quel la fascia alta, ma poi quando hanno visto che HSA non se l'è filato nessuno hanno cambiato idea.

http://www.bitsandchips.it/9-hardwar...eous-processor

A me pare che AMD sia ritornata all'idea originale...

Originariamente inviato da cdimauro

Allora avevo capito male io. Siamo perfettamente d'accordo.