Algorithmes de la morphologie mathématique pour - Pastel - HAL

Jaromír BRAMBOR9.7. RÉCAPITULATIONvoi de commandes qui comptent peu de triangles, cet fait étant mentionné dans la présentation deWloka Wlo03 . Le test que nous effectuons ici semble convenable pour cette démonstration. Nous y envoyons1 rectangle (qui est constitué de 2 triangles), il suffirait de comparer les fps obtenus pour les deuxsystèmes d’exploitation.Nous remarquons que ce type de travail n’est pas propre à l’utilisation habituelle des GPU car cesderniers ne sont pas conçus pour un travail à une fréquence élevée d’affichage dans le framebuffer maisils sont conçus pour les algorithmes qui se présentent par des taux des fps moindres à 100, le nombrepropre à la fréquence de rafraîchissement des trames pour la visualisation.Les résultats nous révèlent trois idées principales :• Il est à recommander de travailler avec une application qui fonctionne en régime plein écran (cf.les colonnes Plein écran dans la tab. 9.2). Dans le cas opposé où nous travaillerons dans unefenêtre de système d’exploitation (ou de système de fenêtres dans le cas de Linux), les taux de fpschuteraient d’une manière significative (cf. les colonnes Fenêtre dans la tab. 9.2).• On peut percevoir une certaine supériorité des résultats pour Linux et le pilote du processeur pourOpenGL en terme de fps qui sont plus grandes que celles pour Windows et DirectX. Mais noustrouvons également le cas contraire, notamment les valeurs de fps pour les images de 3 Mo lorsd’un remplissage par la couleur variante en plein écran. Il faut souligner que les résultats desdeux API ne sont pas excessivement différents et nous ne pouvons pas faire une recommandationd’utilisation d’un API plutôt que de l’autre. De plus, ces résultats étant fortement dépendants de laversion du pilote, ils peuvent varier fortement d’une version à l’autre.• Le fait d’avoir ajouté au traitement de base l’interpolation des couleurs se manifeste par une diminutiondes fps allant dans certains cas jusqu’à 2 fois (Linux, Plein écran, 4 Mo). Sachant que cetest devait démontrer les capacités d’interpolation des valeurs (nous visons prioritairement l’interpolationdes coordonnées des index de textures lors du travail avec 4 textures, sans avoir effectuél’échantillonnage), les résultats sont plutôt décevants car lors du travail avec les algorithmes detraitement d’images, nous allons encore ajouter aux temps qui correspondent à ces fps la durée desopérations de traitement des fragments (échantillonnage, opérations arithmétiques, etc.).9.7 RécapitulationCe petit chapitre devait nous servir à introduire des techniques pour la description de la complexitédes algorithmes. Nous y avons présenté, sur un exemple pratique pour les GPP/GPPMM les phénomènesque nous devons assumer si nous voulons passer de l’expression théorique de la complexité à l’aidede O() à une estimation pratique du coût d’un algorithme, qui est, dans notre cas, prioritairement lié àl’expression du temps du calcul.Cette estimation pratique n’est pas simple et est fortement liée à une architecture donnée mais également,comme nous l’avons présenté dans 9.4.2, page 180, à d’autres facteurs qui ne sont pas a priori aussiévident à assumer, comme les dimensions relatives d’une image et de la mémoire cache de l’architecture.L’estimation pratique des performances des algorithmes pour les GPU est encore plus délicate. Pourpouvoir obtenir des estimations fiables, on devrait prendre en compte beaucoup de paramètres. De cesderniers, nous avons présenté en particulier le temps de transfert de données et la possible influence dusystème d’exploitation et de l’interface de programmation (l’API) que nous utilisons pour exécuter noscommandes graphiques. Remarquons que pour un programme donné et pour un processeur graphiquedonné, les outils de développement de NVidia permettent de calculer avec précision le nombre de cyclesque les programmes pour les vertex et pour les fragments sont censés consommer. Mais il ne s’agit que dedeux des unités du pipeline graphique et il n’existe pas une méthode pour pré-évaluer les performancesdu pipeline graphique dans son entier.Même dans la littérature portant sur le GPGPU, nul ne présente les estimations de la performancepour les algorithmes pour les GPU. C’est dû au caractère des données, dépendantes de l’interaction avecl’utilisateur, qui sont traitées dans la synthèse d’images. Par conséquent, il n’est pas possible de prévoir187