Ian Buck nous parle du GPGPU

Ian Buck, merci d’avoir pris le temps nécessaire à cette interview. Pouvez-vous vous présenter à nos lecteurs et nous expliquer votre rôle chez NVIDIA ?

Je suis le directeur software du département GPU Computing chez NVIDIA. Mon but est de concevoir et faire évoluer un environnement dédié au GPU computing, ce qui passe par les logiciels système, les outils de développement, la supervision du langage et des compilateurs, les librairies de programmation et enfin les applications cibles et algorithmes. Grâce à une équipe performante, nous développons les logiciels utilisateur autant que nous imprimons la marche à suivre pour l’entreprise en termes de GPU computing.

On imagine bien que vous n’avez pas commencé à vous intéresser au GPU Computing dès votre enfance, à quel moment avez-vous donc eu un déclic ? A Princeton ou Stanford lors de vos études ?

J’ai effectivement commencé à toucher au GPU computing à Princeton lorsque je travaillais sur la convection thermique et la simulation des fluides avec les composants graphiques de l’époque, à savoir un SGI O2 (station de travail Silicon Graphics d'entrée de gamme). Bien que les possibilités fussent alors extrêmement limitées du fait des composants, il était difficile de plaider pour le GPU Computing sur le long terme.

Je suis finalement tombé dans le bain lors de mes études doctorales à Stanford : notre communauté de chercheurs a pris la mesure de l’avancée naturelle de la programmation GPU : les cartes graphiques devenaient alors des unités de calcul dont les applications se faisaient de plus en plus larges. Nous avons rédigé un des premiers articles sur le ray tracing avec les GPU DX9 pour SIGGRAPH (Computing Machinery's Special Interest Group on Graphics and Interactive Techniques) afin de démontrer cet état de fait. Le travail était particulièrement intéressant dans la mesure où les cartes graphiques, composant tout à fait banal, suivaient la loi de Moore mais puissance 3 ! Evidemment, les processeurs n’évoluaient pas au même rythme. Il s’en suivait donc la question suivante : que pourrait-faire un PC s’il avait une multitude de commandes à gérer de pair avec une puissance de calcul supérieure à celle d’aujourd’hui ? Ceci change radicalement la donne en termes d'informatique, de même que la vision de l’informatique, l’intelligence artificielle, le data mining et les graphismes.

Quel a été votre rôle par rapport à Brook ?

Après avoir travaillé sur les possibilités de ray tracing GPU, mes recherches ont évolué vers les modèles pour le GPU computing. Bien d’autres avaient déjà démontré l’utilité du GPU pour une quantité d’applications variées, mais il n’existait pas encore de structure ou modèle de programmation satisfaisant pour appréhender le GPU en tant qu’unité de calcul. Il faut dire qu’à l’époque, il fallait un doctorat en infographie pour porter une application sur le GPU. J’ai donc initié le projet Brook avec le but de définir un langage de programmation pour le GPU computing, lequel faisait abstraction des principes du graphisme pour s’attacher à des concepts de programmation généralistes. Le concept fondamental de la programmation au sein du projet Brook était le « stream », un ensemble d’éléments de données qui nécessitaient un travail similaire. Brook est finalement devenu mon sujet de thèse à Stanford.

Votre travail a commencé par le Merrimac, le supercalculateur de Stanford. En quoi celui-ci diffère-t-il d’un supercalculateur Tesla par exemple ?

Les concepts de programmation modèle issus de Brook pouvaient s’appliquer au-delà des GPU. Ainsi nous avons travaillé sur deux différents types d’implémentation de Brook à Stanford : un pour les GPU et l’autre pour le Merrimac, qui était une architecture développée à l’université pour la recherche. Bon nombre d’idées développées sur le Merrimac ont été un déclic quant à l’utilité du GPU pour l’informatique en général. Par ailleurs, il faut savoir que Bill Dally était le chef de projet Merrimac à Stanford avant de devenir Chief Scientist (Directeur recherche) chez NVIDIA.

Est-ce que CUDA a trouvé ses racines dans Gelato ? Quand est-ce que les premières recherches universitaires sur le GPGGPU ont commencé ? A quand remonte sa première utilisation commerciale ?

J’ai commencé CUDA tout en poursuivant mes recherches à l’université. NVIDIA soutenait déjà mes travaux et voyait clairement l’intérêt à optimiser le GPU computing d’un point de vue matériel. En 2005, j’ai donc intégré NVIDIA pour travailler sur CUDA. A l’époque, nous étions deux : un ingénieur et moi-même. Mais nous avons fait évoluer le projet vers un département à part entière et un des principaux atouts des cartes graphiques NVIDIA actuelles.

Pour ce qui est des éléments chronologiques, www.gpgpu.org fait un bel historique du GPU computing depuis 2002.

Actuellement,  AMD milite pour Brook en tant que langage de programmation principal pour le GPGPU tandis que NVIDIA pousse pour le C avec des extensions CUDA. Comment se comparent les deux en termes de forces/faiblesses ?

En commençant chez NVIDIA, nous avons eu l’opportunité de revoir certaines décisions quant à la conception fondamentale de Brook, lesquelles s’appuyaient assez largement sur ce que les composants DX9 étaient alors capables de faire. Une des principales limitations était due à la mémoire, qui imposait au programmeur de concevoir leur algorithme avec un schéma d’accès mémoire assez limité. L’utilisation de C avec les extensions CUDA a permis d’assouplir ces contraintes puisque le programmeur dispose d’une réserve massive de threads, ce qui lui permet d’accéder à la mémoire comme il/elle le souhaite. Cette amélioration parmi d’autres nous a permis d’implémenter la sémantique complète du langage C sur le GPU.