Sortie des spécifications d'OpenGL 4.3 et OpenGL ES 3.0

Lors de la conférence SIGGRAPH 2012, le groupe Khronos a annoncé la sortie des spécifications d'OpenGL 4.3 et d'OpenGL ES 3.0.

Cette nouvelle version apporte 27 nouvelles extensions, dont les suivantes :

• ajout d'une nouvelle extension nommée GL_ARB_compute_shader, permet d'utiliser un nouveau type de shader : les Compute Shaders. Ceux-ci permettent de réaliser des calculs complexes sur les images ou les volumes en bénéficiant de la puissance du parallélisme des cartes graphiques. Ils ont donc la même utilisation que ce que fournit OpenCL. La différence vient du fait que les Compute Shaders sont destinés aux calculs s'intégrant dans le pipeline graphique, alors qu'OpenCL est destiné aux calculs ne nécessitant pas le pipeline graphique ;
  
• ajout d'un nouveau type de Buffer Object : les shader storage buffer objects (extension GL_ARB_shader_storage_buffer_object). Ce sont des espaces mémoire accessibles en écriture et en lecture par tous les types de shaders. Ils facilitent donc la transmission de gros volumes d'informations entre les shaders ;
  
• les texture parameter queries permettent d'obtenir des informations sur le support des textures sur la plateforme d'exécution ;
  
• les compressions de texture haute qualité ETC2 / EAC (extension GL_ARB_ES3_compatibility) ;
  
• l'extension GL_ARB_arrays_of_arrays ajoute les tableaux multidimensionnels dans le GLSL (pour pouvoir écrire par exemple float f[4][3];) ;
  
• fonctionnalités de débogage pendant l'exécution ;
  
• texture views pour travailler sur les textures selon différentes manières, sans devoir les dupliquer ;
  
• les indirect multi-draws permettent de réaliser des instanciations multiples en deux temps, le premier temps permettant de faire des calculs et de stocker les paramètres dans un Buffer Object, puis de les réutiliser dans une seconde étape de rendu ;
  
• amélioration de l'utilisation d'OpenGL par plusieurs applications : sécurisation des espaces mémoire pour éviter qu'une application écrive dans l'espace mémoire d'une autre application (extension GL_ARB_robust_buffer_access_behavior) et éviter que le reset de la carte graphique déclenché par une application perturbe les autres applications.

Il ne reste plus qu'à attendre la sortie des drivers prenant en charge cette nouvelle spécification pour pouvoir tester ! NVIDIA a sorti les drivers 305.53 pour Windows et 304.15.00.02 pour Linux supportant OpenGL 4.3. Télécharger ici.

:fleche: Quelles sont les nouvelles fonctionnalités qui vous intéressent le plus ?
:fleche: Que pensez-vous de l'ajout des Compute Shaders, en particulier font-ils double-emploi avec OpenCL ?

Spécifications :
- 3D : OpenGL Core profile 4.3 (06/08/2011), Compatibility profile 4.3 (06/08/2011) et OpenGL Shading Language 4.30.6 (06/08/2012)
- 3D embarqué : OpenGL ES 3.0.0 (06/08/2012) et OpenGL ES Shading Language 3.00.3 (06/08/2012)

Sources :
- OpenGL 4.3 Specifications Released, Advanced Computation with Compute Shaders!
- OpenGL 4.3 and OpenGL ES 3.0: Adaptive Scalable Texture Compression Extension (ASTC)
- OpenGL 4.3: Compute Shaders Details

EDIT : review des fonctionnalités d'OpenGL, par Christophe Riccio : 4.3

Bonjour,
le groupe kronos viens de publier OpenGL 4.3 avec comme une des composantes clés le COMPUTE SHADER.

J'ai commencé à apprendre l'openCL pour des besoins d'améliorations de calcul dans l'imagerie ce que font à peu prés 75% du gratin dans le secteur ( blender, adobe, musemage, etc etc...). Franchement ça marche bien mais des pb au niveau des drivers AMD pour la compilation du kernel plombent un peu certains résultats. Cuda s'est libéré que très récemment et direct compute est limité Windows.

Maintenant Compute shaders viens nous donner ce que nous voulons avec OpenCL, je suis franchement sur le cul car je me demande si j'ai juste perdu mon temps avec OpenCL. :calim2::traine:

Il faut savoir que Adobe, Gimp vegas et tous les autres qui font de l'imagerie utilisent les "contexte" OpenGL pour faire le calcul, il y a juste quelques opérations qui nécessitent vraiment openCL, maintenant qu'il y a compute shaders pourquoi encore utilisé OpenCL pour l'imagerie cela n'a vraiment pas de sens. Pour moi il viennent de tuer 30% sinon plus l'intérêt de l'API.

Les possibilités de Compute shaders sont ici

je suis nouveau dans le domaine ( 1 ans ) mais je penses déjà avoir une vue de la chose, mais je demande s'il y a une personne capable de m'aider à répondre à mes questions car là je suis dans un vortex assez noir.:arf:

De toutes les façons enfin une release digne de ce nom. Nvidia à déjà fait un driver pour la 4.3 c'est ici :P:ccool:

@lougne
Alors non. Le GPU Computing n'est pas utilisé majoritairement que pour l'imagerie (c'est l'application du CPU Computing la plus visible du grand public au pire)
C'est également très utilisé dans la simulation (physique, chimie), le calcul numérique, la biologie (alignement de séquence), l'analyse de données, l'intelligence artificielle. Même des applications basée sur des images, mais dont la finalité n'est pas l'affichage d'une image (vision par ordinateur, imagerie biomédicale), ont un intérêt pour OPenCL. Idem pour le calcul hétérogène intensif (cluster).
Bref, il y a beaucoup d'applications qui n'ont pas d'intérêt avec les Compute Shader. Disons que c'est encore une nouvelle brique disponible pour ceux qui veulent utiliser les capacités des GPU.

Donc cela dépend de ton domaine d'utilisation. Si effectivement tu bosses chez Adobe, ça peut limiter l'utilisation de OpenCL (à voir, on manque de recul)

Si c'est pour une utilisation amateur/personnelle, c'est à voir. Il y a beaucoup de retard dans l'utilisation des shaders introduits précédemment (geometry shader et pire avec la tessalation), donc les compute shaders risquent de ne pas être utilisé tout de suite.

De toute façon, le plus important n'est pas de connaître l'API. Savoir qu'il faut utiliser la fonction clCreateShader ou glCreateShader, quelle différence ? (idem avec les autres API) Non, le plus important est de comprendre la programmation concurrente, les spécificités de la programmation parallèle, comprendre que le gestionnaire d'instruction fonctionne sur les SM et ce que cela implique, savoir comment profiler une application pour trouver les goulots d'étranglement et les corriger, etc. Et tout ça est indépendant de l'API utilisée, si tu sais faire ça avec OpenCL, tu n'auras pas de problème avec les compute shaders (tout comme il n'y a pas trop de difficultés pour passer de OpenCL à CUDA par exemple, quand on comprend comment ça fonctionne)

Citation:

---

Envoyé par gbdivers

@lougne
Alors non. Le GPU Computing n'est pas utilisé majoritairement que pour l'imagerie (c'est l'application du CPU Computing la plus visible du grand public au pire)

---

Salut,
je n'ai pas dit que cela servait uniquement pour l'imagerie, j'ai dit pour les besoins de l'imagerie on a plus besoin de l'openCL on dirait. grosse nuance :).

Bref, évidemment je suis passé du Cuda à openCL, testé direct compute et voilà un autre à tester compute shader. Il faut savoir que OpenCL pour l'imagerie à un méga retard sur l'API CUDA. Ce dernier offre plus de fonctions utiles pour arriver à ses fins. Mais maintenant avec l'OpenGL 4.3 on a accès à la même puissance, la tesselation amélioré, le calcul de physique et de l'IA, des extensions pour la mémoire partagé entre CPU et GPU et tout cela sans une énième compilation du kernel OpenCL.

Oui on ne touche plus le proco ( je crois) mais pour l'imagerie là où tout est fortement parallélisable "who cares" avec un bon GPU. D'où ma question est que OpenCL est encore viable pour l'imagerie? Il reste super utile pour certains cas mais je fais une liste des besoins en parallélisation:

• physic processing ---> API GPU plus rapide
• imagerie 2D ----> API GPU plus rapide
• imagerie 3D ---> API GPU plus rapide mais est limité par sa mémoire donc en pro CPU vainqueur au delà des scénes qui demandent plus de 6 Go de données car la carte particulier sur le marché à exactement 6 Go de DDR5 HD radeon 7970
• database -----> pour le moment API CPU/GPU vainqueur
• calcul par éléments finis (physics, béton, simulation par atome, palplanches) -----> API GPU
• Calcul hétérogéne ----->API CPU/GPU uniquement utilisable

Citation:

---

Envoyé par gbdivers

C'est également très utilisé dans la simulation (physique, chimie), le calcul numérique, la biologie (alignement de séquence), l'analyse de données, l'intelligence artificielle. Même des applications basée sur des images, mais dont la finalité n'est pas l'affichage d'une image (vision par ordinateur, imagerie biomédicale), ont un intérêt pour OPenCL.

---

Euh non. Comme je viens de le montrer toutes ta liste est facilement remplaçable si on parle puissance brute par une une API 100% GPU avec une architecture faite pour. Seul le calcul hétérogène donne vie à OpenCL.

il reste réellement peu d'endroit où le CPU sera fortement demandée sauf si l'architecture entre nos mains est CPU only comme avec la nouvelle carte d'INTEL la Xeon phi.

@lougne

Pas tout compris :aie:

Citation:

---

Envoyé par lougne

je n'ai pas dit que cela servait uniquement pour l'imagerie, j'ai dit pour les besoins de l'imagerie on a plus besoin de l'openCL on dirait. grosse nuance

---

J'avais mal compris ta phrase avec les 75% alors

Citation:

---

Envoyé par lougne

D'où ma question est que OpenCL est encore viable pour l'imagerie ?

---

Oui, si la question porte que sur l'imagerie, OpenCL risque d'être inutile. C'est bien le but des Compute Shader (éviter les changement de contexte)

Citation:

---

Envoyé par lougne

je fais une liste des besoins en parallélisation
(...)
Euh non. Comme je viens de le montrer toutes ta liste est facilement remplaçable si on parle puissance brute par une une API 100% GPU avec une architecture faite pour. Seul le calcul hétérogène donne vie à OpenCL.

---

Je n'en fais pas la même interprétation que toi, simplement du faire que le calcul hétérogène n'est pas un "besoin" mais un outil : tous les autres besoins peuvent être exécutés sur des machines classiques (1 CPU + 1 GPU), ou sur des machines plus évoluées (multi proc, multi gpu) ou en réseau (qui bénéficient alors du calcul hétérogène)

Citation:

---

Envoyé par lougne

il reste réellement peu d'endroit où le CPU sera fortement demandée sauf si l'architecture entre nos mains est CPU only comme avec la nouvelle carte d'INTEL la Xeon phi.

---

J'ai pas encore de retour sur le xeon phi, mais je suis dubitatif. Le but est normalement d'éviter à devoir utiliser une autre api et compiler directement avec un langage généraliste. En pratique, je pense que cela ne vas pas être aussi directe et simple à faire que ce qui est annoncé, en particulier parce que le plus gros boulot (écrire un algo parallèle et l'optimiser pour une architecture) ne pourra pas être évité


Bref, OpenCL a de l'avenir, mais plus (à voir avec les retours) en association avec OpenGL. Mais on disait la même chose avec OpenCL a sa sortie, comme quoi ça faisait double emploi avec le GPGPU en utiliser les shaders d'OpenGL et finalement les fonctionnalités d'OpenCL ont fait que ça a supplanté en partie OpenGL pour les calculs. Peut être que OpenCL aura encore des fonctionnalités non accessibles dans les Compute Shader d'OpenGL qui le rendront encore intéressant. Ou alors que OpenCL disparaisse :aie:

Citation:

---

Envoyé par gbdivers

J'ai pas encore de retour sur le xeon phi, mais je suis dubitatif. Le but est normalement d'éviter à devoir utiliser une autre api et compiler directement avec un langage généraliste. En pratique, je pense que cela ne vas pas être aussi directe et simple à faire que ce qui est annoncé, en particulier parce que le plus gros boulot (écrire un algo parallèle et l'optimiser pour une architecture) ne pourra pas être évité

---

100% d'accord c'est l'algo le plus important

Citation:

---

Envoyé par gbdivers

Peut être que OpenCL aura encore des fonctionnalités non accessibles dans les Compute Shader d'OpenGL qui le rendront encore intéressant. Ou alors que OpenCL disparaisse :aie:

---

Voilà le nerf de mon problème, je viens d'installer openGL 4.3 sur mon portable perso je vais tester ça ce weekend pour voir un peu plus clair. Si c'est vraiment le cas ( compute shader pareil que OpenCL pour imagerie) alors là adios openCL sinon j'analyserais point par point

Citation:

---

Envoyé par lougne

Voilà le nerf de mon problème, je viens d'installer openGL 4.3 sur mon portable perso je vais tester ça ce weekend pour voir un peu plus clair. Si c'est vraiment le cas ( compute shader pareil que OpenCL pour imagerie) alors là adios openCL sinon j'analyserais point par point

---

Il est vrai que l'abandon de OpenCL pour les Compute Shader sera plus facile que l'abandon de CUDA, qui bénéficie d'un écosystème beaucoup plus important (libs utilisé par CUDA ou libs utilisant CUDA). Par contre, ceux qui utilisent CUDA devront attendre un peu les retours je pense

J'avais abandonné CUDA à cause de l'obligation d'avoir une carte Nvidia mon desktop ATI et mon portable nvidia. Au bureau c'est du ATI.

Maintenant je suis plus que content de ce choix car les nouvelles cartes grands publics Nvidia pour du GPGPU c'est....:calim2: :? :aie: :bug: vous avez compris perfs hyper médiocres ATI POWER là je change d'école ^^ ;)