Le souci d'aller toujours de l'avant.

Celui aussi de passer à autre chose alors que ce qui devrait être n'est pas totalement fonctionnel...

Après en entreprise mieux vaut utiliser CentOS/RHEL!
De toi pour CentOS/RHEL, si ta un stagiaire à mon avis c'est pas perso ou alors j'ai pas deviné la bonne solution.

Sinon c'était pour les dev sous linux...
VINDICATORs wrote:De toi pour CentOS/RHEL, si ta un stagiaire à mon avis c'est pas perso ou alors j'ai pas deviné la bonne solution.
Effectivement, c'est dans le cadre du boulot. J'avais espoir qu'avec Fedora j'aurai des paquets plus récents que sous centos et que ça fonctionnerait mieux, mais comme je n'ai pas réussi à faire fonctionner l'opencl correctement, je change de fusil d'épaule.
Celui aussi de passer à autre chose alors que ce qui devrait être n'est pas totalement fonctionnel...
Sinon c'était pour les dev sous linux...
Oui, c'est malheureux, mais le manque de bonnes volontés est présent dans tout le volontariat.
10 jours plus tard
Niveau professionnel il vaut quand même mieux privilégier la stabilité avec un support long (même si mettre plus de 10 ans avant de changer d'infra système c'est une belle bêtise pour rester correct...). De plus rien que le pilote "semi-libre/semi-propriétaire" AMD fonctionne pas mal sur RHEL/CentOS 7 et apporte l'OpenCL.

Il y a bon espoir d'avoir un support correct d'ici quelques temps, AMD apporte beaucoup de solutions qu'il faut intégrer maintenant.
Exemple : https://phoronix.com/scan.php?page=news_item&px=ROCm-1.6-Released
Bon j'ai testé de nouveau Blender 2.80alpha et l'OpenCL, il ne manque plus que le rendu et c'est tout bon.
[USER... Blender-2-80]$ CYCLES_OPENCL_SPLIT_KERNEL_TEST=1 ./blender
Read prefs: /home/sylvain/.config/blender/2.80/config/userpref.blend
ATTENTION: default value of option vblank_mode overridden by environment.
Warning! Unable to find a multisample pixel format that supports exactly 16 samples. Substituting one that uses 8 samples.
found bundled python: /home/sylvain/3D/Experimental/Blender-2-80/2.80/python
Device init success
Device init success
Compiling OpenCL program split
Kernel compilation of split finished in 1.84s.

Compiling OpenCL program base
Kernel compilation of base finished in 1.21s.

Compiling OpenCL program split
OpenCL build failed with error CL_BUILD_PROGRAM_FAILURE, errors in console.
OpenCL program split build output: source/kernel/kernel_compat_opencl.h:146:9: warning: 'NULL' macro redefined
/usr/include/clc/clctypes.h:89:9: note: previous definition is here
source/util/util_math_float3.h:377:32: warning: double precision constant requires cl_khr_fp64, casting to single precision
source/util/util_math_float3.h:378:32: warning: double precision constant requires cl_khr_fp64, casting to single precision
source/util/util_math_float3.h:379:32: warning: double precision constant requires cl_khr_fp64, casting to single precision
source/util/util_math.h:517:14: warning: implicit declaration of function 'lgamma' is invalid in C99
source/kernel/closure/bsdf_ashikhmin_shirley.h:136:52: warning: implicit declaration of function 'native_tan' is invalid in C99
source/kernel/kernel_compat_opencl.h:128:19: note: expanded from macro 'tanf'
<unknown>:0:0: in function kernel_ocl_path_trace_data_init void (i8 addrspace(1)*, %struct.KernelData addrspace(2)*, i8 addrspace(1)*, i32, i8 addrspace(1)*, i32 addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, <2 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32 addrspace(1)*, <4 x float> addrspace(1)*, <4 x i32> addrspace(1)*, i32 addrspace(1)*, <2 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32 addrspace(1)*, <4 x i32> addrspace(1)*, float addrspace(1)*, <4 x float> addrspace(1)*, <4 x i8> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, <2 x float> addrspace(1)*, <2 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x i32> addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, float addrspace(1)*, i32 addrspace(1)*, <4 x i8> addrspace(1)*, <4 x float> addrspace(1)*, i8 addrspace(1)*, float addrspace(1)*, <4 x i32> addrspace(1)*, i32, i32, i32, i32, i32, i32, i32, i32, i32 addrspace(1)*, i32, i8 addrspace(1)*, i32 addrspace(1)*, i32, float addrspace(1)*): unsupported call to function get_global_id

Device init success
Device init success
Compiling OpenCL program split
OpenCL build failed with error CL_BUILD_PROGRAM_FAILURE, errors in console.
OpenCL program split build output: source/kernel/kernel_compat_opencl.h:146:9: warning: 'NULL' macro redefined
/usr/include/clc/clctypes.h:89:9: note: previous definition is here
source/util/util_math_float3.h:377:32: warning: double precision constant requires cl_khr_fp64, casting to single precision
source/util/util_math_float3.h:378:32: warning: double precision constant requires cl_khr_fp64, casting to single precision
source/util/util_math_float3.h:379:32: warning: double precision constant requires cl_khr_fp64, casting to single precision
source/util/util_math.h:517:14: warning: implicit declaration of function 'lgamma' is invalid in C99
source/kernel/closure/bsdf_ashikhmin_shirley.h:136:52: warning: implicit declaration of function 'native_tan' is invalid in C99
source/kernel/kernel_compat_opencl.h:128:19: note: expanded from macro 'tanf'
<unknown>:0:0: in function kernel_ocl_path_trace_data_init void (i8 addrspace(1)*, %struct.KernelData addrspace(2)*, i8 addrspace(1)*, i32, i8 addrspace(1)*, i32 addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, <2 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32 addrspace(1)*, <4 x float> addrspace(1)*, <4 x i32> addrspace(1)*, i32 addrspace(1)*, <2 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, i32 addrspace(1)*, <4 x i32> addrspace(1)*, float addrspace(1)*, <4 x float> addrspace(1)*, <4 x i8> addrspace(1)*, <4 x float> addrspace(1)*, <4 x float> addrspace(1)*, <2 x float> addrspace(1)*, <2 x float> addrspace(1)*, <4 x float> addrspace(1)*, <4 x i32> addrspace(1)*, i32 addrspace(1)*, i32 addrspace(1)*, float addrspace(1)*, i32 addrspace(1)*, <4 x i8> addrspace(1)*, <4 x float> addrspace(1)*, i8 addrspace(1)*, float addrspace(1)*, <4 x i32> addrspace(1)*, i32, i32, i32, i32, i32, i32, i32, i32, i32 addrspace(1)*, i32, i8 addrspace(1)*, i32 addrspace(1)*, i32, float addrspace(1)*): unsupported call to function get_global_id

Erreur: Failed loading render kernel, see console for errors

Saved session recovery to '/tmp/quit.blend'

Blender quit
Sur Fedora 26 + LLVM/CLANG 4.0.x + Mesa 17.2git
De mon côté, avec CUDA c'est une horreur. 😐

Sur les Debian de mon ancien-ancien taf à Paris ça avait été une horreur d'installer le pilote propriétaire et de le faire fonctionner, puis ensuite d'installer le toolkit et le faire tourner.

Pire encore, mon dernier essai en date (dans le début de semaine) : pouvoir continuer à développer avec CUDA sur mon laptop une fois ce dernier entièrement passé sous Fedora. Sauf que bon, un PC portable Optimus avec BIOS du pauvre qui ne permet pas de désactiver l'IGP... ça rend le tout un peu hardcore quand on n'est pas expert Linux/drivers.
Autant faire fonctionner prime pour basculer entre IGP et GPU via la console (DRI_PRIME=1), ça n'a pas été très dur (merci pour cela aux contributeurs de la doc française), autant arriver à remplacer nouveau par le pilote propriétaire tout en ayant ce basculement je n'ai jamais réussi.

Résultat, j'ai un Windows 10 serré dans une partition un peu étroite et paramétré au mieux (le peu qu'on peut choisir) pour limiter le téléchargement de 36 mises à jour, avec un Visual Studio et le CUDA Toolkit, en dual boot avec Fedora.
Et ça fonctionne, et les perfs sont optimales. Et en 3D n'en parlons pas, c'est le jour et la nuit par rapport à nouveau sur ma 940M (qui s'avère en général moins bonne que l'IGP pour le coup à cause de ça).

Bref, tout ça c'est dommage, j'adore cette techno et le GPGPU en général. C'est un peu mon hobby de développer avec ça. 😉
A tu testé avec une CentOS 7 pour voir si un peut plus de calme dans les développements n'arrangerai pas ton souci tout en restant dans le petit monde de Fedora?

AMD ouvre du code pour l'OpenCL et les radeon, il faut juste le temps que ce soit intégré. Comme il y a le code source ouvert, ce sera plus simple à adapter et à prendre en compte.

Le souci de "nouveau" c'est qu'il faut toujours reprendre le code source pour que cela fonctionne. Sans aide de NVIDIA c'est le jour et la nuit. Au contraire d'AMD/Intel.

Et niveau pilote propriétaire regarde si ce n'est pas simplement wayland qui pose problème. Perso je n'ai pas eu autant de retour négatif avec CUDA...
Merci pour les suggestions !
Mais je ne sais pas si je vais m'essayer à une autre distribution, ni même à m'aventurer dans le paramétrage de ma Fedora actuelle.

En tout et pour tout j'ai dû faire une bonne dizaine de fois l'install sur ce laptop, j'ai expérimenté plein de trucs et installé tout plein de choses, au fur et à mesure j'ai noté les étapes réelles à suivre pour ce qui fonctionnait et abandonné le reste.
Ca m'a permis de faire une dernière install propre et prévue pour durer, avec juste les paquets et les modifs nécessaires 🙂

Sur mon SSD de 250 Go j'ai limité Windows à 60 Go. Au départ, il ne voulait pas lui-même me laisser redimensionner plus bas que 117 Go même après compactage (sous l'utilitaire des disques sous Windows), j'ai utilisé le Live-USB de Fedora pour lancer Gparted et je voyais visuellement qu'il tenait dans 40 Go en vrai, après installation de Visual studio pour 11 Go (Gparted, depuis le temps que je l'utilise, je le classe dans mon top 3 des applications trop bien qui ne doivent pas disparaitre sinon je sombre du côté obscur). Du coup je me suis dit 60 ce sera pas mal.
CentOS reste une base Fedora (la 7 est basé sur Fedora 19 + Fedora 20 si je me souvient bien), rien de particulier, sauf que par défaut tu te retrouve à devoir utiliser yum. DNF s'installe par le dépôt EPEL (paquets fourni par la communauté Fedora) , qui est aussi utilisé pour avoir des applications plus récentes.

60Go c'est le minimum pour MS windows, vu le bordel que c'est pour gérer les emplacements (programmes, données utilisateurs...). On y arrive, mais ce n'est pas vraiment le pied. Trop d'héritages d'un temps lointain fort fort lointain... Rien que leurs terminal de ligne de commande autant le prompt (cmd) que powershell c'est pas le pied comparé à ce que l'on trouve rien que de base sous GNU/Linux! Devant en plus me farcir une vielle version de ces terminaux tout les jours... Devoir taper sur la touche "entrée" 36x pour afficher quelques chose sur celui de powershell... NON PITIÉÉÉÉÉÉÉÉÉÉ ASSEZZZZZZZ!!!!... C'est pas tenable! Même un copier collez c'est la misère...

Enfin bref, à toi de voir tu peux aussi tester une installation sur clef usb histoire de voir si cela correspondrait pas mieux à tes besoins.

Bon comme j'ai du refaire mon système à cause d'une connerie dans /boot/efi (me suis trompé de répertoire pour supprimer un truc), j'en ai profité pour étendre l'espace de stockage par défaut de /boot et /boot/efi à 2Go chaque un. Du coup je vais pouvoir tester ROCM ( https://rocm.github.io/ ) et voir si il y a de l'espoir coté Radeon+ pilote libre.

A suivre.
Merci pour ces infos.

De mon côté, je suis passé à centos 7 sur le portable Intel i7-6500U + Intel HD Graphics 520 + AMD Radeon R7 M265.

J'ai réussi à faire fonctionner l'opencl sur le CPU et le GPU Intel, en installant le runtime CPU intel puis le pilote CPU/GPU. :idea: Si je ne fais pas l'installation dans cet ordre, le CPU n'est pas détecté, car le fichier /etc/OpenCL/vendors/intel64.icd n'est pas créé. Par contre, cela entraine que le CPU est détecté par les deux plateformes, mais il vaut mieux avoir un doublon que rien du tout, non ? 😉

Côté AMD, impossible de faire tourner le pilote graphique propriétaire, que ce soit catalyst 15.xx ou amdgpu-pro 17.10. :-? J'ai pour l'instant mis de côté cette carte graphique et j'essaye de faire tourner ArrayFire ou ViennaCL qui permettent de faire du calcul sur tous les cœurs de la machine.
un mois plus tard
Bon le pilote libre semble être bien plus rapide que le pilote propriétaire maintenant, mais au niveau de l'openCL...

Mais il y a de l'espoir, clpeak commence à en afficher un peut plus : 
Platform: Clover^@
  Device: AMD HAWAII (DRM 2.50.0 / 4.12.4-300.fc26.x86_64, LLVM 4.0.0)^@
    Driver version  : 17.3.0-devel^@ (Linux x64)
    Compute units   : 44
    Clock frequency : 1040 MHz
    Build Log: input.cl:34:127: error: call to 'mad' is ambiguous
input.cl:30:22: note: expanded from macro 'MAD_64'
input.cl:29:22: note: expanded from macro 'MAD_16'
input.cl:28:25: note: expanded from macro 'MAD_4'
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
input.cl:34:127: error: call to 'mad' is ambiguous
input.cl:30:22: note: expanded from macro 'MAD_64'
input.cl:29:22: note: expanded from macro 'MAD_16'
input.cl:28:43: note: expanded from macro 'MAD_4'
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
/usr/include/clc/math/mad.inc:1:39: note: candidate function
....
A suivre....
Merci VINDICATORs.

De mon côté, j'ai upgradé en F25 ma machine fixe avec trois GPU nvidia. Je suis en train de compiler llvm, clang et pocl, mais j'envisage de sauter par la fenêtre :-? . Pas sérieusement bien sûr.

Quand je vois ce genre de messages dans la doc, je suis un peu désespéré :
Configure & Build

CMake version 2.8.12 or higher is required.

The build+install is the usual CMake way:

cd <directory-with-pocl-sources>
mkdir build
cd build
cmake [-D<option>=<value> ...] ..
make && make install

To see the default detected values, run cmake .. without any options, it will produce a summary.
S'ensuit tout un paragraphe abscons sur les différentes options de cmake. Franchement, c'est peut-être compréhensible pour un PROGRAMMEUR, mais c'est du charabia pour un simple UTILISATEUR 🙁
Question bête, comment fait-on pour installer un paquet de la distribution suivante ?

Finalement, j'ai résolu une partie du problème: la version de clpeak dans le dépot f25 (0.1-11.20160207git1f90347.fc24) semble corrompue. En prenant la version rawhide (0.1-14.20170711git8edab23.fc27), ça marche.

Autre question: comment résoudre le problème de l'absence de version fournie par cuda dans sont libOpenCl.so ? En effet, sous clinfo et clpeak, j'ai un message d'erreur : 
# clinfo -l
clinfo: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by clinfo)
Platform #0: NVIDIA CUDA
 +-- Device #0: GeForce GTX 1060 6GB
 +-- Device #1: GeForce GTX 780
 `-- Device #2: GeForce GT 730
Platform #1: Portable Computing Language
 `-- Device #0: pthread-Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz
Perso je ne connois pas CUDA, donc "je"laisse les gens qui connaissent en parler.

Pour la paquet tu peux ajouter un fichier .repo dans /etc/yum.repo.d reprenant les liens vers les repo f26.

Mais bon si tu utilise le pilote propriétaire, je doute que tu ai besoin de tout cela.
GuL wrote: Autre question: comment résoudre le problème de l'absence de version fournie par cuda dans son libOpenCl.so ? En effet, sous clinfo et clpeak, j'ai un message d'erreur : 
# clinfo -l
clinfo: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by clinfo)
J'ai trouvé une explication intéressante:
It's that the binary wants some versions, but the library doesn't provide any information about its versions.
What does it mean in practice? Usually, exactly what is seen in this example — nothing, things just work ignoring versioning. Could things break? Of course, yes, so the other answers are correct in the fact that one should use the same libraries at runtime as the ones the binary was linked to at build time.
Traduction :
C'est que le binaire veut une version, mais la bibliothèque ne fourni aucune information de version.
Qu'est-ce que ça signifie en pratique ? En général, exactement ce qui est vu dans cet example — rien, cela marche en ignorant la version. Est-ce que ça peut cesser de fonctionner? Bien-sûr, et les autres réponses sont correctes quant au fait d'utiliser les mêmes bibliothèques à l'éxécution que celles avec lesquelles le binaire a été lié lors de la compilation.
Du coup, c'est juste un message d'insulte que l'on peut ignorer 8-)
Dsl j'avais oublié "je" avant "laisse". Sans le "je" ma phrase était agressive alors que ce n'était pas le but.
VINDICATORs wrote:Dsl j'avais oublié "je" avant "laisse". Sans le "je" ma phrase était agressive alors que ce n'était pas le but.
J'avais compris 😉
Bonne journée à toi