Difference between revisions of "EA2014 GPGPU"
Jump to navigation
Jump to search
| (47 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Image: |
+ | [[Image:EA2014_GPGPU_thumb.png|right|thumb|300px|Logo d'OpenCL]] |
= Présentation = |
= Présentation = |
||
| Line 7: | Line 7: | ||
* Date : 17 octobre 2014 |
* Date : 17 octobre 2014 |
||
* Auteur : William Bobo <william.bobo@e.ujf-grenoble.fr> |
* Auteur : William Bobo <william.bobo@e.ujf-grenoble.fr> |
||
| − | * Lien vers les slides de la présentation : [ |
+ | * Lien vers les slides de la présentation : [[https://slides.com/willbobo/gpgpu Transparents]] |
= Résumé = |
= Résumé = |
||
| + | GPGPU ou General-purpose Processing on Graphics Processing Units. C'est une méthode permettant l’exécution de calculs hautes performances sur des GPU. |
||
| − | - |
||
| + | Ces calculs peuvent ne pas être des calculs graphique pour lesquels ont été conçu les GPU à l'origine. |
||
| − | |||
| + | Nous prenons OpenCL comme exemple pour l’exécution de calcul sur le GPU. |
||
== Mots Clés == |
== Mots Clés == |
||
| + | GPGPU, GPU, calculs hautes performances, OpenCL |
||
| − | - |
||
= Abstract = |
= Abstract = |
||
| + | GPGPU or General-purpose Processing on Graphics Processing Units. It's a methodology for high-performance computing that uses graphics processing. |
||
| − | - |
||
| + | Accelerated algorithms can be others than graphics algorithms that have enabled the development of GPU. |
||
| − | == Key Words == |
||
| + | We will use OpenCL to run algorithms on a GPU. |
||
| − | - |
||
| + | == Key Words == |
||
| + | GPGPU, GPU, HPC, OpenCL |
||
= Synthèse = |
= Synthèse = |
||
| − | - |
||
| + | ==Introduction== |
||
| − | = Les systèmes d'exploitation pour réseaux de capteurs et leurs caractéristiques = |
||
| + | [[Image:EA2014_GPGPU_graph.png|300px|thumb|right|Puissances de calcul brutes comparées entre GPU NVidia et CPU Intel de 2003 à 2008.]] |
||
| − | Les nœuds qui composent un réseau de capteur subissent de nombreuse contraintes. Ils sont tout d’abord limités par la capacité de leur batterie, la puissance de leur processeur et leur faible capacité de communication. |
||
| + | Les GPU ont été à l'origine concu pour les calculs graphiques permettant l'affichage sur un écran. Leur architecture est différente des CPU, les GPU contiennent beaucoup plus de cœurs permettant la parallélisation d'une même tache. Les écrans se modernisant, les besoins en calcul ont aussi augmenté et avec leur nombre de coeur, les GPU ont gagné en puissance brut comparé aux CPU. |
||
| + | En 2002, une importante avancée dans la flexibilité de la programmation des GPU facilite les calculs autres que graphiques sur ces circuits. |
||
| + | C'est la naissance de la méthode GPGPU. |
||
| + | [[Image:EA2014_GPGPU_power.png|300px|thumb|center|Representation schematique des coeurs des CPU et GPU]] |
||
| + | ==Motivations== |
||
| − | Un système d’exploitation devient alors nécessaire. En se présentant comme une interface entre les ressources matérielles limitées et des applications distribuées, il permet de faciliter la programmation des applications, mais aussi d’optimiser les utilisations de ressources. En effet il est capable de de gérer de nombreuses tâches telles que l’allocation de ressource sur les périphériques, l’interruption et la gestion et la planification de tâches, sans oublier la gestion du réseau support. |
||
| + | De nombreux domaines nécessitent des calculs à hautes performances. Le fait d'utiliser GPGPU pour une application est appelé acceleration GPU. |
||
| + | Les principaux domaines sont : |
||
| + | * Le traitement de l'image |
||
| + | * Les simulations (Météorologique, simulation neuronal, simulation de fluide etc ) |
||
| + | * Les outils scientifiques tel que Matlab |
||
| + | * Tout ce qui calcul sur de grands ensembles de données (Moteur physique etc..) |
||
| + | Les calculs hautes performances peuvent aussi être fait sur des CPU à l'aide de cluster mais le coût est incomparable. Le rapport prix/puissance baisse régulièrement grâce aux jeux vidéos qui démocratisent l'utilisation de GPU. |
||
| − | == |
+ | ==Pre-conditions== |
| + | Les algorithmes exécutés sur les GPU ne sont pas les même que ceux sur les CPU. Les algorithmes doivent être re-écris pour une exécution parallèle. |
||
| − | L’architecture d'un système d'exploitation ainsi que sur la façon de fournir des services aux programmes d'application sont des caractéristiques essentielles. |
||
| + | [[Image:EA2014_GPGPU_algorithme.png|300px|thumb|center|Exécution en série et exécution parallèle]] |
||
| + | Ce type d’exécution rend très efficace le traitement de grands ensembles de données dans le cas où le traitement est identique pour chacun de ces éléments. |
||
| + | ==Solutions== |
||
| − | Nous distinguons 4 types quatre types d'architectures de système d'exploitation : |
||
| + | Il y a trois grandes solutions. |
||
| − | *Monolithique : Les services fournis par le système d'exploitation sont mis en œuvre séparément et chaque service fournit une interface pour d'autres services. |
||
| − | *Micro Noyau : le noyau fournit le strict minimum pour assurer le fonctionnement du système. La plupart des fonctionnalités du système d'exploitation est fournie via des serveurs au niveau utilisateur comme un serveur de fichiers, un serveur de mémoire |
||
| − | *Modulaire ou composant : le système d'exploitation met en œuvre des services sous la forme de couches. |
||
| − | *Machine virtuelle : Le principe d'une machine virtuelle est d'intégrer le système d'exploitation à l'application de l'utilisateur |
||
| + | La plus ancienne est celle des shaders qui semblera familière aux utilisateurs d'OpenGL. |
||
| − | == Modèle d’exécution et ordonnancement == |
||
| − | On distingue 3 modèles d'exécution pour les réseaux de capteurs : |
||
| − | *'''Événementiel (Event-based) :''' qui donne la priorité aux événements. |
||
| − | *'''Multi Thread (Thread-based) :''' gestion de la préemption et de la concurrence |
||
| − | *'''Hybrid :''' qui combine les 2 modèles précédents |
||
| + | La second méthode est conçu par les constructeurs de GPU. Nvidia a fait CUDA et AMD FireStream par exemple. |
||
| − | En ce qui concerne l’ordonnancement, il y a deux catégories : |
||
| − | *'''L'ordonnancement en temps réel''' pour les applications en temps réel |
||
| − | *'''L’ordonnancement en temps partagé''' adapté aux événements asynchrones |
||
| + | La dernière méthode est celle présenté : OpenCL. |
||
| − | =TinyOS= |
||
| − | TinyOS est un système d’exploitation open-source conçu pour des réseaux de capteurs sans fil. Il a été créé pour répondre aux caractéristiques et aux nécessités des réseaux de capteurs, que sont : |
||
| − | *Une taille de mémoire réduite. |
||
| − | *Une basse consommation d’énergie. |
||
| − | *Des opérations d’assistance intensive. |
||
| − | *Des opérations robustes. |
||
| − | *L’optimisation en termes d’usage de mémoire et d’énergie. |
||
| + | ==OpenCl== |
||
| − | == Notions principales == |
||
| + | [[Image:EA2014_GPGPU_OpenClSurcouche.png|300px|thumb|right|OpenCl et certaines de ses surcouche]] |
||
| − | TinyOS est plus qu’un automate. Il repose sur une architecture basée sur une association de composants, réduisant la taille du code nécessaire à sa mise en place. Cette plate-forme logicielle ouverte, ainsi qu'une série d'outils, développés à la base par l'Université de Berkeley sont enrichis par une multitude d'utilisateurs. |
||
| + | OpenCl ou Open Computing Langage est un standard proposé par le Khronos Group. C'est un consortium industriel dont font parti entre autres Nvidia, ATI, AMD, ARM et Intel. |
||
| − | Les composants sont constitués d’une frame, de tâches et d’interfaces. |
||
| − | * '''Les frames''' contiennent l’état interne du composant. Il s’agit d’un espace mémoire de taille fixe réservée, permettant au composant de stocker les variables globales et les données qu’il utilise pour réaliser ses fonctionnalités. Il n’existe qu’une seule par composant et celle-ci est allouée statiquement à la compilation. |
||
| − | * '''Les tâches''' elles contiennent l’implémentation des fonctions métiers. Elle se subdivisent en deux catégories : les commandes et les évènements. |
||
| − | *'''Les interfaces''' représentent le descriptif de ces fonctions. |
||
| + | OpenCL spécifie une API et un langage. Le langage est un dérivé du C et permet d’écrire les algorithme à exécuter dans des fichiers ".cl" . L'API permet de gérer les entré sorties de l'algorithme, la synchronisation et l’exécution. |
||
| − | Il y a deux types de composants : |
||
| + | OpenCL permet d'utiliser GPGPU mais va au delà. Ce standard est conçu pour qu'avec le même code, l’exécution puisse être faite sur un GPU ou un CPU. |
||
| − | * '''Les modules''' |
||
| − | * '''Les configurations''' |
||
| + | ===Principes=== |
||
| + | Les programmes crées dans le langage OpenCl sont compilé à l’exécution à l'aide de l'API OpenCl. Cela rappel l'utilisation des shader dans OpenGl. |
||
| + | Il est possible de créer un pont entre OpenCl et OpenGl pour échanger des objets tel que des buffers. |
||
| + | [[Image:EA2014_GPGPU_OpenClexecution.jpg|300px|thumb|right|Organisation des executions dans OpenCl]] |
||
| − | TinyOS repose sur l’idéologie suivante : “Hurry up and sleep” (“Effectuer rapidement la tâche et se mettre en veille”). Ainsi il se met automatiquement en veille lorsqu’aucune tâche n’est active. |
||
| + | Le CUDA se basait sur l'unité "Thread" pour exprimé l’exécution parallèle. |
||
| + | Pour OpenCl, l'unité est le work-item. Pour chaque work-item, une execution de l'algorithme est invoqué. Chaque work-item a une memoire privée. |
||
| + | Les work-item sont rassemblé dans es work-group. Chaque work-item d'un work-group partagent une mémoire local. |
||
| + | Le nombre total de work-item est specifié par la taille des données à traiter. Il y a une memoire constante et une memoire globale partagé par tout les work-item. |
||
| + | OpenCl utilise la notion de dimension. Les work-item et les work-group peuvent être déclaré avec des indices dimensionnel plutôt qu'un entier simple. |
||
| − | Il est aussi dit '''event-driven''', c’est à dire que le fonctionnement du système s’appuie sur la gestion des évènements se produisant. Ces événements déclenchent à leur apparition l’activation de tâches, leur interruption ou encore la mise en veille du capteur. Par ailleurs, TinyOS ne gère pas le mécanisme de préemption entre les tâches mais donne la priorité aux interruptions matérielles. Il n’est pas prévu pour avoir un fonctionnement temps réel. |
||
| − | L’allocation mémoire |
||
| − | TinyOS ne nécessite pas beaucoup de place mémoire.Il n’a besoin que de 300 à 400 octets dans le cadre d’une distribution minimale. Il est primordial d’avoir 4 Ko de mémoire libre. L’allocation de la mémoire se fait de façon statique. On distingue dans celle-ci : |
||
| − | *'''La pile''' : Elle sert de mémoire temporaire pour l’empilement et le dépilement des variables locales. |
||
| − | *'''Les variables globales''' : Elles réservent un espace mémoire pour stocker des valeurs pouvant être accessibles depuis différentes tâches. |
||
| − | *'''La mémoire libre''' : Pour tout le reste du stockage temporaire. La notion d’allocation dynamique de mémoire n’est pas prise en charge dans le système, ni les pointeurs de fonctions |
||
| + | [[Image:EA2014_GPGPU_OpenClClasse.jpg|300px|right|right|Diagramme de classe de l'API]] |
||
| − | ==L’allocation de ressources== |
||
| + | L'API bien qu'initialement prevu en C est aussi decliné en C++. Le diagramme de classe associé permet de mieux comprendre la construction de l'API. |
||
| − | |||
| + | *Platform : Versions d'OpenCL exécutables sur cette machines |
||
| − | L’Ordonnanceur TinyOS est caractérisé par ces '''deux niveaux de priorité''' (bas pour les tâches, haut pour les événements) et sa '''file d’attente FIFO''' (disposant d’une capacité de 7). |
||
| + | *Device : Les GPU ou CPU supportant la plateformes. |
||
| − | |||
| + | *Program : Un fichier .cl une fois compilé. |
||
| − | ==Le langage : NesC== |
||
| + | *Kernel : L'un des points d'entré du programme. |
||
| − | '''NesC''' est un langage de programmation dérivé du langage C, conçu pour minimiser l’utilisation de mémoire et de puissance de calcul par les capteurs, qui très souvent disposent de ressources très limitées (batterie de faible puissance et non changeable, mémoire réduite...). Il est ainsi essentiellement dédié pour la réalisation de systèmes embarqués distribués. Il cible en particulier l’implémentation d’applications pour les réseaux de capteurs. Il offre donc une réactivité importante vis-à-vis de l’environnement, une gestion de la concurrence même intensive et un support de communication. Il propose de nombreuses optimisations pour diminuer l’occupation de l’espace mémoire. |
||
| + | *Command Queue : La serie de command que devra executer un "device". |
||
| − | |||
| − | NesC permet la décomposition d’une application en « modules » réutilisables en fournissant d’abord trois abstractions de programmation : les interfaces, les modules et les configurations. |
||
| − | |||
| − | Les '''interfaces''' spécifient un ensemble de fonctions, appelées commandes : |
||
| − | |||
| − | Interface Timer { |
||
| − | command result_t start(char type, uint32_t interval); |
||
| − | command result_t stop(); |
||
| − | event result_t fired(); |
||
| − | } |
||
| − | |||
| − | Eléments de base de la programmation, les '''modules''' permettent d’implémenter les composants. |
||
| − | |||
| − | module NomModuleM { |
||
| − | provides { |
||
| − | //liste des interfaces fournies, ex : |
||
| − | interface NomInterfaceFournie1 ; |
||
| − | } |
||
| − | uses { |
||
| − | //liste des interfaces requises, ex : |
||
| − | interface NomInterfaceRequise1 ; |
||
| − | } |
||
| − | } |
||
| − | implementation { |
||
| − | //déclarations des variables, ex : |
||
| − | int state ; |
||
| − | //implementations des fonctions decrites par les |
||
| − | //interfaces fournies ; |
||
| − | } |
||
| − | |||
| − | Les '''configurations''' sont constituées de modules et/ou d’interfaces ainsi que de la description des liaisons entre ces composants. |
||
| − | |||
| − | configuration NomModule { |
||
| − | } |
||
| − | implementation { |
||
| − | //liste des modules et configurations utilises, ex : |
||
| − | components Main,Module1,...,ModuleN,Config1,...,ConfigM ; |
||
| − | //descriptifs des liaisons |
||
| − | //Interface fournie <- Interface requise ou |
||
| − | //Interface requise -> interface fournie, ex : |
||
| − | Main.StdControl -> Module1.StdControl ; |
||
| − | } |
||
| − | |||
| − | ==Le simulateur TOSSIM== |
||
| − | TOSSIM est un simulateur à événements discrets pour les réseaux de capteurs TinyOS. Il permet aux utilisateurs de déboguer, tester et analyser des algorithmes dans un environnement contrôlé et reproductible. Sachant que TOSSIM fonctionne sur un PC, les utilisateurs peuvent examiner leur code de TinyOS en utilisant les débogueurs et autres outils de développement. |
||
| − | L'objectif principal de TOSSIM est de fournir une simulation de haute fidélité de demandes TinyOS. Pour cette raison, il se concentre sur la simulation TinyOS et son exécution, au lieu de la simulation du monde réel. Alors que TOSSIM peut être utilisée pour comprendre les causes du comportement observé dans le monde réel, il ne saisit pas tous d'entre eux, et ne doit pas être utilisé pour les évaluations absolues. |
||
| − | |||
| − | TOSSIM dispose d'une GUI JTOSSIM. Il permet de définir les paramètres de simulation (comme les paramètres de la radio et la topologie du réseau) et offre une visualisation différente des résultats des simulations. |
||
| − | |||
| − | [[Image:jtossim.jpg|250px|thumb|right|Capture d'écran d'une simulation sur JTOSSIM]] |
||
| − | |||
| − | ==Domaines d’utilisation== |
||
| − | La répartition des applications dépend du but pour lequel les capteurs en réseau sont utilisés. |
||
| − | Nous pouvons distinguer quatre domaines majeurs : |
||
| − | *Domaine militaire (espionnage) |
||
| − | *Environnemental (contrôle de la température ambiante, de la lumière, de l'air conditionné, de la qualité de l'air) |
||
| − | *Santé (traçage de l'utilisation des médicaments par les patients et les médecins dans les hôpitaux) |
||
| − | *Industrie (contrôle du niveau de liquide dans des réservoirs à carburant multiple dans le raffinage de pétrole et des installations de stockage) |
||
| − | |||
| − | |||
| − | =Conclusion= |
||
| − | En conclusion, l'apport d'une ingénierie logicielle sur les réseaux de capteurs est considérable mais également essentiel. En effet, les contraintes associées aux capteurs et à leur mise en réseau sont très fortes. Pour résoudre la plupart de ses contraintes, des systèmes d'exploitation telles que TinyOS basé événement apportent des solutions, mais qui malheureusement ne couvrent pas l'ensemble de ses contraintes. Pour palier ainsi aux limites des systèmes existants, de nombreuses autres tels que Mbed OS sont en cours de développement. |
||
| + | ==Conclusion== |
||
| + | L'un des principaux problème de accélération GPU et qu'ils étaient soit difficile à utiliser (au travers des shader) soit limité à certaines machine de par l’implémentation propre à chaque propriétaire. OpenCl résout ce problème partiellement en offrant un standard inter-constructeur. OpenCl est maintenant disponible dans plusieurs langages, permet à toutes les cartes compatibles d'utiliser GPGPU et d'effectuer des calculs hautes performances. CUDA reste tout d même le plus utilisé pour l'acceleration GPU. |
||
= Notes et références = |
= Notes et références = |
||
| + | *Alexandre Chariot, Quelques Applications de la Programmation des Processeurs Graphiques à la Simulation Neuronale et à la Vision par Ordinateur, Thèse, [https://tel.archives-ouvertes.fr/file/index/docid/501212/filename/These_AChariot.pdf] |
||
| + | * [https://software.intel.com/en-us/intel-opencl https://software.intel.com/en-us/intel-opencl] |
||
| − | == TinyOS == |
||
| − | |||
| − | *[http://norbertobarrocablog.wordpress.com/2012/12/19/how-to-install-tinyos-2-1-2-on-ubuntu-12-04/ Guide d'installation détaillé de TinyOS] |
||
| + | * [http://jorudolph.wordpress.com/2012/02/03/opencl-work-item-ids-globalgrouplocal/ http://jorudolph.wordpress.com/2012/02/03/opencl-work-item-ids-globalgrouplocal/] |
||
| − | *[http://www.tinyos.net/ Site officiel de TinyOS] |
||
| + | Permet de comprendre le fonctionnement des ID dans OpenCl |
||
| + | *[http://gpgpu.org/ http://gpgpu.org/] |
||
| − | *[https://github.com/tinyos/tinyos-main Dépôt officiel de TinyOS] |
||
| + | *[https://www.khronos.org/registry/cl/specs/opencl-1.2.pdf OpenCl specification] |
||
| − | == JTOSSIM == |
||
| − | * [http://arni.epfl.ch/software/jtossim_tutorial Guide d'installation de JTOSSIM ] |
||
| + | *[https://www.khronos.org/ https://www.khronos.org/] |
||
| − | == Documentation == |
||
| − | * [http://fr.wikipedia.org/wiki/Syst%C3%A8me_d'exploitation_pour_capteur_en_r%C3%A9seau Système d'exploitation pour capteur en_réseau] |
||
| − | * [http://imag-moodle.e.ujf-grenoble.fr/mod/resource/view.php?id=7828 Cours de Bernard TOURANCHEAU] |
||
Latest revision as of 14:07, 17 October 2014
Présentation
- Enseignants : Georges-Pierre Bonneau, Didier Donsez (EA2014)
- Sujet : GPGPU
- Date : 17 octobre 2014
- Auteur : William Bobo <william.bobo@e.ujf-grenoble.fr>
- Lien vers les slides de la présentation : [Transparents]
Résumé
GPGPU ou General-purpose Processing on Graphics Processing Units. C'est une méthode permettant l’exécution de calculs hautes performances sur des GPU. Ces calculs peuvent ne pas être des calculs graphique pour lesquels ont été conçu les GPU à l'origine. Nous prenons OpenCL comme exemple pour l’exécution de calcul sur le GPU.
Mots Clés
GPGPU, GPU, calculs hautes performances, OpenCL
Abstract
GPGPU or General-purpose Processing on Graphics Processing Units. It's a methodology for high-performance computing that uses graphics processing. Accelerated algorithms can be others than graphics algorithms that have enabled the development of GPU. We will use OpenCL to run algorithms on a GPU.
Key Words
GPGPU, GPU, HPC, OpenCL
Synthèse
Introduction
Les GPU ont été à l'origine concu pour les calculs graphiques permettant l'affichage sur un écran. Leur architecture est différente des CPU, les GPU contiennent beaucoup plus de cœurs permettant la parallélisation d'une même tache. Les écrans se modernisant, les besoins en calcul ont aussi augmenté et avec leur nombre de coeur, les GPU ont gagné en puissance brut comparé aux CPU. En 2002, une importante avancée dans la flexibilité de la programmation des GPU facilite les calculs autres que graphiques sur ces circuits. C'est la naissance de la méthode GPGPU.
Motivations
De nombreux domaines nécessitent des calculs à hautes performances. Le fait d'utiliser GPGPU pour une application est appelé acceleration GPU. Les principaux domaines sont :
- Le traitement de l'image
- Les simulations (Météorologique, simulation neuronal, simulation de fluide etc )
- Les outils scientifiques tel que Matlab
- Tout ce qui calcul sur de grands ensembles de données (Moteur physique etc..)
Les calculs hautes performances peuvent aussi être fait sur des CPU à l'aide de cluster mais le coût est incomparable. Le rapport prix/puissance baisse régulièrement grâce aux jeux vidéos qui démocratisent l'utilisation de GPU.
Pre-conditions
Les algorithmes exécutés sur les GPU ne sont pas les même que ceux sur les CPU. Les algorithmes doivent être re-écris pour une exécution parallèle.
Ce type d’exécution rend très efficace le traitement de grands ensembles de données dans le cas où le traitement est identique pour chacun de ces éléments.
Solutions
Il y a trois grandes solutions.
La plus ancienne est celle des shaders qui semblera familière aux utilisateurs d'OpenGL.
La second méthode est conçu par les constructeurs de GPU. Nvidia a fait CUDA et AMD FireStream par exemple.
La dernière méthode est celle présenté : OpenCL.
OpenCl
OpenCl ou Open Computing Langage est un standard proposé par le Khronos Group. C'est un consortium industriel dont font parti entre autres Nvidia, ATI, AMD, ARM et Intel.
OpenCL spécifie une API et un langage. Le langage est un dérivé du C et permet d’écrire les algorithme à exécuter dans des fichiers ".cl" . L'API permet de gérer les entré sorties de l'algorithme, la synchronisation et l’exécution. OpenCL permet d'utiliser GPGPU mais va au delà. Ce standard est conçu pour qu'avec le même code, l’exécution puisse être faite sur un GPU ou un CPU.
Principes
Les programmes crées dans le langage OpenCl sont compilé à l’exécution à l'aide de l'API OpenCl. Cela rappel l'utilisation des shader dans OpenGl. Il est possible de créer un pont entre OpenCl et OpenGl pour échanger des objets tel que des buffers.
Le CUDA se basait sur l'unité "Thread" pour exprimé l’exécution parallèle. Pour OpenCl, l'unité est le work-item. Pour chaque work-item, une execution de l'algorithme est invoqué. Chaque work-item a une memoire privée. Les work-item sont rassemblé dans es work-group. Chaque work-item d'un work-group partagent une mémoire local. Le nombre total de work-item est specifié par la taille des données à traiter. Il y a une memoire constante et une memoire globale partagé par tout les work-item.
OpenCl utilise la notion de dimension. Les work-item et les work-group peuvent être déclaré avec des indices dimensionnel plutôt qu'un entier simple.
L'API bien qu'initialement prevu en C est aussi decliné en C++. Le diagramme de classe associé permet de mieux comprendre la construction de l'API.
- Platform : Versions d'OpenCL exécutables sur cette machines
- Device : Les GPU ou CPU supportant la plateformes.
- Program : Un fichier .cl une fois compilé.
- Kernel : L'un des points d'entré du programme.
- Command Queue : La serie de command que devra executer un "device".
Conclusion
L'un des principaux problème de accélération GPU et qu'ils étaient soit difficile à utiliser (au travers des shader) soit limité à certaines machine de par l’implémentation propre à chaque propriétaire. OpenCl résout ce problème partiellement en offrant un standard inter-constructeur. OpenCl est maintenant disponible dans plusieurs langages, permet à toutes les cartes compatibles d'utiliser GPGPU et d'effectuer des calculs hautes performances. CUDA reste tout d même le plus utilisé pour l'acceleration GPU.
Notes et références
- Alexandre Chariot, Quelques Applications de la Programmation des Processeurs Graphiques à la Simulation Neuronale et à la Vision par Ordinateur, Thèse, [1]
Permet de comprendre le fonctionnement des ID dans OpenCl