Les API de calcul GPU aujourd’hui

NVIDIA

Pionnier du marché, avec un toolkit mature. L’écosystème continue d’évoluer rapidement, et c’est encore plus vrai pour les API de plus haut niveau. Tous les GPU vendus par NVIDIA prennent en charge CUDA.

Le HPC SDK, autrefois appelé PGI et disponible uniquement sous Linux, a ajouté la prise en charge d’OpenACC, de la parallélisation standard C++ (stdpar) et d’OpenMP (bêta).

L’un des problèmes de licence du HPC SDK de NVIDIA est la clause suivante :

You shall strictly prohibit the further distribution of the Run-Time Files by users of an End-User Application

Comme les utilisateurs ne peuvent pas redistribuer une application en conservant les fichiers d’exécution nécessaires inclus dans l’app packagée, il peut devenir impossible de distribuer l’application elle-même. Ce problème ne concerne pas le CUDA SDK utilisé par la plupart des gens.

AMD

Le principal environnement de programmation GPGPU sur le matériel AMD est ROCm. En dehors de HIP, également détenu par AMD, les seules options officiellement prises en charge sont OpenMP et OpenACC.

Il y a ici plusieurs inconvénients évidents :

• Linux uniquement, ce qui l’exclut d’une grande partie du marché.

• Les binaires générés avec la toolchain ROCm ne ciblent pas un IR, mais sont liés au matériel. À l’arrivée d’une nouvelle génération, il faut recompiler les binaires.

• Pendant une période assez longue après leur sortie, la prise en charge du nouveau matériel est en pratique inexistante.

Ces défauts rendent son utilité sur desktop quasiment nulle et laissent OpenCL comme seule API fournie par le fournisseur pour le matériel GPU AMD.

Intel

oneAPI est pris en charge sur tous les GPU Intel récents, mais les performances élevées ne sont pas encore au rendez-vous. En dehors de Level Zero d’Intel, les API officiellement prises en charge sont OpenMP et SYCL.

Le Level Zero de oneAPI utilise SPIR-V comme IR, ce qui permet une prise en charge transparente du matériel à venir. Windows est également pris en charge.

Khronos

L’organisation fournit des standards industriels utilisables chez plusieurs fournisseurs.

La remise à plat connue sous le nom d’OpenCL 3.0 n’a pas encore eu beaucoup d’impact. L’association de SYCL et du calcul Vulkan pourrait être une meilleure voie, permettant d’utiliser un binaire unique chez plusieurs fournisseurs tout en offrant une bonne expérience développeur.

Prise en charge réelle d’OpenCL :

Aujourd’hui, NVIDIA propose OpenCL 1.2 avec prise en charge des extensions.

AMD fournit une implémentation OpenCL 1.2 exploitable, ainsi qu’une implémentation OpenCL 2.x extrêmement boguée (sans moyen correct de la déboguer).

Intel fournit une implémentation OpenCL 3.0 pour les GPU Intel.

OpenCL 1.2 est aussi pris en charge sur macOS, y compris Apple Silicon, mais la documentation est marquée comme obsolète.

Microsoft

C++ AMP semble mort. C’était une solution indépendante des fournisseurs et prise en charge par Visual C++, mais elle n’a pas été mise à jour depuis D3D11. D’anciennes versions de ROCm étaient également prises en charge.

Apple

Le calcul Metal ne vise que macOS/iOS/… Il est bien moins attractif dans le domaine du GPGPU, en particulier du point de vue des performances de calcul GPU.

[kbumsik]

Le GPGPU varie énormément selon les fournisseurs et les OS, donc j’aimerais qu’il y ait un jour une unification.

Cela dit, il n’y a aucune mention de DirectML sur Windows. Il prend en charge un large éventail de matériels et, récemment, ils l’ont même fait fonctionner sous WSL, ce qui avait éveillé mon intérêt.