Ordinateurs

OpenCL 3.0 démarre avec un énorme pas en arrière

Ce site peut gagner des commissions d’affiliation à partir des liens sur cette page. Conditions d’utilisation.

OpenCL, autrefois salué comme l’avenir de l’informatique GPGPU, a récemment disparu des projecteurs. La plupart des sociétés de PC qui l’ont soutenu ont trouvé des raisons de poursuivre d’autres objectifs : Apple a sa propre API Metal, Nvidia a le CUDA au succès phénoménal et auto-créé, et AMD s’est concentré sur Linux et sa solution RoCm. Intel semble être la seule entreprise à travailler sur ses pilotes et son support OpenCL de manière cohérente.

Malgré tout, la norme OpenCL 2.2, publiée en 2017, n’est pas encore prise en charge par n’importe quel fournisseur dans toute l’industrie informatique. Ce n’est pas bon signe lorsque vous ne trouvez pas une seule entreprise pour prendre en charge votre norme trois ans après sa publication, et le groupe Khronos adopte une approche radicale du développement d’OpenCL 3.0. Plus précisément, ils abandonnent OpenCL 2.0 et reviennent à un fork de développement OCL 1.2.

Pour être clair, le code et la capacité OCL 2.x ne seront pas supprimés de la norme, ils deviendront simplement un moyen facultatif de prendre en charge le matériel OCL. Toutes les fonctionnalités introduites jusqu’à OpenCL 2.2 resteront disponibles pour tout fournisseur souhaitant écrire un pilote pour les prendre en charge. La raison pour laquelle la nouvelle norme est basée sur OpenCL 1.2 est qu’il s’agit de la dernière version dont tout le monde convient qu’elle contient des fonctions absolument nécessaires pour prendre en charge l’ensemble des cas d’utilisation de la norme. L’accord est important dans ce cas car Khronos est un consortium composé de diverses organisations membres, mais il n’exerce aucun pouvoir propre.

Outre les fonctionnalités de base d’OCL 1.2, tout ce qui est introduit dans la norme dans OCL 2.x et 3.0 sera facultatif. Chaque fournisseur sera en mesure de prendre en charge des fonctionnalités spécifiques adaptées à son matériel, mais il n’y a pas de restrictions « taille unique » du type qui a conduit les fournisseurs à s’éloigner de la norme en premier lieu. Cette nouvelle approche est calquée sur la façon dont Khronos a déployé Vulkan, et OCL 3.0 sera facile à prendre en charge par les développeurs. Toutes les applications OpenCL 1.2 fonctionneront parfaitement sur un appareil OpenCL 3.0 et les applications OpenCL 2.x fonctionneront parfaitement sur les appareils OCL 3.0 tant que ces appareils prennent en charge les fonctionnalités utilisées par l’application. Si vous avez une application OCL 1.2 ou 2.x, vous n’avez pas à vous soucier de l’impact d’OCL 3.0 sur votre rétrocompatibilité.

Psssssst :  Examen du processeur Intel Core i9-10900K : Comet Lake peint une cible sur Matisse d'AMD

Ceux d’entre vous qui espéraient voir OpenCL C++ s’imposer, cependant… nous avons de mauvaises nouvelles. La langue est entièrement mise au rebut. Il sera remplacé par « C++ pour OpenCL », qui est similaire à OpenCL C++, mais distinct de celui-ci et exécuté sous les auspices d’un projet différent.

La grande nouveauté de la norme est la prise en charge de DMA asynchrone, qui permet aux transactions DMA de s’exécuter en même temps que les noyaux de calcul ou de manière synchrone avec d’autres transactions DMA.

Anandtech a plus de détails sur les fonctionnalités et capacités de bas niveau ajoutées à la norme si vous souhaitez en savoir plus sur le sujet. Il n’est pas clair que cette nouvelle version d’OpenCL fera une réelle différence pour l’industrie du PC, en particulier pour les utilisateurs de Windows. Malgré le fait que des applications comme Folding@Home et Blender utilisent OpenCL à diverses fins (Blender l’utilise pour le rendu Cycles sur les GPU AMD, par exemple), aucun des principaux fournisseurs ne semble mettre le langage au centre de ses plans futurs, bien que cela puisse changer une fois qu’Intel lancera la version centre de données de Xe.

Maintenant lis:

Bouton retour en haut de la page