Je développe en CUDA depuis presque le début, vers 2009-2010, et je me suis intéressé aussi à OpenCL, pour l'aspect portabilité en plus, mais j'ai fait face à beaucoup de problèmes de drivers, de performance, etc, et je suis finalement resté sur CUDA (je sais Nvidia pas bien, pas libre, etc, mais ça marche, il y a plein d'outils qui fonctionnent très bien, et c'est ce qui est installé sur les machines auxquelles j'ai accès).
Suite à mes déboires, j'avais recherché un peu d'autres expériences sur le sujet et je suis tombé sur cette présentation qui résume bien les problèmes avec OpenCL : l'API est libre, ok, les implantations peuvent l'être, ok, mais chaque implanteur est aussi libre d'interpréter certains aspects de la spec comme il l'entend, de ne supporter qu'une version de l'API (Nvidia reste en 1.2 il me semble) et évidemment d'introduire ses propres bugs. Donc la portabilité annoncée, c'est pas garantie.
Une erreur toute bête à mes débuts sur laquelle j'étais tombé entre Intel et Nvidia, je précise que c'est de ma faute, j'étais pressé : les fonctions OpenCL retournent un code erreur sous la forme d'un int : cl_int err = clMaFonctionOpenCL(...), et pour traiter l'erreur j'ai supposé que, comme d'habitude, 0 c'était ok, donc if( err ) {// je traite l'erreur}. Mais rien ne précise la valeur dans la spec, donc un des 2 vendeurs a choisi une autre valeur que 0 quand tout va bien donc il faut faire explicitement if( err != CL_SUCCESS ) {...}.
Ce n'est pas grand chose, mais ça ajoute à la verbosité d'OpenCL.
Heureusement SYCL est là pour résoudre tous ces problèmes... ou pas...
Personnellement, je ne comprends pas l'acharnement à faire vouloir mettre une API portable partout alors que pour avoir les performances il faut de toute façon réécrire des kernels optimisés pour presque chaque architecture.
# OpenCL, portabilité et performance en général
Posté par sjub . En réponse à la dépêche OpenCL sous Linux : l’état des pilotes AMD est désormais pire que ce qu’il était à l’époque de fglrx. Évalué à 6. Dernière modification le 01 février 2022 à 11:55.
Je développe en CUDA depuis presque le début, vers 2009-2010, et je me suis intéressé aussi à OpenCL, pour l'aspect portabilité en plus, mais j'ai fait face à beaucoup de problèmes de drivers, de performance, etc, et je suis finalement resté sur CUDA (je sais Nvidia pas bien, pas libre, etc, mais ça marche, il y a plein d'outils qui fonctionnent très bien, et c'est ce qui est installé sur les machines auxquelles j'ai accès).
Suite à mes déboires, j'avais recherché un peu d'autres expériences sur le sujet et je suis tombé sur cette présentation qui résume bien les problèmes avec OpenCL : l'API est libre, ok, les implantations peuvent l'être, ok, mais chaque implanteur est aussi libre d'interpréter certains aspects de la spec comme il l'entend, de ne supporter qu'une version de l'API (Nvidia reste en 1.2 il me semble) et évidemment d'introduire ses propres bugs. Donc la portabilité annoncée, c'est pas garantie.
Une erreur toute bête à mes débuts sur laquelle j'étais tombé entre Intel et Nvidia, je précise que c'est de ma faute, j'étais pressé : les fonctions OpenCL retournent un code erreur sous la forme d'un int : cl_int err = clMaFonctionOpenCL(...), et pour traiter l'erreur j'ai supposé que, comme d'habitude, 0 c'était ok, donc if( err ) {// je traite l'erreur}. Mais rien ne précise la valeur dans la spec, donc un des 2 vendeurs a choisi une autre valeur que 0 quand tout va bien donc il faut faire explicitement if( err != CL_SUCCESS ) {...}.
Ce n'est pas grand chose, mais ça ajoute à la verbosité d'OpenCL.
Heureusement SYCL est là pour résoudre tous ces problèmes... ou pas...
Personnellement, je ne comprends pas l'acharnement à faire vouloir mettre une API portable partout alors que pour avoir les performances il faut de toute façon réécrire des kernels optimisés pour presque chaque architecture.