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

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.

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

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).

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.

...
Doppio

farà la fine di mantle...

@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:


Io non ne so molto, ma tu mi batti.

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

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.

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.

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.

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

ancora co sta storia che dx12 è mantle?