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

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

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

di pubblicata il , alle 09:01 nel canale Schede Video
FireProCUDANVIDIAAMDRadeon
 

Boltzmann Initiative è il nome scelto da AMD per indicare una nuova e importante iniziativa incentrata sulle proprie architetture FirePro, destinate quindi all'utilizzo per il calcolo ad elevate prestazioni all'interno di workstation grafiche e nei datacenter.

Grazie ad un nuovo set di driver Linux di tipo headless, AMD implementerà supporto alla propria Heterogeneous System Architecture anche attraverso l'utilizzo di schede video di tipo discreto e non unicamente tramite architetture APU, come avvenuto sino ad ora. AMD giunge a questo risultato sviluppando un ambiente specifico che viene indicato con la sigla HSA+, sviluppato a partire da quello HSA nel quale sono state implementate apposite estensioni che permettono l'utilizzo di GPU di tipo discreto nel processo di calcolo eterogeneo.

In questo modo AMD potrà integrare processori e schede video discrete all'interno di un singolo spazio di indirizzamento memoria condiviso, replicando quanto HSA permette di ottenere in tradizionali architetture di APU. Così facendo AMD offre un ambiente di elaborazione integrato, con il plus di una riduzione della latenza e di una più efficiente gestione delle risorse a disposizione in presenza di ampi cluster di elaborazione parallela.

Altra novità di questa iniziativa è la disponibilità di Heterogeneous Compute Compiler o HCC, una soluzione che mira a facilitare il lavoro degli sviluppatori software per adattare il proprio codice a venir eseguito in parallelo sfruttando le GPU basate su architettura AMD. HCC permetterà agli sviluppatori di scrivere codice che potrà venir eseguito dalla CPU come dalla GPU utilizzando un singolo linguaggio di programmazione, servendosi di un unico compilatore il tutto all'interno di un singolo file sorgente. Oltre a questo Heterogeneous Compute Compiler offrirà agli sviluppatori alcune funzionalità specifiche per sfruttare al meglio le potenzialità delle GPU in termini di capacità di elaborazione parallela.

Il ruolo di HCC è per molti versi simile a quello di OpenCL, linguaggio che AMD continuerà a supportare in futuro con le proprie architetture ma che non ha trovato ampio utilizzo tra gli sviluppatori.

Ultimo blocco della Boltzmann Initiative è quello che viene indicato con la sigla HIP, o Heterogeneous-compute Interface for Portability: questa permette agli sviluppatori di programmare codice che verrà eseguito dalle GPU AMD utilizzando una sintassi che è per approccio simile a quella CUDA, con la quale gli sviluppatori sono ormai abituati ad avere a che fare. Non solo: HIPify Tools è un set di utility che permetteranno di convertire automaticamente codice CUDA in codice HIP; una volta ottenuto codice di questo tipo sarà possibile compilarlo per l'utilizzo su GPU AMD o NVIDIA, rispettivamente servendosi di HCC oppure di NVCC.

Quest'ultimo annuncio non implica che le GPU AMD potranno eseguire codice CUDA, ma che a partire da codice CUDA sarà possibile per gli sviluppatori ottenere rapidamente codice compatibile attraverso una conversione in automatico. In questo modo AMD si apre spazio ai numerosi scenari di utilizzo nei quali le GPU NVIDIA vengono utilizzate per il calcolo parallelo ad elevate prestazioni via CUDA.

La Boltzmann Initiative mira quindi a espandere in modo importante gli ambiti di utilizzo delle GPU AMD all'interno del mondo del calcolo parallelo professionale, puntando a ridurre il gap con le proposte concorrenti di NVIDIA sul versante software. In questi scenari di utilizzo è molto spesso la componente software più di quella hardware a incidere verso l'utilizzo o meno di una determinata famiglia di GPU: è stata questa la forza di NVIDIA, capace di guadagnare quote di mercato dominanti in questo settore, ed è in questa stessa direzione che AMD vuole da oggi muoversi con convinzione.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

52 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Bivvoz17 Novembre 2015, 09:11 #1
Io continuo a credere che HSA possa veramente diventare qualcosa di vincente per AMD, ma se non raggiunge la massa critica servirà a poco.
AceGranger17 Novembre 2015, 09:39 #2
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.
Tedturb017 Novembre 2015, 11:27 #3
non farebbero prima a rellare estensioni per opencl invece di inventarsi un'altra cosa proprietaria che in questo caso non usera veramente nessuno?
tuttodigitale17 Novembre 2015, 12:24 #4
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).
CrapaDiLegno17 Novembre 2015, 13:12 #5
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.
CrapaDiLegno17 Novembre 2015, 13:14 #6
...
Doppio
marchigiano17 Novembre 2015, 14:16 #7
farà la fine di mantle...
tuttodigitale17 Novembre 2015, 16:38 #8
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.
Bivvoz17 Novembre 2015, 17:08 #9
Originariamente inviato da: marchigiano
farà la fine di mantle...


Gli cambieranno nome e lo useranno tutti quindi?
OptimusAl17 Novembre 2015, 18:33 #10
Originariamente inviato da: tuttodigitale
@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.


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.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^