Calcul intensif sur GPU - Computer Science and Management Group

Calcul intensif sur GPU:
exemples en traitement d’images, en
bioinformatique et en télécommunication
Sidi Ahmed Mahmoudi, Sébastien Frémal, Michel Bagein, Pierre Manneback
Université de Mons, Faculté Polytechnique
Service d’nformatique
20, Place du Parc
7000 Mons, Belgique
Email: {Sidi.Mahmoudi, Sebastien.Fremal, Michel.Bagein, Pierre.Manneback}@umons.ac.be
Résumé – Les Processeurs Graphiques ou GPUs
sont devenus en quelques années des outils puissants
pour le calcul intensif massivement parallèle. On les
retrouve actuellement exploités par exemple pour des
applications en traitement multimédia, en modélisation
numérique ou en bioinformatique. Leurs avantages sont
un coût modique, une accélération de traitement et
une baisse de consommation énergétique par rapport à
une puissance CPU équivalente. Nous proposons dans
cette contribution d’exploiter les GPUs pour améliorer
les performances de méthodes de traitement d’images
ainsi que celles d’applications en bioinformatique et
en télécommunications. Nous proposons aussi une
implémentation hybride de méthodes de traitement
d’images, basée sur l’exploitation de l’intégralité des
ressources hétérogènes de calcul à disposition (multiCPU/multi-GPU).
Mots Clés – GPU, multicoeur hétérogène, traitement
d’images, agglomération, télécommunication
I. I NTRODUCTION
Ces dernières années, l’accélération de performances des
processeurs centraux (CPU) s’est retrouvée plafonnée, pour
des raisons thermiques, à environ 4 GHz. Cette limitation a
été contournée par un changement des architectures internes
des processeurs en multipliant des unités de calcul intégrées
dans les processeurs. L’objectif de ces nouvelles architectures
est de multiplier le nombre d’unités de traitement (coeurs) sur
la mémoire centrale (RAM CPU), permettant ainsi de faire
tourner simultanément plusieurs applications indépendantes.
Les processeurs graphiques (GPU), qui équipent les ordinateurs personnels, sont dévolus aux traitements spécialisés de
rendus d’images 2D/3D, des applications graphiques ainsi que
des jeux vidéo. Spécialisés pour des traitements synchrones de
grosses quantités de données, les GPUs possèdent nativement
une structure de coeurs massivement parallèle (jusqu’à 3840)
et offrent des puissances brutes de calcul largement supérieures
aux CPUs. A la différence des CPUs multi-coeurs, les coeurs
des GPUs fonctionnent de manière synchrone en appliquant
simultanément la même opération sur des données multiples
(SIMD) dans leur propre espace mémoire (RAM-GPU). Une
tendance est actuellement de proposer la convergence des ces
deux types d’unités de calcul, avec la propsition de processeurs
accélérés (APU), combinant CPU et GPU sur la même puce
et partageant le même espace mémoire [1].
Avec l’ouverture des interfaces de programmation (API)
des GPUs, de nombreux chercheurs ont entrepris de les
exploiter pour booster les traitements, habituellement destinés
aux CPUs. Les calculs peuvent donc être portés sur GPU,
mais le mode de fonctionnement SIMD de ces derniers impose
la nécessité d’une grande quantité de données en entrée. En
effet, ces processeurs tirent leurs forces du recouvrement des
threads inactifs (en attente de données à distance du coeur)
par l’exécution d’autres threads actifs (dont les données sont
disponibles). S’il n’y a pas suffisamment de données, les
threads seront en nombre insuffisant pour assurer un fonctionnement à plein régime du processeur graphique, et celui-ci
verra ses performances se dégrader [2].
Les algorithmes de visualisation et de traitement d’images
sont à la fois de gros consommateurs de puissance de calcul
et de mémoire. Au-delà du rendu 2D/3D, la majorité de
ces algorithmes contiennent des phases qui consistent en des
calculs similaires entre les pixels de l’image ce qui se prête
bien à une parallélisation sur GPU. Dans cette catégorie,
Yang et al. ont mis en oeuvre plusieurs algorithmes classiques de traitement d’images sur GPU avec CUDA [3]. On
trouve aussi dans le projet OpenVIDIA [4] une collection
d’implémentations d’algorithmes de vision par ordinateur sur
des processeurs graphiques, utilisant OpenGL [5], Cg [6] et
CUDA [7]. Luo et al. ont proposé une implémentation GPU de
la méthode d’extraction de contours [8] basée sur le détecteur
de Canny [9]. Il existe aussi des implémentations sur GPU
dédiées au monde médical, permettant notamment le calcul
du rendu d’images volumineuses [10], [11], ainsi que des
reconstructions d’images IRM [12].
Dans le domaine de la bioinformatique, les GPUs sont aussi
prisés pour le traitement des séquences ADN. Avec quelques
milliards de nucléotides (3 milliards de paires pour l’homme
et jusqu’à 150 milliards pour la Paris Japonica [13]), les
GPUs permettent de réduire significativement les temps de
traitements algorithmiques de ces chaı̂nes, notamment pour
les tris de très gros volumes de données (tris bitonique et par
base) [14]. Le domaine des télécommunications utilise par
exemple les GPUs pour accélérer le calcul de la dispersion
obtenue dans le cadre des entrelaceurs de bits par blocs [15].
Ici aussi les données ne manquent pas : une matrice d’entrée
de taille MxN offre un domaine de M N solutions à explorer,
soit 135012 (3, 66 × 1037 ) dans le cadre de nos recherches.
Par ailleurs, il existe différents travaux pour l’exploitation
de plateformes multi-coeurs et hétérogènes. Ayguadé et al.
ont proposé un modèle de programmation flexible sur plateformes multi-coeurs [16]. StarPU [17] offre un support
exécutif unifié pour les architectures multi-coeurs hétérogènes
(CPUs et GPUs), permettant de concevoir des stratégies
d’ordonnancement efficaces.
Notre contribution porte sur le développement d’approches
efficaces non seulement pour la parallélisation d’algorithmes
de traitement d’images, mais aussi sur l’adaptation de ces
algorithmes pour exploiter au mieux la puissance de calcul des nouvelles architectures parallèles hétérogènes. Nous
contribuons ainsi à la mise en évidence de l’efficacité
de l’agglomération des données en temps que technique
d’optimisation, cette méthode permettant de maximiser
l’exploitation de la mémoire GPU et d’en améliorer par
conséquent les performances. La contribution est organisée
comme suit : la deuxième section décrit l’utilisation du GPU
en traitement d’images, en proposant un modèle basé sur
CUDA et OpenGL, et en décrivant l’implémentation GPU de
méthodes de détection des coins et contours. La troisième
section présente une méthode d’agglomération de données
pour processeurs graphiques, avec des applications dans les
domaines des télécommunications et de la bioinformatique.
La quatrième section expose l’exploitation des architectures
hétérogènes (multi-CPU/multi-GPU) pour améliorer les performances des applications intensives en calcul, et en particulier des méthodes de traitement d’ensemble d’images volumineuses. Finalement, la dernière section est consacrée à la
conclusion et aux perspectives.
II. T RAITEMENT D ’ IMAGES SUR GPU
Les algorithmes de traitement, et en particulier les méthodes
d’extraction des caractéristiques (coins, contours) représentent
un excellent champ d’applications pour l’accélération sur
GPU, puisque la majorité de ces algorithmes disposent de
sections de traitements identiques sur les pixels. Nous proposons dans cette section un modèle de traitement d’images
sur GPU, ainsi que les implémentations GPU des méthodes
de détection des coins et contours basées sur ce modèle. Cette
section est donc présentée en trois parties: la première partie
décrit notre modèle proposé pour le traitement d’images sur
GPU. La deuxième partie décrit l’implémentation GPU de la
méthode de détection des coins basée sur le détecteur de Harris
[18]. La troisième partie présente l’implémentation GPU de
l’approche de détection des contours basée sur le principe de
Deriche utilisant les critères de Canny [19].
A. Modèle proposé pour le traitement d’images sur GPU
Nous proposons dans ce paragraphe un modèle de
traitement d’images sur GPU, permettant le chargement, le
traitement et l’affichage d’images sur processeurs graphiques.
Notre modèle s’appuie sur CUDA pour les traitements
parallèles et OpenGL pour la visualisation des résultats, ce
qui permet de réduire les coûts de transfert de données entre
la mémoire CPU et la mémoire GPU. Ce modèle repose sur
quatre étapes principales (Fig. 1)
1) Chargement des images d’entrée: Le transfert des
images d’entrée depuis la mémoire CPU vers la mémoire
GPU permet de les traiter sur GPU par la suite.
2) Allocation des threads: Après chargement de l’image en
mémoire GPU, le nombre de threads de la grille de calcul GPU est déterminé de telle sorte que chaque thread
puisse effectuer son traitement sur un ou plusieurs pixels
groupés. La sélection du nombre de threads dépend du
nombre de pixels de l’image.
3) Traitement parallèle avec CUDA: Les fonctions CUDA
(kernels) sont exécutées N fois en utilisant les N threads
créés lors de l’étape précédente.
4) Présentation des résultats: A l’issue des traitements,
les résultats peuvent être présentés en utilisant deux
scénarios différents:
• Visualisation OpenGL: L’affichage des images de
sortie avec la bibliothèque OpenGL permet une
visualisation rapide grâce à la réutilisation de zones
mémoires allouées par CUDA dans les fonctions
OpenGL. En effet, la compatibilité d’OpenGL avec
CUDA permet ainsi de supprimer des transferts de
données. Ce scénario est utile lorsqu’on applique le
traitement GPU sur une seule image.
• Transfert des résultats: La visualisation sous
OpenGL n’est plus requise lorsque l’on désire
sauvegarder les images traitées. Dans ce cas, le
transfert des images résultats depuis la mémoire
GPU vers la mémoire CPU est indispensable. Le
temps de transfert de ces images représente un coût
supplémentaire pour l’application.
B. Extraction des points d’intérêts dans une image sur GPU
Les méthodes d’extraction des points d’intérêts représentent
des étapes préliminaires à de nombreux processus de vision
par ordinateur. Ce paragraphe présente notre implémentation
GPU du détecteur de coins utilisant la technique décrite par
Bouguet [20] et basée sur le principe de Harris. Cette méthode
est connue pour son efficacité, due à sa forte invariance à la
rotation, à l’échelle, à la luminosité et au bruit de l’image.
Sur base du modèle décrit dans la section II.A, nous avons
parallélisé cette méthode en implémentant chacune de ses cinq
étapes sur GPU (Fig. 2):
2)
Fig. 1.
Modèle de traitement d’images sur GPU avec CUDA et OpenGL.
3)
4)
5)
Fig. 2.
Détection des points d’intérêts (coins) sur GPU
de pixels de l’image. Chaque thread calcule les dérivées
spatiales d’un pixel en utilisant les équations (1) et (2).
Ensuite, le thread peut calculer le gradient spatial de
chaque point de l’image en appliquant l’équation (3).
Les valeurs des pixels voisins (gauche, droit, haut et
bas) de chaque point sont chargées dans la mémoire
partagée du GPU, puisque ces valeurs sont utilisées pour
le calcul des dérivées spatiales. Cela permet d’accéder
plus rapidement aux données.
Calcul des valeurs propres de la matrice du gradient:
Sur base du gradient calculé par l’équation (3), on
calcule les valeurs propres de la matrice G pour chaque
pixel. L’implémentation GPU de cette étape est effectuée
par le calcul de ces valeurs en parallèle sur les pixels de
l’image, en utilisant une grille de calcul GPU contenant
un nombre de threads égal au nombre de points de
l’image.
Recherche de la valeur propre maximale: Une fois
les valeurs propres calculées, on extrait la valeur propre
maximale. Cette valeur est obtenue sur GPU en faisant
appel à la librairie CUBLAS [21].
Suppression des petites valeurs propres: La recherche
des petites valeurs propres est réalisée de telle sorte que
chaque thread compare la valeur propre de son pixel
correspondant à la valeur propre maximale. Si cette
valeur est inférieure à 5% de la valeur maximale, ce
pixel est exclu.
Sélection des meilleures valeurs: La dernière étape
permet d’extraire pour chaque zone de l’image le
pixel ayant la plus grande valeur propre. Pour
l’implémentation sur GPU, nous avons affecté à chaque
thread GPU un groupe de pixels représentant une zone
(10x10 pixels). Chaque thread permet d’extraire la
valeur propre maximale dans une zone en utilisant toujours la libraire CUBLAS. Les pixels ayant ces valeurs
extraites représentent ainsi les points d’intérêts.
C. Détection des contours sur GPU
1) Calcul des dérivées et du gradient spatial: La première
étape est le calcul de la matrice du gradient spatial G
pour chaque pixel de l’image I, en utilisant l’équation
(3). Cette matrice de 4 éléments (2x2) est calculée sur
base des dérivées spatiales Ix , Iy calculées suivant les
équations (1) et (2).
Ix (x, y) =
I(x + 1, y) − I(x − 1, y)
2
I(x, y + 1) − I(x, y − 1)
2
2
Ix
Ix Iy
G=
Ix Iy
Iy2
Iy (x, y) =
(1)
(2)
(3)
L’implémentation GPU est effectuée par un traitement
parallèle des pixels, en utilisant une grille de calcul
GPU contenant un nombre de threads égal au nombre
Ce paragraphe présente l’implémentation GPU de la
méthode de détection des contours basée sur la technique
récursive de Deriche [19]. L’immunité au bruit de troncature
et le nombre réduit d’opérations de cette approche la rendent
très efficace au niveau de la qualité des contours extraits.
Cependant, cette méthode est entravée par les coûts de calcul
qui augmentent considérablement en fonction du nombre et de
la taille des images utilisées. Cette technique est composée de
quatre étapes principales (Fig. 3). Notons que l’étape du calcul
des gradients applique un lissage gaussien récursif avant de
filtrer l’image en utilisant les filtres de Sobel [9]. Toutefois,
les étapes de calcul de la magnitude et de la direction du
gradient, la suppression des non maxima, ainsi que le seuillage
sont les mêmes que celles utilisées pour le filtre de Canny.
Ces dernières étapes permettent de sélectionner les meilleurs
contours sur base des magnitudes et directions des gradients calculés précédemment. L’implémentation GPU de cette
méthode est décrite en détail dans [22]. Cette implémentation
est essentiellement basée sur le modèle proposé dans la section
III.
Fig. 3.
Détection des contours basée sur le principe de Deriche-Canny
Des résultats expérimentaux ont été obtenus en utilisant
des ensembles d’images (images médicales, images HD),
montrant une accélération allant d’un facteur de 10 à 20
par rapport à une implémentation séquentielle sur CPU. La
Table I montre la comparaison des temps de calcul entre les
implémentations séquentielles (CPU) et parallèles (GPU) de
la méthode regroupant la détection des coins ainsi que les
contours, appliquées sur des images de différentes résolutions.
Notons que les facteurs d’accélérations présentés dans la Table
I augmentent considérablement en fonction de la taille des
images utilisées. Ceci est interprété par l’exploitation de plus
d’unités de calcul en parallèle sur GPU.
Résolution
d’image
512*512
1024*1024
1476*1680
3936*3936
Détection
Coins + Contours
(CPU: OpenCV)
75 ms
201 ms
543 ms
2 297 ms
Détection
Coins + Contours
(CUDA + OpenGL)
6.86 ms
14.14 ms
32.87 ms
109.74 ms
Accélération
illustré dans cette section à l’aide de deux exemples : le tri de
vecteurs à l’aide des algorithmes de tri par base (radix sort) et
de tri fusion (merge sort), ainsi qu’une application du domaine
des télécommunications qui calcule la valeur optimale du
paramètre twist intervenant dans l’entrelacement des bits d’un
message.
Le tri de vecteur a été étudié dans le cadre d’une application de recherche de similitudes de chaı̂nes ADN/ARN en
bioinformatique. L’algorithme passe une partie importante de
son temps à effectuer des tris de petits vecteurs contenant
de 70 à 2000 éléments. La parallélisation des opérations
de tri sur GPU a été étudiée. Les résultats présentés dans
cet article ont été obtenus avec le tri de la librairie Thrust
[25], un tri conçu pour processeur graphique et très flexible
au niveau des données d’entrée. Pour de faibles quantités
de données, l’implémentation GPU est moins efficace que
son équivalent sur CPU : un tableau de 500 éléments de 8
octets est trié 17,36 fois plus rapidement par un processeur
central. L’agglomération des tâches de tri par concaténation
des vecteurs d’entrée fournit une plus grande charge de travail
au GPU. A partir de 2 à 3 vecteurs agglomérés, les résultats
s’inversent au profit du GPU et permettent d’atteindre des
accélérations de l’ordre de 15,6 fois plus rapide que le CPU
(Fig. 4(a)).
10.93
14.21
16.51
20.93
TABLE I
P ERFORMANCE DE D ÉTECTION DES COINS + CONTOURS SUR GPU
(CUDA + O PEN GL) PAR RAPPORT AU CPU (O PEN CV)
Notons que les implémentations CPU étaient effectuées avec
la bibiothèque OpenCV [23], permettant le traitement d’image
sur CPU.
III. L’ AGGLOM ÉRATION SUR PROCESSEURS GRAPHIQUES
L’efficacité des processeurs graphiques a été montrée dans
le cas des algorithmes de type flux de données dans la section
précédente, cette section l’illustrera dans le cas des algorithmes
de type flux de contrôle. Les flux de contrôle impliquent une
mise à disposition séquentielle des données. Le lancement du
traitement pour chaque donnée individuelle entraı̂ne une sousutilisation des ressources du GPU et une dégradation des performances. L’agglomération des données permet de remédier
à cet inconvénient. Le partitionnement et l’agglomération de
tâches est un sujet qui a déjà été traité par Ian Foster [24]
dans le but de diminuer les coûts engendrés par les communications entre les différentes tâches. L’agglomération des
données d’entrée permet de fournir une quantité suffisamment
importante de données (et donc de traitements) pour exploiter
puissance des GPUs (meilleur remplissage). Ceci permet un
recouvrement des tâches avec masquage optimal des temps
d’attente du processeur graphique (latence des mémoires) et
donc une amélioration des performances de ce dernier. Cela est
(a) Tri par lot de taille croissante de vecteurs de 500 élements
(b) Calcul de la dispersion par lot de taille croissante de vecteurs de
16000 élements
Fig. 4. Présentation des temps obtenus avec les deux algorithmes exécutés
sur processeurs centraux et graphiques en agglomérant les données
La seconde application d’agglomération des données concerne le calcul de la valeur optimale du paramètre twist. Ce
paramètre détermine la qualité de l’entrelacement de bits, une
méthode permettant une meilleure récupération des erreurs
altérant le message au cours d’une transmission numérique.
Cet algorithme passe la majorité de son temps d’exécution à
calculer la dispersion des erreurs dont la valeur est égale à la
cardinalité de l’ensemble D des vecteurs de déplacement :
D = {(∆x , ∆y ) ∈ Z 2 }
∆x = j − i, ∆y = π(j) − π(i) (0 ≤ i < j < T )
où π est la fonction d’entrelacement qui entrelace les bits
en changeant leurs indices, T le nombre de bits constituant
le message entrelacé, et i et j les indices des éléments au
sein du message. Le calcul de la cardinalité de D, et donc
de la dispersion, nécessite le comptage du nombre d’éléments
distincts présents dans de nombreux vecteurs obtenus à partir
des données d’entrée. La fonction de comptage qui prend
la majorité du temps de calcul, elle a été portée sur GPU.
Ici également, l’algorithme traitait les vecteurs un par un
et la parallélisation sur processeur graphique dégradait ses
performances, le processeur central étant 1,3 fois plus rapide
pour compter le nombre d’éléments distincts d’un vecteur de
16000 éléments de 8 octets (Fig. 4(b)). En agglomérant les
vecteurs, nous arrivons de nouveau à améliorer les temps
d’exécution, le processeur graphique devenant 6,7 fois plus
rapide que le processeur central.
Pour les deux exemples présentés, l’agglomération a été
effectuée en concaténant les vecteurs dans la mémoire et
en y associant un identifiant aux données pour permettre de
distinguer le vecteur auquel elles appartiennent. Les données,
qui étaient au départ contenues dans des structures de 4 octets,
ont été placées dans la partie basse (least significant bits)
d’une structure de 8 octets avec l’identifiant qui occupe la
partie haute (most significant bits). L’identifiant permet ainsi
de conserver le regroupement des données au sein de leur
vecteur d’origine dans le cadre du tri, et de différencier plus
rapidement les données appartenant aux différents vecteurs
dans le cadre du comptage d’éléments distincts.
IV. V ERS DES MULTI -CPU/ MULTI -GPU
Dans les sections II et III, nous avons présenté les
implémentations GPU de méthodes de traitement d’images
ainsi que de méthodes de manipulation de vecteurs. Ces
implémentations ont permis d’accélérer considérablement les
temps de calcul. Cependant, ces solutions peuvent être encore améliorées par l’exploitation simultanée des cœurs CPU
et GPU multiples. Dans ce contexte, la librairie StarPU,
développée à l’INRIA Bordeaux [17], permet d’offrir un
support exécutif unifié pour exploiter les architectures multicœurs hétérogènes, tout en s’affranchissant des difficultés liées
à la gestion des transferts de données. L’idée principale est de
décomposer le traitement en une codelet qui défini le traitement pour des unités de calcul différentes : CPU, GPU et/ou
processeur CELL. StarPU se chargera de lancer les tâches
d’exécution sur les données unitaires avec la codelet. Le placement des tâches est défini par les versions d’implémentations
de la codelet, les disponibilités des unités de calcul et un
ordonnanceur de tâches efficace. Ainsi, le traitement global
des données est réalisé simultanément sur le(s) CPU(s) et
le(s) GPU(s). Si nécessaire, StarPU gère les transferts de
données entre les différentes mémoires des unités de calcul.
StarPU propose plusieurs stratégies d’ordonnancement efficaces et offre en outre la possibilité d’en concevoir aisément
de nouvelles.
Cette section présente l’intérêt de l’exploitation des plateformes hétérogènes (multi-CPU/multi-GPU) en traitement
d’images. Comme montré à la section II, le traitement
d’images sur GPU est très performant pour une image individuelle, puisque l’image résultante peut être visualisée
directement sur un moniteur connecté à la carte graphique
grâce à la bibliothèque OpenGL. Cependant, si l’on désire
conserver les résultats pour une consultation ultérieure, il
devient nécessaire de transférer les données de la mémoire
graphique vers la mémoire centrale. Ces transferts deviennent
très coûteux lors de l’utilisation de grandes bases d’images
volumineuses. Nous proposons une implémentation hybride
de ces méthodes permettant une exploitation de l’intégralité
des ressources hétérogènes de calcul, en utilisant le support
StarPU. Cette implémentation est décrite en trois étapes:
1) Chargement des images d’entrée: La première étape
est le chargement des images d’entrée dans des files
d’attente de telle sorte que StarPU puisse appliquer les
traitements à partir de ces files.
2) Traitement hétérogènes d’images avec StarPU: Une
fois les images chargées, le traitement hétérogène est
confié à StarPU qui lance les tâches à partir des fonctions décrites dans les sections précédentes en versions
CPU et GPU. Dans notre cas, toutes les tâches StarPU
sont crées et lancées (chaque tâche traite une image).
L’ordonnanceur de StarPU distribue les tâches sur les
différentes unités de traitement.
3) Mise à jour et récupération des résultats: Lorsque
toutes les tâches StarPU sont terminées, les résultats
des traitements sur GPU doivent être rapatriés dans les
tampons. La mise à jour est assurée par une fonction
spécifique de StarPU.
La figure 5.a montre la comparaison des temps de calcul
entre les implémentations séquentielles (CPU simple cœur),
parallèles (traitement uniquement en version GPU) et hybrides
de la méthode regroupant la détection des coins ainsi que
des contours, appliquée sur un ensemble de 200 images.
La figure 5.b montre les accélérations obtenues grâce à ces
implémentations. Les accélérations obtenues sont dues à deux
facteurs principaux :
• Le premier facteur est l’exploitation des cœurs GPU permettant d’appliquer des traitements parallèles à l’intérieur
des images, tels que décrit en section II.A.
• Le second facteur est l’exploitation simultanée des CPUs
et GPUs permettant d’appliquer le traitement parallèle
des images de telle sorte que chaque cœur CPU ou GPU
traite un sous-ensemble d’images.
(séquentielles, parallèles, hybrides) à appliquer, selon la nature
des médias à traiter. Par ailleurs, dans le cadre des applications
de calcul générique à petits ensembles de données, si les modifications propres à l’algorithme ne peuvent être automatisées,
une perspective de notre travail est d’élaborer un outil qui
permet d’agglomérer complètement et automatiquement les
données, libérant ainsi le programmeur de ce travail, et de
créer des tâches de taille optimum pour une exécution dans
un environnement hétérogène.
R EMERCIEMENT
(a) Temps de détection hybride des coins + contours
Les auteurs tiennent à remercier :
• La Communauté Française de Belgique, au travers du
soutien du projet Arc-OLIMP (Optimization for Live
Interaction Multimedia Processing), convention AUWB2008-12.
• La Région Wallonne et de le Fond Européen de
Développement Régional (FEDER), au travers du soutien
au projet UMONS/Recherche TIC 1, Portefeuille TIC,
Objectif Convergence, 2008-11.
• La Région Wallonne, au travers du soutien du projet
PSOPP (Porting Software on Parallel Processors ), convention 1017139, 2011-12.
R EFERENCES
(b) Taux d’accélération de détection des coins + contours
Fig. 5. Performances de détection des coins + contours sur architectures
hétérogènes (multi-CPU/multi-GPU)
V. C ONCLUSION
Ce travail montre l’intérêt de l’exploitation des architectures parallèles (GPU) et hétérogènes (multi-CPU/multi-GPU)
en traitement d’images et en calcul intensif. Les résultats
expérimentaux montrent des gains allant d’un facteur de 6 à
20 par rapport à une implémentation classique sur CPU. Ces
gains sont dus essentiellement à trois facteurs :
• Une parallélisation de bas niveau qui se retrouve dans le
portage de l’application sur le GPU (traitements parallèles
des pixels intra-image, des tris et du comptage des
éléments distincts d’un tableau).
• Une parallélisation de haut niveau (traitements parallèles
inter-image) exploitant à la fois les GPUs et les CPUs,
chaque cœur traitant un sous-ensemble d’images.
• Un remplissage efficace du GPU grâce à l’agglomération
des données permettant ainsi un meilleur recouvrement
des temps d’inactivité et donc de meilleures performances
Comme perspectives, nous envisageons de concevoir un
modèle plus général pour le traitement d’objets multimédia
(images et vidéos HD, etc.) sur plateformes parallèles et
hétérogènes. Ce modèle devra choisir automatiquement les
ressources à utiliser (CPU et/ou GPU) ainsi que les méthodes
[1] AMD, “The future brought to you by amd introducing the amd apu
family.” AMD FusionTM Family of APUs, 2011. [Online]. Available:
http://sites.amd.com/us/fusion/apu/Pages/fusion.aspx/
[2] D. B. Kirk and W.-M. W. Hwu, in Programming Massively Parallel
Processors - A Hands-on Approach, M. Kaufman, Ed.
[3] Z. Yang, Y. Zhu, and Y. pu, “Parallel Image Processing Based on
CUDA,” International Conference on Computer Science and Software
Engineering. China, pp. 198–201, 2008.
[4] J. Fung, S. Mann, and C. Aimone, “OpenVIDIA:Parallel gpu computer
vision.” In Proc of ACM Multimedia, pp. 849–852, 2005.
[5] OpenGL, “OpenGL Architecture Review Board: ARB vertex program.
Revision 45.” 2004. [Online]. Available: http://oss.sgi.com/projects/
ogl-sample/registry/
[6] W. R. Mark, R. S. Glanville, K. Akeley, and M. J. Kilgard, “Cg: A
system for programming graphics hardware in a C-like language,” ACM
Transactions on Graphics 22, pp. 896–907, 2003.
[7] NVIDIA, “NVIDIA CUDA,” 2007. [Online]. Available: http://www.
nvidia.com/cuda.
[8] Y. Luo and R. Duraiswani, “Canny Edge Detection on NVIDIA CUDA,”
Proceedings of the Workshop on Computer Vision on GPUS, CVPR,
2008.
[9] J. Canny, “A computational approach to edge detection,” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 8, no. 6, pp.
679–714, 1986.
[10] Y. Heng and L. Gu, “GPU-based Volume Rendering for Medical Image
Visualization,” Proceedings of the 2005 IEEE Engineering in Medicine
and Biology 27th Annual Conference Shanghai, China, pp. 5145–5148,
2005.
[11] M. Smelyanskiy, D. Holmes, J. Chhugani, A. Larson, and al, “Mapping
high-fidelity volume rendering for medical imaging to CPU, GPU
and many-core architectures,” IEEE Transactions on Visualization and
Computer Graphics, 15(6), pp. 1563–1570, 2009.
[12] T. Schiwietz, T. Chang, P. Speier, and R. Westermann, “MR image
reconstruction using the GPU,” Image-Guided Procedures, and Display.
Proceedings of the SPIE, pp. 646–655, 2006.
[13] J. PELLICER, M. F. FAY, and I. J. LEITCH, “The largest eukaryotic
genome of them all?” Botanical Journal of the Linnean Society, 164,
pp. 10–15, 2010.
[14] F. Sébastien, “Conception et mise en oeuvre d’algorithmes de sélection
de ressources dans un environnement informatique hétérogène multiprocesseur,” Rapport de Travail de Fin d’Étude, 2010.
[15] M. Boukesse, V. Moeyaert, S. Bette, and P. Mégret, “Analysis of the
twisting parameters in the DVB-T2 column-twist interleaver,” Proceedings of the 17th IEEE Annual Symposium on Communications and
Vehicular Technology in the Benelux, Enschede, The Netherlands, 2010.
[16] E. Ayguadé, R. M. Badia, F. D. Igual, J. Labarta, R. Mayo, and E. S.
Quintana-Orti, “An Extension of the StarSs Programming Model for
Platforms with Multiple GPUs,” Proceedings of the 15th International
Euro-Par Conference on Parallel Processing. Euro-Par’09, pp. 851–862,
2009.
[17] C. Augonnet, S. Thibault, R. Namyst, and P.-A. Wacrenier, “StarPU:
A Unified Platform for Task Scheduling on Heterogeneous Multicore
Architectures,” In Concurrency and Computation: Practice and Experience, Euro-Par 2009, best papers issue, pp. 863–874, 2009.
[18] C. Harris, “A combined corner and edge detector,” In Alvey Vision
Conference, pp. 147–152, 1988.
[19] R. Deriche, “Using Canny’s criteria to derive a recursively implemented
optimal edge detector,” Internat. J. Vision,Boston, pp. 167–187, 1987.
[20] J. Y. Bouguet, “Pyramidal Implementation of the Lucas Kanade Feature
Tracker, Description of the algorithm,” Intel Corporation Microprocessor Research Labs.
[21] NVIDIA, “CUBLAS,” 2007. [Online]. Available: http://developer.
download.nvidia.com/compute/cuda/1 0/CUBLAS Library 1.0.pdf
[22] S. A. Mahmoudi, F. Lecron, P. Manneback, B. Mohammed, and M. Saı̈d,
“GPU-Based Segmentation of Cervical Vertebra in X-Ray Images,”
Proceeding of the workshop HPCCE. In Conjunction with IEEE Cluster,
pp. 1–8, 2010.
[23] OpenCV, “OpenCV computer vision library.” [Online]. Available:
http://opencv.willowgarage.com/wiki/
[24] I. Foster, “Designing and Building Parallel Programs : Concepts and
Tools for Parallel Software Engineering,” Addison Wesley, 1995.
[25] THRUST, “Thrust,” 2007. [Online]. Available: http://code.google.com/
p/thrust/