PoCL 7.2-RC1 est arrivée le 7 août avec quelque chose de plus intéressant qu'un changement de numéro. La version candidate revendique la conformité officielle OpenCL 3.0 pour son périphérique CPU sur RISC-V comme sur x86-64, validée contre la suite de tests de conformité du Khronos Group. C'est la différence entre une implémentation qui fonctionne à peu près et une implémentation mesurée contre la spécification par l'organisme qui l'a écrite. Pour qui construit du calcul sur cartes RISC-V, et il y en a davantage chaque trimestre, cela signifie que le calcul portable sur cette architecture a cessé d'être une promesse. Nous avons regardé ce que couvre la conformité, ce qu'elle ne couvre pas, et sur quelles cartes les tests ont réellement tourné.
The short answer
PoCL 7.2-RC1 est arrivée le 7 août avec la conformité officielle OpenCL 3.0 pour son périphérique CPU sur RISC-V et sur x86-64, validée contre l'étiquette v2026-03-25-00 de la suite de tests de conformité Khronos. Les tests ont tourné sur les cartes RISC-V Star64 et Milk-V Jupiter et sur un AMD Ryzen 9 9900X. Le pilote CPU a gagné sept extensions, dont le produit scalaire entier et la taille de groupe de travail suggérée, les variables de portée programme sont réactivées, et le support LLVM atteint désormais la version 23 pour le backend CPU.
Quiconque a tenté de faire du calcul sur une carte RISC-V a rencontré le même mur, et ce n'est jamais le silicium. La puce va bien. Ce qui manque, c'est la couche au-dessus, ces runtimes et ces bibliothèques que toutes les autres architectures tiennent pour acquis, et la réponse habituelle était que quelque chose compile techniquement et que personne n'a vérifié à quel point c'est juste. PoCL 7.2-RC1 raye une ligne de cette liste.
Ce que signifie la conformité, et pourquoi ce n'est pas une formalité
Portable Computing Language est une implémentation open source d'OpenCL dont la particularité est de ne pas exiger de GPU. Elle compile les noyaux OpenCL via LLVM et les exécute sur les cœurs du processeur, et par des backends supplémentaires elle vise aussi les GPU NVIDIA via libCUDA, les GPU Intel via Level Zero et des périphériques distants.
La revendication de 7.2-RC1 est la conformité officielle OpenCL 3.0 du périphérique CPU sur RISC-V et x86-64, validée contre la suite de tests Khronos à l'étiquette v2026-03-25-00. Il vaut la peine d'être précis sur ce que cela apporte, parce que le mot conformité est employé de façon élastique.
La suite de tests vérifie que l'API se comporte comme spécifié, que le langage de noyaux compile ce qu'il doit compiler, et surtout que les résultats numériques restent dans les bornes d'erreur imposées par la spécification. Ce dernier point est celui que l'on sous-estime. Une implémentation subtilement fausse dans les derniers bits d'une fonction transcendante passera tous les tests que vous écrirez, puis divergera discrètement de la référence au fil d'un long calcul. Les tests de conformité sont conçus pour trouver exactement cela, et les résultats sont soumis et examinés plutôt qu'autodéclarés, ce qui rend l'affirmation vérifiable là où « nous implémentons OpenCL 3.0 » ne l'est pas.
Ce que la conformité ne signifie pas, c'est la vitesse. Rien dans la suite ne mesure le débit. Une implémentation conforme calcule la bonne réponse, avec la bonne marge d'erreur, et ne dit strictement rien du temps que cela a pris. Vu les cartes concernées, la distinction compte ici plus que d'habitude.
La partie RISC-V, lue attentivement
Le matériel est le détail qui rend l'ensemble crédible. La validation a tourné sur une Star64 et une Milk-V Jupiter, deux ordinateurs monocartes que l'on peut acheter, plus un AMD Ryzen 9 9900X pour x86-64. Les revendications de conformité sont parfois établies contre des simulateurs ou des modèles de référence où le comportement est plus facile à maîtriser, donc tester sur des cartes commercialisées signifie que le résultat reflète de vrais systèmes RISC-V, y compris les parties optionnelles de l'architecture qui varient d'une implémentation à l'autre.
Vient maintenant la réserve la plus importante, parce que c'est celle qui risque le plus d'être mal lue. Il s'agit de la conformité du périphérique CPU. PoCL compile vos noyaux et les exécute sur les cœurs du processeur hôte, et le RISC-V de l'annonce désigne l'architecture de cet hôte, pas un processeur graphique. Il n'y a pas d'histoire de GPU RISC-V ici.
Ce que vous obtenez à la place est un chemin portable et vérifié pour exécuter du code OpenCL sur du matériel RISC-V, ce qui sert dans deux situations concrètes. La première est le développement : écrire et valider des noyaux sur une machine RISC-V sans qu'un accélérateur y soit rattaché. La seconde est l'embarqué et le déploiement en périphérie, où le processeur est la seule ressource de calcul disponible et où l'intérêt d'OpenCL est de disposer d'un modèle de programmation parallèle de données à la sémantique correcte plutôt que d'un multithreading écrit à la main. Ni l'une ni l'autre n'est de l'accélération GPU, et les deux sont du vrai travail.
Les extensions qui méritent l'attention
Sept extensions ont rejoint le pilote CPU : cl_khr_extended_bit_ops, cl_khr_device_uuid, cl_khr_suggested_local_work_size, cl_khr_integer_dot_product, cl_khr_kernel_clock, cl_khr_spirv_linkonce_odr et cl_khr_spirv_no_integer_wrap_decoration. Deux d'entre elles changent ce que l'on ressent en écrivant du code contre ce runtime.
Le produit scalaire entier est la primitive qui se trouve sous l'inférence quantifiée. Si vous faites de l'arithmétique sur huit bits, et sur une cible sans accélérateur c'est très probablement le cas, l'alternative consiste à reconstruire la même opération à partir de multiplications et d'additions dans le code du noyau en espérant que le compilateur reconnaisse le motif. L'exposer comme extension permet au runtime de la faire correspondre à ce que le matériel fournit réellement.
La taille de groupe de travail suggérée est plus modeste et plus immédiatement satisfaisante. Choisir une taille de groupe a longtemps voulu dire deviner, mesurer, ou coder en dur un nombre qui était le bon sur la machine de développement. Cette extension permet au runtime d'indiquer une valeur sensée pour le noyau et le périphérique qu'il a devant lui. Sur un projet qui vise plusieurs architectures, cela supprime une étape de réglage qui de toute façon ne se généralisait pas.
Le reste de la version relève de l'entretien qui garde un projet en vie : variables de portée programme réactivées, support LLVM étendu à la version 22 pour les backends CUDA et Level Zero et aux versions 22 et 23 pour le périphérique CPU, et exigence minimale relevée à LLVM 18. Abandonner les vieilles versions de LLVM est la façon dont un projet bâti sur LLVM évite de se noyer dans du code de compatibilité, et 18 est un plancher raisonnable en 2026.
Pour décider quoi en faire, le partage est simple. Si vous travaillez sur du calcul RISC-V, installez la RC et faites tourner vos propres noyaux dessus, parce que RISC-V est la surface la plus récente de cette version et donc celle qui compte le moins de testeurs indépendants. Les rapports de bugs issus de charges réelles valent en ce moment plus que tout le reste pour le projet. Si vous livrez quelque chose, attendez la 7.2 finale. Le résultat de conformité ne sera pas retiré entre la RC et la publication, donc attendre ne coûte rien.
Sources et pour aller plus loin
- PoCL 7.2-RC1 apporte la conformité officielle OpenCL 3.0 sur processeurs RISC-V et x86_64, Phoronix, 7 août 2026
- Publications PoCL sur GitHub, dont les notes de version 7.2-RC1
- Site du projet PoCL, portablecl.org
- Suite de tests de conformité OpenCL du Khronos Group
- La spécification OpenCL 3.0, Khronos Group
- PoCL 7.0 publiée avec la conformité officielle OpenCL 3.0 sur processeurs x86_64, Phoronix
Questions fréquentes
Que garantit réellement la conformité OpenCL ?
Qu'une implémentation a passé la suite de tests de conformité OpenCL du Khronos Group, un vaste ensemble de tests qui éprouve la surface d'API, le langage de noyaux et les exigences de précision numérique de la spécification. PoCL 7.2-RC1 a été validée contre l'étiquette CTS v2026-03-25-00. La garantie porte sur la justesse et la portabilité plutôt que sur la performance : une implémentation conforme calcule ce que la spécification dit qu'elle doit calculer, les résultats en virgule flottante restent dans les bornes d'erreur imposées, et les appels d'API se comportent comme documentés. Rien dans la conformité ne dit que l'implémentation est rapide. Ce que cela apporte en pratique, c'est la possibilité d'arrêter d'écrire du code défensif contre les particularités d'un runtime donné, ce qui représente l'essentiel du coût réel de l'arrivée sur une nouvelle plateforme. C'est aussi une affirmation vérifiable, puisque les soumissions de conformité sont examinées et non autodéclarées, ce qui la distingue d'un projet qui affirme simplement implémenter une norme.
Sur quel matériel RISC-V les tests ont-ils été faits ?
Deux cartes, la Star64 et la Milk-V Jupiter, des ordinateurs monocartes disponibles dans le commerce plutôt que des simulateurs ou du silicium interne. Côté x86-64, le périphérique CPU a été validé sur un AMD Ryzen 9 9900X. Ce choix de matériel mérite d'être noté, parce que les revendications de conformité sont parfois établies contre des émulateurs ou des modèles de référence où le comportement est plus facile à maîtriser. Tester sur des cartes commercialisées signifie que le résultat reflète ce que fait un vrai système RISC-V, y compris les parties optionnelles de l'architecture qui varient d'une implémentation à l'autre. Cela cadre aussi correctement les attentes. Ce sont des processeurs modestes, donc le résultat de conformité vous dit que vos noyaux produiront des réponses justes, pas qu'ils les produiront vite.
Cela veut-il dire qu'OpenCL tourne sur des GPU RISC-V ?
Non, et c'est la lecture erronée la plus fréquente. La conformité concerne le périphérique CPU, c'est-à-dire que PoCL compile vos noyaux OpenCL et les exécute sur les cœurs du processeur hôte. La mention RISC-V désigne l'architecture processeur de la machine, pas un processeur graphique. PoCL vise bien des accélérateurs par d'autres backends, les GPU NVIDIA via libCUDA et les GPU Intel via Level Zero, et il avait obtenu la conformité Level Zero en même temps que la conformité CPU x86-64 dès la version 7.0. Mais sur une carte RISC-V aujourd'hui, PoCL vous donne une façon correcte et portable d'exécuter du code OpenCL sur le processeur. C'est réellement utile pour le développement et pour l'embarqué, et ce n'est pas de l'accélération GPU.
Qu'est-ce qui change dans 7.2 en dehors de la conformité ?
Le pilote CPU a gagné sept extensions : cl_khr_extended_bit_ops, cl_khr_device_uuid, cl_khr_suggested_local_work_size, cl_khr_integer_dot_product, cl_khr_kernel_clock, cl_khr_spirv_linkonce_odr et cl_khr_spirv_no_integer_wrap_decoration. Deux d'entre elles comptent davantage que les autres pour le travail courant. Le produit scalaire entier est la primitive qui se trouve sous l'inférence quantifiée, donc l'exposer plutôt que de l'émuler dans le code du noyau fait la différence entre raisonnable et pénible pour qui manipule de l'arithmétique basse précision. La taille de groupe de travail suggérée permet au runtime de vous indiquer une valeur sensée au lieu de vous laisser deviner ou mesurer, ce qui supprime une étape de réglage réellement agaçante. La prise en charge des variables de portée programme a également été réactivée, et le support LLVM a avancé : jusqu'à LLVM 22 pour les backends CUDA et Level Zero, LLVM 22 et 23 pour le périphérique CPU, avec un minimum relevé à LLVM 18.
Faut-il utiliser une version candidate ?
Pour évaluer oui, en production non, réponse ordinaire qui s'applique ici. Une RC existe pour que des gens la fassent tourner sur des configurations dont les développeurs ne disposent pas, et un projet qui prend en charge autant d'architectures et de versions de LLVM en a réellement besoin. Si vous travaillez sur du calcul RISC-V, tester cette RC et signaler ce qui casse est la chose la plus utile que vous puissiez faire, parce que RISC-V est la surface la plus récente de cette version et donc celle qui compte le moins de testeurs indépendants. Si vous livrez quelque chose, attendez la 7.2 finale. Le résultat de conformité ne sera pas retiré entre la RC et la publication, donc attendre ne coûte rien, et une RC est par définition une compilation que le projet n'a pas fini de valider.