Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1765 connectés 

  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : GDC: Khronos annonce OpenCL 2.1

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[HFR] Actu : GDC: Khronos annonce OpenCL 2.1

n°9433486
tridam
Profil : Equipe HardWare.fr
Posté le 03-03-2015 à 09:05:01  profilanswer
0Votes positifs
 

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 ...

mood
Publicité
Posté le 03-03-2015 à 09:05:01  profilanswer
 

n°9433576
lapin
Posté le 03-03-2015 à 11:27:57  profilanswer
0Votes positifs
 

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.
 

n°9433666
Gigathlon
Quad-neurones natif
Posté le 03-03-2015 à 13:00:05  profilanswer
0Votes positifs
 

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.

n°9433903
chromatom
Posté le 03-03-2015 à 19:07:30  profilanswer
0Votes positifs
 

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.

n°9434073
wgg_71
Posté le 03-03-2015 à 23:02:02  profilanswer
0Votes positifs
 

chromatom a écrit :

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.
 

lapin a écrit :

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.
 


 
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.

n°9434081
lapin
Posté le 03-03-2015 à 23:12:11  profilanswer
0Votes positifs
 

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

n°9434114
chromatom
Posté le 04-03-2015 à 00:30:50  profilanswer
0Votes positifs
 

wgg_71 a écrit :

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.


Je ne connais rien en programmation donc je te crois sur parole :whistle:  
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.

Message cité 1 fois
Message édité par chromatom le 04-03-2015 à 00:32:44
n°9434186
pinpinb
Posté le 04-03-2015 à 08:33:43  profilanswer
0Votes positifs
 

chromatom a écrit :


Je ne connais rien en programmation donc je te crois sur parole :whistle:  
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).

Message cité 1 fois
Message édité par pinpinb le 04-03-2015 à 09:18:28
n°9434347
iapx
euuuhhhh.....
Posté le 04-03-2015 à 12:21:10  profilanswer
0Votes positifs
 

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.

n°9434371
chromatom
Posté le 04-03-2015 à 12:44:48  profilanswer
0Votes positifs
 

pinpinb a écrit :

tu peux quand même lire la mailing-list posté.


Oups désolé j'ai zappé, faire plusieurs choses à la fois c'est mal [:goumite:2]
 
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 [:black_jack:3]


Message édité par chromatom le 04-03-2015 à 12:47:46
mood
Publicité
Posté le 04-03-2015 à 12:44:48  profilanswer
 

n°9434410
pinpinb
Posté le 04-03-2015 à 13:26:58  profilanswer
0Votes positifs
 

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é,...)


Message édité par pinpinb le 04-03-2015 à 13:27:45
n°9434473
chromatom
Posté le 04-03-2015 à 14:36:33  profilanswer
0Votes positifs
 

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 ! [:chownkey]

n°9434770
pinpinb
Posté le 04-03-2015 à 20:40:03  profilanswer
0Votes positifs
 

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

n°9434874
chromatom
Posté le 04-03-2015 à 21:57:37  profilanswer
0Votes positifs
 

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. :(

n°9435029
cocto81
Posté le 05-03-2015 à 00:58:08  profilanswer
0Votes positifs
 

chromatom a écrit :


Je ne connais rien en programmation donc je te crois sur parole :whistle:  
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.


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.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Actu : GDC: Khronos annonce OpenCL 2.1

 

Sujets relatifs
[HFR] Actu : GDC: Vulkan, l'API bas niveau de Khronos[HFR] Actu : GDC: Direct3D12: premiers conseils aux devs
[HFR] Actu : GDC 2015: D3D12, streaming et VR à l'honneur 
Plus de sujets relatifs à : [HFR] Actu : GDC: Khronos annonce OpenCL 2.1


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR