John Siracusa

OpenCL

OpenCL est associé au Core

Jusqu'à présent, nous avons vu quelques exemples consistant à faire plus avec plus : une infrastructure de compilateur plus moderne, qui supporte une nouvelle possibilité importante du langage et une API pour la simultanéité, puissante et pragmatique. Tout cela représente un gros effort pour aider les développeurs, et l'OS lui-même fait un maximum pour utiliser le matériel disponible.

Mais les CPUs ne sont pas les seuls composants qui fournissent une surabondance de transistors. Quand on parle de prolifération de moteurs de calcul indépendants, un autre morceau de silicium est un tenant du titre incontestable : le GPU.

Les chiffres racontent l'histoire. Alors que les CPUs des Macs contiennent quatre cœurs (qui peuvent monter à huit cœurs logiques grâce au multithreading symétrique) les GPUs de haut de gamme peuvent contenir bien plus de 200 cœurs. Alors que les CPUs dépassent tout juste les 100 GFLOPS, les meilleurs GPUs peuvent dépasser 1000 GFLOPS. C'est mille milliards d'opérations en virgule flottante par seconde. Et comme les CPUs, il y a maintenant plusieurs GPUs sur une carte.

Ecrire pour un GPU

Malheureusement, les cœurs des GPUs ne sont pas des processeurs à usage général (du moins, pas encore). Ce sont des engins de calcul plus simples, qui ont évolué, à partir des fonctions implantées dans le silicium de leurs ancêtres, qu'on ne pouvait pas du tout programmer. Ils ne fournissent pas le riche ensemble d'instructions des CPUs, la taille maximum des programmes qu'ils peuvent faire tourner est souvent limitée et très petite, et ils ne supportent pas toutes les possibilités du standard de calcul en virgule flottante IEEE.

Aujourd'hui, les GPUs peuvent être programmés, mais les possibilités les plus communes de programmation s'inscrivent dans le domaine graphique : calcul de vertex, de primitives géométriques, des attributs de pixels. La plupart des langages utilisés pour programmer les GPUs sont aussi orientés graphique : HLSL, GLSL, Cg.

Il y a cependant des tâches de calcul en dehors du graphisme qui peuvent tirer profit des GPUs en tant que matériel. Ce serait bien s'il y avait un langage non orienté graphique pour écrire des programmes pour elles. Mais créer une chose de ce genre est un vrai défi. Le matériel des GPUs varie de toutes les façons imaginables : nombre et type des unités d'exécution, jeu d'instructions, architecture de mémoire, et tout ce que vous pouvez imaginer. Les programmeurs ne veulent pas être confrontés à ces différences, mais il est difficile de contourner une absence complète d'une caractéristique, ou l'indisponibilité d'un type particulier de données.

Le vendeur de GPUs NVIDIA a cependant fait une tentative avec CUDA : un sous-ensemble du langage C avec des données de type vecteur, des identificateurs de stockage des données, qui reflètent la hiérarchie de mémoire typique des GPUs, et plusieurs bibliothèques de calcul associées. CUDA n'est qu'un entrant dans le champ bourgeonnant des GPGPU (General Purpose computing on Graphics Processing Units). Mais en tant que fabriquant de CPUs, il doit affronter une bataille difficile avec les développeurs qui veulent en fait une solution indépendante d'un vendeur.

Dans le domaine de la programmation 3G, OpenGL remplit ce rôle. Et comme vous l'avez sûrement deviné à présent, OpenCL a pour ambition de jouer le même rôle pour les calculs d'usage général. En fait, Open CL est encouragé par le même consortium que Open GL, le groupe Khronos, au nom inquiétant. Mais ne vous y trompez pas, OpenCL est le bébé d'Apple.

Apple a compris que la meilleure chance de succès d'OpenCL était de devenir un standard de l'industrie, pas seulement une technologie Apple. Et pour que ça arrive, Apple avait besoin de la collaboration des principaux vendeurs de GPUs, et en plus, d'un agrément avec un organisme de standardisation bien établi et largement reconnu. Cela a mis du temps, mais maintenant, tout est en place.

OpenCL est beaucoup comme CUDA. Il utilise un langage proche du C, avec les extensions de vecteurs, il a un modèle de hiérarchie de mémoire similaire, et ainsi de suite. Ce n'est pas une surprise, quand on considère qu'Apple a étroitement travaillé avec NVIDIA pendant le développement d'OpenCL. Il n'y a aussi aucune raison pour qu'un vendeur de GPUs bien établi modifie son matériel de façon radicale, jusqu'à adopter un standard qui n'est pas encore établi, si bien qu'OpenCL devait fonctionner parfaitement avec les GPUs conçus pour supporter CUDA, GLSL, et d'autre langages de programmation existants pour les GPUs.