Près de 6 mois après l’annonce de la création d’un groupe de travail dédié à la mise au point d’OpenCL, celui-ci vient d’être ratifié par le groupe Khronos. Pour rappel, OpenCL (Open Compute Language) est une API dédiée au calcul massivement parallèle dont le développement a été initié par Apple et le groupe Khronos est un consortium d’industriels qui s’occupe du développement d’API ouvertes telles qu’OpenGL.
Comme vous devez maintenant le savoir, les GPUs peuvent être utilisés en tant qu’unités de calcul massivement parallèles, à travers CUDA dans le camp Nvidia et à travers Brook+/CAL dans le camp AMD. Ces APIs propriétaires posent un problème de portabilité puisqu’une application CUDA ne fonctionne pas sur une Radeon et une application Brook+ ne fonctionne pas sur une GeForce. Apple a ainsi proposé OpenCL pour pouvoir exploiter la puissance des GPUs sans être enfermé dans une gamme de produits d’un fabricant particulier (Nvidia). OpenCL peut donc être vu comme une API destinée à standardiser tout cela. La réalité est comme toujours plus complexe, d’où la raison de ce petit article.
OpenCL contre CUDA ?
C’est la question que beaucoup peuvent se poser puisque CUDA est l’API de type GPU Computing la plus mise en avant à l’heure actuelle, mais OpenCL n’est pas destiné à concurrencer CUDA. Pour comprendre cela il convient de se rappeler de ce qu’est CUDA : une architecture dédiée au calcul massivement parallèle. Nvidia lui a développé une API, « C pour CUDA », une subtilité importante à noter puisque par facilité nous parlons souvent de CUDA autant pour l’architecture que pour son API propriétaire.
Les cartes compatibles CUDA (GeForce, Quadro, Tesla) supporteront toutes autant C pour CUDA qu’OpenCL. Il en va de même pour les cartes Stream (Radeon, FireGL, FireStream) qui supporteront autant Brook+ qu’OpenCL. OpenCL se pose donc comme un langage commun à toutes les architectures. Il n’est d’ailleurs pas destiné qu’aux seuls GPUs puisqu’il vise également les CPUs et les accélérateurs tels que le Cell. De quoi permettre de développer un programme compatible avec toutes les architectures ? C’est là que ça se complique. En réalité le groupe de travail en charge d’OpenCL, qui comprend entre autres, Apple, AMD, Intel, Nvidia et Sony, a décidé de favoriser l’utilisation des spécificités de chaque architecture plutôt que la portabilité…
