Programmation GPU

Pour construire sur GPU l'histogramme des valeurs de pixels, faire ajouter directement par tous les threads via atomicAdd dans les 256 cases en mémoire globale peut être lent. Quelle méthode l'améliore ?

  1. AAbandonner atomicAdd et écrire en mémoire globale par une addition ordinaire
  2. BRéunir les cases en une seule
  3. CConstruire par bloc un histogramme partiel en mémoire partagée, puis l'ajouter en une fois aux cases en mémoire globale
Afficher la réponse et l'explication

Réponse : C. Construire par bloc un histogramme partiel en mémoire partagée, puis l'ajouter en une fois aux cases en mémoire globale

Lorsque de nombreux threads effectuent simultanément atomicAdd sur la même case, les mises à jour sont traitées une par une, et la mémoire globale étant lente, l'attente s'allonge. Si chaque bloc dispose de son propre histogramme en mémoire partagée, y compte, puis n'ajoute qu'une fois à la mémoire globale, les conflits en mémoire lente se réduisent à nombre de blocs × nombre de cases. Les opérations atomiques en mémoire partagée sont bien plus rapides.

S'entraîner sur ce thème Retour au thème

Autres questions sur Programmation GPU

  1. Pour calculer sur GPU la somme d'un grand nombre de valeurs, pourquoi utilise-t-on une réduction en arbre (répétition de l'addition de voisins qui divise par deux le nombre de valeurs) ?
  2. Combien d'étapes faut-il pour sommer 1024 valeurs par une réduction en arbre ?
  3. Dans un programme utilisant un GPU discret, quel énoncé est généralement correct au sujet de la mémoire côté CPU et côté GPU ?
  4. Envoyer des données au GPU pour un traitement léger, comme une seule addition par élément d'un tableau, peut être plus lent qu'un calcul sur CPU. Quelle en est la raison principale ?
  5. Pourquoi le transfert vers le GPU est-il plus rapide lorsque la mémoire CPU est épinglée (verrouillée en pages) ?

Comparatifs sur ce thème