OpenCL dans le Trading - page 3

Nouveau commentaire
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL.2. Présentation d'OpenCL



2- Introduction à OpenCL

Cette vidéo fournit une introduction détaillée à OpenCL, une plate-forme de calcul parallèle qui peut utiliser des CPU et des GPU pour accélérer les calculs. Les programmes écrits en OpenCL peuvent être exécutés sur différents appareils et architectures, permettant un code portable sur différentes plates-formes. La vidéo présente les différents modèles d'exécution dans OpenCL, y compris le parallélisme des données et le parallélisme des tâches, et couvre également les différents objets et commandes utilisés dans OpenCL, tels que les objets mémoire, les files d'attente de commandes et les objets noyau. La vidéo se penche également sur les avantages et les limites de l'utilisation d'OpenCL, tels que la nécessité d'une gestion explicite de la mémoire et le potentiel d'améliorations significatives des performances dans les programmes parallèles.

  • 00:00:00 Dans cette section, l'orateur présente OpenCL et sa capacité à utiliser des processeurs et des GPU pour accélérer les calculs parallèles, ce qui entraîne des accélérations significatives. Bien que des nombres comme 100X ou 1000X soient parfois cités, de manière réaliste, des accélérations d'environ 10 à 20X sont attendues pour des programmes optimisés. OpenCL peut écrire du code portable sur différents appareils et architectures ; par conséquent, les programmes écrits pour les GPU AMD peuvent généralement s'exécuter également sur les GPU NVIDIA. Avec l'implémentation AMD, l'implémentation CPU et GPU d'OpenCL est fournie, contrairement à certaines implémentations d'autres concurrents. La section se termine par un aperçu de l'informatique hétérogène et de la manière dont OpenCL s'y intègre.

  • 00:05:00 Dans cette section, le conférencier propose une introduction à OpenCL, qui est une plate-forme de bas niveau et verbeuse qui peut être gratifiante en termes de performances si l'application a les bonnes caractéristiques. OpenCL est un modèle basé sur une plate-forme qui se compose d'une API hôte, d'un modèle d'appareils connectés et d'un modèle de mémoire. Les appareils sont considérés comme une collection d'unités de calcul, et chaque unité de calcul est décomposée en éléments de traitement qui s'exécutent dans SIMD. Le modèle d'exécution est basé sur la notion de noyau, qui est l'unité de code exécutable pouvant être exécuté en parallèle sur plusieurs données. De plus, OpenCL fournit un ensemble de files d'attente qui permettent l'exécution asynchrone des opérations de lecture et d'écriture et l'exécution du noyau, qui peuvent être ordonnées ou non.

  • 00:10:00 Dans cette section, l'orateur aborde les deux principaux modèles d'exécution dans OpenCL : le parallélisme des données et le parallélisme des tâches. Le modèle parallèle de données est le plus efficace pour l'exécution sur les GPU et implique un domaine de calcul à N dimensions où chaque élément individuel est appelé un élément de travail qui peut potentiellement s'exécuter en parallèle. L'exécution des éléments de travail peut être regroupée en dimensions locales appelées groupes de travail qui sont exécutés sur l'une des unités de calcul disponibles. L'orateur explique également comment la boucle est implicite dans le monde parallèle des données d'OpenCL et comment la routine get global identifier est utilisée pour indexer dans a et b.

  • 00: 15: 00 Dans cette section, l'orateur discute de la mémoire locale, qui est similaire à un cache et est gérée par l'utilisateur, étant à faible latence et plus rapide que la mémoire globale. La fonction de synchronisation permet aux éléments de travail d'écrire dans un emplacement mémoire, d'attendre la fin, puis de demander à un autre élément de travail de lire cet emplacement mémoire et d'obtenir la valeur écrite par l'élément de travail précédent. La synchronisation ne peut être effectuée qu'au sein du groupe de travail. OpenCL prend également en charge le parallélisme des tâches, exécuté par un seul élément de travail, et bénéficie de l'utilisation du modèle de file d'attente OpenCL et des fonctionnalités de synchronisation de l'API hôte, permettant un code compilé en mode natif. OpenCL diffère de C en ce que la hiérarchie de la mémoire de GPU particuliers est explicitement exposée, et le programmeur peut induire un ordre et une cohérence des données grâce à l'utilisation d'opérations de barrière et de synchronisation.

  • 00:20:00 Dans cette section, le conférencier discute des avantages d'OpenCL, tels que ses puissantes capacités de performance. Cependant, ils soulignent que la gestion de la mémoire dans OpenCL nécessite des opérations explicites, qui peuvent être compliquées et nécessitent une attention particulière à l'algorithme. Le modèle de compilation est basé sur OpenGL et dispose d'un modèle de compilation en ligne qui permet de transmettre des flux ou des chaînes de code source OpenCL pour la compilation en ligne. OpenCL est construit autour du contexte, d'une collection d'appareils et d'objets mémoire, et les files d'attente sont utilisées pour soumettre le travail à un appareil particulier associé au contexte. Les objets mémoire sont des tampons, qui sont des blocs de mémoire unidimensionnels qui peuvent être considérés comme des tableaux.

  • 00:25:00 Dans cette section, l'orateur explique les différents objets OpenCL, y compris les objets mémoire, les images, les programmes et les noyaux. Les objets mémoire peuvent être des tampons ou des types d'image, où les images ont une implémentation matérielle pour optimiser l'accès. Les programmes qui définissent les noyaux pour l'exécution peuvent être construits et extraits, et les valeurs des arguments du noyau peuvent être définies à l'aide d'objets noyau. Les files d'attente de commandes sont utilisées pour mettre en file d'attente les noyaux et d'autres commandes en vue de leur exécution. De plus, les événements OpenCL sont utiles pour créer des dépendances entre les commandes et interroger l'état des commandes. L'orateur donne également des exemples sur la façon d'interroger les appareils et leurs identifiants.

  • 00:30:00 Dans cette section, l'orateur explique comment OpenCL renvoie les codes d'erreur et les objets. Si une fonction renvoie un objet CL, elle renverra cet objet en conséquence. Mais s'il ne renvoie pas d'objet CL, il renverra le code d'erreur comme résultat. Le contexte est discuté et comment la mémoire est allouée au niveau du contexte, ce qui signifie que les tampons et les images sont partagés entre les appareils. L'orateur mentionne également la fonction CL get X info, en particulier CL get device info, qui permet aux développeurs d'interroger les capacités de l'appareil pour déterminer quel appareil est le mieux adapté à l'algorithme. Enfin, l'orateur discute des tampons et des images, et de la manière dont les noyaux peuvent y accéder, ainsi que des restrictions d'accès aux images.

  • 00: 35: 00 Dans cette section, l'orateur explique comment allouer des tampons et des images dans OpenCL, y compris comment décrire comment les tampons seront accessibles et les avantages de l'utilisation d'images. L'orateur explique également comment accéder aux données d'objet mémoire à l'aide de commandes explicites et comment mettre en file d'attente des commandes dans une file d'attente. De plus, la vidéo explique comment cartographier une région et transférer des données entre les tampons ainsi que les avantages et les inconvénients de l'utilisation d'unités DMA. La section se termine en discutant des objets du programme et du noyau et en définissant les valeurs des arguments.

  • 00:40:00 Dans cette section, l'orateur discute de la répartition et des dépendances dans OpenCL. Ils expliquent comment la répartition s'exécutera en fonction du domaine ou de la grille d'exécution, et comment les dépendances peuvent être configurées pour s'assurer que les choses ne se dépassent pas. L'orateur explique également les arguments de la commande NQ, qui prennent en compte le nombre d'événements dans la liste d'attente et l'événement associé à la commande. Enfin, l'orateur donne un aperçu du langage OpenCL C, qui est basé sur C et comporte certaines restrictions et ajouts, tels que les types de vecteurs et les primitives de synchronisation. Le langage autorise les éléments de travail et les groupes de travail, ainsi que les qualificateurs d'espace d'adressage et les fonctions intégrées.

  • 00:45:00 Dans cette section, l'orateur donne un bref aperçu d'OpenCL et de ses fonctionnalités, telles que les différents espaces d'adressage, les types de vecteurs et les types scalaires qui peuvent être utilisés dans les noyaux de programmation. Ils expliquent également comment créer des objets mémoire et construire et exécuter des programmes à l'aide de l'API OpenCL. L'orateur aborde ensuite une question sur la différence entre le parallélisme des données dans OpenCL et le déroulement de boucle dans les compilateurs.

  • 00:50:00 Dans cette section, l'orateur explique le concept d'exécution parallèle des données et les difficultés des composants à le faire efficacement. Il souligne également la nécessité de paralléliser explicitement les programmes pour OpenCL ou tout autre modèle. Le inq_marker est un autre sujet qui est couvert et comment il est utile dans les cues dans le désordre. L'orateur répète que la mémoire constante signifie que les valeurs sont constantes et qu'elle est utilisée sur des GPU spéciaux pour se charger dans une mémoire constante très rapide, qui est en lecture seule. Il suggère de consulter la zone OpenCL sur le site Web de MD pour plus d'informations sur OpenCL et la programmation parallèle. Enfin, il explique comment get_global_ID(0) renverrait la même valeur pour chaque appel du noyau.

  • 00: 55: 00 Dans cette section, l'orateur explique que lorsque deux applications différentes s'exécutent et tentent d'utiliser OpenCL sur la même machine, toutes les implémentations d'aujourd'hui partageront le matériel et le système d'exploitation multiplexera les applications. Ils recommandent d'utiliser des profileurs visuels pour OpenCL, tels que le plug-in Visual Studio ou la version en ligne de commande Linux, qui permettent d'interroger des informations sur id Hardware. La surcharge de chargement des données dans l'objet image ou la mémoire tampon dépend du périphérique, où le transfert via le bus PCIe aurait une plus grande latence. Enfin, l'orateur a mentionné que la nouvelle série de GPU AMD 680 cent et les meilleures pratiques de programmation pour eux sont similaires à l'architecture Evergreen, sur laquelle ils sont basés.
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL. 3. Architecture GPU



3 - Architecture GPU

Cette vidéo donne un aperçu de l'architecture GPU, en prenant note des origines et de l'utilisation principale des GPU en tant que processeurs graphiques. Les GPU sont conçus pour traiter les pixels avec un haut degré de parallélisme, contrairement aux CPU conçus pour le traitement scalaire avec des pipelines à faible latence. L'architecture des GPU est optimisée pour les tâches spécifiques aux graphiques, qui peuvent ne pas convenir au calcul à usage général. L'orateur explique comment le GPU maximise le débit d'un ensemble de threads plutôt que de minimiser la latence d'exécution d'un seul thread. L'architecture du bloc moteur GPU est également abordée, y compris les partages de données locaux, les fronts d'onde et les groupes de travail. La vidéo explore diverses fonctionnalités de l'architecture GPU qui aident à augmenter la quantité de compactage que le compilateur peut effectuer, y compris l'émission d'opérations dépendantes dans un seul paquet et la prise en charge des compteurs dépendants avec un partage bêta global. Bien que les conceptions de cœur de GPU et de CPU puissent être similaires, leurs charges de travail devront converger pour qu'elles aient des conceptions similaires.

Dans cette vidéo sur l'architecture GPU, le conférencier se penche sur le concept des barrières et leur fonction. Lorsqu'un groupe de travail contient plusieurs fronts d'onde dans un GPU, des barrières sont utilisées pour synchroniser ces fronts d'onde. Cependant, si un seul front d'onde de travail existe dans un groupe, les barrières perdent leur sens et seront réduites à des non-opérations.

  • 00:00:00 Dans cette section, les présentateurs présentent l'objectif du webinaire, qui est de fournir un aperçu de l'architecture GPU sous un angle différent par rapport à l'approche traditionnelle de description de l'architecture ou des optimisations de bas niveau. Les présentateurs visent à mettre l'architecture GPU en contexte en discutant de ses origines et de son principal cas d'utilisation en tant que processeurs graphiques. Ils expliquent comment les GPU sont conçus pour traiter les pixels avec un haut degré de parallélisme, ce qui est différent des CPU conçus pour le traitement scalaire avec des pipelines à faible latence. Les présentateurs expliquent également comment l'architecture des GPU peut ne pas convenir au calcul à usage général en raison de leurs blocs matériels optimisés conçus pour accélérer les tâches spécifiques aux graphiques.

  • 00: 05: 00 Dans cette section, nous apprenons à exécuter des programmes fragmentés indépendants et liés à un seul pixel, écrits en GLSL ou HLSL, et comment ce modèle de programmation permet un parallélisme efficace sans analyse de dépendance ni communication inter-pixels. Le matériel est conçu pour exécuter le code de shader sur plusieurs pixels à la fois, connu sous le nom de front d'onde, mais avec le problème du code de bloc et des branches. Le problème survient lorsque toutes les branches suivent le même chemin, causant un problème, mais le matériel génère un masque pour s'assurer que tous les pixels exécutent la même instruction.

  • 00: 10: 00 Dans cette section, l'orateur explique comment l'exécution de Cindy nécessite simplement des instructions et l'utilisation d'instructions vectorielles. Alors que les instructions vectorielles peuvent être générées par le matériel ou un compilateur, cela peut rendre le développement fastidieux et difficile en raison de la nécessité d'un empaquetage manuel de différentes opérations, d'un masquage de branche et d'un codage manuel minutieux. D'autre part, programmer l'exécution de Cindy à l'aide d'instructions vectorielles risque de faire croire au développeur que les voies se branchent indépendamment, ce qui n'est pas vrai. Malgré cela, il est toujours plus facile pour les programmeurs de réfléchir et pour les GPU AMD actuels, le masquage est contrôlé par le matériel. Ceci est important à prendre en compte pour le calcul, qui est le but de la discussion, car cela peut affecter les performances, en particulier avec la divergence des branches dans le Waveland plus large.

  • 00: 15: 00 Dans cette section, l'orateur discute des aspects visibles des architectures GPU basées sur le calcul du débit, ce qui signifie que si un vecteur d'instruction se bloque dans un GPU, ce qui peut se produire si l'ajout en virgule flottante prend quelques cycles pour complète, la même instruction peut être utilisée pour couvrir le temps de blocage dans le vecteur suivant, ce qui rend le décodage des instructions plus efficace. L'orateur explique qu'au lieu d'augmenter la largeur de vecteur qui peut réduire l'utilisation des ALU, plusieurs fronts d'onde peuvent se faufiler dans les instructions d'autres threads en cours d'exécution, ce qui donne la probabilité de ne pas caler simplement en attendant que les unités de texture renvoient des données mémoire. Cependant, un seul front d'onde prend plus de temps à s'exécuter de cette manière en raison du fonctionnement de l'architecture.

  • 00:20:00 Dans cette section, la vidéo explique comment le GPU maximise le débit d'un ensemble de threads plutôt que de minimiser la latence d'exécution d'un seul thread. Cela signifie que le GPU essaie d'augmenter l'utilisation des threads en attendant la fin de l'exécution du premier thread, puis en alimentant le front d'onde suivant, tandis que les résultats du premier ensemble de pixels sont réutilisés pour maintenir le pipeline aussi proche que possible de l'occupation complète. . Le GPU maintient un grand pool de registres pour couvrir toute la largeur du vecteur pour chaque thread en vol, occupant de l'espace sur l'appareil, qui évolue avec le nombre d'états et la largeur du vecteur. Le GPU est conçu pour couvrir la latence, et donc au lieu de minimiser la latence, le GPU maximise la bande passante mémoire disponible afin qu'il puisse satisfaire tout le parallélisme, en utilisant des caches de texture et de la mémoire locale pour la réutilisation des données entre les éléments de travail.

  • 00: 25: 00 Dans cette section, l'orateur explique comment les caches et les régions de mémoire partagée contrôlées par le programme peuvent réduire le transfert de données en permettant aux données d'être copiées une seule fois à partir de l'interface de mémoire principale, puis réutilisées par différents éléments de travail dans différents chemins. Ils expliquent comment le cache de texture est conçu pour appliquer automatiquement une structure 2D sur ses données de manière efficace afin de capturer les accès 2D par les quads. Les régions de données locales offrent considérablement plus de contrôle, mais il incombe au développeur de structurer efficacement les charges pour utiliser cette mémoire et de partager les données afin de réduire les besoins en mémoire globale. La section explore également comment le GPU peut être considéré comme une collection de cœurs Cindy câblés avec plusieurs états de programme entrelacant 4, 8 ou 16 threads pour couvrir la latence du pipeline. Le compromis entre le nombre de cœurs et la densité ALU est discuté, avec l'avantage d'augmenter l'utilisation, en fonction de la charge de travail.

  • 00:30:00 Dans cette section, le conférencier discute des similitudes et des différences entre les conceptions de cœur de processeur et de processeur graphique, en utilisant des exemples tels que Andy Phenom 2 X6 6 et Intel i7. Alors que l'approche adoptée par le Pentium 4 et l'ultraSPARC T2 impliquait des tailles de cœur plus grandes avec plusieurs ensembles d'états pour augmenter le parallélisme des niveaux d'instructions, les GPU se situent à l'extrémité du spectre avec un degré élevé d'équilibrage des données. Les détails techniques de l'AMD Radeon HD 5870 sont également abordés, soulignant sa bande passante élevée et le nombre de formes d'onde simultanées disponibles qui dépendent du nombre de registres utilisés par chaque front d'onde. L'orateur conclut que même s'il peut y avoir des similitudes dans l'espace de conception entre les neuf CPU et GPU, leurs charges de travail devront converger pour qu'ils aient des conceptions similaires.

  • 00:35:00 Dans cette section, nous découvrons les éléments de conception du GPU, y compris les partages de données locaux et les fronts d'onde et les groupes de travail dans lesquels il est divisé. La conception du GPU comprend un processeur de commande de répartition du colonel qui génère des fronts d'onde, qui sont affectés à une unité SIMD disponible qui dispose de suffisamment de ressources pour s'adapter à l'espace. L'ensemble de la puce dispose de 20 moteurs Cindy avec 8 banques de mémoire GDDR5 pour les crossbars et les caches. En outre, il dispose d'un modèle de cohérence de mémoire global détendu, qui nécessite des instructions de clôture pour garantir les droits de visibilité, permettant aux moteurs Cindy et aux unités fixes de maintenir un degré élevé d'exécution parallèle des données sans la surcharge de performances énergétiques. Le GPU utilise un modèle d'exécution basé sur des clauses, ce qui lui permet d'exécuter simultanément de nombreux programmes de flux de contrôle sur le moteur le plus simple.

  • 00:40:00 Dans cette section, l'architecture du bloc moteur GPU est abordée. Le bloc moteur comporte deux composants principaux : le partage de données local, qui permet le partage de données entre les éléments de travail d'un groupe de travail et les éléments de post-test, ou les cœurs de flux, qui exécutent les instructions des clauses ALU dans le noyau. Le partage de données local a 32 banques, chacun des 16 éléments de traitement du moteur peut demander de lire ou d'écrire des mots de 32 bits à partir de LDS à chaque cycle à des adresses arbitraires, et les conflits sont détectés par l'unité. Les opérations atomiques sont effectuées à l'aide d'ALU d'entiers uniquement, et les opérations atomiques à virgule flottante seraient plus compliquées à effectuer. L'élément de traitement de l'architecture 5870 est un cluster de cinq ALU identiques qui fonctionnent sur un très long paquet de mots d'instruction de cinq opérations emballées par le compilateur, avec un ensemble de dépendances propres, et la plupart des opérations de base peuvent être exécutées.

  • 00: 45: 00 Dans cette section, l'orateur décrit diverses fonctionnalités de l'architecture GPU qui aident à augmenter la quantité de compactage que le compilateur peut effectuer, y compris l'émission d'opérations dépendantes dans un seul paquet et la prise en charge des compteurs dépendants avec un partage bêta global. Le partage bêta global est une fonctionnalité moins connue qui est connectée à l'ensemble des moteurs de calcul sur l'appareil et a une latence bien inférieure à l'accès à d'autres mémoires. L'orateur avertit également que l'accès à des pixels aléatoires dans le cache de texture peut entraîner des problèmes de performances, car il sera plus rapide que de faire des accès à la mémoire globale uniquement si les données sont regroupées.

  • 00:50:00 Dans cette section, l'orateur répond aux questions liées à l'obtention d'une occupation complète dans l'architecture GPU. L'exemple donné est que les groupes de travail doivent être constitués de multiples de 64 éléments de travail pour obtenir une occupation complète. Les fronts d'onde et le nombre de fronts d'onde pouvant tenir sur chaque cœur ont également un impact sur l'occupation complète. L'orateur mentionne également qu'il n'y a pas de versions de précision complète des fonctions transcendantales générées par la 5e voie qui sont des approximations rapides qui peuvent ou non être assez bonnes, selon les besoins du code. Lorsqu'on lui a demandé s'il existe un moyen d'interroger la taille du front d'onde dans tous les appareils, la réponse est qu'il n'en existe pas.

  • 00: 55: 00 Dans cette section, l'orateur explique ce que signifie entièrement fusionné en termes d'accès à la mémoire globale dans une architecture GPU. Essentiellement, cela signifie qu'un front quart d'onde émettra une demande de mémoire dans laquelle chaque voie accédera à 128 bits consécutivement à partir d'adresses alignées traversant l'unité de calcul. Cependant, il existe des niveaux d'efficacité selon le type d'accès, qu'il soit attaché ou détaché, et s'il s'agit d'une collecte aléatoire. L'orateur précise également qu'un front d'onde est une unité de travail composée de 64 éléments de travail exécutés avec une seule instruction, et ce n'est pas la même chose qu'un groupe de travail, qui est un ensemble d'éléments de travail.

  • 01:00:00 Dans cette section, l'orateur explique le concept de barrières dans l'architecture GPU. Si un groupe de travail a plusieurs fronts d'onde, l'émission d'une instruction de barrière synchronisera ces fronts d'onde. Cependant, s'il n'y a qu'un seul front d'onde de travail dans un groupe, les barrières seront réduites à des non-opérations et n'auront aucun sens.
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL. 4 Programmation OpenCL en détail



4 - Programmation OpenCL en détail

Dans cette vidéo, le conférencier donne un aperçu de la programmation OpenCL, discutant de son langage, de sa plate-forme et de ses API d'exécution. Ils élaborent sur le modèle de programmation qui nécessite une parallélisation fine, des éléments de travail et des groupes ou des threads, une synchronisation et une gestion de la mémoire. L'orateur discute ensuite de l'algorithme à n corps et de sa nature d'ordre de calcul n au carré. Ils expliquent comment le code du noyau OpenCL met à jour la position et la vitesse des particules dans la mécanique newtonienne, introduit un cache pour stocker une position de particule et comment le noyau met à jour la position et la vitesse des particules à l'aide de types de données à vecteur flottant. L'orateur se penche également sur la façon dont le code hôte interagit avec les noyaux OpenCL en définissant explicitement les paramètres et les arguments, en transférant les données entre l'hôte et le GPU et en mettant en file d'attente l'exécution du noyau pour la synchronisation. Enfin, la vidéo explore comment modifier le code OpenCL pour prendre en charge plusieurs appareils, synchroniser les données entre les GPU et définir les ID d'appareil pour les tableaux de demi-taille qui les représentent.

La deuxième partie aborde divers aspects de la programmation OpenCL. Il couvre des sujets tels que le schéma à double tampon pour synchroniser la position mise à jour des particules entre deux tableaux, les limitations d'OpenCL et la différence entre les pointeurs globaux et locaux dans l'allocation de mémoire. De plus, il met en évidence les techniques d'optimisation pour la programmation OpenCL, y compris les opérations vectorielles, l'accès contrôlé à la mémoire et le déroulement de boucle, ainsi que les outils disponibles pour analyser l'implémentation OpenCL, tels que les outils de profilage. Le présentateur recommande la norme OpenCL comme ressource pour les programmeurs OpenCL et fournit des URL pour la norme et le SDK ATI Stream. La vidéo aborde également des questions sur des sujets tels que le partage de mémoire, l'optimisation du code, l'allocation de mémoire et l'utilisation des unités de calcul.

  • 00:00:00 Dans cette section, le conférencier présente les concepts OpenCL, discutant de l'émergence des architectures hybrides CPU-GPU et des défis qu'elles posent pour la programmation. OpenCL fournit une API indépendante de la plate-forme et de l'appareil avec une prise en charge à l'échelle de l'industrie, et le conférencier décrit les trois parties de l'API OpenCL : la spécification du langage, l'API de la plate-forme et l'API d'exécution. Le modèle d'exécution est divisé en deux parties : le noyau, qui représente le code exécutable qui s'exécutera sur le périphérique OpenCL, et le programme hôte, qui effectue la gestion de la mémoire et gère l'exécution du noyau sur un ou plusieurs périphériques à l'aide de la file d'attente de commandes. L'extension du langage C utilisée pour la programmation du noyau est basée sur ISO C99 avec quelques restrictions et ajouts pour prendre en charge le parallélisme.

  • 00: 05: 00 Dans cette section, l'orateur explique le modèle de programmation d'OpenCL, qui nécessite une parallélisation fine entre les threads et la synchronisation. Les éléments de travail et les groupes de travail sont introduits sous forme de threads et sont regroupés en groupes de travail qui ont des propriétés particulières en termes de synchronisation et d'accès à la mémoire partagée. L'orateur couvre également le modèle d'exécution côté hôte, expliquant que tout est rassemblé dans un contexte qui comprend une collection de périphériques, d'objets programme, de noyaux, d'objets mémoire et la file d'attente de commandes pour la mise en file d'attente des noyaux et des opérations de transfert de mémoire ou de données. . OpenCL prend également en charge une hiérarchie de différents types de mémoire pour refléter la nature de la mémoire dans un système hybride à mémoire distribuée.

  • 00:10:00 Dans cette section, le conférencier discute de l'importance de la gestion de la mémoire et de la synchronisation lors de l'utilisation de la programmation OpenCL. OpenCL a un modèle de cohérence de mémoire assoupli, ce qui confie au programmeur la responsabilité de gérer les transferts de données et de contrôler le moment où les données sont déplacées d'un appareil à un autre. La synchronisation devient essentielle lors de l'utilisation de plusieurs périphériques, et il incombe au programmeur de s'assurer que les événements, y compris l'exécution du noyau et les transferts de données, sont correctement synchronisés. L'orateur présente l'utilisation de Standard CL, qui est une interface simplifiée pour OpenCL et fournit un contexte par défaut prêt à l'emploi, inclut tous les périphériques et est ininterrompu à partir de la fonctionnalité OpenCL complète. De plus, Standard CL simplifie la gestion de la mémoire via CL Maylock, qui alloue de la mémoire partageable entre les appareils OpenCL.

  • 00: 15: 00 Dans cette section, l'orateur discute de l'algorithme de base à n corps, qui modélise le mouvement de n particules soumises à une certaine forme d'interaction particule-particule. L'algorithme consiste à calculer la force sur chaque particule en additionnant les contributions de l'interaction avec toutes les autres particules du système. Une fois que la force sur chaque particule est connue, la position et la vitesse des particules sont mises à jour sur un petit pas de temps. Ce processus est répété pour chaque particule, résultant en une simulation de ces particules se déplaçant sous l'effet des forces d'interaction. L'algorithme est d'ordre de calcul n-carré, ce qui permet une bonne accélération en utilisant des coprocesseurs avec des limitations de bande passante de transfert de mémoire. L'algorithme entier peut être écrit en quelques dizaines de lignes de code en C.

  • 00:20:00 Dans cette section, l'orateur explique la mise en œuvre de l'algorithme à n corps à travers une boucle qui accumule l'interaction entre les particules. Le code du noyau est conçu pour fournir une implémentation raisonnablement standard en utilisant les bonnes pratiques du point de vue OpenCL, mais il peut ne pas être optimal pour une architecture particulière. Le noyau sera exécuté pour chaque élément de travail dans un espace d'index, où chaque thread est responsable de la mise à jour de la position et de la vitesse d'une seule particule. L'application a une base d'indexation unidimensionnelle simple avec le nombre d'éléments de travail égal au nombre de particules dans le système. Le code hôte est également essentiel pour l'initialisation, la gestion de la mémoire et la coordination des opérations sur les périphériques OpenCL.

  • 00:25:00 Dans cette section, l'orateur présente le code du noyau pour mettre à jour la position et la vitesse des particules en mécanique newtonienne. Le prototype du code du noyau est similaire à celui d'une fonction C, mais avec quelques qualificateurs qui qualifient l'espace d'adressage et l'utilisation d'un schéma de blocage. Le code du noyau est stocké dans un fichier séparé et utilisé dans la compilation juste-à-temps lorsque le programme s'exécute. L'orateur explique ensuite comment le code du noyau effectue la détermination de la taille et de l'indice avant d'entrer dans le calcul réel de la physique. Les identifiants de threads globaux et locaux sont également expliqués en détail, et l'orateur note qu'une boucle externe est implicite dans le code du noyau car le noyau sera automatiquement exécuté pour chaque particule du système.

  • 00:30:00 Dans cette section, l'orateur explique l'implémentation du noyau OpenCL pour le calcul de force par paire à l'aide d'un cache. Le noyau met en cache une position de particule et s'appuie sur les autres éléments de travail du groupe de travail pour remplir également le cache. Une fois que les 64 positions de particules sont mises en cache, le noyau effectue une boucle sur les positions de particules mises en cache et implémente le même calcul de force que celui indiqué dans le code C, avec des différences notables spécifiques à OpenCL. Celles-ci incluent l'utilisation d'un vecteur flottant pour la position des particules, une fonction intégrée OpenCL pour la racine carrée et le stockage de la masse dans le quatrième composant inutilisé du vecteur flottant pour plus de commodité. Le noyau met à jour la position et la vitesse des particules sur une seule horloge en utilisant le type de données de vecteur flottant. Enfin, l'orateur explique le besoin de barrières pour la synchronisation lors des opérations de remplissage du cache et de bouclage.

  • 00:35:00 Dans cette section, nous apprenons comment la nouvelle position et la nouvelle vitesse sont réécrites dans la mémoire globale dans un nouveau tableau pour éviter d'écraser les données qui sont encore requises par d'autres threads. Ce schéma de double mise en mémoire tampon est utilisé dans les étapes ultérieures pour mettre à jour en toute sécurité la position des particules sans rencontrer de problèmes de simultanéité des threads. Passant à l'implémentation du code hôte du noyau, nous apprenons comment le programme définit les paramètres, alloue de la mémoire, initialise les positions et les vitesses, construit et compile le noyau OpenCL, interroge par son nom le noyau à n corps actuel nécessaire, en crée un -domaine de calcul du noyau dimensionnel et définit explicitement les arguments du noyau. Dans l'ensemble, le code montre comment OpenCL diffère des programmes C de base en ce que l'hôte exécute le noyau par proxy et comment les arguments du noyau doivent être définis directement.

  • 00: 40: 00 Dans cette section, l'orateur explique le processus de transfert de données de l'hôte vers le GPU à l'aide d'un appel clm sink et de synchronisation des baies sur l'appareil (GPU) à l'aide des indicateurs de blocage des appels. Ils discutent ensuite de la boucle sur les étapes, en introduisant la valeur et la rafale qui seront utilisées à des fins de diagnostic, et en retardant la définition des arguments du noyau deux et trois pour la double mise en mémoire tampon. L'orateur note que l'exécution du noyau est mise en file d'attente et que l'appel de synchronisation d'attente CL est utilisé pour s'assurer que toutes les exécutions du noyau sont terminées avant de continuer. Enfin, ils ramènent les données du GPU à l'hôte à l'aide du tampon de lecture de mise en file d'attente CL.

  • 00:45:00 Dans cette section, la vidéo traite de la modification du code pour prendre en charge plusieurs appareils, en exécutant spécifiquement le code sur deux GPU. L'approche consiste à répartir le travail de calcul de la force et de mise à jour de la position des particules entre les deux GPU, un GPU étant responsable de la moitié des particules. Le code du noyau voit peu d'échanges, avec juste un argument supplémentaire ajouté au prototype appelé "position remote", qui pointe vers les positions des particules pour les particules qu'un GPU donné n'est pas responsable de la mise à jour, mais dont il a encore besoin pour calculer la force totale . Il y a des changements notables du côté hôte impliquant des problèmes de gestion de la mémoire et de synchronisation qui surviennent en raison de l'utilisation de deux appareils.

  • 00:50:00 Dans cette section, la conférence explique les modifications qui doivent être apportées au code du noyau afin d'effectuer la simulation de particules sur deux GPU. La boucle sur les positions des particules du cache reste la même qu'avant, mais avant la ligne 21, la boucle est maintenant sur les positions des particules locales que le GPU possède. Le code est ensuite répété pour les particules distantes que l'autre GPU est chargé de mettre à jour. Le code de mise à jour de la position et de la vitesse des particules reste le même. Pour modifier le code hôte de deux GPU, l'initialisation reste la même, mais des tableaux de positions et de vitesses de particules contenant la moitié des particules sont également alloués, A et B représentant les deux GPU. Un domaine de calcul avec un espace d'index de seulement la moitié de la taille d'origine est créé et le code pour définir statiquement le pointeur d'argument sur le tableau de vitesse est supprimé.

  • 00: 55: 00 Dans cette section, nous apprenons à définir l'ID de l'appareil afin de définir sur quel GPU les données seront écrites lors de la copie de plusieurs tableaux de taille réduite vers les GPU respectifs. Nous voyons également que pour échanger des données entre plusieurs GPU, nous devons synchroniser les positions de particules mises à jour vers les GPU en commutant les tableaux de particules de demi-taille qui les représentent. Nous apprenons également que pour certaines implémentations d'OpenCL, un appel de vidage CL peut devoir être introduit pour une véritable concurrence, mais cela ne fait pas partie de la norme.

  • 01:00:00 Dans cette section, le présentateur passe en revue le code, qui implémente le schéma à double tampon pour échanger l'ancienne et la nouvelle position des particules entre deux tableaux. Ce schéma garantit que les positions des particules mises à jour sont remises dans le tableau A ou B. Une fois les particules synchronisées avec l'hôte, elles doivent être recopiées dans le tableau plus grand pour réutiliser certaines des fonctions d'assistance. Le présentateur recommande la norme OpenCL comme ressource nécessaire pour les programmeurs OpenCL et fournit des URL pour la norme et le SDK ATI Stream. Le présentateur répond également aux questions de savoir si OpenCL peut être utilisé pour des algorithmes tels que la décomposition en valeurs singulières ou la factorisation matricielle non négative, et confirme que les données en mémoire globale sur le GPU restent les mêmes entre les exécutions du noyau, ce qui est crucial pour les algorithmes plus complexes.

  • 01:05:00 Dans cette section, la vidéo traite des limitations actuelles de l'API OpenCL, qui ne prend en charge que les systèmes Unix/Linux et est en cours d'élaboration pour un port Windows. La vidéo aborde également la question du partage de la mémoire entre un GPU et l'hôte, expliquant que bien que cela soit possible, il existe des pénalités de performances, ce qui rend typique l'utilisation de la mémoire globale allouée sur la carte graphique. Lors de l'allocation de mémoire via l'API OpenCL, il existe des moyens de contrôler la façon dont elle est gérée, mais une partie de cela est effectuée automatiquement au niveau de l'implémentation. De plus, la vidéo explique la différence entre les pointeurs globaux et locaux dans l'allocation de mémoire et comment le choix du nombre optimal de cœurs dépend de l'algorithme en cours d'exécution.

  • 01:10:00 Dans cette section, l'orateur aborde diverses questions liées à la programmation OpenCL, telles que le chargement et l'exécution du module FTL FGL RX, la compatibilité de Lib standard CL avec les liaisons C++, l'optimisation des noyaux OpenCL pour l'amélioration des performances et l'utilisation de CL mem en lecture seule ou leur scellement en lecture/écriture lors de l'allocation des mémoires tampons. L'orateur souligne également que des outils spécifiques pour l'édition des noyaux OpenCL et l'optimisation pour les GPU AMD peuvent exister tout en notant que les techniques d'optimisation peuvent être très subtiles et nécessiter beaucoup de réglages.

  • 01:15:00 Dans cette section, le conférencier discute des techniques d'optimisation pour la programmation OpenCL, notamment l'organisation des données pour tirer parti des opérations vectorielles, le contrôle minutieux de l'accès à la mémoire pour de meilleures performances et le déroulement manuel des boucles pour l'optimisation. De plus, l'utilisation de types de données complexes et la possibilité de transférer des données entre les GPU sans revenir à l'hôte sont spécifiques à l'implémentation et peuvent varier en fonction du compilateur. L'orateur mentionne également qu'il existe des limitations de taille pour les tampons de mémoire qui dépendront de la mémoire disponible sur les périphériques OpenCL du système. Il peut être possible de stocker des paramètres flottants plus simples dans une mémoire constante pour de meilleures performances.

  • 01:20:00 Dans cette section, l'orateur explique qu'il existe des outils disponibles dans divers SDK pour analyser la mise en œuvre d'OpenCL, y compris des outils de profilage pour mesurer l'utilisation des unités de calcul ou l'utilisation du transfert de mémoire. L'orateur précise également que la gestion de la fragmentation de la mémoire côté GPU est spécifique à l'implémentation et que l'implémentation doit la gérer correctement. Lors de l'utilisation de la double précision, il n'y a pas de réponse évidente quant à l'opportunité de réduire la taille du groupe de travail local à 32 ou 16, car cela dépend de l'architecture utilisée. L'orateur mentionne également la disponibilité d'appels d'assistance pour obtenir facilement des informations sur tous les appareils dans le contexte GPU standard.
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL. 5. Applications OpenCL du monde réel



5 - Applications OpenCL du monde réel

Dans cette vidéo, Joachim Deguara parle d'une application de traitement vidéo multi-flux sur laquelle il a travaillé, avec un accent particulier sur l'optimisation des performances. La vidéo couvre divers sujets tels que le décodage des formats vidéo, l'utilisation de DMA pour transférer de la mémoire entre le CPU et le GPU, la double mise en mémoire tampon, l'exécution des noyaux, l'utilisation d'objets d'événement pour synchroniser et profiler les opérations, l'interopérabilité OpenCL-OpenGL, le traitement des balayages dans les vidéos et le choix entre OpenCL et OpenGL lors du traitement des algorithmes. Joachim discute également de divers échantillonnages et SDK disponibles pour les applications OpenCL, mais note qu'il n'y a actuellement aucun exemple de code disponible pour l'application spécifique discutée dans la vidéo.

  • 00:00:00 Dans cette section, Joachim Deguara explique une application de traitement vidéo multi-flux sur laquelle il a travaillé. L'application consiste à ouvrir plusieurs flux vidéo, à les décoder, à leur appliquer des effets vidéo, à les combiner et enfin à présenter un flux vidéo qui est traité à plusieurs reprises à la fin. Joachim Deguara mentionne que la performance est un objectif clé pour cette application, et pour obtenir une présentation en temps réel, il est essentiel d'adapter le décodage, le traitement et l'affichage dans une structure en boucle qui se produit 30 fois par seconde ou la fréquence d'images de la vidéo d'entrée. .

  • 00:05:00 Dans cette section, l'accent est mis sur le décodage des formats vidéo et le déplacement de l'image vers le GPU. Pour décoder le format vidéo, il est nécessaire de s'assurer que cela se fait le plus rapidement possible afin que cela n'affecte pas les performances. Une façon de procéder consiste à faire en sorte que la fonction de décodage s'exécute séparément de la boucle principale et, lorsqu'elle est appelée, qu'elle renvoie la dernière image. Cela garantit que le décodage est effectué en arrière-plan tandis que la boucle principale se poursuit sans interruption. Pour déplacer le cadre vers le GPU, des appels d'API sont utilisés, qui incluent la spécification de l'image sur laquelle écrire et si l'écriture doit se produire de manière synchrone ou asynchrone.

  • 00: 10: 00 Dans cette section, l'orateur discute du DMA (accès direct à la mémoire) et de la manière dont il peut être utilisé pour transférer de la mémoire entre la mémoire principale du système et la mémoire du GPU sans que le CPU n'ait à le copier. Le moteur DMA gère cette opération en parallèle, libérant des ressources pour le CPU et le GPU. Le transfert de tampons et d'images peut être effectué de manière asynchrone et nécessite des drapeaux spéciaux. Cependant, les données ne peuvent pas être utilisées immédiatement après une copie, le programme doit donc être restructuré en conséquence pour tirer parti du DMA. L'orateur suggère une double mise en mémoire tampon et des processus de boucle de restructuration pour éviter de corrompre les données actuellement traitées ou affichées. Dans l'ensemble, le DMA peut grandement améliorer les performances des applications en déchargeant les cycles CPU et GPU.

  • 00: 15: 00 Dans cette section, l'orateur discute de l'approche de la double mise en mémoire tampon utilisée dans OpenCL pour traiter et afficher les images d'une vidéo. Cette approche implique de mettre constamment en mémoire tampon deux trames, A et B, et de traiter l'une pendant que l'autre est en cours de téléchargement. Cela élimine la nécessité d'additionner le temps de traitement et le temps de téléchargement, et ne prend à la place que le temps maximum nécessaire pour l'un ou l'autre processus. L'orateur discute également de la configuration des arguments pour le noyau, qui ne doit être effectuée qu'une seule fois et peut être utilisée pour toutes les exécutions de traitement ultérieures si les paramètres n'ont pas besoin d'être modifiés.

  • 00:20:00 Dans cette section, l'orateur explique comment exécuter le noyau et mentionne deux façons d'appeler le traitement, y compris les méthodes bloquantes et non bloquantes. Bien que le blocage facilite le débogage, il n'est pas optimal pour les performances, c'est pourquoi l'orateur introduit la possibilité d'utiliser des événements et des vecteurs d'événements pour attendre des opérations ou pour configurer des graphiques de dépendance pour plusieurs opérations. En utilisant les objets d'événement pour signaler l'achèvement de certains éléments de travail, il peut garantir que les opérations en aval ne démarrent qu'une fois celles-ci terminées, ce qui permet un traitement plus efficace.

  • 00:25:00 Dans cette section, l'orateur explique comment utiliser les objets d'événement OpenCL pour synchroniser les opérations et comment utiliser le profilage d'événement pour les tests de performances. Lors de la création du graphique de dépendance pour les filtres, un pointeur vers un événement est passé comme dernier argument pour l'opération de mise en file d'attente, mais l'objet événement est créé à l'intérieur de InQ. Cela peut prêter à confusion, mais cela permet de configurer des dépendances entre les filtres et les opérations de téléchargement. L'orateur décrit comment, avec le profilage d'événement, il est possible d'obtenir des horodatages de l'événement indiquant quand certains événements se sont produits dans le cycle de vie de l'événement, comme le moment où l'opération des références d'événement a été mise en file d'attente, a été soumise, a commencé à s'exécuter, et terminé en cours d'exécution. Cela permet le profilage tout en gardant toutes les opérations asynchrones.

  • 00:30:00 Dans cette section de la vidéo, l'orateur explique les différents états qu'un événement traverse lors de l'utilisation d'OpenCL, tels que mis en file d'attente, soumis, en cours d'exécution et terminé, et comment utiliser les données de profil d'événement et les horodatages pour mesurer les performances et identifiez les problèmes potentiels tels que les longs délais d'exécution des opérations ou les téléchargements de données. L'orateur explique également comment attendre que les événements se terminent afin d'assurer l'affichage précis des flux vidéo avec divers filtres et effets.

  • 00:35:00 Dans cette section, le conférencier discute de l'interopérabilité OpenCL et OpenGL, qui permet le partage de certaines informations entre les deux. Cette fonctionnalité est facultative et toutes les implémentations ne doivent donc pas la prendre en charge. L'orateur souligne l'importance de vérifier l'extension et de créer un contexte dans OpenCL avec certains indicateurs pour activer l'interopérabilité OpenCL-OpenGL. Cela fonctionne en créant une image OpenCL à partir d'une texture OpenGL qui a déjà été créée, afin que les données ne soient pas inutilement copiées dans les deux sens.

  • 00:40:00 Dans cette section, l'orateur explique comment OpenCL et OpenGL peuvent partager des données d'image ensemble via Interop. Ils couvrent la cible, le niveau NIP et l'objet de texture nécessaires pour référencer la texture Open GL. Une fois créée, l'image OpenCl peut être utilisée comme une image OpenCl normale, mais les deux programmes doivent établir une liaison afin de s'assurer qu'ils n'interfèrent pas l'un avec l'autre. Le conférencier répond également à une question sur la façon de créer des transitions dans le rendu vidéo. Il dit que cela peut être fait en utilisant la position d'un balayage comme entrée dans le filtre. En fin de compte, le résultat final est remis à OpenGL à des fins d'affichage, ce qui complète toutes les étapes.

  • 00:45:00 Dans cette section, l'orateur explique comment il traite les balayages dans une vidéo en regardant le marqueur temporel de chaque image et en utilisant une image clé pour interpoler la position du balayage. Ils répondent également à une question sur le profilage dans OpenCL, indiquant que les horodatages dépendent d'une minuterie externe haute résolution mais pas d'un appel à CL finish. De plus, l'orateur discute de l'ordre d'exécution dans les appareils et les runtimes OpenCL et confirme que les opérations sont gérées dans l'ordre pour la plupart des appareils.

  • 00:50:00 Dans cette section, le conférencier explore les différences entre OpenCL et OpenGL lors du traitement des algorithmes. La décision de la plate-forme à utiliser dépend des préférences individuelles, bien qu'OpenCL puisse être plus facile à programmer en raison de sa structure de langage complète. En termes de performances, OpenCL peut permettre de traiter des applications nécessitant un matériel plus complexe ; cependant, il existe des cas où l'utilisation de l'ombrage OpenGL peut conduire à de meilleures performances. De plus, bien que l'orateur n'ait pas pu fournir d'exemple de code disponible pour l'application spécifique, il existe divers exemples de code dans le SDK OpenCL d'AMD dont les utilisateurs peuvent s'inspirer.

  • 00: 55: 00 Dans cette section, l'orateur discute de divers exemples et SDK disponibles pour les développeurs d'applications OpenCL. Les exemples montrent comment interroger les appareils et le temps d'exécution pour obtenir des extensions, ainsi que des exemples d'interopérabilité OpenCL OpenGL. Cependant, aucun exemple de code n'est actuellement disponible pour l'application spécifique décrite dans la vidéo, mais cela peut changer à l'avenir. Le webinaire est maintenant terminé et un enregistrement sera mis à la disposition des participants.
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL. 6. Extensions de fission de périphérique pour OpenCL



6 - Extensions de fission de périphérique pour OpenCL

Dans cette vidéo, le conférencier couvre divers sujets liés aux extensions de fission d'appareils pour OpenCL. Ils expliquent les différents types d'extensions et comment la fission des appareils permet de diviser les grands appareils en plus petits, ce qui est utile pour réserver un cœur pour des tâches hautement prioritaires ou pour s'assurer que des groupes de travail spécifiques sont affectés à des cœurs spécifiques. Ils discutent de l'importance de conserver la sémantique séquentielle lors de la parallélisation des opérations de refoulement de vecteurs, de l'utilisation de modèles parallèles pour optimiser le processus et de la création de noyaux natifs dans OpenCL. L'orateur présente également une application qui utilise la fission de l'appareil pour OpenCL et discute de l'affinité de la mémoire et de l'avenir de la fission de l'appareil sur d'autres appareils.

  • 00:00:00 Dans cette section, l'orateur discute des extensions dans OpenCL, en particulier des trois différents types d'extensions : les extensions KHR, les extensions EXT et les extensions de fournisseur. Les extensions KHR sont approuvées par le groupe de travail OpenCL et sont accompagnées d'un ensemble de tests de conformité. Les extensions EXT sont développées par au moins deux membres du groupe de travail et ne nécessitent pas de tests de conformité. Les extensions de fournisseur, telles que CL_AMD_printf, sont développées par un seul fournisseur et ne peuvent être prises en charge que par ce fournisseur. La documentation de toutes les extensions est disponible sur le site Web du registre Chronos OpenCL, permettant la transparence et l'accessibilité entre les fournisseurs.

  • 00: 05: 00 Dans cette section, l'orateur mentionne l'extension de fission de périphérique pour OpenCL appelée vision de périphérique. Cette extension permet à l'utilisateur de diviser de grands appareils avec de nombreuses unités de calcul en petits appareils OpenCL, soit par nom, soit par affinité mémoire. Cette division peut aider à réserver un noyau pour une tâche prioritaire ou à s'assurer que des groupes de travail spécifiques sont affectés à des noyaux spécifiques, comme dans un système basé sur SMP. L'orateur motive l'utilisation de la vision de périphérique avec un exemple d'algorithmes parallèles et de conteneurs parallèles construits sur OpenCL, et déclare que cette extension est actuellement prise en charge par AMD et IBM sur leurs processeurs et périphériques Cell Broadband.

  • 00: 10: 00 Dans cette section, l'orateur discute de l'importance de conserver la sémantique séquentielle tout en parallélisant les opérations de refoulement vectoriel. Ils expliquent que lors de l'insertion d'éléments dans un vecteur lors d'une boucle séquentielle, l'ordre attendu apparaîtrait en fonction de la boucle. Cependant, lorsqu'il est parallélisé, cet ordre est perdu et des éléments peuvent être insérés dans le désordre, l'orateur propose donc de conserver la sémantique séquentielle de l'opération de refoulement vectoriel. Ils donnent ensuite un exemple de la façon dont cela pourrait être essentiel dans une application telle qu'une version simplifiée d'un flux MPEG-2. Ils concluent en introduisant une fonction C et en expliquant comment implémenter ces opérations parallèles sur les CPU.

  • 00: 15: 00 Dans cette section, l'orateur explique comment utiliser des modèles parallèles pour optimiser le processus Device Fission Extensions for OpenCL. Ils utilisent le modèle de pipeline pour exécuter des fonctions en parallèle et introduisent un bloc de données à lire à partir des données d'entrée pour traiter un élément de travail dans une mémoire locale. L'approche écrit ensuite le décalage de la boîte aux lettres dans le groupe de travail correspondant pour calculer les décalages tout en préservant l'ordre de la sortie. L'ordre est réalisé par la communication entre les groupes de travail au lieu de s'appuyer sur l'ID global qui peut s'exécuter dans un ordre arbitraire. Le modèle de pipeline garantit que les fonctions s'exécutent en parallèle pour optimiser le processus.

  • 00:20:00 Dans cette section, l'orateur discute de leur pipeline et de la façon dont ils utilisent maintenant le terme "comptoir" comme boîte aux lettres, car ils sont allés au-delà du simple comptage des choses. Ils expliquent qu'ils transmettent des identifiants de groupe pour l'indexation dans les boîtes aux lettres et utilisent la mémoire locale et globale pour des calculs simples. Cependant, ils notent qu'il n'y a aucune garantie d'exécution du groupe de travail et expliquent comment cela pourrait provoquer une situation de blocage. Pour résoudre ce problème, l'orateur suggère de diviser l'appareil en deux cœurs distincts à l'aide de la vision de l'appareil, de lancer un groupe de travail sur chaque cœur et de garantir la progression. Ils introduisent également un mécanisme important fourni par OpenCL pour s'exécuter sur un périphérique hôte.

  • 00:25:00 Dans cette section, l'orateur discute des avantages de l'utilisation de noyaux natifs dans OpenCL, qui permet l'exécution de fonctions C ou C++ arbitraires. Il peut offrir plus de flexibilité pour essayer différentes implémentations, ainsi que la possibilité d'appeler des routines d'E/S standard ou d'autres fonctions de bibliothèque qui peuvent ne pas être disponibles dans OpenCL. Le processus de création d'un noyau natif dans OpenCL implique de transmettre une file d'attente de commandes et une fonction avec ses arguments et ses objets mémoire. Cependant, il faut être prudent avec le stockage local du thread car la fonction peut ne pas être exécutée dans le même thread que celui dans lequel elle a été incluse. L'orateur présente également l'API de liaisons OpenCL C++ qui offre quelques abstractions en plus de l'API C. Le programme commence par interroger les plates-formes disponibles et créer un contexte et un type d'appareil.

  • 00:30:00 Dans cette section, l'orateur discute de l'utilisation des extensions de fission de périphérique pour OpenCL. Une fois qu'un appareil valide est interrogé, une liste d'appareils est renvoyée et le premier appareil est choisi pour prendre en charge la fission de l'appareil. La fission de périphérique est nouvelle dans l'API OpenCL et nécessite des mécanismes d'extension, qui permettent de décrire une partition. Ils utilisent la partition de manière égale pour la partitionner en périphériques d'unités d'un seul. Les propriétés du sous-périphérique sont ensuite configurées et la fonction de création de sous-périphériques est appelée. En supposant qu'au moins un sous-périphérique est créé, des boîtes aux lettres sont créées et une file d'attente de commandes est créée pour chaque périphérique. Les périphériques résultants sont exactement comme n'importe quel autre périphérique et peuvent être utilisés de manière interchangeable avec les bibliothèques existantes. L'orateur passe ensuite à la configuration des noyaux OpenCL natifs.

  • 00: 35: 00 Dans cette section, l'orateur discute des entrées et des arguments nécessaires à la mise en œuvre des extensions Device Fission pour OpenCL. L'orateur explique que la mémoire tampon des entrées sera divisée en quatre parties, où les pointeurs seront placés par le runtime FN c. La mémoire tampon sera composée de boîtes aux lettres, de blocs et de transactions de cache, et des ID uniques seront générés pour chaque noyau. L'orateur explique en outre que chaque instance du noyau s'exécutera sur des appareils individuels, et une fois tous les événements terminés, les données seront écrites avec le rembourrage inséré. Le noyau lui-même inclura des optimisations liées au blocage et à la mise en cache pour assurer une exécution efficace.

  • 00: 40: 00 Dans cette section, l'orateur discute de la mise en œuvre d'une application qui utilise la fission de périphérique pour OpenCL. Ils expliquent comment l'application fonctionne en utilisant différents types, tels que les entrées/sorties, les boîtes aux lettres, les tableaux de blocs locaux, la taille des blocs et les ID de groupe, pour indexer les ensembles de données en parallèle. L'application implémente également des optimisations simples d'attente et de blocage pour s'assurer que tout s'exécute autant que possible en parallèle. En utilisant la fission de l'appareil, la mise en œuvre de cette application présente le potentiel d'accélération du processeur avec peu ou pas d'opérations ALU, ce qui pourrait encore augmenter avec la mise en œuvre de vecteurs plus larges à l'avenir. L'orateur aborde également les autres applications et cas d'utilisation de la fission des dispositifs, tels que la division par rapport à l'infini et les systèmes spatiaux Numa.

  • 00:45:00 Dans cette section, le conférencier discute des avantages de l'affinité mémoire dans OpenCL, qui permet l'association précise de tampons avec un périphérique particulier. Cela peut conduire à une meilleure localisation du cache et à de meilleures performances en évitant les conflits et le partage négatif. Le schéma de boîte aux lettres utilisé dans OpenCL peut être étendu pour prendre en charge plusieurs itérations, permettant une boucle qui démarre encore et encore le pipeline en cascade. L'orateur mentionne également la disponibilité de ressources sur la zone OpenCL sur developer.amd.com, où les parties intéressées peuvent trouver plus d'informations sur OpenCL, y compris des webinaires, des présentations passées et un prochain sommet sur l'informatique hétérogène. L'orateur évoque également la possibilité de prendre en charge la fission des appareils sur le GPU à l'avenir, ce qui réserverait une partie du cœur aux tâches hautement prioritaires et garantirait de meilleures performances.

  • 00: 50: 00 Dans cette section de la vidéo, l'orateur discute de l'avenir de la fission des appareils vers d'autres appareils. Actuellement, seuls AMD et IBM prennent en charge les extensions de fission de périphérique pour OpenCL, mais d'autres fournisseurs ont manifesté leur intérêt pour la proposition. La question est posée de savoir si les bibliothèques mathématiques comme BLAS et FFT seront prises en charge, et l'orateur confirme qu'ils travaillent sur des implémentations OpenCL de BLAS et de différentes variantes et implémentations pour l'algèbre linéaire qui seront présentées dans une bibliothèque de style FFT.
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL. 7. Hydrodynamique des particules lissées




7 - Hydrodynamique des particules lissées

Cette vidéo traite de l'hydrodynamique des particules lissées (SPH), une technique de résolution des équations de la dynamique des fluides, en particulier les équations de Navier-Stokes. La vidéo explique les différents termes dans les équations, y compris les termes de densité, de pression et de viscosité, et comment ils sont approximés à l'aide d'un noyau de lissage. L'algorithme numérique utilisé pour SPH, ainsi que l'utilisation de l'indexation spatiale et Interop, sont également discutés. L'orateur explique le processus de construction d'un index spatial et d'une carte de voisinage et comment la physique est calculée. La vidéo invite les téléspectateurs à télécharger et à utiliser le programme et discute des limites de la simulation. L'orateur répond ensuite aux questions du public sur les performances du GPU, le comportement incompressible et l'utilisation d'images en cache.

  • 00:00:00 Dans cette section, Alan Hierich, membre principal du personnel technique chez AMD, donne un aperçu de la dynamique des fluides computationnelle, en particulier de l'hydrodynamique des particules lisses (SPH). SPH était à l'origine utilisé pour les calculs d'astrophysique, mais il est devenu très populaire dans les jeux vidéo et les simulations. La technique est utilisée pour résoudre les équations de Navier-Stokes, qui sont des équations différentielles partielles formulées dans les années 1900 et qui sont à la base de la plupart des travaux de dynamique des fluides aujourd'hui. Allen explique la définition des fluides et fournit une explication intuitive de leur fonctionnement, en se concentrant sur les liquides et les gaz. Il souligne également que les fluides sont généralement décrits par les équations de Navier-Stokes et que les équations incompressibles de Navier-Stokes régissent les fluides comme l'eau à des vitesses normales et à des températures normales.

  • 00:05:00 Dans cette section, l'orateur explique les équations qui régissent les fluides, connues sous le nom d'équations de Navier-Stokes. L'équation du mouvement représente le changement de vitesse en fonction de la gravité, de la pression et de la viscosité, tandis que l'équation de continuité de la masse indique que la masse n'est ni créée ni détruite. Les phénomènes qui régissent un fluide sont la gravité, la pression et la vitesse, et la viscosité est le caractère collant du fluide, qui détermine la probabilité que des particules de fluide se déplacent dans la même direction. Le terme d'accélération convective est également discuté, qui décrit l'accélération d'un fluide lorsqu'il se déplace à travers une ouverture plus petite, telle qu'une buse sur un tuyau d'arrosage. L'orateur invite le public à télécharger et à jouer avec le programme qui simule des fluides dans une boîte qui a été démontré.

  • 00: 10: 00 Dans cette section, l'orateur explique les différents termes de l'équation du mouvement pour la dynamique des fluides, notamment l'accélération convective, le gradient de pression et la viscosité. La pression est définie comme la différence entre la densité réelle du fluide en un point et la densité au repos. Le terme de viscosité, qui est le dernier terme du côté droit de l'équation du mouvement, diffuse la quantité de mouvement du système, aboutissant finalement à un état où la vitesse est équivalente à tous les endroits. Il existe également une équation de continuité de masse, del dot V égal à 0, ce qui implique que la masse n'est ni créée ni détruite dans les équations incompressibles. Enfin, pour représenter la dynamique du système, le locuteur prend la dérivée matérielle de l'équation pour obtenir l'équation du mouvement d'une particule.

  • 00: 15: 00 Dans cette section, la vidéo traite de la technique de l'hydrodynamique des particules lissées (SPH) pour résoudre les équations simplifiées incompressibles de Navier-Stokes introduites dans la section précédente. La technique SPH a été introduite pour la première fois en 1992 pour étudier l'astrophysique et les galaxies, mais peut également être utilisée pour les équations fluides. Il s'agit d'introduire des représentations du noyau de lissage des quantités, qui sont comme des fonctions de base qui nous permettent d'approximer n'importe quelle quantité par une sommation de la quantité à des points proches multipliée par une fonction de pondération. La technique SPH est utilisée pour approximer les termes de densité et de gradient de pression dans les équations de Navier-Stokes. La vidéo mentionne également que les équations de Navier-Stokes sont numériquement sensibles à l'échelle et que les calculs sont effectués à une échelle plus petite avant d'être étendus à l'échelle spatiale régulière afin de déplacer les particules dans l'espace.

  • 00: 20: 00 Dans cette section, l'orateur explique les trois principaux termes qui sont approximés dans l'hydrodynamique des particules lissées (SPH), qui sont les termes de densité, de pression et de viscosité. Pour calculer la densité, le programme calcule la masse des particules en différents points et la multiplie par le gradient d'un noyau de lissage. Le terme de pression est alors calculé à l'aide d'une quantité scalaire de pression divisée par la densité, qui est multipliée par le gradient du noyau de lissage. D'autre part, le terme de viscosité est approximé à l'aide d'un coefficient scalaire qui détermine le niveau de viscosité du fluide et la différence de vitesse entre deux points divisé par la densité du point J. L'orateur explique également les propriétés du noyau de lissage, qui est utilisé dans la simulation SPH, et comment il se résume à un sur une sphère de rayon H.

  • 00:25:00 Dans cette section, le conférencier discute de l'algorithme numérique utilisé pour l'hydrodynamique des particules lissées (SPH). L'algorithme implique le calcul de la densité, de la pression, du gradient de pression, du terme visqueux et de l'accélération, qui sont ensuite utilisés pour chronométrer les vitesses et les positions des particules. L'orateur explique que l'algorithme initial consiste à tester les interactions de toutes les particules contre toutes les particules, ce qui est correct mais pas assez rapide. Par conséquent, un meilleur algorithme est introduit, qui divise l'espace en voxels, permettant des interactions avec uniquement des particules dans le rayon d'interaction. De plus, un sous-ensemble de particules est choisi au hasard pour calculer les interactions au lieu de considérer toutes les particules, ce qui produit un programme efficace.

  • 00:30:00 Dans cette section, le conférencier discute de l'utilisation de l'indexation spatiale pour calculer uniquement les interactions avec un nombre limité de particules dans les simulations OpenCL, ainsi que de l'importance d'utiliser Interop pour partager des tampons de données avec un système graphique. Alors qu'Interop permet le rendu directement à partir du tampon GPU et économise de l'espace dans la mémoire graphique, sans cela, le programme devrait copier les données vers la mémoire hôte et inversement, ce qui ralentirait considérablement la simulation. L'orateur explique les modifications nécessaires pour utiliser Interop, y compris la création d'un contexte différent, et présente l'ensemble des tampons nécessaires à la simulation, y compris l'indice de particules pour le tri. Malgré la discussion sur l'importance d'Interop, le programme présenté ne l'utilise pas, ce qui ralentit la simulation.

  • 00:35:00 Dans cette section, l'orateur discute des différents noyaux utilisés dans l'algorithme Smoothed Particle Hydrodynamics. Le premier noyau est "particules de hachage", qui associe des particules à un voxel. Ensuite, les noyaux "sort" et "sort post pass" trient les particules en voxels et les organisent pour la construction de l'index spatial. Ensuite, les noyaux "index" et "index post pass" construisent un index spatial des voxels aux particules. Après cela, le noyau "bons voisins" décide quels voisins vont interagir les uns avec les autres. Enfin, les noyaux « calculer la pression de densité », « calculer l'accélération » et « intégrer » calculent les interactions et la physique entre les particules. L'orateur explique que le tri par base est utilisé dans la version GPU du code, tandis que le tri Q est utilisé dans la version CPU du code.

  • 00: 40: 00 Dans cette section, la vidéo explique le processus de construction d'un index spatial des voxels aux particules dans Smoothed Particle Hydrodynamics (SPH). Le noyau utilise une recherche binaire pour identifier la particule numérotée la plus basse dans chaque voxel et laisse une valeur négative dans les voxels qui ne contiennent pas de particules. Le post-passe d'index remplit ensuite une valeur d'index pour les voxels vides en copiant la valeur du voxel non vide suivant dans l'index de cellule de grille. Une fois l'indexation effectuée, le programme construit une carte de voisinage en recherchant dans la région locale des voxels deux par deux par deux qui entourent chaque particule. Pour éliminer les biais, le programme génère un décalage aléatoire dans chaque voxel et alterne la direction de la recherche. Le noyau sélectionne ensuite les 32 premières particules dans le rayon d'interaction et les ajoute à la carte voisine.

  • 00:45:00 Dans cette section, l'orateur explique comment il a calculé la physique en construisant une carte voisine, qui lui permet d'interagir avec 32 particules. Ils passent en revue les équations utilisées pour approximer la densité et la pression, calculer les termes d'accélération, puis combiner le tout pour déterminer l'accélération totale. La vitesse et la position sont ensuite avancées par intégration numérique, avec des conditions aux limites en place pour empêcher les particules de s'échapper de la boîte. L'orateur encourage les téléspectateurs à télécharger et à jouer avec le code source, et souligne que bien qu'il existe de nombreuses méthodes lentes pour résoudre les équations de Navier-Stokes, lente ne signifie pas nécessairement bonne.

  • 00:50:00 Dans cette section de la vidéo, l'orateur explique l'étape de mise à jour de la simulation, où la vitesse est intégrée à sa nouvelle position avant de mettre à jour la position. La mise à jour de la vitesse est explicite, tandis que la mise à jour de la position est semi-implicite, en utilisant la valeur de la vitesse au pas de temps suivant. La simulation est flottante à des fins de performances, mais si une fidélité et une précision élevées sont nécessaires, l'utilisation de double serait recommandée. L'algorithme est entièrement parallélisable, mais les compromis du partitionnement spatial doivent être pris en compte. Enfin, l'orateur répond aux questions sur l'utilisation d'Interop avec plusieurs GPU, la simulation de la turbulence et le nombre maximal pratique de particules dans la simulation.

  • 00:55:00 Dans cette section, l'orateur répond à quelques questions du public. Ils expliquent que la limite pratique de leur simulation est le taux de performance, qui dépend de la classe de GPU et de CPU utilisée. Ils mentionnent également que bien que leur simulation soit basée sur des équations incompressibles, ils ne résolvent pas explicitement la condition d'incompressibilité, ce qui pourrait limiter son comportement compressible. L'orateur répond également à une question sur la raison pour laquelle ils ont utilisé des tampons au lieu de la mémoire d'image en cache, déclarant qu'au moment où ils ont développé le programme, ils ne voyaient aucun avantage en termes de performances à utiliser des images en cache. Cependant, ils mentionnent qu'OpenCL prendra en charge les tampons mis en cache à l'avenir et qu'ils pourraient modifier le programme pour les prendre en charge. Dans l'ensemble, l'orateur invite le public à télécharger et à utiliser le programme comme il le souhaite, car il n'y a aucune limite.
 

AMD Developer Central : Série de webinaires sur la programmation OpenCL. 8. Techniques d'optimisation : Convolution d'image



Dans cette vidéo, Udeepta D. Bordoloi discute des techniques d'optimisation en convolution d'image.

 

Développeur AMD Inside Track : Comment optimiser la convolution d'image



Comment optimiser la convolution d'image

Cette vidéo présente diverses méthodes d'optimisation de la convolution d'image, notamment l'utilisation du partage de données locales, l'optimisation des constantes et l'utilisation de zones locales plus importantes pour améliorer l'efficacité. Le conférencier souligne l'importance de minimiser le temps de traitement en convolution d'image pour améliorer les performances globales et met en évidence une nouvelle méthode de réutilisation des données en utilisant la mémoire locale. La vidéo propose des suggestions d'étapes d'optimisation telles que l'utilisation d'évidences ou de textures, l'utilisation de la force de pensée et l'utilisation des options de passage au compteur. Un article étape par étape sur l'optimisation des techniques de convolution d'image est disponible sur le site Web du développeur AMD.

  • 00:00:00 Dans cette section, Udeepta Bordolo de l'équipe graphique d'AMD explique le concept de convolution d'image, qui consiste à effectuer une somme pondérée sur une zone de l'image d'entrée pour générer un pixel d'image de sortie. Il utilise OpenCL et un GPU 5870 pour effectuer l'optimisation, en travaillant progressivement à partir du code de corrélation de base. La mise en miroir et l'utilisation de LDS (Local Data Share) font partie des méthodes d'optimisation utilisées, entraînant une réduction significative du temps d'exécution.

  • 00: 05: 00 Dans cette section, l'orateur discute de l'optimisation de la convolution d'image dans un programme qui fonctionne pour toutes les tailles de filtre et toutes les tailles d'entrée. Il se concentre sur l'utilisation des zones locales pour améliorer le partage des données et réduire le temps d'attente. En interprétant les constantes et les entrées comme des valeurs 128 bits, le compilateur et le génie peuvent plus facilement interpréter le code et réduire le temps de traitement. Il montre comment l'optimisation des constantes et l'utilisation de zones locales plus grandes peuvent grandement améliorer l'efficacité de la convolution d'image. Dans l'ensemble, le conférencier souligne l'importance de trouver des moyens de minimiser le temps de traitement en convolution d'image pour améliorer les performances globales.

  • 00: 10: 00 Dans cette section, l'orateur explique comment optimiser la convolution de l'image en déterminant la taille du filtre et comment la modifier pour différents masques. L'orateur note que l'application de l'optimisation à différents moments peut affecter les performances, mais cela peut aider à détecter tout problème inattendu. L'orateur discute également de l'exécution du même nombre d'éléments pour une image d'entrée de 2k par 2k avec des données de force complète, ce qui a abouti à un format de données plus efficace. De plus, l'orateur met en évidence une nouvelle méthode de réutilisation des données au lieu d'utiliser le moteur en utilisant la mémoire locale, connue sous le nom de LDS dans le matériel.

  • 00:15:00 Dans cette section, le conférencier parle de l'optimisation des techniques de convolution d'image. Ils chargent toutes les entrées, les retardent d'un groupe particulier, puis travaillent sur l'évidence. Ils utilisent l'argent tel qu'ils le connaissent et arrêtent d'utiliser LDS pour essayer d'utiliser des textures. Ils mènent une expérience avec une résolution de 2K par 2K et différentes tailles de filtre, et ils obtiennent le nombre le plus rapide lors de l'utilisation de textures. Ils suggèrent les étapes d'optimisation consistant à utiliser des textures évidentes, à utiliser la force de la pensée et à utiliser les options de passage au compteur. Ils suggèrent également d'utiliser le monstre de trésorerie lorsque cela est possible. Ils ont publié un article étape par étape sur l'optimisation des techniques de convolution d'image sur le site Web du développeur AMD, auquel ils renvoient à côté de la vidéo.
How to Optimize Image Convolution
How to Optimize Image Convolution
  • 2013.05.28
  • www.youtube.com
Udeepta Bordoloi, MTS Software Engineer in the Stream Computing Group Udeepta Bordoloi walks though several different ways to optimize an image convolution a...
 

AMD Developer Central : Présentation technique d'OpenCL. Présentation d'OpenCL



AMD Developer Central : Présentation technique d'OpenCL. Présentation d'OpenCL

Dans cette vidéo, Michael Houston donne un aperçu d'OpenCL, une norme industrielle pour le calcul parallèle des données ciblant les processeurs multicœurs, les appareils mobiles et d'autres formes de silicium. OpenCL vise à unifier les implémentations propriétaires précédemment concurrentes telles que CUDA et Brook+, ce qui simplifiera le développement pour les éditeurs de logiciels indépendants. Il propose une répartition entre le code qui s'exécute sur l'appareil et le code qui gère l'appareil à l'aide d'un système de file d'attente conçu pour les commentaires des développeurs de jeux. OpenCL est conçu pour bien fonctionner avec les API graphiques, créant un langage informatique omniprésent qui peut être utilisé pour diverses applications telles que l'édition photo et vidéo, ainsi que pour les systèmes d'intelligence artificielle, la modélisation et la physique. Le présentateur discute également de l'utilisation d'OpenCL pour le rendu Hollywood et espère voir plus de travail dans ce domaine.

  • 00:00:00 Dans cette section, Mike Houston explique l'objectif d'OpenCL en tant que norme industrielle pour le calcul parallèle des données, ciblant les processeurs multicœurs, les appareils mobiles et d'autres formes de silicium. OpenCL vise à unifier les implémentations propriétaires précédemment concurrentes telles que CUDA et Brook+, ce qui simplifiera le développement pour les éditeurs de logiciels indépendants. Bien qu'il existe un dialecte différent et des différences mineures dans OpenCL, la transition à partir d'autres langages de données parallèles tels que CUDA est directe et rapide. OpenCL propose également une répartition entre le code qui s'exécute sur l'appareil et le code qui gère l'appareil à l'aide d'un système de file d'attente conçu pour les commentaires des développeurs de jeux. Il est conçu pour bien fonctionner avec les API graphiques, créant un langage informatique omniprésent pour l'espace grand public dans des applications telles que l'édition photo et vidéo.

  • 00: 05: 00 Dans cette section, l'orateur explique certaines des utilisations initiales d'OpenCL, notamment le traitement d'images ou de vidéos haute résolution et l'exécution d'analyseurs de virus. De plus, la technologie est utile pour les systèmes d'intelligence artificielle, les systèmes de modélisation, la physique, le post-traitement et l'accélération de l'éclairage et du rendu des films. L'orateur espère voir plus de travail sur l'utilisation d'OpenCL pour le rendu Hollywood, entre autres.
Introduction to OpenCL
Introduction to OpenCL
  • 2013.05.29
  • www.youtube.com
Michael Houston, GPG System Architect Learn about OpenCL, what the transition to OpenCL will be like, what applications are ideal for OpenCL and what impact ...
 

AMD Developer Central : Épisode 1 : Qu'est-ce qu'OpenCL™ ?



AMD Developer Central : Épisode 1 : Qu'est-ce qu'OpenCL™ ?

Cette vidéo fournit une introduction à OpenCL et à ses objectifs de conception, qui se concentrent sur l'exploitation de divers processeurs pour accélérer les calculs parallèles au lieu des calculs séquentiels. OpenCL permet l'écriture de code portable pour différents processeurs utilisant des noyaux, des dimensions globales et locales et des groupes de travail. Les éléments de travail et les groupes de travail peuvent collaborer en partageant des ressources, mais la synchronisation entre les éléments de travail dans différents groupes de travail n'est pas possible. Les dimensions optimales du problème varient selon les différents types de traitement, et il est important de choisir les meilleures dimensions pour obtenir les meilleures performances. OpenCL peut utiliser pleinement les capacités d'un système en exprimant le parallélisme des tâches et des données à l'aide du modèle d'événement OpenCL.

  • 00: 00: 00 Dans cette section, Justin Hensley discute des bases d'OpenCL et de ses objectifs de conception, qui se concentrent principalement sur l'exploitation des processeurs, des GPU ou de tout autre processeur, tel que le moteur à large bande cellulaire ou les DSP, pour accélérer les calculs parallèles plutôt que séquentiels, entraînant des accélérations spectaculaires. OpenCL permet d'écrire du code portable pour s'exécuter sur n'importe quel type de processeur, tel que les CPU et GPU AMD, en utilisant des noyaux, qui sont similaires aux fonctions C utilisées pour exploiter le parallélisme, et des programmes qui sont des collections de noyaux et d'autres fonctions, avec des applications exécutant des instances de noyau utilisant files d'attente qui sont mises en file d'attente et exécutées dans l'ordre ou dans le désordre. Les dimensions globales et locales d'OpenCL définissent la plage de calcul, tandis que l'intérêt d'OpenCL est d'utiliser des appareils hautement parallèles pour accélérer le calcul simultanément, permettant aux groupes de travail locaux de collaborer en partageant les ressources car les éléments de travail globaux doivent être indépendants avec la synchronisation uniquement possible. au sein d'un groupe de travail.

  • 00:05:00 Dans cette section, nous découvrons les éléments de travail et les groupes de travail, et comment OpenCL nous permet de synchroniser les éléments de travail au sein d'un groupe de travail à l'aide de barrières ou de clôtures de mémoire. Cependant, les éléments de travail de différents groupes de travail ne peuvent pas se synchroniser les uns avec les autres. Les dimensions optimales du problème varient également selon les différents types de traitement, et il est important de choisir les meilleures dimensions pour le problème donné afin d'obtenir les meilleures performances. Dans OpenCL, il est également possible d'exprimer le parallélisme des tâches en exécutant un seul élément de travail en tant que tâche à l'aide du modèle d'événement OpenCL. En permettant au parallélisme des tâches et des données de fonctionner ensemble, OpenCL peut utiliser pleinement les capacités du système.
Episode 1: What is OpenCL™?
Episode 1: What is OpenCL™?
  • 2013.05.27
  • www.youtube.com
In this video, you learn what OpenCL™ is and why it was designed the way itis. We go through design goals and the execution model of OpenCL™. Topicscovered i...
12345678910
Nouveau commentaire
Raison: