Quest’oggi vi propongo una riflessione in merito ad un fenomeno che sta prendendo piede nell’ambito della programmazione GPGPU e che proprio in questi giorni, nel corso della GPU Technology Conference tenutasi in questi giorni a San Jose, conferma l’interesse suscitato nell’ambito dello sviluppo di software di calcolo raccogliendo diversi consensi.
Parlo di CUDA, l’API per lo sviluppo di applicazioni mediante GPGPU, sviluppata da NVIDIA al fine di promuovere i propri processori grafici come piattaforma di riferimento per il GPGPU computing, cioè essenzialmente per l’uso delle GPU non solo per le elaborazioni della grafica in tempo reale così come la vediamo nei videogames, ma più in generale per la programmazione di un più ampio spettro di applicazioni.
Naturalmente le caratteristiche intrinseche dell’hardware di una GPU, la rendono particolarmente adatta ad alcune tipologie di elaborazioni e meno adatta ad altre. In generale si può ragionevolmente affermare che l’enorme molte di unità di calcolo in parallelo presenti in un processore grafico di ultima generazione ben si sposa con le elaborazioni massive di tipo SIMD, cioè Single Instruction Multiple Data.
Nel corso della GPU Technology Conference NVIDIA ha annunciato il supporto a CUDA da parte di nomi importanti nel mondo software come Matlab e Amber, oltre che 3D Studio Max per il rendering via ray tracing mediante mental ray iray. Inutile riportare che l’uso delle GPU Fermi in tutti questi ambiti, rispetto a workstation basate solo su classici processori x86, ha portato a un incremento di performance spesso sbalorditivo.
Alla luce del successo di CUDA, la questione che pongo personalmente è la seguente: quanto futuro può avere un’API proprietaria sviluppata per semplificare e accelerare lo sviluppo di applicazioni che utilizzano il GPGPU computing, considerando che esistono almeno due altri produttori hardware interessati al medesimo mercato?
Per meglio esprimere il mio punto di vista vi propongo due parallelismi con il passato: Glide e Cg. Non so quanti dei lettori conoscono la storia della gloriosa 3dfx Interactive, tuttavia indipendentemente da ciò che ha rappresentato quest’azienda per gli appassionati di videogames su PC negli anni 90, uno dei suoi principali punti di forza furono sicuramente le Glide.
Queste erano librerie proprietarie per l’accelerazione in hardware della grafica tridimensionale che ebbero un enorme successo all’epoca per almeno due ragioni. La prima è che erano state sviluppate come un sottoinsieme di OpenGL (ma che non aveva nulla a che fare ufficialmente con quest’ultimo) il che le rese molto più semplici e malleabili della mastodontica libreria utilizzata in ambito professionale. La seconda è che all’epoca la concorrenza di Microsoft con le sue DirectX era abbastanza scarna, in quanto queste ultime proponevano (parliamo della versione 3) un’API meno intuitiva e matura per lo sviluppo di motori grafici.
L’API Glide, essenzialmente uno standard de facto nella seconda metà degli anni 90, fu tuttavia soggetto di un rapido declino nel momento in cui emerse la sua più grande limitazione: era una libreria proprietaria e, in quanto tale, sviluppare un titolo usando esclusivamente le Glide significava renderlo incompatibile con il parco hardware di computer che possedevano una scheda video con chip non 3dfx.
Ci furono naturalmente delle concause: Microsoft mostrò gli artigli con le DirectX versione 5 e superiori, così come diversi titoli basati sui motori grafici Id Software preferirono adottare OpenGL. L’utilizzo di API non proprietarie di un produttore hardware da parte dei videogames fu, quindi, la soluzione preferita dal mercato sul lungo periodo.
Passiamo adesso al Cg anche denominato C for Graphics. Si tratta di un linguaggio di programmazione ad alto livello per lo sviluppo di vertex, geometry e pixel shader. La peculiarità di questo prodotto, sviluppato da NVIDIA, fu quella di introdurre per primo un linguaggio di programmazione degli shader ad alto livello per OpenGL, caratteristica che personalmente me lo fece adottare nello sviluppo del mio primo motore grafico in C++ :-).
In sintesi, il runtime del Cg non è altro che una libreria che compila il linguaggio Cg nell’equivalente HLSL – High Level Shader Language, per DirectX, e GLSL – OpenGL Shader Language, per OpenGL.
Dal momento in cui è stato introdotto (inizio del secolo) ad oggi, non si può affermare che il Cg abbia ricevuto un enorme successo commerciale per ragioni che risultano essere abbastanza comprensibili. Innanzitutto è raro trovare videogame che supportino sia OpenGL, che DirectX e, se viene meno questo requisito, allora tanto vale utilizzare direttamente il linguaggio della libreria prescelta. Inoltre esistono leciti dubbi sull’imparzialità del compilatore Cg, cioè sulla sua capacità di compilare gli shader in maniera ottimale anche per GPU non NVIDIA.
Queste due piccole retrospettive sono un esempio di come le librerie e le API sviluppate da un produttore di hardware che rendono le applicazioni che le utilizzano incompatibili o scarsamente ottimizzate per le altre piattaforme hardware, raramente hanno raggiunto un successo duraturo nel tempo e curiosamente i due esempi che vi ho riportato, in modalità differenti, trovano spazio proprio nel passato di NVIDIA.
Sicuramente CUDA rappresenta per NVIDIA più di una semplice scommessa visto che è in gioco il futuro della sua supremazia in ambito GPGPU e giustamente sta facendo tutto quanto è in suo potere per supportare la propria piattaforma hardware con uno strumento software estremamente valido e, al momento, ben recepito dal mercato.
Restano comunque le mie perplessità sulla longevità di CUDA: benché OpenCL e DirectCompute siano più a basso livello e non altrettanto ben supportati dagli altri produttori hardware, restano pur sempre le uniche API disponibili per lo sviluppo di software che voglia sfruttare le capacità di calcolo di qualsiasi GPU compatibile, e non solo con un logo verde marchiato sopra.
