Les contenus liés aux tags Nvidia et CUDA

Après une release candidate, Nvidia vient de rendre disponible la version finale de CUDA 5.0 . Rappelons que CUDA représente l'écosystème de programmation massivement parallèle qui englobe l'architecture de ses GPU et tout l'environnement logiciel dédié à leur bonne exploitation.

CUDA 5.0 apporte tout d'abord, enfin, un environnement de développement intégré (IDE) dédié à Eclipse, la plateforme ouverte qui, en plus de Windows, supporte également Linux et Mac OS. Nsight Eclipse Edition se limite par contre à CUDA alors que Nsight Visual Studio Edition se charge également de la partie graphique.

Le but premier de CUDA 5.0 est cependant de supporter le GK110 de manière à préparer son arrivée. Ce GPU, et peut-être d'autres dérivés, reprend la base de l'architecture Kepler mais l'améliore sur certains petits détails. Des détails qui pourront faire la différence dans le monde du calcul haute performance.

Le SC11 aura vu débarquer officiellement un énième langage destiné aux accélérateurs massivement parallèle, et en particulier aux GPU : OpenACC. Standard ouvert proposé par Nvidia, The Portland Group (PGI) et Cray, avec l'aide de CAPS, il représente une alternative à une initiative similaire proposée par Microsoft avec C++ AMP.

Un exemple simple de conversion d'un code classique vers le modèle de PGI à base de directives dont OpenACC est très proche.

L’université d’Utah, en partenariat avec Nvidia , vient de rendre disponible un projet original pour Linux baptisé kgpu . L’idée est de proposer une passerelle pour le noyau Linux sous la forme d’un mini pilote capable de communiquer avec des modules CUDA, qui continueront tout de même de s’exécuter en mode utilisateur. Sur le papier l’idée n’est pas inintéressante puisque cela permet de décharger certaines tâches systèmes des pilotes du noyau vers la carte graphique et son GPU. Pour mettre en avant l’intérêt du concept, les auteurs ont réecrit un module de cryptage pour eCryptfs  en version GPU. Dans ce test que vous pouvez voir ici . Si les résultats sont convaincants en lecture, en écriture les gains dépendent massivement de la taille des données écrites.

Kgpu reste pour l’instant un exercice de style plus qu’autre chose, en grande partie à cause de l’algorithme de cryptage implémenté actuellement (ECB) qui n’est pas considéré comme sécurisé. Dans l’absolu, on peut également se poser la question de l’intérêt d’un cryptage qui nécessite de faire transiter les données dans un espace mémoire utilisateur à cause de la passerelle. En prime, si la méthode qui consiste à utiliser un mini driver côté kernel et un pilote en mode utilisateur est bonne pour la majorité des tâches, dans le cas de tâches critiques comme les accès disques, la gestion de la mémoire peut devenir problématique.

Dans tout les cas, l’initiative n’est pas inintéressante et devrait peut être inciter toute l’industrie qui pousse actuellement le GPGPU à proposer des pilotes OpenCL qui puissent exécuter également du code côté noyau.