U NIVERSITÉ PARIS -S ACLAY

U NIVERSITÉ PARIS -S UD

M ASTER E3A - S YSTÈMES EMBARQUÉS ET TRAITEMENT

DE L’ INFORMATION (SETI)

RAPPORT DE STAGE

Parallélisation multi-GPU des méthodes

itératives de reconstruction 3D en
tomographie à rayons X

Lieu :
- Groupe Problèmes Inverses -
- Laboratoire des Signaux et Systèmes -
- CentraleSupélec -

Auteur : Encadrant :
Mohammed CHGHAF Nicolas GAC
 i

Table des matières

Introduction 1

1 Reconstruction Tomographique Multi-GPU 2

1.1 Reconstruction tomographique à rayons X . . . . . . . . . . . . . . . . . 2
1.1.1 Principes de la tomographie à rayons X . . . . . . . . . . . . . . 2
1.1.2 Algorithmes de projection et de rétroprojection . . . . . . . . . 3
1.1.3 Evolution de la reconstruction tomographique . . . . . . . . . . 5
1.2 TomoBayes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Description générale . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Calcul parallèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Distribution des données en calcul parallèle . . . . . . . . . . . 7
1.3 Evaluation des différentes interconnexions entre GPUs . . . . . . . . . 8

2 Parallélisation Multi-GPU avec distribution de données 11

2.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 TomoBayes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 TIGRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 ASTRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Opérateur de projection . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Opérateur de rétroprojection . . . . . . . . . . . . . . . . . . . . 18
2.2.3 Algorithme itératif . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Résultats 22
3.1 Opérateurs simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1 Performance de calcul en version données centralisées . . . . . 22
3.1.2 Performance de calcul en version données distribuées . . . . . . 24
3.2 L’algorithme itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Conclusion et Perspectives 32

Bibliographie 33
 ii

Table des figures

1.1 Processus d’acquisition des mesures pour reconstruction tomographique.

[CDL18]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 (1) Algorithme de projection : Echantillonnage régulier. (2) Algorithme
de rétroprojection : voxel driven. . . . . . . . . . . . . . . . . . . . . . . 4
1.3 De (1) à (4) l’évolution des 4 générations de scanners. [CDL18]. . . . . 5
1.4 Schéma simplifié de l’algorithme itératif sans régularisation. . . . . . . 6
1.5 Diffusion des rayons (1) en géometrie parallèle (2) en géometrie conique. 8
1.6 Topologie du serveur multi-GPUs du L2S. . . . . . . . . . . . . . . . . . 9

2.1 Schéma simplifié en 2D de la distribution des données du volume et

de données de mesures sur les différents GPUs pour l’opérateur de
projection (version actuelle de TomoBayes). . . . . . . . . . . . . . . . . 12
2.2 Schéma simplifié en 2D de la distribution des données du volume et
de données de mesures sur les différents GPUs pour l’opérateur de
rétroprojection (version actuelle de TomoBayes). . . . . . . . . . . . . . 12
2.3 Chronologie des calculs et transferts mémoires de l’opérateur de pro-
jection dans le cas de 2 GPUs et 2 sous-ensemble de projection [Big+19] 14
2.4 Schéma simplifié en 2D de la distribution des données du volume et
de données de mesures sur les différents GPUs pour l’opérateur de
projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Schéma simplifié en 2D de la distribution des données du volume et
de données de mesures sur les différents GPUs pour l’opérateur de
rétroprojection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Calcul des limites du sous-volume utilisé pour l’opérateur de projec-
tion du 3ème GPU dans le cas où 5 GPUs sont utilisés. . . . . . . . . . . 19
2.7 Calcul des limites du plan détecteur utilisé pour l’opérateur de rétro-
projection du 3ème GPU dans le cas où 5 GPUs sont utilisés. . . . . . . 19

3.1 Fantôme de Shepp-Logan (1) Vue 3D (2) Vue en coupe. . . . . . . . . . 22

3.2 Opérateur de rétroprojection exécuté en un stream en une seule sé-
quence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Opérateur de rétroprojection exécuté en 4 streams parallèles. . . . . . . 23
3.4 (1) Résultat de projection du fantôme Shepp-Logan. (2) Résultat de
rétroprojection du fantôme Shepp-Logan. . . . . . . . . . . . . . . . . . 25
3.5 Efficacité de parallélisation en fonction du nombre des GPUs pour un
volume de taille 2563 dans le cas des données centralisées et distribuées. 26
3.6 Efficacité de parallélisation en fonction du nombre des GPUs pour un
volume de taille 10243 dans le cas des données centralisées et distri-
buées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Pourcentage des calculs et des transferts mémoires par rapport au
temps d’exécution de la version centralisée pour l’opérateur de pro-
jection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 iii

3.8 Pourcentage des calculs et des transferts mémoires par rapport au

temps d’exécution de la version distribuée pour l’opérateur de pro-
jection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Efficacité de parallélisation en fonction du nombre des GPUs pour un
volume de taille 2563 dans le cas des données centralisées et distribuées. 28
3.10 Efficacité de parallélisation en fonction du nombre des GPUs pour un
volume de taille 10243 dans le cas des données centralisées et distri-
buées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.11 Pourcentage des calculs et des transferts mémoires par rapport au
temps d’exécution de la version centralisée pour l’opérateur de ré-
troprojection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.12 Pourcentage des calculs et des transferts mémoires par rapport au
temps d’exécution de la version distribuée pour l’opérateur de rétro-
projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.13 (1) Fantôme Shepp-Logan reconstruit avec 10 itérations. (2) Fantôme
Shepp-Logan reconstruit avec 100 itérations. . . . . . . . . . . . . . . . 30
3.14 Efficacité de parallélisation en fonction du nombre des GPUs dans le
cas ou les données sont centralisées et distribuées pour 100 itérations.
(taille du volume 10243 ). . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.15 Pourcentage des calculs et des transferts mémoires par rapport au
temps d’exécution de la version centralisée en fonction des itérations
et du nombre des GPUs ( taille du volume 10243 ). . . . . . . . . . . . . 31
3.16 Pourcentage des calculs et des transferts mémoires par rapport au
temps d’exécution de la version distribuée en fonction des itérations
et du nombre des GPUs ( taille du volume 10243 ). . . . . . . . . . . . . 31
 iv

Liste des tableaux

1.1 Vitesse de transfert des données entre les différents GPUs du serveur
dans le cas où la communication directe pair-à-pair est désactivée. . . . 9
1.2 Vitesse de transfert des données entre les différents GPUs du serveur
dans le cas où la communication directe pair-à-pair est activée. . . . . . 9

3.1 Comparaison entre les temps d’exécution d’ASTRA et TomoBayes pour

les opérateurs simples sur un serveur multi-GPUs interconnectés avec
un PCIe de génération 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Comparaison entre les temps d’exécution d’ASTRA et TomoBayes pour
les opérateurs simples sur un serveur multi-GPUs interconnectés avec
un PCIe de génération 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
 v

Remerciements

Avant de présenter mon projet de fin d’études, je tiens à

remercier tous ceux qui ont contribué à sa réalisation. Ce stage
est le fruit de ma formation au Master Systèmes Embarqués et
Traitement de l’Information, grâce à laquelle j’ai pu acquérir les
connaissances nécessaires pour réaliser ce travail.

J’adresse mes remerciements les plus sincères à mon encadrant

de stage Monsieur Nicolas GAC, de m’avoir donné l’occasion
d’effectuer ce stage, ainsi que pour son très bon accueil au sein
du L2S. Je souhaite le remercier pour sa patience, son aide et
ses conseils durant toutes les étapes de mon travail.

Je tiens à remercier également tous les chercheurs du L2S,

surtout Monsieur François Orieux et Monsieur Patrice Brault,
pour leur temps ainsi que nos discussions intéressantes. Je
remercie également tous mes collègues et mes compagnons de
bureau : Daouda, Ralph, Thanh, Fabio ; vos encouragements
m’ont permis de continuer mes recherches et mes
développements.

Je remercie également les honorables membres du jury pour le

temps qu’ils ont bien voulu m’accorder afin d’évaluer mon
tavail.
Finalement, je tiens à Te remercier. Tout cela, n’aurait jamais pu
être sans Toi. . .
 1

Introduction

La tomographie à rayons X est utilisée dans plusieurs applications indus-

trielles et médicales. Elle permet de dessiner la structure interne d’un volume
en l’exposant aux rayons X sous un ensemble d’angles.
Les algorithmes de reconstruction peuvent être très variés mais on les
classe souvent en deux catégories : les algorithmes analytiques et les algo-
rithmes algébriques. Mon stage au sein du L2S s’est focalisé sur les méthodes
algébriques basées sur une représentation discrète du problème et des mé-
thodes itératives.
Une première version de parallélisation multi-gpus avec données centra-
lisées sur CPU a été développée pour le logiciel TomoBayes, utilisé pour la re-
construction tomographique au L2S. L’objectif de mon stage est de produire
une nouvelle version, permettant d’effectuer une parallélisation multi-gpus
des calculs itératifs de la reconstruction avec des données distribuées sur les
GPUs.
Ce rapport étant une synthèse de mon travail au L2S. Il sera réparti en 4
parties principales. Nous allons commencer au premier chapitre par la dé-
finition des principes généraux de la tomographie à rayons X ainsi que par
l’introduction au calcul parallèle et les différentes problématiques rencon-
trées dans ces cas.
Dans le deuxième chapitre nous allons présenter une vue générale sur
l’ensemble des stratégies existantes permettant de résoudre les probléma-
tiques des méthodes de reconstruction itératives, puis nous allons exposer
la solution proposée dans le cadre du stage. Nous allons également expliciter
ses avantages par rapport aux autres stratégies utilisées.
Le troisième chapitre sera consacré aux résultats obtenus et les différentes
évaluations qui ont été effectuées. Ce chapitre présente les gains en temps de
calculs en se comparant aux autres stratégies utilisées.
La dernière partie du document présente une conclusion générale et des
perspectives à court et à long termes de ce projet.
 2

Chapitre 1

Reconstruction Tomographique
Multi-GPU

L’objectif général étant de réaliser une parallélisation multi-gpus des algorithmes

itératifs de reconstruction de reconstruction tomographique. Nous allons commen-
cer dans ce chapitre par une présentation du contexte général de notre étude. La pre-
mière partie est une description générale de la tomographie à rayons X. La deuxième
et la troisième partie présentent les défis du calcul parallèle en général et dans le
cadre du logiciel TomoBayes en particulier.

1.1 Reconstruction tomographique à rayons X

1.1.1 Principes de la tomographie à rayons X
La tomographie à rayons X est une technique d’imagerie où un objet est placé
entre une source de rayons X et un plan détecteur. La source irradie le volume de
l’objet avec une intensité de rayons qui décroit de manière continue avant d’at-
teindre le détecteur. Ces irradiations sont par la suite mesurées et le système "Source-
Détecteur" est pivoté avec un certain pas de rotation afin de créer une séquence
d’images qui décrit la structure interne de ce volume. Le système d’acquisition des
mesures des intensités est schématisé dans la Figure 1.1.

F IGURE 1.1 – Processus d’acquisition des mesures pour reconstruc-

tion tomographique. [CDL18].

L’atténuation de l’intensité des rayons X dépend du matériel traversé par ce

rayon dans le volume et elle est donnée par la loi de Beer-Lambert (dans le cas d’un
rayon monochromatique) [SB93] :
Z 
Ii = I0 exp f (l) dl (1.1)
Li
Chapitre 1. Reconstruction Tomographique Multi-GPU 3

Où I0 est le nombre de photons envoyé par la source et Li la ligne suivie par le

rayon i en passant par le volume. La quantité f (l) est le coefficient d’atténuation au
point l ∈ R3 .
Afin de reconstruire le volume initial, il faut estimer la valeur f (l) en tout point l
de l’objet. Ainsi, en linéarisant l’équation précédante on trouve :
Z 
I0
gi = = exp f (l) dl (1.2)
Ii Li

Les mesures correspondant à la diminution de l’intensité des rayons sur le plan

détecteur forment une image appelée projection du volume sur le détecteur. En no-
tant Nϕ le nombre de projections effectuées et Nu × Nv la surface du plan détec-
teur(égale à la taille de chaque image de projection), le nombre total des mesures
est : M = Nu × Nv × Nϕ . De la même manière, en notant Nx , Ny et Nz les dimensions
du volume à reconstruire, sa taille est donnée par : N = Nx × Ny × Nz . Afin d’obtenir
des reconstructions du volume de bonne qualité le nombre de projections doit être
assez grand. De manière générale Nϕ peut varier entre 256 et 2048 [Cha+17].
En discrétisant le volume en voxels, l’équation analytique (1.2) peut être réecrite
algébriquement en tenant compte des incertitudes comme :

g = Hf +ε (1.3)
Où f est le volume à reconstruire, g les données mesurées, H la matrice de pro-
jection et ε décrit le bruit relié au modèle d’acquisition. La matrice H est donc de di-
mension M × N. Ainsi, en travaillant en valeurs flottantes simple précision la taille
de la matrice H peut varier de 112,6 téraoctet à 295,1 exaoctet (1018 ). En pratique,
les coefficients de cette matrice ne peuvent être stockés en mémoire et doivent être
recalculés à chaque fois qu’on en a besoin. Dans le but d’accélérer ces calculs, les
processeurs graphiques GPUs sont privilégiés pour leur capacité de paralléliser les
calculs arithmétiques.
On appelle opérateur de projection les opérations arithmétiques quantifiant la
traversée des rayons X à travers l’objet. Il correspond à la matrice H appelée ma-
trice de projection. L’opérateur adjoint est la rétroprojection et est représenté par H>
la matrice de rétroprojection. Dans les algorithmes itératifs de reconstruction tomo-
graphique ces deux opérateurs sont réitérés de manière successive et sont les plus
gourmands en temps de calculs.

1.1.2 Algorithmes de projection et de rétroprojection

La matrice de projection H ainsi que la matrice de rétroprojection H> sont de
taille trop grande pour être stockées en mémoire. Le but des algorithmes de pro-
jection et de rétroprojection est donc d’approximer ces deux matrices. Pour cela, il
existe en littérature deux sortes d’algorithmes : les algorithmes dit «voxel driven»
(voir Figure 1.2) : (2) et les algorithmes dit «ray driven» (voir Figure 1.2 : (1)).
Pour les algorithmes «ray driven», le calcul est centré sur les cellules du plan dé-
tecteur et on cherche les voxels du volume qui contribuent à la valeur du pixel pour
cette cellule. Dans la littérature, les algorithmes les plus connus sont l’échantillonage
régulier [Bha08], l’algorithme de Joseph [Jos] et l’algorithme de Siddon [Sid85]. Ces
algorithmes ont tous la particularité de se focaliser sur le rayon, d’où le nom «ray
driven». Pour chaque rayon, l’objectif est de calculer alors la contribution des voxels
traversés par ce rayon.
Chapitre 1. Reconstruction Tomographique Multi-GPU 4

(1) (2)

F IGURE 1.2 – (1) Algorithme de projection : Echantillonnage régulier.

(2) Algorithme de rétroprojection : voxel driven.

Dans le cas des algorithmes «voxel driven», le calcul est centré sur le voxel (pixel
en 3D) et pour chacun de ces voxels on cherche l’ensemble des projections lui cor-
respondant. Ces algorithmes ont l’avantage d’éviter les conflits en écriture lors de
la rétroprojection qui peuvent être causé par les algorithmes «ray driven». D’autre
part, ces algorithmes sont fortement parallélisable.

Algorithme de projection échantillonage régulier

L’algorithme de projection utilisé dans mon stage est un algorithme de projection
à échantillonnage régulier, il est «ray driven». Le volume est alors intégré linéaire-
ment selon le rayon.

P(u, v, φ) = ∑ f (Mk ) = ∑ f (xk , yk , zk ) (1.4)

k k

Mk est la position du voxel traversé par le rayon X, chaque position «k» est à
une distance fixée de la position voisine «k+1», d’où l’appellation échantillonnage
régulier. La valeur f (xk , yk , zk ) est ensuite calculée par interpolation tri-linéaire. La
Figure 1.2 : (1) illustre le principe de projection à échantillonage régulier dans le cas
à deux dimensions, le principe restant le même en 3 dimensions.

Algorithme de rétroprojection «voxel driven»

Dans le cadre de mon stage, j’ai utilisé l’algorithme «voxel driven» avec interpo-
lation linéaire. Le principe de cet algorithme consiste à chercher les Nφ projections
P(φ, u, v) correspondantes à chaque voxel (xn , yn , zn ). Les valeurs des mesures sur le
plan détecteur notées P(φ, u, v) étant connues.
Ainsi, pour chaque voxel f (xn , yn , zn ) on a :

f (xn , yn , zn ) = ∑ Pinterp (φ, un (φ, x, y), vn (φ, x, y, z)) (1.5)

φ
Chapitre 1. Reconstruction Tomographique Multi-GPU 5

Les projections Pinterp (φ, un , vn ) sont obtenues après une interpolation bilinéaire :

Pinterp (φ, un , vn ) = (1 − eu ).(1 − ev ).P(φ, une , vne )

+ eu .(1 − ev ).P(φ, une + 1, vne )
(1.6)
+ (1 − eu ).ev .P(φ, une , vne + 1)
+ eu .ev .P(φ, une + 1, vne + 1)
Avec : une et eu (vne et ev ) sont respectivement la partie entière et décimale de un
(vn ).

1.1.3 Evolution de la reconstruction tomographique

Le développement des premiers scanners a commencé en 1963 et depuis l’évolu-
tion des tomodensitomètres a été marquée par des modifications dans la conception
des sous-systèmes de projection et du système d’acquisition de données [Sha14].
Cette évolution est souvent décrite par 4 grandes générations de scanners.

(1) (2) (3) (4)

F IGURE 1.3 – De (1) à (4) l’évolution des 4 générations de scanners.

[CDL18].

La première génération de scanners se caractérisait par un système de translation-

rotation. Dans ce modèle, la source de rayons X et le détecteur se déplacent linéaire-
ment sur l’objet afin d’acquérir les mesures à partir de l’espace balayé. La source et
le détecteur subissent par la suite une rotation d’un degré et le processus se répète
pour collecter le reste des mesures de l’objet, comme indiqué schématiquement dans
la Figure 1.3. Ce modèle, avait un temps de scan typique de 4,5 minutes [CDL18].
La deuxième génération de scanners a permis de réduire le temps de scan, en
augmentant le nombre faisceaux à rayons X de la source. Le nombre des translations
et des rotations a été ainsi réduit et le scan a été accéléré. Ce modèle est montré
schématiquement dans la Figure 1.3. Ces deux générations ont une géométrie de
faisceaux dite parallèle.
Les scanners de la troisième génération sont les plus populaires de nos jours. En
effet, ces scanners utilisent un tableau de détecteurs placés dans la direction opposée
à la source émettrice des faisceaux de rayons X et qui permet de couvrir tout l’objet
à travers une géométrie conique des faisceaux. Le mouvement de translation a été
ainsi éliminé. Ainsi, le temps du scan a été réduit car il ne nécessitait qu’un mouve-
ment de rotation autour de l’objet. Les scanners de la quatrième génération avaient
pour but l’amélioration de la qualité des images obtenues car dans leur configura-
tion seule la source des faisceaux de raysons X étaient mobiles. Ce qui se traduisait
par une meilleure stabilité. Les schémas expliquant le principe de ces deux dernières
générations est montré dans la Figure 1.3.
Chapitre 1. Reconstruction Tomographique Multi-GPU 6

1.2 TomoBayes
1.2.1 Description générale
Le Laboratoire des Signaux et Systèmes (L2S) a développé «TomoBayes», un lo-
giciel de reconstruction tomographique [Bou+15]. Ce logiciel est le fruit de la colla-
boration entre le L2S et Safran, sa première version date de 2015. Ce logiciel permet
de lire les données des scanners au format brut et d’avoir en sortie le volume recons-
truit par des méthodes analytiques ou itératives, il peut être appliqué au contrôle
non destructif ou à l’imagerie médicale.
Les reconstructions sont accélérées grâce à une parallélisation sur les processeurs
GPU des opérateurs les plus gourmands en temps de calcul (projection et rétropro-
jection). Cette parallélisation est effectuée à deux niveaux : (i) sur les différents cœurs
des processeurs many-cores des GPUs et (ii) sur les différentes cartes GPU du ser-
veur (validé sur le serveur 10 GPUs du L2S).
Dans le cadre de mon stage, je me suis focalisé sur les méthodes de reconstruc-
tion itératives du logiciel TomoBayes. Dans sa version simple (sans régularisation)
cet algorithme peut être schématisé comme montré dans la Figure 1.4. L’objectif de
cet algorithme est de trouver une valeur estimée du volume fˆ(n+1) en minimisant
de manière itérative l’erreur quadratique JMC ( f ) = k g − H f k2 . Le calcul du terme
des moindres carrées δMC f (n) = −2.H> (g − H f (n) ) se fait en trois étapes principales :
la première consiste à effectuer une projection estimée d’un volume d’initialisation.
Dans la deuxième étape, les données estimées obtenues sont corrigées en les sous-
tractant des données réelles obtenues du scanner. La troisième étape permet d’effec-
tuer une rétroprojection de cette soustration et de corriger le volume estimé.

F IGURE 1.4 – Schéma

simplifié de l’algorithme
itératif sans régularisa-
tion.
Chapitre 1. Reconstruction Tomographique Multi-GPU 7

1.2.2 Calcul parallèle

Utilisation des GPUs
L’utilisation des serveurs à base de processeurs graphiques GPUs (Graphics Pro-
cessing Unit) pour la reconstruction tomographique est devenue presque une né-
cessité, vu les performances de calculs de ces derniers [ZZZ12]. Contrairement aux
CPUs, les GPUs ont une architecture plus simple qui contient un large nombre d’uni-
tés de calculs massivement parallèle. Le modèle de mémoire de cette architecture est
organisé comme suit : mémoire globale (accessible par tous les threads avec une
latence importante), mémoire privée ou registres (dédiée pour chaque thread) et
d’autres mémoires caches telle que la mémoire texture (plus adaptée au traitement
bi-dimensionnel ou tri-dimensionnel). L’architecture des GPUs est surtout concen-
trée sur le pouvoir de calcul qui dépasse souvent son pouvoir de transfert mémoire
entre CPU et GPU.

CUDA
CUDA (Compute Unified Device Architecture) est une plateforme de program-
mation des calculs parallèles sur des GPUs NVIDIA et qui permet de résoudre de
manière efficace de nombreux problèmes de calcul complexes[CGM14]. La techno-
logie CUDA permet d’exécuter plusieurs threads organisés en «warps» (32 threads)
qui exécutent les mêmes instructions (kernels). Un ensemble de «warps» forment
un block. Les «warps» du même block peuvent être synchronisés automatiquement.
Cependant, les blocks ne peuvent pas être synchronisés. Cette hiéararchisation des
niveaux de parallélisations permet une accélération importante du calcul.
CUDA nécessite l’utilisation d’un CPU (appelé «host») en parallèle avec le GPU
(appelé «device»). Le GPU est utilisé pour accélérer les calculs intensifs du pro-
gramme, tandis que le reste est exécuté sur le CPU. Globalement, les étapes prin-
cipales d’un programme en CUDA sont comme suit :
— Allocation mémoire sur le CPU et le GPU ;
— Transfert de données du CPU vers le GPU ;
— Exécution des kernels sur le GPU ;
— Récupération des données, transfert depuis le CPU vers le GPU ;
— Désallocation mémoire sur le CPU et le GPU.
Même si CUDA permet une accélération nette des calculs, la gestion des trans-
ferts mémoire reste une problématique importante à considérer en développement
logiciel en général et dans le cadre des optimisations à effectuer sur le logiciel Tomo-
Bayes en paraticulier.

1.2.3 Distribution des données en calcul parallèle

La principale contrainte pour les algorithmes itératifs de reconstruction tomo-
graphique vient du fait que le volume à reconstruire doit, en général, être chargé
en mémoire pour que les opérations de projection et de rétroprojection soient effec-
tuées de manière plus efficace. Ces volumes peuvent atteindre des tailles de l’ordre
du gigabyte et dépassent dans certains cas la mémoire disponibles sur le GPU. D’où
la nécessité d’implémenter ces algorithmes sur des serveurs de calculs multi-GPUs.
Pour le cas des scanners à faisceau parallèle, le problème de parallélisation des
calculs sur un serveur multi-GPUs peut être facilement résolu en répartissant sur les
Chapitre 1. Reconstruction Tomographique Multi-GPU 8

différentes mémoires des GPU les tranches axiales du volume. Il suffit de séparer
le volume en tranches perpendiculaires à l’axe de rotation, équivalentes en nombre
à celui des GPUs. Les zones correspondantes à ces tranches sur le plan détecteur
vont être disjointes et vont permettre d’effectuer les calculs de reconstruction de
manière indépendante entre les différents GPUs sans besoin de communiquer entre
eux. Chaque processeur étant responsable d’une partie spécifique du volume et du
détecteur.
Néanmoins, dans le cas des scanners à faisceau conique, les procédures de pa-
rallélisation ne sont pas immédiates. A cause de la divergence des faisceaux, un
rayon entre la source et le détecteur peut intersecter plus qu’une zone du volume.
En conséquence, les zones du détecteur qui correspondent aux tranches du volume
vont se chevaucher. Ainsi, pour effectuer une projection où chaque GPU est respon-
sable d’une tranche du volume, les données des deux tranches adjacentes doivent
être combinées pour effectuer le calcul nécessaire de la projection dans ces régions
qui se chevauchent.
Cette dépendance de données qui existe entre les différentes instructions qui
forme les noyaux de calculs des GPUs influence de manière importante sur les per-
formances globales du programme. D’autre part, la communication à travers des
bus souvent plus lents qu’un simple accès mémoire devient une contrainte supplé-
mentaire à gérer.

(1) (2)

F IGURE 1.5 – Diffusion des rayons (1) en géometrie parallèle

(2) en géometrie conique.

1.3 Evaluation des différentes interconnexions entre GPUs

La communication entre CPU et GPU est réalisée via le bus PCI Express (Peripheral-
Component-Interconnect-Express). Les deux générations les plus répandues de ce
bus sont la génération 2.0 avec un débit d’environ 4 Go/s et la génération 3.0 avec
un débit d’environ 12 Go/s. Cependant, comparé à l’interconnexion entre CPU et
DRAM, PCIe est beaucoup plus lent. Cela devient souvent un goulot d’étranglement
majeur en termes de performances pour l’accélération GPU [Li+19].
Le L2S dispose d’un serveur qui comprend 10 GPUs sur lesquels le calcul de re-
construction tomographique est effectué. Les cartes GPUs utilisées sont des GeForce
GTX Titan X. Chacune de ces cartes possède 3072 coeurs de calcul et une mémoire
globale de 12 Go. Ces cartes sont reliées à deux CPUs Intel Xeon de 14 coeurs chacun
à travers un commutateur PCIe. Les GPUs numérotés de «0» à «4» se trouvent du
même côté du commutateur PCIe, tandis que les GPUs numérotés de «5» à «9» sont
connectés à l’autre commutateur. La Figure 1.6 montre la topologie utilisée par ce
serveur.
Chapitre 1. Reconstruction Tomographique Multi-GPU 9

F IGURE 1.6 – Topolo-

gie du serveur multi-
GPUs du L2S.

GPU/GPU 0 1 2 3 4 5 6 7 8 9
0 246.72 10.37 10.27 10.36 10.36 19.09 18.99 17.39 18.65 13.95
1 10.36 247.67 10.33 10.40 10.37 19.14 18.65 17.32 18.61 13.89
2 10.36 10.32 246.95 10.43 10.34 17.25 17.46 17.12 17.34 13.90
3 10.30 10.32 10.39 248.23 10.38 18.44 18.62 17.29 18.35 13.98
4 10.36 10.31 10.35 10.23 247.77 13.83 13.85 13.86 13.92 13.82
5 18.65 18.78 17.33 18.45 13.87 247.72 10.23 10.41 10.40 10.27
6 18.65 18.63 17.41 18.70 13.94 10.29 247.37 10.22 10.32 10.30
7 16.99 17.14 17.00 17.25 13.89 10.41 10.33 247.65 10.38 10.30
8 18.19 18.61 17.29 18.42 13.96 10.35 10.32 10.41 247.19 10.25
9 13.89 13.97 13.86 13.89 13.81 10.28 10.16 10.23 10.21 247.08

TABLEAU 1.1 – Vitesse de transfert des données entre les différents

GPUs du serveur dans le cas où la communication directe pair-à-pair
est désactivée.

GPU/GPU 0 1 2 3 4 5 6 7 8 9
0 246.65 25.23 25.22 25.22 25.24 19.64 19.65 18.23 19.65 14.19
1 25.24 247.49 25.22 25.24 25.24 19.65 19.65 18.23 19.65 14.19
2 25.22 25.21 247.36 25.23 25.23 18.22 18.22 18.24 18.22 14.19
3 25.23 25.23 25.23 248.11 25.24 19.65 19.64 18.23 19.65 14.19
4 25.24 25.25 25.24 25.23 247.39 14.18 14.18 14.18 14.18 14.19
5 19.67 19.68 18.23 19.66 14.19 247.92 25.25 25.24 25.23 25.26
6 19.67 19.67 18.24 19.67 14.19 25.25 246.55 25.24 25.23 25.26
7 18.22 18.22 18.24 18.22 14.19 25.24 25.23 247.85 25.23 25.24
8 19.66 19.67 18.23 19.67 14.19 25.23 25.24 25.23 247.31 25.24
9 14.18 14.18 14.18 14.18 14.19 25.25 25.25 25.23 25.23 247.03

TABLEAU 1.2 – Vitesse de transfert des données entre les différents

GPUs du serveur dans le cas où la communication directe pair-à-pair
est activée.
Chapitre 1. Reconstruction Tomographique Multi-GPU 10

Dans le but de mettre en évidence la rapidité de la communication directe GPU-

GPU par rapport à la communication CPU-GPU, j’ai lancé l’application "p2pBandwidth-
TestLatency" fournie par Nvidia sur le serveur du L2S. Cette application permet de
transférer des données de test entre les différentes paires de GPUs et de mesurer les
bandes passantes ainsi que les latences entre ces différentes paires dans le cas où l’ac-
cès pair-à-pair est activé et dans le cas où il est désactivé. Ainsi, on peut remarquer
clairement que l’utilisation de l’accès direct pair-à-pair (P2P) (voir Tableau 1.2) per-
met d’atteindre une vitesse de transmission de données beaucoup plus rapide que
celle dans le cas où l’accès direct pair-à-pair (P2P) n’est pas utilisé (voir Tableau 1.1).
En plus, les vitesses de transmission de données pour les GPUs se trouvant du même
côté du commutateur sont plus petites que pour des vitesses de transmission entre
des GPUs devant communiquer à travers le CPU (voir la Figure 1.6).
Nvidia a introduit depuis 2014 une interface de communication NVLink permet-
tant la communication entre CPU et GPU ainsi qu’entre GPU et GPU. Il permet une
lecture et une écriture directes sur la mémoire du CPU et du GPU. En général, cet
interface améliore le débit de manière significative en camparaison avec le PCIe et
atteint un débit de 20 Go/s [FD17]. Néanmoins, jusqu’à présent, le NVLink, ne peut
être utilisé en communication CPU-GPU qu’avec un processeur IBM.
 11

Chapitre 2

Parallélisation Multi-GPU avec

distribution de données

Dans le but de réaliser une parallélisation des calculs en reconstruction tomo-

graphique, il est indispensable de prendre en compte les deux problématiques prin-
cipales qui limitent les performances globales. Premièrement, le goulot d’étrangle-
ment existant entre le CPU et le GPU. Deuxièmement, la géométrie conique utilisée
dans la majorité des scanners et qui se traduit par une dépendance de données entre
les instructions des algorithmes de reconstruction.
Dans ce chapitre, nous allons explorer les différentes stratégies qui existent pour
résoudre ces problématiques. Par la suite, nous allons présenter notre solution et ses
avantages par rapport aux solutions existantes.

2.1 Etat de l’art

2.1.1 TomoBayes
TomoBayes est un logiciel codé en C++/CUDA. L’utilisation du langage de pro-
grammation C++ pour ce logiciel est d’un intérêt majeur parce qu’elle permet d’at-
teindre un niveau d’abstraction permettant de gérer la mémoire de manière plus
efficace ainsi que de spécifier des optimisations possibles qui peuvent ne pas être
faites de manière automatique. En outre, TomoBayes permet également à l’utilisa-
teur d’ajuster plusieurs paramètres selon les besoins et le cas étudié. Par exemple,
l’utilisateur pourra choisir la taille physique du plan détecteur et du volume, il
pourra également choisir la précision des nombres utilisés dans le calcul ou encore
le rapport signal sur bruit des données mesurées et l’extension des images utilisées.
Dans sa version actuelle, TomoBayes permet d’atteindre une accélération impor-
tante grâce à sa parallélisation efficace des calculs sur un ensemble de cartes gra-
phiques GPU. Sa stratégie de parallélisation des calculs est dite à «Données centrali-
sées» au CPU. Le principe est donc de toujours s’assurer que les données du volume
ainsi que les données de projection sont stockés au CPU. L’algorithme de projection
utilisé par TomoBayes est l’algorithme «ray driven» échantillonnage régulier. L’algo-
rithme de rétroprojection utilisé est l’algorithme «voxel driven» avec interpolation
trilinéaire.
Avant de lancer l’opérateur de projection, on calcule pour chaque GPU les limites
du sous-volume qui lui seront nécessaires pour le calcul des projections. Par la suite,
et pour chaque GPU, toute la région du volume global délimitée par les résultats
de ces calculs est transférée du CPU vers le GPU. Les noyaux de calcul de l’opéra-
teur de projection sont alors découpés en «streams», ce découpage permet de lancer
les calculs tout en réalisant le reste des transferts mémoire asynchrones du CPU au
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 12

GPU. L’utilisation des «streams» permet d’exploiter au maximum le recouvrement

des transferts et des calculs sur GPUs. Une fois une partie du calcul est terminée, les
résultats sont également récupérés de manière asynchrone du GPU vers le CPU. Le
résultat de projection est donc centralisé au CPU à la fin de l’opérateur.

F IGURE 2.1 – Schéma simplifié en 2D de la distribution des données

du volume et de données de mesures sur les différents GPUs pour
l’opérateur de projection (version actuelle de TomoBayes).

La rétroprojection est réalisée en suivant les mêmes étapes que celles de la pro-
jection. Les mesures de projection restent alors centralisés dans le CPU. On n’envoie
que la partie nécessaire au calcul à chaque GPU. Le volume de rétroprojection est à
son tour centralisé au CPU quand les calculs se terminent.
La Figure 2.1 illustre le cas où 4 GPUs sont utilisés pour réaliser l’opérateur de
projection. Dans cette situation, le «GPU 0» a besoin de quelques slices supplémen-
taires au 14 du volume global (représenté en couleur bleue) pour calculer les mesures
représentées en couleur orange. Ces slices supplémentaires sont représentées en cou-
leur verte. Dans la stratégie utilisée par la version actuelle de TomoBayes, l’ensemble
des données représenté en couleur bleu et vert est transféré alors au «GPU 0».

F IGURE 2.2 – Schéma simplifié en 2D de la distribution des données

du volume et de données de mesures sur les différents GPUs pour
l’opérateur de rétroprojection (version actuelle de TomoBayes).

Pour illustrer le transfert de mémoire nécessaire au retroprojecteur on se place

dans la même situation avec 4 GPUs de calcul. Pour réaliser la rétroprojection sur la
région du sous volume colorée en vert, le «GPU 0» a besoin des slices supplémen-
taires colorées en rouge en plus des de la tranche colorée en orange. Juste avant le
début des calculs, l’ensemble des données représentées par les couleurs orange et
rouge est transféré au «GPU 0».
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 13

Le reste des opérations intermédiaires nécessaires dans le cadre d’un algorithme

itératif se réalisent d’une manière similaire que les opérations de projection et de
rétroprojection. En décomposant à chaque fois les données stockés au CPU et en les
répartissant sur les GPUs de calcul.
En résumé, la stratégie de parallélisation utilisée dans TomoBayes consiste alors
à effectuer une décomposition du volume, préalablement stocké au CPU. C’est donc
une stratégie à «Données Centralisées» au CPU. Les étapes de l’algorithme itératif
de la stratégie de parallélisation utilisée dans TomoBayes peuvent être explicitées
comme suit :
1. Initialisation : Volume f (n) sur CPU
(a) Transfert CPU -> GPU de f (n)
(b) Projection sur GPU de f (n) sur sous-ensemble de projection
(c) Transfert GPU -> CPU de gb(n)
2. Calcul : δg = g − gb(n) sur CPU
3. (a) Transfert CPU -> GPU de δg
(b) Rétroprojection de δg sur le sous-volume
(c) Transfert GPU -> CPU de δ f
4. Calcul : f (n+1) = f (n) + δ f sur CPU

2.1.2 TIGRE
TIGRE est une toolbox à base de Matlab et de Python pour la reconstruction to-
mographique accélérée sur GPUs. L’objectif général de l’optimisation réalisée par
TIGRE est de réorganiser les opérations de calcul et les transferts mémoire de ma-
nière à ce que les premiers soient maximisées et les deuxièmes soient minimisés.
Afin de réaliser l’opération de projection, l’approche utilisée dans la toolbox
TIGRE consiste à stocker le volume sur le CPU et décomposer sur les différents
GPUs les sous-ensembles des données de projection. Chaque GPU effectue alors la
projection du volume sur un sous ensemble de projection. Les données sont par la
suite récupérées de manière asynchrone : tout en exécutant les nouveaux calculs sur
les nouveaux sous-ensemble de projection les transferts mémoire entre CPU et GPU
sont lancés afin de réduire le temps global d’exécution [Big+19]. La Figure 2.3 illustre
la chronologie des calculs et des transferts mémoires pour l’opérateur de projection
en utilisant la toolbox TIGRE dans le cas de 2 GPUs et de 2 sous-ensemble de projec-
tion.
De la même manière, l’opérateur de rétroprojection est réalisé dans l’approche
proposée par la toolbox TIGRE. Les images de projections sont donc divisées en piles
de tranches axiales de taille égale et réparties entre les différents GPUs, chacun de ces
GPUs effectue les calculs nécessaires sur le sous-ensemble des images de projection
dont il est responsable. Le reste des opérations nécessaires pour l’algorithme itératif,
comme la comparaison des mesures estimées avec les mesures réelles et la correction
du volume obtenu, s’effectuent en décomposant de la même manière à chaque fois
les mesures ou le volume sur l’ensemble des GPUs selon l’axe de rotation du volume.
En résumé, la stratégie de parallélisation utilisée dans TIGRE consiste alors à ef-
fectuer une décomposition du volume, préalablement stocké au CPU. C’est donc
également une stratégie à «Données Centralisées» au CPU. Les étapes de l’algo-
rithme itératif de la stratégie de parallélisation utilisée dans TIGRE peuvent être
explicitées comme suit :
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 14

F IGURE 2.3 – Chronologie des calculs et transferts mémoires de l’opé-

rateur de projection dans le cas de 2 GPUs et 2 sous-ensemble de pro-
jection [Big+19]

1. Diffusion : diffusion du volume f (n) sur l’ensemble des GPUs utilisés pour le
calcul
2. Projection : projection du volume pour chaque GPU sur un sous ensemble des
données de projection
3. Comparaison : comparaison des données estimées gb(n) avec les données réelles
g
4. Rétroprojection : rétroprojection de la correction des données δg(n)
5. Réduction : sommation des corrections partielles δMC f (n)
6. Correction : correction du volume f (n+1)

La toolbox TIGRE a l’avantage d’être facile à utiliser puisqu’elle fournit des fonc-
tions prédéfinies pour effectuer toute les opérations nécessaires à une reconstruction
tomographique. Par ailleurs, l’utilisation de langages de haut Python et Matlab, per-
met à l’utilisateur d’avoir un niveau d’abstraction plus haut. Malheureusement, ces
fonctions présentées comme des «boites noires» peuvent pénaliser les optimisations
qui peuvent être effectuées en gestion de la mémoire et en organisation globale des
noyaux de calculs CUDA.

2.1.3 ASTRA
ASTRA (All Scale Tomographic Reconstruction Antwerp) [Aar+15] est une tool-
box de reconstruction tomographique pouvant également s’interfacer avec Matlab
et Python. Contrairement à son interface Matlab, son interface Python permet la pa-
rallélisation multi-GPUs des calculs.
Pour faciliter l’utilisation d’ASTRA plusieurs fonctions sont disponibles et peuvent
être appelées pour gérer de manière interne la distribution des données sur les dif-
férents GPUs. Ainsi, en supposant qu’on a N GPUs, le volume est réparti en N sous-
volumes indépendants de taille comparables où on attribue à chaque GPU un sous-
volume orthogonal à l’axe de rotation. Chaque GPU, effectue alors la projection du
sous-volume qui lui correspond sur tous les angles de projection. On note bien que
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 15

les régions du détecteur correspondants à différents sous-volumes peuvent se che-

vaucher. Chaque GPU stocke les données de son sous-volume ainsi que les données
correspondants à la région du détecteur affectée.
La décomposition en sous-volumes est effectuée de manière à minimiser la quan-
tité de données sur chaque GPU. Chaque noeud ne contient donc que les données
nécessaires aux opérations de projection et de rétroprojection. Cependant, d’autres
opérations, telles que le calcul des gradients, nécessitent des informations prove-
nant (généralement d’un petit ensemble) de voxels voisins. Lorsque tous les voxels
sont dans la mémoire du même GPU, cela ne pose pas de problème et les données
requises peuvent être lues directement. Cependant, lorsque les voxels voisins sont
stockés dans la mémoire d’un autre GPU, cela ne serait plus possible. Pour permettre
l’exécution de ces opérations, les fonctions de répartition du volume d’ASTRA per-
met de réaliser une décomposition en sous-volumes légérement plus grands que ce
qui est strictement nécessaire. Ces tranches supplémentaires qui se chevauchent avec
des GPUs voisins sont appelées cellules fantômes [Pal+17]. Ces voxels fantômes sont
automatiquement synchronisés après les opérations de projection et de rétroprojec-
tion.
A cause de la géométrie conique utilisée par ASTRA, pour calculer le résultat
de l’opérateur de projection correspondant à un GPU, on a besoin des données des
sous-volumes provenant des GPUs adjacents. Puisque ASTRA est modélisée de ma-
nière à ce que ces opérations soient linéaires, l’opérateur de projection peut être ef-
fectué séparément pour chaque GPU sur les données dont il dispose, par la suite le
résultat est additionné à celui du GPU voisin pour trouver le résultat final de pro-
jection. Le calcul exact des limites de chaque région permet de minimiser la quantité
des données à échagner tout en veillant à ce que chaque GPU dispose de la version
correcte des donnée du sous volume et des projections. Pour l’opérateur de rétro-
projection, chaque GPU stocke localement le sous-ensemble des mesures nécessaires
pour effectuer son opération de manière indépendante des autres GPUs.
Pour illustrer cette distribution de données, on prend un exemple de paralléli-
sation sur 4 GPUs. La Figure 2.4 montre les régions réparties dont chaque GPU est
responsable. Pour l’opérateur de projection, le «GPU 0» a besoin de ses données du
sous-volume en bleu ainsi que des données du sous-volume du «GPU 1» représentée
en jaune afin de calculer la région de projection représentée en vert. Dans l’approche
utilisée par ASTRA, le «GPU 0» effectue les calculs de projection relatives à la région
en bleu, le «GPU 1» effectue également les calculs de projection relatives à la région
en jaune. En fin, le «GPU 1» transmet ses résultats au «GPU 0» pour les additionner
et retrouver les mesures de projection relatives à la région en vert. Pour l’opérateur
de rétroprojection, le «GPU 0» a besoin de toute la partie des mesures du plan détec-
teur colorée en orange pour reconstruire la région du volume colorée en gris qui lui
correspond. Ainsi, toute les données des mesures de projection en orange sont sto-
ckées en mémoire du «GPU 0» afin d’effectuer les calculs de manière indépendante.
Une partie de ces mesures est évidemment stockées sur le «GPU 1» car elles sont
utilisées pour la rétroprojection de la région qui correspond au «GPU 1».
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 16

F IGURE 2.4 – Schéma simplifié en 2D de la distribution des données

du volume et de données de mesures sur les différents GPUs pour
l’opérateur de projection

F IGURE 2.5 – Schéma simplifié en 2D de la distribution des données

du volume et de données de mesures sur les différents GPUs pour
l’opérateur de rétroprojection.

On peut résumer les principales étapes de l’algorithme itératif pour la stratégie

de parallélisation utilisée dans ASTRA comme suit :
1. Répartition : répartition en sous-volumes du volume global f (n) sur l’ensemble
des GPUs utilisés pour le calcul
2. Projection : projection du sous volume pour chaque GPU sur l’ensemble des
données de projection
3. Réduction : sommation des données estimées partiellement gb(n)
4. Comparaison : comparaison des données estimées gb(n) avec les données réelles
g
5. Répartition : répartition des corrections des données δg(n) sur chacun des GPUs
de clacul
6. Rétroprojection : rétroprojection de la correction des données δg(n) sur les
sous-volumes attachés à chaque GPU de calcul
7. Réduction : sommation des corrections partielles δMC f (n)
Le reste des opérations intermédiaires nécessaires pour l’algorithme itératif, peuvent
également être appelées à travers des fonctions précodées par la toolbox ASTRA.
Néanmoins, et pour les même raisons que pour la toolbox TIGRE, ces fonctions sont
opaques et gèrent les fonctionnalités de CUDA d’un niveau qui ne permet de garan-
tir l’efficacité de la gestion de la mémoire et des noyaux des calculs.
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 17

Ces opérations peuvent être directement exécutés sur les différents GPUs sans
avoir besoin de transférer les données du volume ou les mesures de projection vers
le CPU. Pour cette raison, c’est une stratégie dite à «Données Distribuées» sur GPU.

2.2 Solution proposée

Dans la littérature, l’objectif général en reconstruction tomographique multi-GPU
est de profiter au maximum de la puissance de calcul des GPUs tout en réduisant
les temps de transferts entre CPU et GPU. Pour cela, nous avons vu qu’il y a deux
stratégies principales pour réduire les temps de reconstruction tomographique, une
dite à «Données Centralisées» sur CPU et l’autre à «Données Distribuées» sur GPU.
La stratégie que nous adoptons dans le cadre du stage est une stratégie à «Don-
nées Distribuées» sur GPU. Il s’agit alors d’une nouvelle version du logiciel To-
moBayes reposant sur le même principe que celui de la toolbox d’ASTRA tout en
profitant de la rapidité des transferts mémoire pair-à-pair du GPU et en réduisant
davantage les tailles des données transférées.
La stratégie proposée est une décomposition dans l’espace des images et dans
l’espace des projection avec des synchronisatons entre chaque appel aux opérateurs
de projection et de rétroprojection. Ceci, permet de ne transférer du CPU au GPU
que le strict minimum des données afin de gagner davantage en accélération de cal-
culs. Par ailleurs, l’utilisation du langage C++/CUDA permet d’avoir une meilleure
gestion de la mémoire et des noyaux de calculs.

2.2.1 Opérateur de projection

Ainsi, pour l’opérateur de projection, les données du volume sont stockées dans
le CPU, par la suite on les répartit de parts égales sur l’ensemble des GPUs qu’on
souhaite utiliser. Si on suppose qu’on utilise N-GPUs pour effectuer l’opération de
projection, chaque GPU aura alors exactement N1 de la quantité globale du volume.
On alloue également sur chaque GPU la quantité N1 de la mémoire nécessaire pour
stocker les mesures de projection.
Au moment du transfert entre CPU et GPU, la mémoire linéaire utilisée est atta-
chée à la mémoire texture du GPU. Ce type de mémoire est utilisé parce qu’il per-
met de simplifier énormément le traitement des images car il permet l’accès direct
aux pixels pour effectuer en une seule opération une interpolation bilinéaire ou tri-
linéaire. Pour cette raison, il est avantageux d’utiliser ce type de mémoire au lieu de
la mémoire globale du GPU.
Avant de commencer les calculs relatifs à l’opérateur, on calcule également préci-
sément les limites du sous-volume nécessaire pour réaliser le calcul de chaque zone
du plan détecteur. Ces parties manquantes sont après envoyées avec une communi-
cation directe pair-à-pair des GPUs adjacents au GPU responsable des calculs. Une
fois les opérations de projections sont achevées, les mesures de projections sont alors
récupérées sur le CPU. L’algorithme 1 décrit le pseudo-code dans le cas général de
l’opérateur de projection, avec NGPU le nombre de GPUs disponibles.
Pour illustrer le calcul de ces limites dans le cas de deux dimensions la Figure 2.6
montre le cas où 5 GPUs sont utilisés pour l’opérateur de projection (le principe
restant le même en trois dimensions). Dans ce cas, le sous-volume coloré en jaune
sera à l’initialisation chargé dans le «GPU 2». La limite inférieure
du sous-volume
utilisé par le «GPU 2» est notée Z1p , elle est égale à V1p SOD +X
SDD . «SOD» étant la
distance entre la source et le volume, «SDD» la distance entre la source et le détecteur
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 18

Algorithme 1 Pseudo-code de l’opérateur de projection.

1: Vérifier le Nombre et les Propriétés des GPUs
2: for NGPUdo 
3: while TailleNGPU
Volume
+ TailleNSinogram
GPU
≥ 0, 7 × (Mémoire-GPU) do
4: (Taille-Volume-GPU) / = 2
5: (Taille-Sinogramme-GPU) / = 2
6: end while
7: Activer la communication pair-à-pair
8: Calculer limites du Bloc-Volume
9: for (Bloc-Volume ∈ Volume-GPU) do
10: Transférer Bloc CPU -> GPU
11: Calculer limites du sous-volume
12: Echanger les données manquantes entre GPUs
13: Lier les données à la mémoire texture
14: Lancer les Kernels de projection
15: Synchroniser les calculs entre Kernels
16: Transférer les résultats GPU -> CPU
17: end for
18: Synchroniser transferts CPU -> GPU
19: Désactiver la communication pair-à-pair
20: Libérer les ressources allouées sur GPU
21: end for

et V1p la limite inférieure de la zone du détecteur dont le «GPU 2» est responsable.

Ces données sont connues. De la même manière on calcule la limite supérieure du
sous-volume utilisé par «GPU 2» : Z2p = V2p SOD +X


SDD . V2p est la limite supérieure
de la zone du détecteur dont le «GPU 2» est responsable, également connue. Ainsi,
on arrive à retrouver les slices manquantes au «GPU 2» Pour effectuer le calcul de
la projection. Dans ce cas de figure, la partie en couleur orange de la Figure 2.6 sera
transférée avec une communication directe pair-à-pair du «GPU 3» au «GPU 2». De
l’autre côté, la partie en couleur magenta sera transférée avec une communication
directe pair-à-pair du «GPU 1» au «GPU 2».

2.2.2 Opérateur de rétroprojection

Pour l’opérateur de rétroprojection, chaque GPU ne possède que les mesures re-
présentant N1 des mesures du plan détecteur et cherche à calculer la rétroprojection
sur le sous-volume qui lui correspond et qui représente exactement le N1 du vo-
lume global. Ces mesures sont également attachées à la mémoire texture afin d’ac-
célérer les calculs. Juste avant le début de l’opération de rétroprojection, on calcule
les limites des mesures nécessaires pour la rétroprojection sur le sous-volume. Ces
données sont également transférées entre GPUs adjacents avec une communication
pair-à-pair directe. Une fois le calcul terminé, le sous-volume reconstruit est trans-
féré au CPU depuis chacun des GPUs. L’algorithme 2 montre le pseudo-code de ce
processus.
De manière similaire, on peut retrouver les limites de chaque sous-ensemble de
mesures de projections qui vont servir pour la rétroprojection pour chaque GPU. La
Figure 2.7 illustre ces calculs dans le cas de deux dimensions (le principe restant le
même également pour trois dimensions). Dans ce cas, le «GPU 2» ne possède que les
données du plan détecteur en couleur jaune. La limite inférieure du plan détecteur
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 19

F IGURE 2.6 – Calcul des limites du sous-volume utilisé pour l’opéra-

teur de projection du 3ème GPU dans le cas où 5 GPUs sont utilisés.

F IGURE 2.7 – Calcul des limites du plan détecteur utilisé pour l’opé-
rateur de rétroprojection du 3ème GPU dans le cas où 5 GPUs sont
utilisés.

−X
utilisé par le «GPU 2» est notée V1r , elle est égale à Z1r SOD


SDD . Z1r étant la limite
inférieure du sous-volume dont le «GPU 2» est responsable. De même, on calcule la
limite supérieure
du plan détecteur utilisé par le «GPU 2» :
−X
V2r = Z2r SODSDD . Z2r . La limite supérieure du sous-volume dont le «GPU 2» est res-
ponsable, également connue, est notée Z2r . Ainsi, on retrouve la partie des mesures
manquantes au «GPU 2» pour effectuer la rétroprojection. Dans ce cas de figure, la
partie en couleur orange de la Figure 2.7 sera alors transférée par une communica-
tion directe pair-à-pair du «GPU 1» au «GPU 2».

2.2.3 Algorithme itératif

La réalisation de l’algorithme itératif nécessite des opérations intermédiaires telles
que le calcul des différences entre les mesures estimées et les mesures réelles (g −
H fb(n) ) ainsi que l’addition de la correction apportée aux données :
δ f (n+1) = δ f MC
n + fbn .

La solution proposée permet d’effectuer toutes ces opérations directement sur

les GPUs. Dans la stratégie de calcul avec «Données Centralisées» sur CPU, les ré-
sultats de calculs de chaque opérateur (projection ou rétroprojection) devaient être
centralisés au CPU avant de passer à la prochaine étape de calcul. Dans la version
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 20

Algorithme 2 Pseudo-code de l’opérateur de rétroprojection.

1: Vérifier le Nombre et les Propriétés des GPUs
2: for NGPUdo 
3: while TailleNGPU
Volume
+ TailleNSinogram
GPU
≥ 0, 7 × (Mémoire-GPU) do
4: (Taille-Volume-GPU) / = 2
5: (Taille-Sinogramme-GPU) / = 2
6: end while
7: Activer la communication pair-à-pair
8: Calculer limites du Bloc-Sinogramme
9: for (Bloc-Sinogramme ∈ Sinogramme-GPU) do
10: Transférer Bloc CPU -> GPU
11: Calculer limites du sous-ensemble de mesures
12: Echanger les données manquantes entre GPUs
13: Lier les données à la mémoire texture
14: Lancer les Kernels de rétroprojection
15: Synchroniser les calculs entre Kernels
16: Transférer les résultats GPU -> CPU
17: end for
18: Synchroniser transferts CPU -> GPU
19: Désactiver la communication pair-à-pair
20: Libérer les ressources allouées sur GPU
21: end for

de l’algorithme itératif proposée, tous les calculs sont réalisés sans avoir besoin d’ef-
fectuer ces échanges intermédiaires entre CPU et GPU.
Chapitre 2. Parallélisation Multi-GPU avec distribution de données 21

Algorithme 3 Pseudo-code de l’algorithme itératif.

1: Vérifier le Nombre et les Propriétés des GPUs
2: for NGPUdo 
3: while TailleNGPU
Volume
+ TailleNSinogram
GPU
≥ 0, 7 × (Mémoire-GPU) do
4: (Taille-Volume-GPU) / = 2
5: (Taille-Sinogramme-GPU) / = 2
6: end while
7: Activer la communication pair-à-pair
8: Calculer limites du Bloc-Sinogramme
9: Transférer Bloc-Sinogramme CPU -> GPU
10: Synchroniser transferts CPU -> GPU
11: end for
12: for Iteration = 1..n do
13: Effectuer «Projection»
14: Synchroniser les calculs
15: Mise des résultats de projection en mémoire texture
16: Effectuer «Rétroprojection»
17: Synchroniser les calculs
18: end for
19: for NGPU do
20: Transférer le volume final GPU -> CPU
21: Synchroniser transferts GPU -> CPU
22: Désactiver la communication pair-à-pair
23: Libérer les ressources allouées sur GPU
24: end for

Ainsi, dans l’algorithme itératif proposé, on arrive à maximiser les temps de cal-
culs effectués sur les GPUs tout en réduisant les temps de transfert mémoire. En
effet, les slices exactes nécessaires pour effectuer les opérations de projection et de
rétroprojection, sont échangés entre les GPUs adjacents, ce qui permet de profiter du
débit de communication directe pair-à-pair, supérieur au débit de communication
CPU-GPU. Cet échange est effectué juste avant le début de ces noyaux de calculs, ce
qui permet un gain du temps par rapport aux autres stratégies existantes. Pour des
raisons de simplification, les opérations intermédiaires n’ont pas été détaillées dans
l’Algorithme 3 qui présente un pseudo-code de l’algorithme itératif.
En résumé, la solution proposée est une stratégie de parallélisation avec «Don-
nées Distribuées» sur les différents GPUs. Parmi ses avantages on peut citer :
— Meilleure gestion de la mémoire : utilisation de la mémoire texture permettant
l’interpolation bi-linéaire et tri-linéaire en un seul accès mémoire ;
— Réduction des quantités transférées entre le CPU et chacun des GPUs ;
— Utilisation de la communication directe pair-à-pair entre GPUs adjacents.
 22

Chapitre 3

Résultats

Après avoir présenté les différentes solutions existantes et la solution proposée.

Nous allons présenter dans ce chapitre les résultats de comparaison entre ces straté-
gies. Nous mesurons l’efficacité de parallélisation pour chacune des méthodes éva-
luées afin de montrer les gains en performance obtenus.

3.1 Opérateurs simples

3.1.1 Performance de calcul en version données centralisées
Cas 1 : Serveur multi-GPUs Titan X Maxwell avec bus de génération 3
La première partie de mon stage a été consacrée à la comparaison des perfor-
mances de calcul de TomoBayes dans sa version de données centralisées sur CPU
et la toolbox ASTRA. Les tests ont été effectuées sur le serveur multi-GPU du L2S.
Les GPUs sont des Nvidia GeForce GTX TITAN X interconnectés avec un PCIe de
génération 3 (débit 12 Go/s).

(1) (2)

F IGURE 3.1 – Fantôme de Shepp-Logan (1) Vue 3D (2) Vue en coupe.

Les évaluations sont effectuées sur le fantôme de Shepp-Logan, utilisé classi-

quement pour tester les algorithmes de reconstruction tomographique (voir la Fi-
gure 3.1). C’est un volume constitué de 10 élipsoïdes qui servent comme simulation
d’un crâne. Ce fantôme est de dimension 10243 , ce qui correspond à environ 4 Go en
représentation décimale en virgule flottante simple précision. L’opérateur de projec-
tion est réalisé en effectuant une rotation de 360°du système «Source-Détecteur» au-
tour de l’axe vertical du fantôme Shepp-Logan. Dans notre cas, nous avons effectué
Chapitre 3. Résultats 23

1024 projections du volume sur le plan détecteur, réparties uniformément sur [0, 2π [.
Le nombre total de projections étant Nφ = 1024. Puis, pour effectuer la rétroprojec-
tion, on repart de chaque projection réalisée sur le plan détecteur pour retrouver
chaque pixel du volume en se basant sur l’algorithme présenté dans la Figure 1.2.
Les résultats sont regroupés dans le Tableau 3.1.

GPUs utilisés 1-GPU 8-GPUs

Logiciel utilisé ASTRA TomoBayes ASTRA TomoBayes
Projection 19,4 19,92 2,794 (× 6,943) 2,65 (× 7,516)
Rétroprojection 13,39 6,28 2,043 (× 6,554) 0,895 (× 7,016)

TABLEAU 3.1 – Comparaison entre les temps d’exécution d’ASTRA et

TomoBayes pour les opérateurs simples sur un serveur multi-GPUs
interconnectés avec un PCIe de génération 3.

On peut remarquer tout d’abord l’intérêt d’utiliser des streams qui masquent les
temps nécessaires aux transferts mémoire. En effet, si on n’utilise pas les streams, le
GPU restera inactif durant la durée du transfert des données du CPU vers le GPU
et puis durant la récupération des calculs du GPU vers le CPU, ce qui constitue un
temps mort qui pénalise l’accélération des calculs apportée par les GPUs. Par contre,
si on utilise des streams on arrive à effectuer plusieurs opérations en parallèle tout
en respectant l’ordre de ces opérations. Ainsi, en découpant un opérateur (projection
ou rétroprojection) en un nombre de streams, les résultats de calcul de l’opérateur
peuvent être transferés au CPU au fur et à mesure que les calculs s’effectuent.

F IGURE 3.2 – Opérateur de rétroprojection exécuté en un stream en

une seule séquence.

F IGURE 3.3 – Opérateur de rétroprojection exécuté en 4 streams pa-

rallèles.

La Figure 3.2 et la Figure 3.3 illustre l’importance de l’utilisation des streams

afin de masquer les temps de transferts CPU-GPU. L’opération de rétroprojection
dure environ 13 s si on n’utilise pas de streams dans ce cas. Alors que si 4 streams
sont utilisés, l’opération ne dure que 4,4 s. Sur la Figure 3.3, on a utilisé 4 streams.
Chaque stream a la responsabilité de gérer tous les transferts mémoire d’une zone
du sous-ensemble des données qu’il faut traiter. Une fois le premier stream trans-
fère les données nécessaires pour lancer un kernel du CPU vers le GPU, il exécute
immédiatement le calcul. En parallèle, le stream suivant commence son transfert de
données du CPU vers le GPU. Une fois que le kernel achève ses calculs, le stream
gère alors le transfert des résultats du GPU vers le CPU. Une remarque importante
est qu’il faut respecter l’ordre d’exécution des kernels pour chaque stream, ceci est
primordial pour garantir l’exactitude des données sur lesquels les calculs sont effec-
tués.
Chapitre 3. Résultats 24

L’accélération obtenue sur 8 GPUs (entre ×7 et ×7, 5) pour TomoBayes est proche
de l’accélération théorique (qui de ×8), ceci est dû aux optimisations qui ont été
faites pour les noyaux de calculs et de la gestion de mémoire efficace apportée par
l’utilisation des streams. Par contre, l’exécution séquentielle des noyaux de calcul et
des transferts mémoire utilisée par ASTRA cause la limitation de l’accélération du
calcul (limitée à ×6, 95 dans les meilleurs des cas) même si on utilise 8 GPUs.

Cas 2 : Serveur multi-GPUs Titan X Maxwell avec bus de génération 2

On a vu dans le paragraphe précédant, l’influence des transferts mémoire sur
les temps d’exécution des différents opérateurs. Afin de montrer davantage l’impor-
Temps de communication
tance d’un quotiont ηcomm = le plus faible possible, on se
Temps global
positionne dans une situation avec la même configuration que celle utilisée dans la
section précédente mais en utilisant cette fois un bus PCIe de génération 2 (débit
4 Go/s).

GPUs utilisé 1-GPU 8-GPUs

Logiciel utilisé ASTRA TomoBayes ASTRA TomoBayes
Projection 24,619 22,138 5,32 (× 4,627) 3,735 (× 5,927)
Rétroprojection 18,37 8,71 4,98 (× 3,688) 1,96 (× 4,443)

TABLEAU 3.2 – Comparaison entre les temps d’exécution d’ASTRA et

TomoBayes pour les opérateurs simples sur un serveur multi-GPUs
interconnectés avec un PCIe de génération 2.

Le Tableau 3.2 résume les temps d’exécution obtenus. En comparaison avec le

Tableau 3.1, on remarque que les accélérations obtenues sont plus faibles. Ceci est
dû principalement au débit réduit de transmission de données que permet le PCIe
de génération 2. Dans ce cas, l’utilisation des streams n’est pas suffisante pour l’accé-
lération des calculs. En effet, l’accélération chute pour les deux logiciels utilisés car
une partie importante du temps est perdue durant les transferts mémoire.
Temps de communication
En résumé, dans le cas où le ratio ηcomm = est
Temps global
important, l’utilisation des streams ne peut plus résoudre la problématique des temps
morts des calculs et il faut alors réduire davantage les communications entre CPU et
GPU afin de profiter au maximum de la puissance de calculs des GPUs. La solution
proposée dans le Chapitre 2 permet de résoudre cette problématique

3.1.2 Performance de calcul en version données distribuées

Validation des résultats
Les volumes et projections obtenues avec les opérateurs de projection et de ré-
troprojection ont été validés en se comparant à ceux obtenus avec TomoBayes (en
version parallélisation multi-gpu avec données centralisées sur CPU). La Figure 3.4
montre le résultat de la projection et de la rétroprojection du fantôme de Shepp-
Logan.
Chapitre 3. Résultats 25

(1) (2)

F IGURE 3.4 – (1) Résultat de projection du fantôme Shepp-Logan.

(2) Résultat de rétroprojection du fantôme Shepp-Logan.

Comparaison avec la version données centralisées

Opérateur de projection
Dans cette évaluation, nous avons comparé les performances de calcul des deux
versions (données centralisées et données distribuées) en changeant à chaque fois le
nombre de GPUs utilisé. Nous avons, effectué cette comparaison également pour le
fantôme Shepp-Logan de taille 2563 (64 Mo).
Pour comparer les différents résultats d’évaluations obtenus, on définit «η» un
indicateur de l’efficacité de parallélisation. L’équation 3.1 est la définition de cette
quantité qui a toujours une valeur comprise entre 0 et 1.

facteur d’accélération t NGPU

η= = (3.1)
NGPU t1GPU × NGPU
La Figure 3.5 montre les résultats de cette comparaison. En effet, pour le volume
2563 comme pour le volume 10243 , l’accélération apportée par les deux versions en
utilisant le même nombre de GPUs est presque la même (approximativement une
accélération d’un facteur ×8 en utilisant 8 GPUs). Ceci est dû au fait d’utiliser des
streams pour masquer les temps de transfert mémoire pour la version «Données
Centralisées» comme pour la version «Données Distribuées» qui utilise en plus la
communication directe pair-à-pair entre GPUs. Ainsi, on arrive à obtenir une effica-
tion de parallélisation légèrement supérieure pour la version «Données Distribuées»
en comparaison avec la version «Données Centralisées».
Chapitre 3. Résultats 26

Efficacité de parallélisation
1

0.95

0.9
Données centralisées
Données distribuées
0.85
1 2 3 4 5 6 7 8 9
Nombre de GPUs
F IGURE 3.5 – Efficacité de parallélisation en fonction du nombre des
GPUs pour un volume de taille 2563 dans le cas des données centrali-
sées et distribuées.
Efficacité de parallélisation

0.95

0.9
Données centralisées
Données distribuées
0.85
1 2 3 4 5 6 7 8 9
Nombre de GPUs
F IGURE 3.6 – Efficacité de parallélisation en fonction du nombre des
GPUs pour un volume de taille 10243 dans le cas des données centra-
lisées et distribuées.

Une autre évaluation intéressante à réaliser est celle du quotient

Temps de communication Temps de calculs
ηcomm = Temps global ainsi que 1 − ηcomm = Temps global . La Figure 3.7 montre
le pourcentage du temps de transfert mémoire par rapport au temps d’exécution glo-
bale indiqué en couleur rouge. En couleur bleu, le pourcentage du temps de calcul
par rapport au temps d’exécution global. Pour la version avec données centralisées,
le temps de transfert mémoire varie de 10% à 26%. Alors que, pour la version avec
données distribuées (Figure 3.8) ce pourcentage ne dépasse pas 20%.
Grâce à cette plus faible proportion du temps de transfert, notre version multi-
GPU avec données distribuées sera beaucoup moins sensible au goulot d’étrangle-
ment du bus PCIe. Nous avons vu que pour un serveur de 8 GPUs Maxwell (datés
de 2015) avec un bus PCIe de génération 3, le facteur d’accélération peut atteindre
un facteur ×7. Malheureusement, cela risque de ne plus être le cas dans le futur
avec 8 GPUs de dernière génénration Volta. Ces GPUs ont une puissance de calcul
2 fois plus rapide et donc leur ratio de communication est plus élevé (ηcomm ). Dans
ce cas, notre version distribuée devrait être la seule jusqu’à présent à présenter une
efficacité de parallélisation proche de l’optimale.
Chapitre 3. Résultats 27

120

s
PUs
s

s
PUs
s
2GPU
4GPU
8GPU

2GPU
4GPU
8GPU
1G

1G
100

Pourcentage % 80
% Calcul
60
% Transfert Mémoire

40

20

0
256 1024
Taille du volume
F IGURE 3.7 – Pourcentage des calculs et des transferts mémoires par
rapport au temps d’exécution de la version centralisée pour l’opéra-
teur de projection.

120
s
PUs
s

s
PUs
s
2GPU
4GPU
8GPU

2GPU
4GPU
8GPU
1G

1G

100
Pourcentage %

80
% Calcul
60
% Transfert Mémoire

40

20

0
256 1024
Taille du volume
F IGURE 3.8 – Pourcentage des calculs et des transferts mémoires par
rapport au temps d’exécution de la version distribuée pour l’opéra-
teur de projection.

Opérateur de rétroprojection
On s’intéresse également à la comparaison entre les performances obtenues par
la version avec données centralisées et la version avec données distribuées pour
l’opérateur de rétroprojection. La comparaison est effectuée sur un volume de taille
2563 puis sur un volume de taille 10243 . La Figure 3.9 montre les résultats d’accéléra-
tion obtenus pour l’opérateur de rétroprojection pour les deux versions (en variant
le nombre de GPUs utilisés et la taille du volume), égale approximativement à un
facteur ×8 si 8 GPUs sont utilisés.
L’efficacité de parallélisation est alors presque identique pour les deux version
avec une légère supériorité de la version «Données Distribuées» surtout quand la
taille du volume est importante.
Chapitre 3. Résultats 28

Efficacité de parallélisation
1

0.95

0.9

Données centralisées
Données distribuées
0.85
1 2 3 4 5 6 7 8 9

Nombre de GPUs
F IGURE 3.9 – Efficacité de parallélisation en fonction du nombre des
GPUs pour un volume de taille 2563 dans le cas des données centrali-
sées et distribuées.
Efficacité de parallélisation

1
Données centralisées
Données distribuées
0.95

0.9

0.85
1 2 3 4 5 6 7 8 9
Nombre de GPUs
F IGURE 3.10 – Efficacité de parallélisation en fonction du nombre
des GPUs pour un volume de taille 10243 dans le cas des données
centralisées et distribuées.

En comparant également les pourcentages du temps de transfert pour la ver-

sion avec données distribuées (Figure 3.12) et la version avec donnée centralisée (Fi-
gure 3.11). On remarque alors que pour les deux versions ηcomm représente presque
la moitié du temps total d’exécution dans le cas d’un volume de taille 2563 . Ce pour-
centage devient approximativement égal à 20% pour un volume plus grand de taille
égale à 10243 .
Chapitre 3. Résultats 29

120

s
PUs
s

s
PUs
s
2GPU
4GPU
8GPU

2GPU
4GPU
8GPU
1G

1G
100

Pourcentage % 80
% Calcul
60
% Transfert Mémoire

40

20

0
256 1024
Taille du volume
F IGURE 3.11 – Pourcentage des calculs et des transferts mémoires par
rapport au temps d’exécution de la version centralisée pour l’opéra-
teur de rétroprojection.

120
s
PUs
s

s
PUs
s
2GPU
4GPU
8GPU

2GPU
4GPU
8GPU
1G

1G

100
Pourcentage %

80
% Calcul
60
% Transfert Mémoire

40

20

0
256 1024
Taille du volume
F IGURE 3.12 – Pourcentage des calculs et des transferts mémoires
par rapport au temps d’exécution de la version distribuée pour l’opé-
rateur de rétroprojection

En résumé, l’utilisation de la communication directe pair-à-pair pour échanger

les données tout en réduisant au maximum les données échangés entre le CPU et
le GPU a permis de réduire davantage les temps "perdus" en transfert de données
pour les deux opérateurs de projection et de rétroprojection.
Chapitre 3. Résultats 30

3.2 L’algorithme itératif

(1) (2)

F IGURE 3.13 – (1) Fantôme Shepp-Logan reconstruit avec 10 itéra-

tions.
(2) Fantôme Shepp-Logan reconstruit avec 100 itérations.

Dans l’algorithme itératif, le nombre des itérations effectuées influence générale-

ment la qualité du volume reconstruit. La Figure 3.13 montre une comparaison entre
le volume reconstruit avec 10 puis avec 100 itérations. Ainsi, en pratique, on a ten-
dance à choisir une valeur importante pour le nombre des itérations de l’algorithme
itératif.
Dans ce cas, les pertes du temps en transfert des données sera encore plus impor-
tant. Ainsi, en représentant le facteur d’efficacité de parallélisation η pour la version
des données centralisées et la version des données distribuées pour différentes tailles
du volume, on remarque toujours que ce facteur est presque égal à 1 pour la version
avec données distribuée, tandis qu’il continue à chuter en augmentant le nombre de
GPUs dans la version centralisée (voir Figure 3.14).
Efficacité de parallélisation

0.98

0.96

0.94

0.92

0.9

0.88

0.86
Données centralisées
0.84
Données distribuées
0.82
1 2 3 4 5 6 7 8 9

Nombre de GPUs
F IGURE 3.14 – Efficacité de parallélisation en fonction du nombre des
GPUs dans le cas ou les données sont centralisées et distribuées pour
100 itérations. (taille du volume 10243 ).
Chapitre 3. Résultats 31

Pour expliquer cette remarque, on peut comparer le ratio ηcomm permettant de

calculer les temps de communications par rapport au temps de calcul dans le cas
des données centralisées et le cas des données distribuées. La Figures 3.15 montre le
résultat dans le cas des données centralisées et la Figure 3.16 dans le cas distribué.

120

8G PUs
PU s

8GPUs
PUs
s

8GPUs
PUs
s
s
2GPU
4GPU

2GPU
4GPU

2GPU
4GPU
1G

1G

1G
100 % Calcul
Pourcentage %

% Transfert Mémoire
80
60
40
20
0 1 Itération 50 Itérations 100 Itérations
Taille du volume
F IGURE 3.15 – Pourcentage des calculs et des transferts mémoires par
rapport au temps d’exécution de la version centralisée en fonction des
itérations et du nombre des GPUs ( taille du volume 10243 ).

120
8G PUs
PU s

8GPUs
PUs
s

8GPUs
PUs
s
s
2GPU
4GPU

2GPU
4GPU

2GPU
4GPU
1G

1G

1G

100 % Calcul
Pourcentage %

% Transfert Mémoire
80
60
40
20
0 1 Itération 50 Itérations 100 Itérations
Taille du volume
F IGURE 3.16 – Pourcentage des calculs et des transferts mémoires
par rapport au temps d’exécution de la version distribuée en fonction
des itérations et du nombre des GPUs ( taille du volume 10243 ).

Ainsi, on remarque que pour la version avec les données distribuées sur GPUs les
temps de transfert mémoire tendent vers 0 en augmentant le nombre des itérations.
Alors, que pour la version des données centralisées, les taux de transferts deviennent
de plus en plus important en augmentant le nombre des itérations et le nombre des
GPUs.
En résumé, l’optimisation qui a été effectuée sur les tailles données à échanger
entre le CPU et les GPUs ainsi que l’utilisation de la communication directe pair-à-
pair a permis d’obtenir une nette amélioration en performance pour les algorithmes
itératifs de reconstruction tomographique.
 32

Conclusion et Perspectives

Conclusion
Durant ces mois de stage au L2S, j’ai eu l’opportunité de mettre en œuvre
mes connaissances en traitement de signal et d’image avec mes compétences
en programmation. Ce stage m’a permis d’élargir mon spectre de connais-
sances, commençant par la tomographie à rayons X. J’ai pu alors avoir une
meilleure compréhension des principes physiques et mathématiques qui ré-
gissent la tomographie.

J’ai pu tout d’abord, à travers ce stage, découvrir les problématiques ren-

contrées en reconstruction tomographique surtout en géométrie conique, qui
est la plus utilisée dans le milieu industriel. J’ai pu, par la suite découvrir les
principales stratégies de solutions possibles à ces différentes problématiques.
Ainsi, j’ai pu découvrir et étudier les principales technologies et toolbox exis-
tantes dans le domaine de la tomographie.
La deuxième étape de mon stage m’a donné l’occasion d’expérimenter
les problèmes rencontrés en développement logiciel, puisque mon travail a
été de développer une version parallélisée en multi-gpus avec des données
distribuées afin d’améliorer davantage les performances des versions précé-
dentes. Cette étape, m’a permis de développer mes compétences en program-
mation parallèle ainsi qu’en optimisation.
Finalement, faire un stage de recherche au sein d’un laboratoire aussi dy-
namique que le L2S, m’a permis d’être au plus près de l’environnement de
recherche et de ses défis.

Perspectives
En guise de perspective, les prochaines semaines seront dédiées à la fi-
nalisation de toutes les fonctions nécessaires au bon fonctionnement de l’al-
gorithme itératif. Ensuite, l’intégration de cette version aux versions dispo-
nibles du logiciel est prévue.
A long terme, on peut envisager l’utilisation du bus NVLink pour les com-
munications pair-à-pair pour bénéficier davantage de la rapidité des trans-
ferts mémoire. Une autre possibilité est de tester le logiciel sur des clusters
permettant la gestion automatique du nombre des GPUs à utiliser pour les
calculs afin d’obtenir les meilleurs performances possibles.
 33

Bibliographie

[Aar+15] Wim van A ARLE et al. « The ASTRA Toolbox : A platform for advanced
algorithm development in electron tomography ». In : Ultramicroscopy
157 (2015), p. 35–47.
[Bha08] Venkatesh Bantwal B HAT. « High-Speed Reconstruction of Low-Dose CT
Using Iterative Techniques for Image-Guided Interventions ». Thèse de
doct. 2008.
[Big+19] Ander B IGURI et al. « Arbitrarily large iterative tomographic reconstruc-
tion on multiple GPUs using the TIGRE toolbox ». In : arXiv preprint
arXiv :1905.03748 (2019).
[Bou+15] Thomas B OULAY et al. TomoBayes v1.0 - logiciel de reconstruction en tomo-
graphie CT - Ref CNRS du pré-dépôt APP 11562-03 (num IDDN prochaine-
ment disponible). Déc. 2015. URL : https://hal.inria.fr/hal-01771489.
[CDL18] Simone C ARMIGNATO, Wim D EWULF et Richard L EACH. Industrial X-ray
computed tomography. Springer, 2018.
[CGM14] John C HENG, Max G ROSSMAN et Ty M C K ERCHER. Professional Cuda C
Programming. John Wiley & Sons, 2014.
[Cha+17] Camille C HAPDELAINE et al. « A 3D Bayesian computed tomography re-
construction algorithm with Gauss-Markov-Potts prior model and its ap-
plication to real data ». In : Fundamenta Informaticae 155.4 (2017), p. 373–
405.
[FD17] Denis F OLEY et John D ANSKIN. « Ultra-performance Pascal GPU and
NVLink interconnect ». In : IEEE Micro 37.2 (2017), p. 7–17.
[Jos] Peter M J OSEPH. « An improved algorithm for reprojecting rays through
pixel images ». In : IEEE transactions on medical imaging 1.3 (), p. 192–196.
[Li+19] Ang L I et al. « Evaluating Modern GPU Interconnect : PCIe, NVLink,
NV-SLI, NVSwitch and GPUDirect ». In : arXiv preprint arXiv :1903.04611
(2019).
[Pal+17] Willem Jan PALENSTIJN et al. « A distributed ASTRA toolbox ». In : Ad-
vanced structural and chemical imaging 2.1 (2017), p. 19.
[SB93] Ken S AUER et Charles B OUMAN. « A local update strategy for iterative
reconstruction from projections ». In : IEEE Transactions on Signal Proces-
sing 41.2 (1993), p. 534–548.
[Sha14] Chris C S HAW. Cone beam computed tomography. Taylor & Francis, 2014.
[Sid85] Robert L S IDDON. « Fast calculation of the exact radiological path for a
three-dimensional CT array ». In : Medical physics 12.2 (1985), p. 252–255.
[ZZZ12] Yining Z HU, Yunsong Z HAO et Xing Z HAO. « A multi-thread scheduling
method for 3D CT image reconstruction using multi-GPU ». In : Journal
of X-ray Science and Technology 20.2 (2012), p. 187–197.