Déterminer une méthodologie complète de développement GPGPU est un travail qui pourrait occuper une thèse entière. Nous avons pré- féré donner des indications plus synthétiques au lecteur voulant se lancer dans la programmation GPGPU, sous la forme d’une série organisée de questionnements importants à envisager avant même le début d’un déve- loppement. Nous avons classé ces questions en deux catégories, à laquelle nous rajoutons un rappel des avantages et inconvénients de l’utilisation généraliste des GPU.
Possibilité d’adaptation ou de formulation d’un nouvel algo- rithme sur GPU
– Les premières et principales interrogations face à un algorithme à développer sur GPU sont les suivantes : est-il parallélisable pour une implémentation GPU ? En d’autres termes, les calculs qu’il implique peuvent-ils être traités de façon indépendante, ou bien suffisamment indépendante pour ne pas trop pénaliser l’exécution globale ? Tous les processeurs effectueront-t-il les mêmes calculs sur des données différentes ? Si non, les divergences seront-elles suffisamment res- treintes ? L’algorithme cherchera-t-il à propager des données ou à utiliser un aspect scatter ? Si oui, peut-on en imaginer une reformu- lation ?
– Dans le cas où l’algorithme est parallélisable, existe-il un mapping simple des données du problème vers un tableau 2D, structure prin- cipalement utilisée ? Les opérations ou routines que l’algorithme né- cessite existent-elles sur GPU ? Si non, sont-elles assez facilement réimplémentables, de façon optimisée ? Les types de données dont l’algorithme a besoin existent-ils sur GPU (en particulier, a-t-on be- soin de réels double précision), ou peuvent-ils être adaptés à des types GPU (en particulier les vecteurs) ?
– Lorsqu’une version optimisée d’un algorithme n’est pas adaptable sur GPU, doit-on pour autant s’arrêter à une version CPU algorith- miquement meilleure ? Suivant la taille du problème envisagé, il est possible qu’une version plus naïve sur GPU soit plus efficace au ni- veau des temps de calculs (c’est le cas pour notre application d’ap- pariements d’image décrite dans le chapitre 6) ; cette éventualité est donc à ne pas négliger.
– Le temps d’apprentissage d’un des langages GPU est également à prendre en compte : pour une utilisation ponctuelle, le choix du GPU n’est peut être pas le plus pertinent.
Comment adapter sur GPU ?
La possibilité d’implémentation d’un algorithme sur GPU est parfois fonction de choix que l’on a à faire.
– Le premier de ces choix est celui du constructeur de la carte gra- phique. Le portage d’un programme d’une carte d’un constructeur à une carte d’un autre constructeur n’est pas nécessairement assuré et dépend du langage de programmation utilisé. Pour l’heure, c’est NVidia qui supporte la plus large gamme de langage, ayant de plus proposé un langage graphique reconnu, Cg, ainsi qu’un langage gé- néraliste, CUDA, de plus en plus utilisé à des fins de recherche et développement. Une fois le choix du constructeur effectué, le choix du modèle est rapide, étant donné les prix très abordables de ces cartes. Un tout nouveau langage généraliste, OpenCL, a la parti- cularité d’être indépendant du modèle de carte et du constructeur, rendant les choix précédents moins décisifs.
– Le choix du langage est des plus important et dépend des besoins de l’algorithme à implémenter, ainsi que des savoir-faire du déve- loppeur. Selon le langage choisi, on rencontrera certains avantages et difficultés. C’est en particulier le cas entre un shading language et un langage généraliste : un shading language impose de raison- ner en terme de fragments et de processeurs CREW, mais libère de la contrainte de répartition des charges et permet l’utilisation d’as- tuces purement hardware liées au pipeline graphique. Au contraire, un langage généraliste permettra une flexibilité accrue de program- mation, au prix d’une organisation mémorielle plus complexe.
Avantages et inconvénients d’un développement sur GPU
Comme nous l’avons vu au cours de ce document, l’emploi de GPU dans un contexte généraliste peut s’avérer très rentable en terme de vi- tesse de calcul. Néanmoins, il ne faut pas perdre de vue qu’il existe des
contreparties parfois sévères. Nous proposons ici un rappel des atouts et désavantages de l’emploi de ces GPU.
Avantages
– Actuellement, les cartes les plus puissantes de NVidia possèdent 240processeurs travaillant en parallèle, pour une puissance brute de presque 1TFLOPS, soit 8 fois plus que les CPU quad core actuels ; – La portabilité des algorithmes développés sur des GPU actuels vers
des GPU futurs est assurée. Sans modifier le code, le gain (GPU comparé à CPU) s’amplifiera en changeant simplement de carte. Ceci est assuré par l’évolution plus rapide des GPU. Il est à noter que de nouveaux types de CPU pourraient venir modifier ce résultat (architectures many core, projet Tera-Scale), ainsi que des processeurs hybrides CPU/GPU (Larrabee d’Intel, par exemple) ;
– Il est possible d’associer facilement plusieurs GPU en cluster, dé- multipliant la puissance de calcul ;
– De génération en génération, la flexibilité de programmation s’ac- croît, les GPU tendent à devenir aussi facilement programmables que les CPU ;
– Prochainement, une plus grande transparence et compatibilité entre marques seront proposées, le projet OpenCL allant entièrement dans ce sens ;
– Un GPU haut de gamme coûte dans les 400e, mettant à la portée budgétaire de toute institution des machines équivalentes à des su- percalculateurs.
Inconvénients
– L’impossibilité d’écriture arbitraire en mémoire (scatter non auto- risé), lors de l’utilisation d’un shading language, peut se révéler gê- nante, nécessitant de réorganiser tout ou partie d’algorithme ; – La rétrocompatibilité des programmes n’est présentement pas to-
tale, ce qui peut poser certains problèmes lors d’une distribution ; – Actuellement, la portabilité entre cartes de différents constructeurs
n’est pas encore assurée. Il faudra probablement attendre les avan- cées d’OpenCL pour voir apparaître ces possibilités ;
– Les compilateurs de shader ou kernel sont encore obscurs car non livrés à la communauté. De légers artefacts peuvent parfois interve- nir, sans raison apparente ;
– Un investissement initial est exigé pour la maîtrise des concepts GPU/GPGPU, pénalisant les cycles de développement courts ; – Bien que la tendance disparaisse très vite, le GPU jouit encore, dans
la communauté scientifique, d’une réputation d’outil peu sérieux.