Perché Google ha scelto RenderScript invece di OpenCL

Question

Mi sono chiesto se fosse possibile utilizzare OpenCL per Android, scoprire che non era possibile e abbandonare del tutto l'argomento. Ma grazie al post sul blog del 14 gennaio sul blog ufficiale degli sviluppatori Android (http://android-developers.blogspot.fr/2013/01/evolution-of-renderscript-performance.html), ho scoperto che la programmazione parallela era possibile da Android 4.0, grazie a RenderScript! Un'API che ha alcune caratteristiche comuni con OpenCL.

Quello che mi chiedo ora è: perché Google ha scelto di implementare questa nuova soluzione, invece di spingere OpenCL in avanti (una specifica aperta ora gestita dal gruppo Khronos).

Voglio dire, lo so, non è davvero difficile convertire da uno all'altro, ma ancora ...

In ogni caso, se qualcuno come la spiegazione vera e propria, per favore fatemelo sapere!

Answer 1

La risposta è che le esigenze di Android sono molto diverse da quelle che OpenCL cerca di fornire.

OpenCL utilizza il modello di esecuzione introdotto per la prima volta in CUDA. In questo modello, un kernel è costituito da uno o più gruppi di lavoratori e ogni gruppo ha una memoria condivisa veloce e le primitive di sincronizzazione all'interno di quel gruppo. Ciò che fa è far sì che la descrizione di un algoritmo sia combinata con il modo in cui tale algoritmo dovrebbe essere programmato su una particolare architettura (perché stai decidendo la dimensione di un gruppo e quando sincronizzarlo all'interno di quel gruppo).

È fantastico quando si scrive per un'architettura e si vogliono prestazioni di picco assolute, ma si ottengono prestazioni ottimali a scapito della portabilità delle prestazioni. Forse sulla tua architettura, hai abbastanza registri e memoria condivisa per eseguire 256 lavoratori per gruppo per le migliori prestazioni, ma su un'altra architettura, si finirebbe con enormi perdite di registro con qualcosa sopra 128 lavoratori per gruppo, causando una regressione delle prestazioni dell'80% . Nel frattempo, poiché il tuo codice è scritto esplicitamente per 256 lavoratori per gruppo, il runtime non può fare nulla per cercare di migliorare la situazione su un'altra architettura: deve obbedire a ciò che hai scritto. Questo tipo di situazione è comune quando si passa dall'architettura all'architettura sul lato desktop/HPC del calcolo GPU.

Su dispositivo mobile, Android richiede la portabilità delle prestazioni tra diversi fornitori di GPU e CPU con architetture molto diverse. Se Android dovesse fare affidamento su un modello di esecuzione in stile CUDA, sarebbe quasi impossibile scrivere un singolo kernel e farlo funzionare in modo accettabile su una gamma di dispositivi.

Gli abstract di RenderScript controllano la programmazione lontano dallo sviluppatore al costo di alcune prestazioni di picco; tuttavia, stiamo costantemente colmando il gap in termini di ciò che è possibile con RenderScript. Ad esempio, ScriptGroup, un'API introdotta in Android 4.2, è una parte importante dei nostri piani per migliorare ulteriormente la generazione del codice GPU. Ci sono molti nuovi miglioramenti che rendono ancora più facile scrivere codice veloce.

Answer 2

Apple detiene il marchio su OpenCL. Google compete con Apple. Forse è davvero così semplice.

Abbiamo lavorato su OpenCL con Android (see here) e siamo felici di vederlo andare avanti grazie al lavoro di Intel, Imagination e altri produttori di chip. Google si girerà abbastanza presto.