Parallèlement à l'annonce de Vulkan, le groupe Khronos fait évoluer légèrement OpenCL avec l'annonce des spécifications provisoires de la version 2.1 de cette ...
Lire la suite ...

question est il prévu un jour un grand dossier!!?, sur le GPGPU ou GPU Computing en expliquant profondément le fonctionnement des différents API proposer sur le marché, parce que là j'ai rien pus assimiler et je sais qu'a l'avenir se sera de plus en plus important avec le haut niveau de programmabilité des GPU et des différentes interaction GPU et CPU entre autre via HSA.
 
ou alors faire des dossiers séparer un pour OpenCl 2.1 et un pour chaque API.
 
déjà que j'ai un peux du mal à assimiler les diagramme des GPU après la Radeon 9800 qui était encore simple à comprendre.
 

Il n'y a pas de "via HSA", dire "HSA" c'est comme dire "PC"...
 
Mais effectivement, ça pourrait être intéressant de publier une étude de cas pas forcément très complexe de façon à voir les similitudes/différences entre les API Khronos et Microsoft, y compris dans leurs interactions.

Ce serait bien que le discours officiel d'AMD rejoigne la pratique parce que l'utilisation d'OpenCL pour les possesseurs de Radeon n'est pas forcément possible.
 
cf. Blender qui s'en plaint depuis des années
et AMD qui ferme les sujets qui en parlent
 
Forcément NVIDIA avec CUDA a le champ libre et n'a aucune raison de ne pas continuer.

 
J'ai fait que 6 mois d'OpenCL lors d'un stage, mais il me parait évident que le code OpenCL de Blender est un copier/coller d'un code CPU. Quand on voit la taille énorme (et encore le mot est faible) de l'unique kernel, on comprend que celui qui a fait ça n'a soit aucune expérience en GPGPU, soit c'est un softeux GUI qui ne comprend absolument rien au fonctionnement d'un GPU. J'ai farfouillé dans le code, on trouve des structures énormes, des quantités de branchements qui partent dans tous les sens... En générale un kernel c'est quelques milliers de lignes maximums avec le moins de branchement possible.
 
Le code va être repris par un gars d'AMD qui confirme mes premières impressions : http://lists.blender.org/pipermail [...] 02115.html
 
L'implémentation OpenCL d'AMD n'est pas parfaite, mais elle n'a rien à envier à CUDA.
 

 
L'OpenCL est très proche de CUDA, j'avais même trouvé un tableau de correspondance pour le vocabulaire et les fonctions. Mais contrairement à ce que certains essaient de faire croire, il faut une bonne connaissance du matériel pour obtenir un bon rendement. Après pour comprendre le fonctionnement ça dépend du niveau de détails que tu veux, mais ça peut devenir très abstrait si tu regardes la doc.
 
Pour revenir au sujet de la news, les nouveautés apportées sont assez maigres comparées à la version 2.0 qui a apporté les dernières fonctionnalités manquantes. Le support de la version 2.0 par les GPU est encore tout récent. Il y a malheureusement trop peu de soft qui propose une accélération OpenCL.

je crois y a libre office qui utilise Opencl, si non peut être quelques jeux vidéo et benchmark.

Je ne connais rien en programmation donc je te crois sur parole  
Il n'empêche que Blender n'est pas le seul à reprocher à AMD des drivers tout pourris pour OpenCL et des bugs présents depuis des années.
Ce qui a été commencé pour OpenCL dans Blender est peut-être mauvais en l'état (je ne sais pas à quel point ils ont bossé dessus) mais pour CUDA ça roule parfaitement visiblement. Il doit bien y avoir une raison à chercher côté AMD pour qu'ils aient laissé ça en plan depuis des années, autre que l'éventuelle incompétence de ceux qui essayaient.

Oui, enfin, même si tu ne connais rien en programmation, tu peux quand même lire la mailing-list posté. Tu verras que ce n'est pas vraiment la faute d'AMD. Un peu sur certain aspect (compiler opencl moins "permissiif" que celui d'NVIDIA), mais pas trop non plus.
Car de l'aveu même des développeurs, ça marche sur nvidia, mais c'est vraiment pas super(au niveau code) et que c'est dû à leur manque de connaissance sur les codes gpgpu (y'a pas de reproche derrière, juste une constatation).

La programmation OpenCL (ou CUDA pour le coup) nécessite de ré-écrire le code généralement: pas de complexité, pas de divergence (ou un minimum), s'assurer que ça soit massivement parallèle, et surtout éviter absolument les synchronisations entre tâches, ou alors s'assurer qu'elles démarrent toutes (une erreur de débutant). Ça fait beaucoup beaucoup de changement, moi je conseille de tout revoir, depuis les algorithmes employés, certains étant plus GPU-friendly que d'autres.

Oups désolé j'ai zappé, faire plusieurs choses à la fois c'est mal
 
Pour ma défense je viens seulement de me (re)mettre à Blender et découvre la situation jour après jour. J'ignorais qu'AMD avait déjà pris les choses en mains.
 
Mes excuses AMD et merci

AH, mais comme dit, il n'y a aucun reproche de ma part, je prends juste les devants ^^
 
C'est juste qu'il y a tellement de gens qui crache à tout va sur telle ou telle marque, que je préfère prévenir (surtout pour que ce ne soit pas répété, amplifié, déformé,...)

Dans mon cas il s'agit d'un client fidèle qui aimerait bien pouvoir profiter à fond des produits de la marque. On nous vend du rêve avec OpenCL depuis des années mais en pratique je n'ai pas l'occasion de l'utiliser dans les programmes où il m'apporterait le plus. Je parle de Blender mais il y a aussi Gimp qui se convertit de longue date et pour qui ce sera une énorme étape.
 
En attendant j'ai Libre Office pour mettre à genoux ma Radeon !

Pour gimp, vu le temps qu'il leur a fallu pour supporter les images 16bits, ne soit pas trop pressé

C'est tellement lent que je me suis souvent dis qu'une équipe pourrait développer, en partant de rien, un meilleur programme plus rapidement et qui profiterait d'OpenCL/GL avant que Gimp en soit capable...
 
Si Krita élargit ses horizons et maintient sa montée en puissance ça pourrait arriver encore plus tôt. J'ai l'impression qu'il n'y a plus grand monde pour développer Gimp depuis longtemps.

Non, c'est effectivement ce qui est dit depuis le début ici. La compilation foire et les exécutables plantent un peu comme si la plateforme n'avait pas les caractéristiques. Il faut pour ce faire "downsizer" le code, ce qui évidemment est très pénible, demande quasiment une réécriture complète.
Chez Nvidia c'est le compilateur qui doit s'occuper de tout ça et pas forcément de façon optimale, mais ça tourne et ça donne l'impression qu'il n'y a pas de bugs et qu'on peut porter n'importe quel programme dessus. Or beaucoup de programmes n'ont aucun intérêt à se servir du GPU.
 
Je pense qu'AMD devrait au moins s'orienter dans une direction où on pourrait optionnellement compiler de tout, de façon permissive, en OpenCL sans se soucier des possibilités du hardware, quitte à perdre en optimisation.