Le API CUDA
Ma il successo di Brook era sufficiente per attrarre l'attenzione di ATI ed nVidia, poiché entrambi i produttori intuirono l'incipiente interesse di questa iniziativa come un'opportunità per espandere il loro mercato, raggiungendo un nuovo settore.
I ricercatori impegnati in Brook entrarono nel team di sviluppo di Santa Clara (nVidia), per realizzare una strategia globale. L'idea era di offrire un sistema hardware/software indicato per questo tipo di calcoli. Poiché gli sviluppatori di Nvidia conoscevano tutti i segreti delle loro GPU, non c'era più motivo di affidarsi solo alle API grafiche, che comunicavano con l'hardware solo tramite driver, con tutti i problemi che implicava questo approccio. È qui che il team di sviluppo CUDA (Compute Unified Device Architecture) sviluppò una suite software in grado di comunicare con la GPU, dando vita all'omonimo linguaggio.
Come potete vedere da questo grafico, CUDA offre due API:
- Un'API di alto livello: la CUDA Runtime API
- Un'API di basso livello: la CUDA Driver API
Poiché l'API d'alto livello è "sopra" l'API di basso livello, ogni chiamata alla funzione Runtime è divisa in due istruzioni più basilari, gestite dall'API Driver. Queste due API si escludono mutuamente, nel senso che il programmatore deve vederne una o l'altra, ma è impossibile mischiare le funzioni di entrambe. Il termine "API di alto livello", poi, è relativo: l'API Runtime è sempre quella che le persone considerano di livello molto basso, però offre funzioni che sono molto pratiche per l'inizializzazione o il context management. Non aspettatevi qualcosa di semplice però: dovrete conoscere molto bene le GPU Nvidia per lavorarci.
L'API Driver è più complessa, ma ha il vantaggio della flessibilità, che da ai programmatori maggior controllo. Le due API sono in grado di comunicare con funzioni OpenGL e Direct3D (solo nove per il momento). CUDA può quindi servire per generare risorse (geometry, procedural textures, etc), che poi possono essere passate alle API grafiche, o al contrario, è possibile che un'API 3D invii i suoi risultati di rendering a CUDA, che in questo caso può essere usato con scopo di post-processing. Ci sono numerosi esempi di integrazioni, e il vantaggio è che le risorse rimangono immagazzinate nella RAM della GPU, senza dover passare tramite il bus PCI-Express, che farebbe da collo di bottiglia.
Al contrario, dobbiamo puntualizzare che la condivisione di risorse - in questo caso la memoria video - con i dati grafici non è sempre idilliaca, e potrebbero creare alcuni problemi. Per esempio, per cambiare la risoluzione o la profondità dei colori, i dati grafici hanno la priorità, quindi, se le risorse del frame buffer devono essere aumentate, il driver non esiterà a prendere le risorse allocate da un'applicazione che usa CUDA, creando crash di varia natura. Non è molto elegante, certo, ma dobbiamo ammettere che questa situazione non si verificherà molto spesso. Già che stiamo parlando di svantaggi: se volete usare più GPU per un'applicazione CUDA, dovete disabilitare prima di tutto la modalità SLI, altrimenti CUDA vedrà una sola GPU.
Infine, il terzo livello software è il set di librerie - due per essere precisi:
- CUBLAS, che dispone di una serie di parti fondamentali per i calcoli di algebra lineare;
- CUFFT, che può calcolare le trasformazioni di Fourier - un algoritmo molto utilizzato nel campo del signal processing.