Les derniers contenus liés au tag OpenCL

Deux billets de blogs d'AMD (ici et là) nous annoncent que la Creative Suite en version 6 d'Adobe, annoncée officiellement lundi, proposera pour la première fois une utilisation d'OpenCL dans certains de ses logiciels, ainsi qu'une utilisation accrue d'OpenGL (déjà utilisable précédemment pour le moteur de rendu de Photoshop par exemple).

Le premier blog cite deux exemples sous Photoshop (parmi un "fantastique nombre" non précisé) d'accélérations. Tout d'abord une nouvelle galerie d'effets de flous dont le calcul est accélérée par OpenCL. Côté performances, AMD indique que l'activation de l'OpenCL sur un APU A8-3530MX (processeur mobile quatre cœurs cadencé à 1.9 GHz) permet de réduire le temps de rendu de 394 à 51 secondes. Le second exemple cité sous Photoshop CS6 concerne l'effet "Liquify" qui profite lui du mode de rendu OpenGL. Sur la même plateforme qu'évoquée précédemment le temps de rendu passe de 86.6 à 15.6 secondes.

Le second blog cite un cas un peu particulier d'accélération OpenCL sous Premiere. Cependant en y regardant de plus près, l'exemple cible spécifiquement la version Mac de Premiere et plus précisément l'export H.264 dont le temps de rendu sur un MacBook Pro 15" passerait de 3 minutes 39 secondes à une minute et 4 secondes en mode OpenCL via la Radeon HD 6750M intégrée à la machine. On rappellera qu'Adobe proposait déjà sous Windows une accélération GPU CUDA de son moteur de rendu Mercury Engine, mais qui ne touchait pas l'encodeur H.264 présent dans le logiciel. Le billet d'AMD laisse penser qu'il s'agit de l'accélération du moteur de rendu, et non de l'encodage lui-même, qui propose l'accélération OpenCL. Il sera bon de voir si cette fonctionnalité sera également portée sur la version PC et si elle fonctionnera sur les autres GPU.

Un point que l'on pourra vérifier d'ici 30 jours, délai de disponibilité effectif annoncé pour CS6, tout comme l'étendu réelle de l'utilisation d'OpenCL. Le modèle de développement itératif de Photoshop et des autres outils Adobe fait qu'assez souvent, les nouveautés technologiques (jeux d'instructions particuliers comme Altivec ou SSE, support du multi-core, etc) ont souvent été implémentées de manière isolée dans certains filtres ou certaines fonctionnalités.

MAJ : Adobe à indiqué sur son forum que le support OpenCL sous Premiere serait bel et bien limité à la plateforme Mac (merci a fir3ball12).

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.

OpenACC permet ainsi de définir très simplement dans le code les zones à accélérer, à l'aide de directives pour le compilateur, qui se charge ensuite de toute la complexité liée à l'utilisation d'un accélérateur. Cette approche simplifie nettement le travail des développeurs et permet de conserver la compatibilité avec les systèmes dépourvus d'accélérateur, puisqu'il suffit alors d'ignorer ces directives.

Reste bien entendu qu'une telle approche est moins efficace qu'un code optimisé manuellement pour une architecture spécifique, mais elle permet d'obtenir rapidement des résultats intéressants pour les morceaux de code naturellement parallèles, de pouvoir juger de l'intérêt des accélérateurs sans gros investissement et d'éviter d'être enfermé dans le support d'une seule architecture. Compte tenu de temps de développement qui peuvent être très longs, utiliser un langage tel qu'OpenACC et, éventuellement, intégrer quelques fonctions natives lors de la mise en production (cela reste bien entendu possible), permet de limiter les risques.


Un exemple simple de conversion d'un code classique vers le modèle de PGI à base de directives dont OpenACC est très proche.
OpenACC, défini pour C, C++ et Fortran, est une version étendue et ouverte du modèle de programmation à base de directives pour les accélérateurs de PGI, un petit peu comme OpenCL est une version étendue et ouverte de C pour CUDA. OpenACC complexifie légèrement le langage de PGI, ce qui était nécessaire pour étendre ses possibilités. Dans un premier temps 3 compilateurs seront compatibles :

- PGI Accelerator C/C++/Fortran pour CUDA (GPU Nvidia)
- Cray CCE pour systèmes Cray (qui supportent les GPU Nvidia)
- CAPS Enterprise HMPP Workbench (qui supporte OpenCL)

Grossièrement, les compilateurs OpenACC qui sont actuellement prévus concernent avant tout l'utilisation d'accélérateurs CUDA, Nvidia étant l'un des membres à l'origine du langage. Rien n'empêche cependant la mise en place de compilateurs OpenCL, comme le fait CAPS, ou dédiés aux GPU AMD, si ce n'est le fait qu'actuellement chacun semble développer son propre "standard" en prenant soin de nier les initiatives issues de la concurrence.

Reste qu'OpenACC semble avoir été tiré de la réflexion initiale du groupe de travail sur les accélérateurs d'OpenMP, dont l'exploitation représente un des objectifs de la version 4.0 de ses spécifications. Les membres fondateurs d'OpenACC ne cachent d'ailleurs pas leur intention de l'intégrer à OpenMP, précisant que ce lancement anticipé permettra à ce sujet d'obtenir de la part des développeurs des retours importants pour la finalisation du standard complet et robuste d'OpenMP pour le calcul hétérogène.

Vous pourrez obtenir les spécifications complètes de la version 1.0 d'OpenACC par ici.

Ce qui est probablement l'annonce la plus importante de l'AFDS a été quelque peu éclipsée hier compte tenu des détails dévoilés sur la future architecture des GPUs AMD : la FSA.

Phil Rogers, AMD Corporate Fellow, dévoile les évolutions à venir dans le calcul hétérogène.
Un frein à l'utilisation du GPU computing réside dans l'overhead énorme lié à son exploitation, un point qu'AMD entend bien faire disparaître avec la Fusion System Architecture, une combinaison hardware et software destinée à simplifier le GPU computing et son utilisation combinée avec les cores CPUs.



La FSA fait disparaître la lourdeur de la plateforme GPU compute actuelle.
Comme son nom l'indique, la FSA est avant tout pensée pour les APUs dans lesquels cores CPU et GPU sont proches l'un de l'autre, ce qui implique une communication simplifiée entre eux et une gestion d'un espace mémoire unifié plus simple à mettre en place. AMD compte cependant faire profiter les GPUs présents sur les cartes graphiques de tout ceci, grâce au PCI Express 3.0 qui offrira une bande passante supérieure ainsi qu'un espace unifié cohérent.


Cores CPU et GPU travaillent main dans la main plus efficacement grâce à la FSA.
La FSA n'est pas une nouvelle API mais une plateforme optimisée pour OpenCL et destinée à remettre à plat l'utilisation du GPU computing. Latence réduite, fin des copies de données inutiles entre les espaces CPU et GPU, pointeurs partagés entre CPU et GPU, possibilité d'un accès bas niveau au hardware pour des librairies hyper optimisées, modèle de queues hardware repris du SMP…

L'arrivée complète de la FSA se fera dans les 3 ans selon AMD, dont une partie (le dispatching optimisé) introduite en principe cette année avec la nouvelle architecture GPU dévoilée à l'AFDS également. AMD entend rendre la FSA ouverte à la concurrence, reste à voir si cet appel trouvera un écho chez Intel et Nvidia !

Dans tous les cas il est intéressant d'observer qu'AMD, vu comme plutôt passif dans le domaine du GPU computing ces dernières années, à décidé de prendre à bras le corps les challenges que représentent son exploitation. Il faut dire que le fabricant n'a pas d'autre choix, les APUs ayant un besoin criant de telles évolutions pour montrer tout leur intérêt. La documentation complète de la FSA devrait être publiée avant la fin de l'année de manière à permettre aux développeurs de s'y préparer.

Selon les résultats d'une étude que nous a présentés AMD, OpenCL est en train de gagner du terrain, notamment par rapport à C pour CUDA, l'API similaire mais propriétaire proposée par Nvidia depuis 2007. Plus récent, mais ouvert, OpenCL est prévu pour supporter tout type de processeurs, qu'ils soient CPU ou GPU, ce qui permet aux développeurs de s'assurer un support, même si peu performant, sur un maximum de systèmes.

Le sondage présenté à plus de 500 développeurs d'une part en Amérique du Nord et d'autre part en EMEA a fait ressortir une préférence pour OpenCL par rapport à CUDA. OpenMP d'une part et les outils Intel d'autre part conservent cependant la première place. Reste bien entendu à voir quand cette progression chez les développeurs portera ses fruits en pratique pour les utilisateurs…

Pour la première fois, AMD organise son propre forum technologique, centré autour des nouvelles possibilités offertes par les plateformes Fusion ainsi que, plus globalement, par OpenCL et la programmation hétérogène. Une première édition d'autant plus importante qu'elle coïncide avec le lancement de la version mobile de l'APU Llano.

La bonne exploitation des GPUs en dehors du rendu 3D temps réel des jeux vidéo est la clé du succès des APUs. Convaincre de nombreux développeurs de l'intérêt de la puissance de calcul des APUs, les former et obtenir leurs commentaires sur les évolutions ou outils dont ils ont besoin sont devenus des points essentiels pour AMD. Pour cela, la stratégie d'AMD consiste à inciter à l'utilisation d'OpenCL et à lui donner de la visibilité, notamment à travers l'AFDS, organisé à Bellevue, en plein territoire Microsoft.


Cet évènement, que nous couvrirons pour vous toute cette semaine, sera ainsi l'occasion de démontrer la progression d'OpenCL, de reparler du fond d'investissement Fusion, des nouveaux outils de développement, du concours de programmation OpenCL lancé en partenariat avec TopCoder, de lancer Llano et de dévoiler quelques détails sur la future architecture GPU qui devrait arriver cet automne.