Intervista: dietro le quinte con AMD
Uno dei principali obiettivi in questa serie di articoli sul calcolo eterogeneo è avere una migliore comprensione di OpenCL e DirectCompute. Perché un produttore sceglie di usarle al posto di altre API come OpenGL o DirectX? Come si comportano queste interfacce di programmazione con i dati? Quali sono i loro limiti e qual è il loro potenziale inespresso?
Non ci sono risposte nei documenti del marketing, ma fortunatamente due persone con grande esperienza in materia (di AMD e Adobe) ci hanno dato qualche informazione. La prima è Alex Lyashevsky, un ingegnere di AMD "acquisito" all'epoca dell'integrazione con ATI: detiene brevetti sulla compressione parallela d'immagini lossless e sul primo codificatore H.264 all'interno della GPU, e vanta una comprensione rara e profonda del GPGPU; pertanto e una delle poche persone al mondo che possano discutere di accelerazione OpenCL.
Clicca per ingrandire
Tom's Hardware: Photoshop CS6 è l'applicazione principale che testiamo in quest'articolo e si tratta di un programma che sfrutta anche OpenGL. Perché è stato aggiunto OpenCL?
Alex Lyashevsky: OpenGL è usato abbastanza diffusamente e ha alcune capacità simili a quelle di OpenCL. OpenGL però è più indicato per la gestione della grafica: quando lo si usa di solito s'ipotizza che ci sia una sorta d'immagine o di buffer da cui si cerca di attingere; OpenCL offre invece una piattaforma di programmazione più generica dal punto di vista del calcolo. C'è assoluta libertà nella definizione del proprio dominio di calcolo, senza vincoli a qualche tipo d'immagine o un ipotetico calcolo bidimensionale basato su pixel. A volte però incoraggio le persone a usare OpenGL, perché ha un input buffer filtering gestito davvero bene a livello hardware, e un output color buffer molto efficiente.
Clicca per ingrandire
TH: Per gli sviluppatori c'è una differenza rilevante tra le due API in fatto di codice?
AL: OpenCL potrebbe essere un po' più semplice per gli sviluppatori, perché programmare in linguaggio shader OpenGL è una cosa difficile; questo approccio ipotizza che si debba realizzare un qualche tipo di contesto grafico, il che significa stabilire il punto di vista, le matrici di trasformazione del modello e così via. OpenGL è un linguaggio grafico e funziona bene per problemi di calcolo. Dal punto di vista della programmazione generica però OpenGL non ha senso: se si vogliono manipolare i dati, perché impostare un triangolo, un punto di vista o una matrice? Ci vuole un modo più generico di programmare la GPU, ed è qui che entra in gioco OpenCL. Ad esempio non è molto utile usare OpenGL per accelerare qualcosa come l'algoritmo deflate e la codifica nelle applicazioni di compressione, ma è utile probabilmente per applicazioni che elaborano immagini.