X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/these_gilles.git/blobdiff_plain/e81bd9912542bc52e4b0fd1206e0b6f9b93a5fda..0b60f2b9f649af92fb00ae9fb88d77fe1cbb5c85:/THESE/Chapters/chapter5/chapter5.tex

diff --git a/THESE/Chapters/chapter5/chapter5.tex b/THESE/Chapters/chapter5/chapter5.tex
index be63700..88ec0cb 100644
--- a/THESE/Chapters/chapter5/chapter5.tex
+++ b/THESE/Chapters/chapter5/chapter5.tex
@@ -6,12 +6,11 @@ Les performances annoncÃ©es pour des fenÃªtres de petite taille comme 3$\times$3
 Un rapide prototypage a confortÃ© cette idÃ©e et nous a conduit Ã  chercher plus avant une technique d'implÃ©mentation du filtre mÃ©dian qui exploite pleinement les capacitÃ©s de nos GPU.
 
 \section{Les transferts de donnÃ©es}
-
 Le chapitre \ref{ch-GPU}, prÃ©sentant l'architecture et les caractÃ©ristiques principales des GPUs, donne Ã©galement la liste et les spÃ©cificitÃ©s des types de mÃ©moire accessibles par un kernel. Lorsqu'il s'agit de stocker des volumes importants de donnÃ©es, comme les images d'entrÃ©e et de sortie, les alternatives sont assez limitÃ©es. En effet, le seul espace mÃ©moire suffisamment important est celui la mÃ©moire dite globale, malheureusement la plus lente. On dispose cependant de plusieurs modes pour y accÃ©der, comme la dÃ©claration de textures, qui offre un mÃ©canisme de cache 2D permettant d'augmenter assez nettement les dÃ©bits en lecture dans le cas d'accÃ¨s au voisinage d'une donnÃ©e.
 Dans le cadre de nos travaux, cette mÃ©morisation sous forme de texture s'est montrÃ©e la plus performante pour les images d'entrÃ©e.
 
 Les images de sortie filtrÃ©es sont produites en mÃ©moire globale standard, hors texture, puis copiÃ©es vers une zone de mÃ©moire de l'hÃ´te (CPU) dont les pages sont rÃ©servÃ©es Ã  l'avances et verrouillÃ©es, ce qui Ã©vite les pertes de performances liÃ©es aux dÃ©fauts de page. L'algorithme \ref{algo-median-memcpy} synthÃ©tise ces pratiques en introduisant aussi les notations pour la suite. 
-Cet emploi de mÃ©moire que l'on qualifiera dorÃ©navant de \og non paginÃ©e \fg{}, apporte un gain de temps important dans les transferts mÃªme s'il peut aussi s'avÃ©rer limitant lorsqu'il s'agit de traiter de trÃ¨s grands volumes de donnÃ©es. Les quantitÃ©s de mÃ©moire vive dont disposent les ordinateurs modernes permettent cependant de traiter sans restriction des images de plusieurs centaines de millions de pixels. Nos essais ont Ã©tÃ© conduits avec des images d'au maximum 100~MP.
+Cet emploi de mÃ©moire que l'on qualifiera dorÃ©navant de \og non paginÃ©e \fg{}, apporte un gain de temps important dans les transferts mÃªme s'il peut aussi s'avÃ©rer limitant lorsqu'il s'agit de traiter de trÃ¨s grands volumes de donnÃ©es, puisqu'il empÃªche d'accÃ©der Ã  l'ensemble de la mÃ©moire vive de l'hÃ´te CPU. Les quantitÃ©s de mÃ©moire vive dont disposent les ordinateurs modernes permettent cependant de traiter sans restriction des images de plusieurs centaines de millions de pixels. Nos essais ont Ã©tÃ© conduits avec des images d'au maximum 100~MP.
 
 \begin{algorithm}
 %\SetNlSty{textbf}{}{:}
@@ -60,7 +59,7 @@ Le tableau \ref{tab-median-memcpy} donne le dÃ©tail des temps de transfert pour
 
 \section{Utilisation des registres}
 
-En traitement d'image, les filtres mÃ©dians sont beaucoup employÃ©s avec des tailles de fenÃªtres modestes comme prÃ©-traitement, Ã©ventuellement itÃ©ratif, ou bien avec de grandes tailles de fenÃªtres pour de l'estimation d'intensitÃ© d'arriÃ¨re plan. Les taille intermÃ©diaires, de l'ordre de quelques dizaines de pixels, ne sont Ã  notre connaissance pas employÃ©es.
+En traitement d'image, les filtres mÃ©dians sont beaucoup employÃ©s avec des tailles de fenÃªtres modestes comme prÃ©-traitement, Ã©ventuellement itÃ©ratif, ou bien avec de grandes tailles de fenÃªtres pour de l'estimation d'intensitÃ© d'arriÃ¨re plan. Les taille intermÃ©diaires, de l'ordre de quelques dizaines de pixels, ne sont Ã  notre connaissance que rarement employÃ©es.
 
 Un filtre mÃ©dian de petite taille ne rÃ©alise que peu d'opÃ©rations, sans complexitÃ© de surcroÃ®t, et doit donc atteindre des niveaux de performances Ã©levÃ©s.
 Le cadre gÃ©nÃ©ral des traitements sur GPU prÃ©sentÃ© au paragraphe \ref{sec-bilateral} n'est alors plus pertinent, pour deux raisons :
@@ -80,7 +79,6 @@ De ce point de vue, l'architecture Fermi, et en particulier le modÃ¨le C2070, ne
 
 
 \subsection{La sÃ©lection de la valeur mÃ©diane}
-
 Dans le cas des filtres mÃ©dians Ã  petite fenÃªtre, on peut envisager d'attribuer un registre par valeur Ã  trier. Dans ce cas, un mÃ©dian 3$\times$3 emploiera 9 registres par thread, et cette mÃ©thode pourra thÃ©oriquement s'appliquer jusqu'au mÃ©dian 7$\times$7 sur C2070 et 11$\times$11 sur C1060.
 Comme la recherche de performance impose de rationaliser l'utilisation des registres, nous nous sommes orientÃ©s vers l'algorithme dit \textit{forgetful selection} (sÃ©lection par oubli) qui Ã©vite d'avoir recours Ã  cette cardinalitÃ© de \og un registre pour un pixel\fg{} de la fenÃªtre (\cite{medianggems5}).
 
@@ -156,7 +154,7 @@ L'ensemble des choix que nous venons de dÃ©crire et qui ont prÃ©sidÃ© Ã  l'Ã©lab
 
 Les valeurs prÃ©sentÃ©es dans les tableaux  \ref{tab-median-coutcpy}, \ref{tab-median-chronos} et la figure \ref{fig-median-comp} sont obtenues par moyennage du chronomÃ©trage de 1000 exÃ©cutions du mÃªme kernel, dÃ©veloppÃ© en variantes 8 et 16 bits de profondeurs de niveau de gris. 
  
-La premiÃ¨re analyse que nous pouvons en faire est la pertinence des choix faits quant aux transferts de donnÃ©es, qui reprÃ©sentent entre 13\% et 82\% du temps total d'exÃ©cution des configurations testÃ©es. 
+L'analyse que nous pouvons tirer du tableau \ref{tab-median-coutcpy} est la pertinence des choix relatifs aux transferts de donnÃ©es, qui reprÃ©sentent entre 13\% et 82\% du temps total d'exÃ©cution des configurations testÃ©es. 
 
 \begin{table}[ht]
 \renewcommand{\arraystretch}{1.5}
