OpenGL vs. OpenCL, lequel choisir et pourquoi ?

Question

Quelles sont les caractéristiques qui font qu'il faut choisir OpenCL plutôt qu'OpenGL avec GLSL pour les calculs ? Malgré la terminologie liée au graphisme et les types de données peu pratiques, y a-t-il un réel problème avec OpenGL ?

Par exemple, l'évaluation parallèle des fonctions peut être effectuée en rendant une texture à l'aide d'autres textures. Les opérations de réduction peuvent être effectuées en effectuant un rendu itératif vers des textures de plus en plus petites. D'un autre côté, l'accès aléatoire en écriture n'est pas possible de manière efficace (la seule façon de faire est de rendre les triangles par des données de sommet pilotées par la texture). Est-ce possible avec OpenCL ? Quoi d'autre n'est pas possible avec OpenGL ?

Answer 1

OpenCL est créé spécifiquement pour l'informatique. Lorsque vous effectuez des calculs scientifiques à l'aide d'OpenGL, vous devez toujours réfléchir à la manière de faire correspondre votre problème de calcul au contexte graphique (c'est-à-dire parler en termes de textures et de primitives géométriques comme les triangles, etc.

Dans OpenCL, il suffit de formuler le calcul avec un noyau de calcul sur un tampon mémoire et le tour est joué. C'est en fait une GRANDE victoire (je dis cela du point de vue d'une personne qui a réfléchi et mis en œuvre les deux variantes).

Les schémas d'accès à la mémoire sont pourtant les mêmes (votre calcul se déroule toujours sur un GPU - mais les GPU sont de plus en plus flexibles de nos jours).

Mais qu'attendez-vous d'autre que d'utiliser plus d'une douzaine de "CPU" parallèles sans vous casser la tête sur la façon de traduire - par exemple (exemple idiot) Fourier en Triangles et Quads... ?

Answer 2

Un élément qui n'a pas été mentionné dans les réponses jusqu'à présent est la vitesse d'exécution. Si votre algorithme peut être exprimé en graphiques OpenGL (par exemple, pas d'écritures dispersées, pas de mémoire locale, pas de groupes de travail, etc.), il s'exécutera très souvent plus rapidement qu'une contrepartie OpenCL. ), il sera très souvent plus rapide que son homologue OpenCL. Mon expérience spécifique à ce sujet a consisté à réaliser des noyaux de filtres d'images (gather) sur des GPU AMD, nVidia, IMG et Qualcomm. Les implémentations OpenGL s'exécutent invariablement plus rapidement, même après une optimisation hardcore du noyau OpenCL. (aparté : je soupçonne que cela est dû à des années de matériel et de pilotes spécifiquement réglés pour les charges de travail orientées graphiques).

Mon conseil serait que si votre programme de calcul se sent si vous pensez que cela correspond bien au domaine graphique, utilisez OpenGL. Sinon, OpenCL est plus général et plus simple pour exprimer les problèmes de calcul.

Un autre point à mentionner (ou à demander) est de savoir si vous écrivez en tant que hobbyiste (c'est-à-dire pour vous-même) ou commercialement (c'est-à-dire pour une distribution à d'autres). Alors qu'OpenGL est supporté à peu près partout, OpenCL manque totalement de support sur les appareils mobiles et, à mon avis, il est très peu probable qu'il apparaisse sur Android ou iOS dans les prochaines années. Si la compatibilité entre plates-formes à partir d'une base de code unique est un objectif, alors OpenGL peut vous être imposé.

Answer 3

Quelles sont les caractéristiques qui font d'OpenCL un choix unique par rapport à OpenGL et GLSL pour les calculs ? Malgré la terminologie liée au graphisme et les types de données peu pratiques, y a-t-il un réel problème avec OpenGL ?

Oui : il s'agit d'une API graphique. Par conséquent, tout ce que vous y faites doit être formulé en ces termes. Vous devez conditionner vos données sous la forme d'un "rendu". Vous devez trouver comment traiter vos données en termes d'attributs, de tampons uniformes et de textures.

Avec OpenGL 4.3 et OpenGL ES 3.1 shaders de calcul les choses deviennent un peu plus confuses. Un shader de calcul est capable d'accéder à la mémoire via SSBOs/Image Load/Store de manière similaire aux opérations de calcul d'OpenCL (bien qu'OpenCL offre des pointeurs réels, alors que GLSL ne le fait pas). Leur interopérabilité avec OpenGL est également beaucoup plus rapide que l'interopérabilité OpenCL/GL.

Malgré tout, les shaders de calcul ne changent pas un fait : les opérations de calcul OpenCL fonctionnent à un très une précision différente de celle des nuanceurs de calcul d'OpenGL. Les exigences de précision en virgule flottante de GLSL ne sont pas très strictes, et celles d'OpenGL ES le sont encore moins. Ainsi, si la précision en virgule flottante est importante pour vos calculs, OpenGL ne sera pas le moyen le plus efficace de calculer ce que vous devez calculer.

De plus, les shaders de calcul OpenGL nécessitent un matériel compatible avec la norme 4.x, tandis qu'OpenCL peut fonctionner sur du matériel beaucoup plus inférieur.

De plus, si vous faites du calcul en cooptant le pipeline de rendu, les pilotes OpenGL supposeront toujours que vous faites du rendu. Ils vont donc prendre des décisions d'optimisation basées sur cette supposition. Ils optimiseront l'affectation des ressources du shader en supposant que vous dessinez une image.

Par exemple, si vous effectuez un rendu sur un framebuffer à virgule flottante, le pilote peut décider de vous donner un framebuffer R11_G11_B10, car il détecte que vous ne faites rien avec l'alpha et que votre algorithme peut tolérer une précision inférieure. Si vous utilisez chargement/stockage d'images au lieu d'un framebuffer, vous avez beaucoup moins de chances d'obtenir cet effet.

OpenCL n'est pas une API graphique, c'est une API de calcul.

Aussi, OpenCL vous donne juste accès à plus de choses. Il vous donne accès à des niveaux de mémoire qui sont implicites en ce qui concerne GL. Certaines mémoires peuvent être partagées entre les threads, mais les instances de shader séparées dans GL ne peuvent pas affecter directement l'une l'autre (en dehors du chargement/stockage d'image, mais OpenCL fonctionne sur du matériel qui n'a pas accès à cela).

OpenGL cache ce que fait le matériel derrière une abstraction. OpenCL vous expose presque exactement ce qui se passe.

Vous peut utiliser OpenGL pour effectuer des calculs arbitraires. Mais vous n'avez pas veulent pas tant qu'il existe une alternative parfaitement viable. Le calcul en OpenGL est au service du pipeline graphique.

Le site seulement La raison de choisir OpenGL pour tout type d'opération de calcul sans rendu est de prendre en charge le matériel qui ne peut pas exécuter OpenCL. À l'heure actuelle, cela inclut beaucoup de matériel mobile.

Answer 4

Une caractéristique notable serait l'éparpillement des écritures, une autre serait l'absence d'"intelligence Windows 7". Windows 7 va, comme vous le savez probablement, tuer le pilote d'affichage si OpenGL n'est pas purgé pendant environ 2 secondes (ne me clouez pas sur le temps exact, mais je pense que c'est 2 secondes). Cela peut être gênant si vous avez une opération longue.

De plus, OpenCL fonctionne évidemment avec une variété de matériel beaucoup plus grande que la seule carte graphique, et il ne dispose pas d'un pipeline rigide orienté graphique avec des "contraintes artificielles". Il est également plus facile (trivial) d'exécuter plusieurs flux de commandes simultanés.

Answer 5

Une autre raison majeure est qu'OpenGL \GLSL ne sont prises en charge que par les cartes graphiques. Bien que l'utilisation du multi-cœur ait commencé par l'utilisation de matériel graphique, de nombreux fournisseurs de matériel travaillent sur des plates-formes matérielles multi-cœurs destinées au calcul. Par exemple, voir Intels Knights Corner.

Développer du code pour le calcul en utilisant OpenGL \GLSL vous empêchera d'utiliser tout matériel qui n'est pas une carte graphique.