Hier AMD sortait la version finale de son Stream SDK 2.0 apportant, entre autres, le support d'OpenCL 1.0.
Stream SDK 2.0 : on change la façon de coder... ça occupe les développeurs
Comme nous le disions dans une mise à jour, GPU Caps Viewer 1.8.0 s'est retrouvé inopérant une fois cette version du SDK installé.
N'ayant pas pu avoir de réponse de la part d'AMD, dont les équipes sont en vacances, nous avons fait quelques recherches avec notre ami JeGX.
Après avoir regardé dans la base de connaissance spécifique aux développeurs, nous avons pu trouver de nouveaux articles qui ont été publiés suite à la mise en ligne de ce nouveau SDK.
En effet, le passage de la version bêta à la version de production a été l'occasion pour AMD de modifier la façon dont les contextes OpenCL devaient être créés.
Création de contexte OpenCL : choisissez votre implémentation
Désormais, plusieurs implémentations d'OpenCL peuvent coexister et c'est au développeur de choisir laquelle utiliser, un choix qui se faisait jusqu'à lors de manière automatique.
Ainsi, cet article explique la modification à apporter à votre code pour que les Radeons fonctionnent avec vos codes OpenCL.
JeGX a ainsi mis à jour GCV en version 1.8.1 afin d'apporter ces corrections, une nouvelle mouture qui était l'occasion de prendre en compte d'autres modifications de ce SDK 2.0 final.
GPU Caps Viewer 1.8.1 : adaptation au SDK 2.0 Final et support des fonctions cachées
En effet, comme vu dans notre mise à jour, AMD évoque le support de plusieurs fonctionnalités en « Preview », telles que l'interopérabilité entre le code OpenCL et du code OpenGL ou DirectX 10.
Dans notre dossier, nous avons vu que cette fonctionnalité permet de simplifier les échanges et donc, de gagner en performance.
Dans un premier temps, nous avons regardé la liste des extensions OpenCL proposées par AMD et nous n'avons pas vu celles concernant cette interopérabilité (cl_khr_gl_sharing dans le cas d'OpenGL, par exemple).
Or, en lisant cet article de la base de connaissance, on peut comprendre que si cette extension n'est pour l'instant pas exposée (preview oblige), elle est bel et bien présente et peut donc être utilisée.
La version 1.8.1 de GPU Caps Viewer a donc été modifiée afin d'exploiter cette possibilité. Malheureusement, l'interopérabilité ne semble pas très fonctionnelle pour le moment puisque nous obtenons un écran noir ou amorphe lors de l'exécution des différentes démos concernées (Julia 4D et Particles).
D'après les réponses que nous avons pu avoir de responsables d'AMD que nous avons tiré hors de leurs congés, le support de ces extensions n'a pas encore été soumis au Khronos Group, elle ne peuvent donc pas être exposées pour le moment.
Deux nouvelles options pour corriger les problèmes rencontrés
De plus, il nous a été confirmé qu'elles ne sont pas encore totalement fonctionnelles, l'interopérabilité OpenGL ne gérant pas encore les actions sur les images, par exemple.
Ainsi, GPU Caps Viewer 1.8.1 fonctionnera avec l'interopérabilité de désactivée par défaut, il sera possible de l'activer via l'option « /cl_demo_gl_interop_enabled ».
Pour ceux qui rencontrent des problèmes depuis l'arrivée du support de l'OpenCL, une option « /disable_cl_support » a aussi été créée afin de le désactiver.
Des batchs intégrant ces options sont présents à la racine du répertoire de GCV afin de vous faciliter la vie.
Envie d'en savoir plus sur le SDK 2.0 d'AMD, allez dans leur base de connaissance
La base de connaissance d'AMD dispose aussi d'articles renseignant la possibilité d'utiliser la double précision dans du code C avec les Radeon HD 5800/5900 ou l'intégration d'OpenCL a du code C++.
Pour voir la liste complète, il vous suffit de vous rendre à cette adresse et de taper « OpenCL » dans le champ de recherche.
Enfin, pour le téléchargement de GPU Caps Viewer en version 1.8.1, ça se passera par là.
Stream SDK 2.0 : on change la façon de coder... ça occupe les développeurs
Comme nous le disions dans une mise à jour, GPU Caps Viewer 1.8.0 s'est retrouvé inopérant une fois cette version du SDK installé. N'ayant pas pu avoir de réponse de la part d'AMD, dont les équipes sont en vacances, nous avons fait quelques recherches avec notre ami JeGX.
Après avoir regardé dans la base de connaissance spécifique aux développeurs, nous avons pu trouver de nouveaux articles qui ont été publiés suite à la mise en ligne de ce nouveau SDK.
En effet, le passage de la version bêta à la version de production a été l'occasion pour AMD de modifier la façon dont les contextes OpenCL devaient être créés.
Création de contexte OpenCL : choisissez votre implémentation
Désormais, plusieurs implémentations d'OpenCL peuvent coexister et c'est au développeur de choisir laquelle utiliser, un choix qui se faisait jusqu'à lors de manière automatique.Ainsi, cet article explique la modification à apporter à votre code pour que les Radeons fonctionnent avec vos codes OpenCL.
JeGX a ainsi mis à jour GCV en version 1.8.1 afin d'apporter ces corrections, une nouvelle mouture qui était l'occasion de prendre en compte d'autres modifications de ce SDK 2.0 final.
GPU Caps Viewer 1.8.1 : adaptation au SDK 2.0 Final et support des fonctions cachées
En effet, comme vu dans notre mise à jour, AMD évoque le support de plusieurs fonctionnalités en « Preview », telles que l'interopérabilité entre le code OpenCL et du code OpenGL ou DirectX 10.
Dans notre dossier, nous avons vu que cette fonctionnalité permet de simplifier les échanges et donc, de gagner en performance.Dans un premier temps, nous avons regardé la liste des extensions OpenCL proposées par AMD et nous n'avons pas vu celles concernant cette interopérabilité (cl_khr_gl_sharing dans le cas d'OpenGL, par exemple).
Or, en lisant cet article de la base de connaissance, on peut comprendre que si cette extension n'est pour l'instant pas exposée (preview oblige), elle est bel et bien présente et peut donc être utilisée.
La version 1.8.1 de GPU Caps Viewer a donc été modifiée afin d'exploiter cette possibilité. Malheureusement, l'interopérabilité ne semble pas très fonctionnelle pour le moment puisque nous obtenons un écran noir ou amorphe lors de l'exécution des différentes démos concernées (Julia 4D et Particles).
D'après les réponses que nous avons pu avoir de responsables d'AMD que nous avons tiré hors de leurs congés, le support de ces extensions n'a pas encore été soumis au Khronos Group, elle ne peuvent donc pas être exposées pour le moment.
Deux nouvelles options pour corriger les problèmes rencontrés
De plus, il nous a été confirmé qu'elles ne sont pas encore totalement fonctionnelles, l'interopérabilité OpenGL ne gérant pas encore les actions sur les images, par exemple.
Ainsi, GPU Caps Viewer 1.8.1 fonctionnera avec l'interopérabilité de désactivée par défaut, il sera possible de l'activer via l'option « /cl_demo_gl_interop_enabled ».
Pour ceux qui rencontrent des problèmes depuis l'arrivée du support de l'OpenCL, une option « /disable_cl_support » a aussi été créée afin de le désactiver.
Des batchs intégrant ces options sont présents à la racine du répertoire de GCV afin de vous faciliter la vie.
Envie d'en savoir plus sur le SDK 2.0 d'AMD, allez dans leur base de connaissance
La base de connaissance d'AMD dispose aussi d'articles renseignant la possibilité d'utiliser la double précision dans du code C avec les Radeon HD 5800/5900 ou l'intégration d'OpenCL a du code C++. Pour voir la liste complète, il vous suffit de vous rendre à cette adresse et de taper « OpenCL » dans le champ de recherche.
Enfin, pour le téléchargement de GPU Caps Viewer en version 1.8.1, ça se passera par là.
David Legrand
Journaliste, responsable des PCi Labs. Geek de l'extrême spécialisé dans l'analyse des produits high-tech, les réseaux sociaux et les trios d'écrans. Adepte du libre.
Le 22 décembre 2009 à 09:47
(8 738
lectures)
Il y a 22 commentaires
Vivement que Folding@Home & les principaux projets Boinc passent à OpenCL.
Cela permet de balayer tous les clients existants et de n'en faire qu'un seul (GPU + CPU).
C'est vraiment top de ce coté là
Cela permet de balayer tous les clients existants et de n'en faire qu'un seul (GPU + CPU).
C'est vraiment top de ce coté là
David_L
Le mardi 22 décembre 2009 à 10:19:47
#2
Inscrit
le vendredi 13 septembre 02
-
25259
commentaires
Oui enfin faudra surtout que la façon de coder s'harmonise d'un constructeur à l'autre, pour éviter ce genre de péripéties...
Y a que AMD comme constructeur non ?
En tout cas OpenCL vaincra et Nvidia dans le CUCUDADA
En tout cas OpenCL vaincra et Nvidia dans le CUCUDADA
David_L
Le mardi 22 décembre 2009 à 10:29:11
#4
Inscrit
le vendredi 13 septembre 02
-
25259
commentaires
NVIDIA gère déjà OpenCL de manière native dans ses pilotes. Comme déjà dit 50x, le fait qu'ils proposent C for CUDA ne les empeche pas de supporter plutôt activement OpenCL (basé d'ailleurs en majorité sur C for CUDA).
NVIDIA gère déjà OpenCL de manière native dans ses pilotes. Comme déjà dit 50x, le fait qu'ils proposent C for CUDA ne les empeche pas de supporter plutôt activement OpenCL (basé d'ailleurs en majorité sur C for CUDA).
Certes mais il me semblait avoir compris avec tes tests que l'implémentation OpenCL de Nvidia était beaucoup moins performante que celle d'AMD en terme de performances. Isn't it ?
Il n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.










