OpenCL e HSA
Il calcolo GPGPU ha preso piede lentamente, più per le difficoltà di programmazione che per il fatto di essere un mercato di nicchia. In parole povere il mondo della programmazione orbitava intorno alla CPU, e passare parte del codice alla GPU era tutt'altro che semplice.
"Molti progetti hardware specializzati, come Cell, GPGPU e MIC hanno trovato successo come design alternativi capaci di offrire prestazioni migliori rispetto a quelli convenzionali", nota D.M. Kunzman, autore di una ricerca sull'argomento.
"Un problema di questi acceleratori però è che aumentano anche il carico di lavoro sul programmatore, in termini di complessità del codice, e riducono la trasportabilità (da un sistema all'altro, NdT) perché serve codice specifico per l'hardware affinché l'applicazione funzioni. Inoltre bilanciare il carico dell'applicazione sui core è un altro problema, specialmente se tale carico va diviso tra core di diverso tipo, con caratteristiche prestazionali diverse".
Clicca per ingrandire
Non sorprende quindi che le API tradizionali create per interagire con la GPU fossero progettate per la grafica, visto che per far rendere il processore grafico sono necessarie operazioni basate su texture e poligoni. Usare il processore grafico per calcoli standard richiede quindi un passaggio in più, che dal punto di vista della programmazione è piuttosto impegnativo.
Il grande vantaggio di OpenCL è quello di offrire un'interfaccia semplice e diretta per sfruttare la GPU che aggira tale ostacolo. Questo standard è gestito dal gruppo non-profit Khronos Group, e oggi ha trovato l'approvazione e il sostegno di molti grandi nomi del settore tecnologico tra cui AMD, ARM, Intel e Nvidia.
OpenCL offre quindi l'ambiente software necessario per il calcolo eterogeneo, ma non risolve la questione hardware. Che si tratti di server, PC o smartphone, in che modo la piattaforma (una cosa diversa da CPU, GPU e/o APU) gestisce il calcolo eterogeneo? In passato questo compito non rientrava nella progettazione dei sistemi, e un dispositivo aveva un bacino di memoria condivisa che lo sviluppatore doveva sfruttare per fare passare i dati dalla CPU alla GPU - e poi la stessa cosa andava fatta per recuperare i risultati. In un sistema con memoria condivisa di questo tipo la copia continua di dati è una procedura inefficiente.
Clicca per ingrandire
Un problema risolto con la tecnologia HSA, che porta la GPU in un ambiente di memoria condiviso con la CPU nel ruolo di coprocessore. Le applicazioni possono così mandare il lavoro direttamente al processore grafico, come farebbe la CPU, e i due elementi possono lavorare insieme allo stesso set di dati. I processori usano gli stessi punti di riferimento, e così aumenta l'efficienza nel gestire piccoli carichi di lavoro perché si elimina l'overhead creato dalla copia e dai trasferimenti in memoria.
Secondo AMD, oltre alla memoria unificata, la tecnica HSA crea una coerenza di cache tra CPU e GPU, ed elimina il bisogno di scaricare il DMA ogni volta che il programmatore sposta i dati tra i due processori. La GPU inoltre può ora usare tutta la memoria virtuale e, infine ma non ultimo, una piattaforma HSA è molto simile nello stile di programmazione a una CPU.
"La memoria condivisa rende tutto il sistema più facile da programmare", ha affermato Phil Rogers di AMD. "Una delle barriere nell'usare il calcolo via GPU oggigiorno è che molti programmatori lo trovano troppo difficile. Devono imparare una nuova API, e gestire diversi spazi da indirizzare, e non sono sicuri su quando sia il momento giusto per copiare i dati. Quando si eliminano barriere come questa e si rende possibile l'uso di linguaggi di alto livello, si rende molto più facile il lavoro di programmazione e all'improvviso ci sono migliaia di programmatori al lavoro, invece di qualche centinaio. È davvero una grande differenza".