Impact de l’association bloc de threads/nombre de pixels par bloc

Nous cherchons à obtenir les paramètres de dimensionnement de kernel optimaux pour nos deux implémentations Exhaust et Interp. Les paramètres sont pour une taille de traducteur donné, la taille du bloc de threads et le nombre de pixels traités par bloc. On va donc faire va- rier ces paramètres sur des intervalles correspondants à des valeurs classiques sur GPU telles que présentée par [Kirk and Hwu, 2010]. Concernant les tailles de bloc, l’intervalle classique sur GPU est [32; 256]. Ces valeurs permettent d’obtenir un chargement suffisant du GPU si plu- sieurs blocs peuvent être exécutés en parallèle sur les multiprocesseurs du GPU. Quant aux valeurs du nombre de pixels par bloc, nous les faisons varier entre 1 et 4 pour l’implémenta- tion Exhaust, et 1 et 16 pour l’implémentation Interp. Dans le cas de l’implémentation Exhaust, ce dernier paramètre joue directement sur la quantité de mémoire partagée utilisée, alors que pour l’implémentation Interp, cela n’a pas d’impact et cela permet donc d’utiliser une valeur plus grande. La valeur de 16 est déterminée en fonction du nombre de pixels par tuile, qui se trouve être de 14× 14 pour la résolution utilisée sur DATA 1.

Nous avons effectué un paramétrage à l’aide du jeu de données DATA 1, sur C2070. Les figures 3.16 et 3.17 présentent les performances des implémentations CUDA Exhaust et Interp sur les paramétrages proposés ci-dessus.

0 100 200 300 400 500 600 700 800 32 64 128 256 Temps (ms)

Taille des blocs de threads Paramétrage CUDA Exhaust C2070 (DATA1)

Nombre de pixels par bloc 1 2 4

FIGURE 3.16 – Paramétrage du noyau de calcul Exhaust pour l’implémentation CUDA sur C2070. 0 100 200 300 400 500 600 700 800 900 1000 32 64 128 256 Temps (ms)

Taille des blocs de threads Paramétrage CUDA Interp C2070 (DATA1)

Nombre de pixels par bloc 1 2 4 8 16

FIGURE3.17 – Paramétrage du noyau de calcul Interp pour l’implémentation CUDA sur C2070.

On constate sur la figure 3.16 que plusieurs valeurs sont optimales, mais à chaque fois pour le plus grand nombre possible de pixels par blocs. On peut constater des écarts de performances allant jusqu’à un facteur×2. L’association 256/4 permet d’obtenir les meilleures performances pour l’implémentation Exhaust. Cependant, les cas 64/4 et 128/4 sont très proches, avec des variations à la baisse de moins de 2%. Nous allons donc choisir d’effectuer nos benchmarks avec le couple 64/4 et ce afin de garder une bonne efficacité pour les cas de jeux de données de petites dimensions, pour lesquels cette taille de bloc est plus adaptée.

Pour l’implémentation Interp, on peut constater le même principe sur la figure 3.17. C’est l’association 256/16 qui permet d’obtenir les meilleures performances. En revanche ici, le fait d’augmenter le nombre de pixels par blocs n’implique pas une augmentation de l’utilisation de mémoire shared (c.f. section 3.5.1.3), on peut donc aller jusqu’à 16 pixels traités par un même bloc. Grâce à cela on peut constater un écart de performances allant jusqu’à un facteur×3,5. Pour les mêmes raisons que précédemment, nous allons préférer le couple 128/16 à 256/16 pour des raisons d’efficacité, mais la différence de performances n’est plus significative à ce niveau.

Sachant que le dimensionnement des blocs de threads en CUDA ou OpenCL est déjà une thécmdmatique d’optimisation [Torres et al., 2012], l’ajout de l’optimisation architecturale per- mettant un sous-découpage de bloc amène des différences de performances d’autant plus im- portantes entre les différentes configurations. Nous avons synthétisé les différentes associations optimales que nous avons obtenues dans le tableau 3.6 pour les différentes implémentations et GPU utilisés. Ces valeurs ont été obtenues en moyennant les performances sur les quatre jeux de données avec les configurations par défaut. Nous pouvons nous permettre d’effectuer cette moyenne dans la mesure où le nombre d’éléments du capteur est constant entre les jeux de données.

On remarque qu’entre CUDA et OpenCL, les paramètres ne sont pas identiques à architec- ture égale. Malgré cela, les valeurs sont très proches. Si par exemple, les paramètres obtenus en CUDA sur la C2070 sont utilisés sur l’implémentation OpenCL, l’écart de performances n’est que de 1,3%. Les paramètres de dimensionnement des kernels présentés dans le tableau précédent seront utilisés dans la suite des benchmarks.

Tableau 3.6 – Association optimale entre le nombre de threads par bloc et le nombre de pixels traités par bloc pour chaque Implémentation.

Implémentation Exhaust Implémentation Interp taille de bloc nombre de pixels taille de bloc nombre de pixels

C2070 CUDA 64 4 128 16

GTX 580 CUDA 64 4 128 16

C2070 OpenCL 64 4 256 8

GTX 580 OpenCL 64 4 128 16

HD 6970 OpenCL 64 4 128 8

3.5.2.2 Impact de la résolution de l’image

Bien que nos configurations par défaut aient une résolution fixée, basée sur une valeur moyenne du besoin de l’utilisateur de l’algorithme FTP, nous avons effectué une étude de performances pour différentes tailles d’image et observé le comportement des différentes im- plémentations. Nous présentons les résultats sur les jeux de données DATA 1 et DATA 4. Les quatre figures, 3.18 à 3.21 présentent les résultats pour les deux jeux de données et les deux méthodes de calcul. Les temps affichés sont normalisés en fonction du nombre de pixels de l’image. Cela permet d’obtenir un temps de calcul par pixel. Deux points importants sont à noter :

• seule la résolution pixel varie, permettant au calcul par interpolation d’être logiquement de plus en plus performant lorsque la résolution grandit,

• les courbes obtenues pour les jeux de données DATA 1 et DATA 4 ne sont pas directe- ment comparable à résolution pixel égales car le maillage sur lequel le calcul est effectué en interpolation dépend du ratio entre la maille physique et la maille pixel. Pour le jeu de données DATA 4, le ratio est inférieur au jeu de données DATA 1 à résolution pixel égale. Cela permet d’obtenir des temps de reconstruction plus adaptés au benchmark et à l’utilisateur qui évitera d’aller chercher des résolutions trop importantes pour des reconstructions qu’il prévoit comme déjà très longues.

10-2 64 128 192 256 320 384 448 512 Temps (ms / (N p *N p ))

Taille de l'image en pixels1/2

Variation Image GPU Exhaust DATA1

GTX580 CUDA Exhaust C2070 CUDA Exhaust GTX580 OCL Exhaust C2070 OCL Exhaust HD6970 OCL Exhaust

FIGURE3.18 – Temps de calcul normalisé pour l’implémentation Exhaust sur GPU pour le jeu de données DATA 1 et pour des tailles d’images de 64× 64 à 512 × 512.

Le jeu de données DATA 1 nécessite le moins de calculs. En effet, dans le cas d’une surface plane, la résolution d’équations polynomiales se fait comme on l’a vu sur un polynôme de degré 4. On constate sur la figure 3.18 que le temps de calcul normalisé devient rapidement constant à partir d’une dimension d’image proche de 200× 200, et ce, quelle que soit l’implé- mentation ou l’architecture. On notera que la courbe de la HD6970 est la plus constante des cinq courbes, ne bénéficiant pas d’amélioration de l’efficacité pour de plus grands traducteurs. Ses performances sont légèrement en retrait des cartes Nvidia. De manière générale, on peut simplement constater qu’à partir d’une certaine quantité de pixels, l’implémentation devient linéairement dépendante du nombre de pixels de l’image. Sur la figure 3.19, on peut constater le même comportement, avec ici une HD6970 au même niveau de performances que la Tesla C2070.

10-2 10-1 64 128 192 256 320 384 448 512 Temps (ms / (N p *Np ))

Taille de l'image en pixels1/2

Variation Image GPU Exhaust DATA4

GTX580 CUDA Exhaust C2070 CUDA Exhaust GTX580 OCL Exhaust C2070 OCL Exhaust HD6970 OCL Exhaust

FIGURE3.19 – Temps de calcul normalisé pour l’implémentation Exhaust sur GPU pour le jeu de données DATA 4 et pour des tailles d’images de 64× 64 à 512 × 512.

Concernant l’implémentation Interp, les figures 3.20 et 3.21 présentent respectivement les résultats pour les jeux DATA 1 et DATA 4. On peut constater que les comportements entre les deux jeux sont extrêmement différents. En effet, lorsque la résolution augmente, le nombre de tuiles d’interpolation est lui fixe, et c’est le nombre de pixels traité par tuile qui augmente.

0.01 64 128 192 256 320 384 448 512 Temps (ms / (N p *Np ))

Taille de l'image en pixels1/2 Variation Image GPU Interp DATA1

GTX580 CUDA Interp C2070 CUDA Interp GTX580 OCL Interp C2070 OCL Interp HD6970 OCL Interp

FIGURE3.20 – Temps de calcul normalisé pour l’implémentation Interp sur GPU pour le jeu de données DATA 1 et pour des tailles d’images de 64× 64 à 512 × 512.

0.01 0.1 64 128 192 256 320 384 448 512 Temps (ms / (N p *Np ))

Taille de l'image en pixels1/2

Variation Image GPU Interp DATA4

GTX580 CUDA Interp C2070 CUDA Interp GTX580 OCL Interp C2070 OCL Interp HD6970 OCL Interp

FIGURE3.21 – Temps de calcul normalisé pour l’implémentation Interp sur GPU pour le jeu de données DATA 4 et pour des tailles d’images de 64× 64 à 512 × 512.

Pour le jeu DATA 1, on constate que les courbes sont relativement constantes. Cela s’ex- plique par le fait du peu de calculs sur cette configuration et on peut donc conclure que cette implémentation est memory-bound sur ce jeu de données. Cette limitation mémoire se situe di- rectement sur les accès mémoire aux signaux. Quant au jeu de données 4, on constate que plus la résolution augmente, plus le coût de calcul par pixel est faible. Lorsqu’on arrive à une résolu- tion de 512× 512, la courbe n’est toujours pas sur un palier. Cela veut dire qu’en contre-partie, le calcul nécessaire aux temps de vol est suffisant pour contre-balancer les accès mémoire aux signaux, qui sont linéairement dépendants du nombre de pixels de l’image, même pour ce type de résolutions.

Pour les implémentations Exhaust, le calcul est donc linéairement dépendant du nombre de pixels, tandis que pour les implémentations Interp, selon la quantité de calcul, on peut constater que cette plage est décalée vers des résolutions supérieures. De manière générale, les résolu- tions utilisées par défauts sont dans la plage où le temps de calcul par pixel est constant. Nous allons maintenant faire varier le nombre d’éléments du traducteur afin de voir le liens avec le temps de calcul.