CUDA driver API vs. CUDA runtime

Question

Durante la scrittura di applicazioni CUDA, è possibile lavorare a livello di driver o al livello di esecuzione, come illustrato su questa immagine (Le librerie sono CUFFT e CUBLAS per la matematica avanzata):

Suppongo che il compromesso tra i due sia un aumento delle prestazioni per l'API low-evel ma al costo di una maggiore complessità del codice. Quali sono le differenze concrete e quali sono le cose significative che non puoi fare con l'API di alto livello?

Sto utilizzando CUDA.net per l'interoperabilità con C# ed è stato creato come una copia dell'API del driver. Ciò incoraggia la scrittura di un codice piuttosto complesso in C# mentre l'equivalente in C++ sarebbe più semplice utilizzando l'API runtime. C'è qualcosa da vincere in questo modo? L'unico vantaggio che vedo è che è più facile integrare la gestione intelligente degli errori con il resto del codice C#.

Answer 1

Il runtime CUDA consente di compilare e collegare i kernel CUDA in file eseguibili. Ciò significa che non devi distribuire i file di Cubin con la tua applicazione, né occuparti di caricarli attraverso l'API del driver. Come hai notato, è generalmente più facile da usare.

Al contrario, l'API del driver è più difficile da programmare ma fornisce un maggiore controllo su come viene utilizzato CUDA. Il programmatore deve occuparsi direttamente dell'inizializzazione, del caricamento dei moduli, ecc.

Le informazioni del dispositivo apparentemente più dettagliate possono essere interrogate tramite l'API del driver piuttosto che tramite l'API di runtime. Ad esempio, la memoria disponibile sul dispositivo può essere interrogata solo tramite l'API del driver.

Dalla del CUDA programmatore Guida:

E 'composto da due API:

• A API di basso livello chiamato il driver API CUDA,
• Un API di livello superiore chiamato API di runtime CUDA implementata in cima a l'API del driver CUDA.

Queste API si escludono a vicenda: un'applicazione deve utilizzare uno o l'altro .

Il runtime CUDA facilita la gestione del codice dispositivo fornendo l'inizializzazione implicita, la gestione del contesto e la gestione dei moduli. Il codice host C generato da nvcc si basa sul runtime CUDA (consultare la Sezione 4.2.5), pertanto le applicazioni che si collegano a questo codice devono utilizzare l'API di runtime CUDA.

Al contrario, il driver API CUDA richiede più codice, è più difficile da programmare e di debug, ma offre un livello migliore di controllo ed è indipendente dal linguaggio poiché esso soltanto offerte con oggetti Cubin (vedere Sezione 4.2.5) . In particolare, è più difficile configurare e avviare i kernel utilizzando l'API del driver CUDA, poiché l'esecuzione della configurazione e i parametri del kernel devono essere specificati con chiamate di funzioni esplicite invece della sintassi di configurazione dell'esecuzione descritta nella Sezione 4.2.3. Inoltre, l'emulazione del dispositivo (consultare la Sezione 4.5.2.9) non funziona con l'API del driver CUDA.

Non c'è alcuna differenza di prestazioni tra le API. Il modo in cui i kernel usano la memoria e il modo in cui sono disposti sulla GPU (in orditi e blocchi) avrà un effetto molto più pronunciato.

Answer 2

un paio di cose importanti da notare:

prima le differenze tra le API si applicano solo al codice lato host. I kernel sono esattamente gli stessi. sul lato host la complessità dell'API driver è piuttosto banale, le differenze fondamentali sono:

in driver api si ha accesso a funzionalità che non sono disponibili nei contesti di runtime api come.

l'emulatore funziona solo con il codice scritto per l'API di runtime.

oh e attualmente cudpp che è una libreria molto utile funziona solo con l'API di runtime.

Answer 3

Ci sono alcuni problemi reali con l'allineamento degli argomenti e l'API del driver. Controlla la documentazione di CUDA 2.2 beta (o successiva) per maggiori informazioni.

Answer 4

Ho trovato che per la distribuzione di librerie in applicazioni multi-thread, il controllo sul contesto CUDA fornito dall'API del driver era fondamentale. La maggior parte dei miei clienti desidera integrare l'accelerazione GPU in applicazioni esistenti e in questi giorni quasi tutte le applicazioni sono multi-thread. Dal momento che non potevo garantire che tutto il codice GPU sarebbe stato inizializzato, eseguito e deallocato dallo stesso thread, ho dovuto usare l'API del driver.

I miei primi tentativi con vari work-around nell'API di runtime hanno portato a un fallimento, a volte in modo spettacolare - Ho scoperto che potevo ripetutamente riavviare immediatamente una macchina eseguendo solo il set errato di chiamate CUDA da diversi thread.

Da quando abbiamo eseguito la migrazione di tutte le API del driver, tutto è andato bene.

J