COMPTOIR
  
register

×

Une API pour les gouverner tous... ou pas

Les spécifications d'OpenCL 3.0 sont officielles !
Une API pour les gouverner tous... ou pas

SI vous souhaitez effectuer un calcul rapidement sur une puce autre que votre CPU — cas dans lequel il est question de calcul dit déporté —, une des solutions (libre) les plus répandues est OpenCL. Au début très proche de l’API CUDA de NVIDIA permettant d’exécuter du code non graphique sur les cartes graphiques — le terme utilisé est alors GPGPU —, le projet a gagné en ampleur pour dorénavant couvrir n’importe quel accélérateur, des GPU aux FPGA en passant par les accélérateurs de machine learning ou encore des ASICs spécialisés, pour peu que le vendeur ait fourni les bibliothèques compatibles.

 

En effet, tout comme Vulkan, OpenCL est une API, c’est-à-dire une définition du format à respecter et des fonctionnalités à fournir, mais ne fournit pas une implémentation du bousin. Pour cela, les constructeurs et partenaires doivent travailler, en collaboration avec le groupe Khronos qui chapeaute tout, à la réalisation de bibliothèques ou de pilotes compatibles... mais cela dépasse la portée de l’annonce du jour !

 

Une API pour les gouverner tous... ou pas [cliquer pour agrandir]

Si vous souhaitez croiser les API, Khronos et ses partenaires y ont pensé : ce devrait être possible

 

La dernière version de cette API bas niveau était, hier encore, la 2.2, mais la maison-mère a depuis dévoilée le premier jet préliminaire pour la mouture 3.0. Au menu : une rétrocompatibilité partielle avec les fonctionnalités précédentes, toutes au-delà de la 1.2 (non incluse) devenant optionnelles... mais les programmes pourront s’assurer de leur prise en charge par une simple requête, laissant ainsi la majorité du code inchangée. L’idée réside sur le constat qu’OpenCL 1.2 est le minimum requis pour les industriels, mais que les fonctionnalités introduites dans les moutures suivantes, monolithiques, sont trop peu flexibles par rapport à la demande, d’où leur découpage en optionnelles. Pour une mise à jour simple à la fois du côté des programmeurs et des intégrateurs, le but devrait être réussi. Parmi les autres changements, citons les extensions DMA asynchrones permettant aux accélérateurs le supportant d’accéder directement à la RAM sans bloquer le flot d’exécution du programme ; ainsi que la scission d’OpenCL C++, qui se nomme désormais C++ for OpenCL.

 

Au niveau des applications, l’API ratisse large, mais le grand public devrait surtout en profiter via l’IoT ou la domotique, car l’IA est l’application ayant le vent en poupe actuellement la plus friande d’accélérateurs dédiés. Néanmoins, cela ne risque pas de transcender l’expérience utilisateur, au vu de la couche bas niveau concernée !

 

khronos group

Un poil avant ?

GIGABYTE sort un nouveau clavier mécanique, le AORUS K1

Un peu plus tard ...

Des cartes B460 au look très manga chez MAXSUN

Les 5 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un médecin des ragots en Île-de-France, le Mardi 28 Avril 2020 à 16h31  
par Scrabble le Lundi 27 Avril 2020 à 16h52
C'est Blender qui utilise OpenCL pour le rendering sur carte graphique AMD, mais malheureusement, il y a des gros problèmes de fiabilité pour l'instant. AMD n'a pas l'air pressé de les résoudre.
AMD était déjà intervenu sur le code source de Luxrender. Blender semblait vouloir s'en inspirer (du moins ils ont progressé à ce moment là ).

Il y a une très bon logiciel de rendu sous OpenCL, payant : Indigo. La preuve que c'est possible.
par Darth Moule, le Mardi 28 Avril 2020 à 08h27  
par Nicolas D. le Mardi 28 Avril 2020 à 08h14
Oui et non, le code source est libre sous Linux, et si le bug est au niveau de l'implémentation OpenCL de Blender, effectivement ce n'est pas du problème d'AMD... en théorie ; puisque, en pratique, NVIDIA ne se gêne pas d'"aider" des studio pour implémenter ses propres technos (RTX et DLSS en tête de ligne). Mais sur des projets libres, ça....
oui je te rejoins sur ce point. C'est l'éternel débat entre le libre et laisser la commu se dépatouiller, ou le propriétaire et forcer un écosystème.
(Sinon les actions de Nvidia sont quand même très orientées sur les titres AAA pour pousser à acheter ses RTX. Je ne pense pas que Blender ou un autre logiciel libre apporterait une grosse clientèle à AMD :tear
par Nicolas D., le Mardi 28 Avril 2020 à 08h14  
par Darth Moule le Lundi 27 Avril 2020 à 21h58
OpenCL/Blender = libres et n'ont rien à voir avec AMD. Je ne pense pas que ça soit à AMD de faire quelque chose, à moins peut être de rendre un peu plus libre le code de leur pilotes.
Oui et non, le code source est libre sous Linux, et si le bug est au niveau de l'implémentation OpenCL de Blender, effectivement ce n'est pas du problème d'AMD... en théorie ; puisque, en pratique, NVIDIA ne se gêne pas d'"aider" des studio pour implémenter ses propres technos (RTX et DLSS en tête de ligne). Mais sur des projets libres, ça....
par Darth Moule, le Lundi 27 Avril 2020 à 21h58  
Pas mal, c'est toujours agréable de voir que des grands groupes entendent ou prennent en compte les retour utilisateur pour le développement de leur produits.
par Scrabble le Lundi 27 Avril 2020 à 16h52
C'est Blender qui utilise OpenCL pour le rendering sur carte graphique AMD, mais malheureusement, il y a des gros problèmes de fiabilité pour l'instant. AMD n'a pas l'air pressé de les résoudre.
OpenCL/Blender = libres et n'ont rien à voir avec AMD. Je ne pense pas que ça soit à AMD de faire quelque chose, à moins peut être de rendre un peu plus libre le code de leur pilotes.
par Scrabble, le Lundi 27 Avril 2020 à 16h52  
C'est Blender qui utilise OpenCL pour le rendering sur carte graphique AMD, mais malheureusement, il y a des gros problèmes de fiabilité pour l'instant. AMD n'a pas l'air pressé de les résoudre.