EA2014 GPGPU: Difference between revisions

From air
Jump to navigation Jump to search
 
(50 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Image:OspourCapteurs.jpg|right|thumb|300px|Caractéristiques d'un système d'exploitation pour capteur]]
[[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 : [Media:EA2104_GPGPU.pdf]
* 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.
Un réseau de capteurs sans fils (wireless sensor network) est un réseau informatique constitué de plusieurs capteurs appelés nœuds. Ces nœuds, chargés de relever et de router les informations relevées sur une zone couverte, sont constitués au minimum d’un micro-processeur d’une mémoire vive, d’une interface radio, de micro-capteurs et d’une source d'énergie.
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.
L’utilisation des capteurs sans fil est aujourd’hui de plus en plus demandée dans de nombreux domaines, dans le cadre de la supervision et la sécurité. Ainsi, pour améliorer la performance de ces réseaux de capteurs, des systèmes d’exploitation comme TinyOS sont mis en place pour gérer les ressources limitées telles que l’énergie.

== Mots Clés ==
== Mots Clés ==
GPGPU, GPU, calculs hautes performances, OpenCL
Réseau, capteur, sans fil, nœud, système d'exploitation, performance, ressources limitées


= Abstract =
= Abstract =
GPGPU or General-purpose Processing on Graphics Processing Units. It's a methodology for high-performance computing that uses graphics processing.
A wireless sensor network is a computer network consisting of multiple sensors called nodes. These nodes, responsible for retrieving and routing information collected on a covered area, consist of at least a microprocessor, a RAM, a radio interface, micro-sensors and a source of energy.
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.
The use of wireless sensors is now increasingly requiered in many fields, for the supervision and security. Thus, to improve the performance of these sensor networks, operating systems such as TinyOS are set up in order to manage limited resources such as energy.
== Key Words ==
== Key Words ==
GPGPU, GPU, HPC, OpenCL
Network, sensor, wireless, node, operating system, performance, limited resources


= Synthèse =
= Synthèse =


==Introduction==
Un capteur en réseau est défini comme un ensemble d’éléments électroniques de taille réduite, composé essentiellement d'un détecteur, d'un microcontrôleur, d’une batterie, d'un émetteur-récepteur et d'une antenne. Ces capteurs peuvent être reliés ensemble pour former un réseau sans fil.
Un réseau de capteurs sans fil est donc un réseau ad hoc composé d’un grand nombre de noeuds qui désignent ces capteurs capables de récolter, de transmettre et renseigner sur plusieurs données de manière autonome.


[[Image:EA2014_GPGPU_graph.png|300px|thumb|right|Puissances de calcul brutes comparées entre GPU NVidia et CPU Intel de 2003 à 2008.]]
L’utilisation des capteurs sans fil est aujourd’hui de plus en plus requise dans des domaines tels que la supervision et la sécurité. Ils se basent sur des protocoles pour communiquer entre eux et proposent des programmes et des réseaux embarqués. A leur début, ces capteurs étaient uniquement composé d’un système dédié à une application précise (Par exemple, capteur permettant de relever la température ambiante d’un milieu, est uniquement constitué d’un thermomètre électronique et d’un afficheur digital). Avec de nouvelles contraintes comme la recherche applicative, ils sont aujourd’hui gérés par des systèmes d’exploitation spécialisés.
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.
Ces systèmes d’exploitation pour capteur en réseau, appelés également WSN, sont par conséquent des systèmes d'exploitation embarqués au sein de capteurs en réseau. Développé et soutenu par l’université américaine de Berkeley, TinyOS est un des premiers systèmes d'exploitation conçus pour les réseaux de capteurs. Il est aujourd’hui le plus répandu et celui qui nous intéressera en particulier.
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==
[[Image:sensors.png|250px|thumb|center|Réseau de capteurs]]
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 systèmes d'exploitation pour réseaux de capteurs et leurs caractéristiques =
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.
[[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==
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.
Il y a trois grandes solutions.


La plus ancienne est celle des shaders qui semblera familière aux utilisateurs d'OpenGL.
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.


La second méthode est conçu par les constructeurs de GPU. Nvidia a fait CUDA et AMD FireStream par exemple.
== Architecture ==
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.


La dernière méthode est celle présenté : OpenCL.
Nous distinguons 4 types quatre types d'architectures de système d'exploitation :
*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


==OpenCl==
== 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


[[Image:EA2014_GPGPU_OpenClSurcouche.png|300px|thumb|right|OpenCl et certaines de ses surcouche]]
En ce qui concerne l’ordonnancement, il y a deux catégories :
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.
*'''L'ordonnancement en temps réel''' pour les applications en temps réel
*'''L’ordonnancement en temps partagé''' adapté aux événements asynchrones


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.
=TinyOS=
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.
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.


===Principes===
== Notions principales ==
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 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.
Le CUDA se basait sur l'unité "Thread" pour exprimé l’exécution parallèle.
Les composants sont constitués d’une frame, de tâches et d’interfaces.
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 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 work-item sont rassemblé dans es work-group. Chaque work-item d'un work-group partagent une mémoire local.
* '''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.
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.
*'''Les interfaces''' représentent le descriptif de ces fonctions.


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 y a deux types de composants :
* '''Les modules'''
* '''Les configurations'''




[[Image:EA2014_GPGPU_OpenClClasse.jpg|300px|right|right|Diagramme de classe de l'API]]
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.
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
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.
*Device : Les GPU ou CPU supportant la plateformes.

*Program : Un fichier .cl une fois compilé.
L’allocation mémoire
*Kernel : L'un des points d'entré du programme.
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 :
*Command Queue : La serie de command que devra executer un "device".
*'''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

==L’allocation de ressources==

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).

==Le langage : NesC==
'''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.

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 12:07, 17 October 2014

Logo d'OpenCL

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

Puissances de calcul brutes comparées entre GPU NVidia et CPU Intel de 2003 à 2008.

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.

Representation schematique des coeurs des CPU et GPU

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.

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

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 et certaines de ses surcouche

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.

Organisation des executions dans OpenCl

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.


Diagramme de classe de l'API

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

Retrieved from "https://air.imag.fr/index.php?title=EA2014_GPGPU&oldid=18757"