chipStar
v1.2.1
chipStar permet de compiler et d'exécuter des applications HIP et CUDA sur des plates-formes prenant en charge SPIR-V comme représentation intermédiaire de l'appareil. Il prend en charge OpenCL et Level Zero comme alternatives d'exécution de bas niveau.
Documentation utilisateur
Documentation du développeur
Une liste des fonctionnalités (non) prises en charge
chipStar a été initialement construit en combinant le travail de prototypage effectué dans les projets (maintenant obsolètes) HIPCL et HIPLZ.
Si vous souhaitez citer chipStar dans des publications universitaires, veuillez vous référer au résumé de l'affiche HIPCL lorsque vous discutez du backend OpenCL et/ou au document de conférence HIPLZ lorsque vous mentionnez le backend Level Zero. Les principaux développeurs de chipStar écrivent un article approprié sur le projet chipStar intégré, mais celui-ci est en cours.
Le nom chipStar vient de c et hip et du mot Star qui signifie astérisque, un caractère générique typique du shell, dénotant l'intention de faire fonctionner "les applications CUDA et HIP partout". Le projet s'appelait auparavant CHIP-SPV.
Les bibliothèques suivantes ont été portées pour fonctionner sur les GPU Intel via MKL :
hipBLAS (Peut être construit dans le cadre de chipStar en ajoutant -DCHIP_BUILD_HIPBLAS=ON )
hipFTT (Peut être construit dans le cadre de chipStar en ajoutant -DCHIP_BUILD_HIPFTT=ON )
hipSOLVER
hipCUB
Les bibliothèques suivantes ont été portées et devraient fonctionner sur n'importe quelle plateforme :
rocRAND
rocPRIM
Si vous avez besoin d'une bibliothèque qui n'est pas encore prise en charge, veuillez ouvrir un ticket indiquant les bibliothèques dont vous avez besoin et l'application que vous essayez de créer.
chipStar a jusqu'à présent été testé avec les applications suivantes :
libCEED Notre fork inclut quelques solutions de contournement.
Le code source de GAMESS n'est pas public.
Benchmarks HeCBench CUDA.
Le moyen le plus rapide de commencer consiste à utiliser un conteneur Docker prédéfini. Veuillez vous référer au Docker README. Si vous souhaitez tout construire vous-même, vous pouvez suivre un guide détaillé de mise en route.
Bien que chipStar 1.1 puisse déjà être utilisé pour exécuter avec succès diverses grandes applications HPC, il est encore fortement en mode développement avec de nombreux problèmes connus et fonctionnalités non implémentées. Il existe également des optimisations peu performantes qui restent à réaliser. Cependant, nous considérons chipStar prêt pour des tests à plus grande échelle et apprécions les contributions de la communauté sous la forme de rapports de bogues reproductibles et de demandes d'extraction de bonne qualité.
Notes de version pour 1.1, 1.0 et 0.9.
Cmake >= 3.20.0
Clang et LLVM 17 (Clang/LLVM 15 et 16 peuvent également fonctionner)
Peut être installé, par exemple, en ajoutant le référentiel Debian/Ubuntu de LLVM et en installant les packages 'clang-17 llvm-17 clang-tools-17'.
Pour de meilleurs résultats, installez Clang/LLVM à partir d'une branche chipStar LLVM/Clang qui contient des correctifs qui ne sont pas encore dans le projet LLVM en amont. Voir ci-dessous pour une manière scriptée de créer et d'installer les versions corrigées.
SPIRV-LLVM-Translator depuis une branche correspondant à la version majeure de LLVM : (par exemple llvm_release_170 pour LLVM 17) , llvm-spirv.
Assurez-vous que le binaire llvm-spirv construit est installé dans le même chemin que le binaire clang, sinon clang pourrait trouver et utiliser un llvm-spirv différent, entraînant des erreurs.
Il est recommandé d'utiliser le fork chipStar de LLVM qui contient quelques correctifs non encore mis en amont. Pour cela vous pouvez utiliser un script inclus dans le dépôt chipStar :
./scripts/configure_llvm.sh Utilisation : ./configure_llvm.sh --version <version> --install-dir <dir> --link-type static(default)/dynamic --only-necessary-spirv-exts <on|off> --binutils- emplacement-en-tête <chemin>--version : LLVM versions 15, 16, 17, 18, 19 --install-dir : répertoire d'installation --link-type : statique ou dynamique (par défaut : statique) --only-necessary-spirv-exts : activé ou désactivé (par défaut : désactivé) --binutils-header-location : chemin d'accès à l'en-tête binutils (par défaut : vide) ./scripts/configure_llvm.sh --version 17 --install-dir /opt/install/llvm/17.0cd llvm-project/llvm/build_17 make -j 16<sudo> make install
Ou vous pouvez effectuer les étapes manuellement :
git clone --profondeur 1 https://github.com/CHIP-SPV/llvm-project.git -b chipStar-llvm-17cd llvm-project/llvm/projects git clone --degree 1 https://github.com/CHIP-SPV/SPIRV-LLVM-Translator.git -b chipStar-llvm-17cd ../..# DLLVM_ENABLE_PROJECTS="clang;openmp" OpenMP est facultatif mais de nombreux les applications l'utilisent# DLLVM_TARGETS_TO_BUILD Accélérez la compilation en créant uniquement la cible hôte CPU nécessaire# CMAKE_INSTALL_PREFIX Où trouver installer LLVMcmake -S llvm -B build -DCMAKE_BUILD_TYPE=Libérer -DLLVM_ENABLE_PROJECTS="clang;openmp" -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_INSTALL_PREFIX=$HOME/local/llvm-17 make -C build -j8 all install
Un pilote OpenCL 2.0 ou 3.0 avec au moins les fonctionnalités suivantes prises en charge :
Mémoire virtuelle partagée (SVM) à tampon grossier
Entrée SPIR-V
Espace d'adressage générique
Variables de portée du programme
D'autres extensions ou fonctionnalités OpenCL peuvent être nécessaires en fonction de l'application CUDA/HIP compilée. Par exemple, pour prendre en charge les primitives warp, le pilote OpenCL doit également prendre en charge des fonctionnalités de sous-groupe supplémentaires telles que les mélanges, les bulletins de vote et cl_intel_required_subgroup_size.
Intel Compute Runtime ou oneAPI
Chargeur de niveau zéro oneAPI
Pour l'interopérabilité HIP-SYCL et HIP-MKL : oneAPI
Vous pouvez télécharger et décompresser le dernier package source publié ou cloner la branche de développement via git. Nous visons à maintenir la branche de développement main stable, mais elle pourrait rencontrer des problèmes de stabilité pendant le cycle de développement.
Pour cloner les sources depuis Github :
clone git https://github.com/CHIP-SPV/chipStar.gitcd chipStar mise à jour du sous-module git --init --recursive
mkdir build && cd build# LLVM_CONFIG_BIN est facultatif si LLVM peut être trouvé dans PATH ou s'il n'utilise pas de binaire à version suffisante# (par exemple, llvm-config-17)cmake ..
-DLLVM_CONFIG_BIN=/chemin/vers/llvm-config
-DCMAKE_INSTALL_PREFIX=/chemin/vers/installer
faire en sorte que tous les build_tests installent -j8 | Vous pouvez également compiler et installer hipBLAS en ajoutant -DCHIP_BUILD_HIPBLAS=ON
REMARQUE : si vous n'avez pas libOpenCL.so (par exemple à partir du package ocl-icd-opencl-dev ), mais uniquement libOpenCL.so.1 installé, CMake ne parvient pas à le trouver et désactive le backend OpenCL. Ce problème décrit une solution de contournement.
Pour créer chipStar à utiliser avec un GPU ARM Mali G52, procédez comme suit :
construire LLVM et SPIRV-LLVM-Translator comme décrit ci-dessus
construire chipStar avec l'option -DCHIP_MALI_GPU_WORKAROUNDS=ON cmake
Il existe certaines limitations : les noyaux utilisant un double type ne fonctionneront pas et les noyaux utilisant des sous-groupes peuvent ne pas fonctionner.
Notez que chipStar s'appuie sur l'implémentation propriétaire OpenCL fournie par ARM. Nous avons réussi à compiler et exécuter chipStar avec un périphérique Odroid N2, en utilisant Ubuntu 22.04.2 LTS, avec la version du pilote OpenCL 3.0 v1.r40p0-01eac0.
Pour créer chipStar à utiliser avec un GPU PowerVR, les étapes par défaut peuvent être suivies. Une solution de contournement automatique est appliquée pour un problème dans l'implémentation OpenCL de PowerVR.
Il existe certaines limitations : les noyaux utilisant un double type ne fonctionneront pas, les noyaux utilisant des sous-groupes peuvent ne pas fonctionner, vous pouvez également rencontrer des erreurs OpenCL inattendues comme CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST et d'autres problèmes.
Notez que chipStar s'appuie sur l'implémentation propriétaire OpenCL fournie par Imagination Technologies. Nous avons réussi à compiler et à exécuter chipStar avec un périphérique VisionFive2, en utilisant l'image Debian 202403 pré-construite de VisionFive2, version du pilote 1.19. D'autres SBC peuvent nécessiter des solutions de contournement supplémentaires.
Il existe un script check.py qui peut être utilisé pour exécuter des tests unitaires et qui filtre les tests défaillants connus pour différentes plates-formes. Son utilisation est la suivante.
BUILD_DIR={chemin vers le répertoire de construction. Assurez-vous que la cible build_tests a été construite}
BACKEND={opencl/level0}
^ Quel backend/pilote/plate-forme vous souhaitez tester : "opencl" = Runtime Intel OpenCL, "level0" = Runtime Intel LevelZero
DEVICE={cpu,igpu,dgpu,pocl} # Quel type de périphérique tester.^ Ceci sélectionne les listes de réussite de test attendues. 'igpu' est un iGPU Intel Iris Xe, 'dgpu' un dGPU Intel récent typique tel que la série Data Center GPU Max ou un Arc.export CHIP_PLATFORM=N # S'il existe plusieurs plates-formes OpenCL présentes sur le système, sélectionne celle à utiliser .Vous pouvez toujours vérifier quel appareil est utilisé par chipStar en :
CHIP_LOGLEVEL=info ./build/hipInfo python3 $SOURCE_DIR/scripts/check.py $BUILD_DIR $DEVICE $BACKEND
Veuillez vous référer à la documentation utilisateur pour obtenir des instructions sur la façon d'utiliser le chipStar installé pour créer des programmes CUDA/HIP.
CHIP_BE=<opencl/level0> # Sélectionne le backend à utiliser. Si Level Zero et OpenCL sont disponibles, Level Zero est utilisé par défautCHIP_PLATFORM=<N> # Si plusieurs plates-formes sont présentes sur le système, sélectionne celle à utiliser. La valeur par défaut est 0CHIP_DEVICE=<N> # Si plusieurs périphériques sont présents sur le système, sélectionne celui à utiliser. La valeur par défaut est 0CHIP_DEVICE_TYPE=<gpu/cpu/accel/fpga> ou vide # Sélectionne le type de périphérique à utiliser. La valeur par défaut est vide.CHIP_LOGLEVEL=<trace/debug/info/warn/err/crit> # Définit le niveau de journalisation. S'il est compilé dans RELEASE, seuls les err/crit sont disponiblesCHIP_DUMP_SPIRV=<ON/OFF(default)> # Vide le code SPIR-V généré dans un fichierCHIP_JIT_FLAGS=<flags> # Indicateurs JIT supplémentairesCHIP_L0_COLLECT_EVENTS_TIMEOUT=<N (30 s par défaut)> # Délai d'expiration dans secondes pour collecter le niveau zéro eventsCHIP_L0_EVENT_TIMEOUT=<N(0 par défaut) # Délai d'expiration en secondes pendant combien de temps Level Zero doit attendre un événement avant d'expirerCHIP_SKIP_UNINIT=<ON/OFF(default)> # Si activé, ignore la désinitialisation des objets backend de chipStar à la fin du programmeCHIP_MODULE_CACHE_DIR=/ chemin/vers/désiré/rép # Rép du cache du module/programme. La valeur par défaut est $HOME/.cache/chipStar, si la mise en cache n'est pas souhaitée, définie sur une chaîne vide, c'est-à-dire export CHIP_MODULE_CACHE_DIR=
Exemple:
╭─pvelesko@cupcake ~╰─$ clinfo -l Plate-forme n°0 : Intel(R) OpenCL Graphics `-- Périphérique n°0 : Intel(R) Arc(TM) A380 GraphicsPlate-forme n°1 : Intel(R) OpenCL Graphics `-- Périphérique n°0 : Intel(R) UHD Graphics 770
Sur la base de ces valeurs, si nous voulons exécuter sur OpenCL iGPU :
export CHIP_BE=openclexport CHIP_PLATFORM=1export CHIP_DEVICE=0
REMARQUE : Level Zero n'a pas d'équivalent clinfo. Normalement, si vous possédez plusieurs appareils de niveau zéro, il n'y aura qu'une seule plate-forme, alors définissez CHIP_PLATFORM=0 puis CHIP_DEVICE sur l'appareil que vous souhaitez utiliser. *Vous pouvez vérifier le nom du périphérique en exécutant un exemple qui imprime le nom tel que build/samples/0_MatrixMultiply/MatrixMultiply
Cela se produit souvent lorsque la dernière version installée de GCC n'inclut pas libstdc++ et que Clang++ choisit par défaut la dernière version trouvée, et finit par ne pas parvenir à lier les programmes C++. Le problème est discuté ici.
Le problème peut être résolu en définissant un fichier de configuration Clang++ qui force le GCC à faire ce que nous voulons. Exemple:
echo --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 > ~/local/llvm-17/bin/x86_64-unknown-linux-gnu-clang++.cfg
Lors de l'exécution des tests sur des appareils OpenCL qui ne prennent pas en charge les flotteurs double précision, plusieurs tests généreront des erreurs.
Il pourrait être possible d'activer l'émulation logicielle de flotteurs double précision pour les iGPU Intel en définissant deux variables d'environnement pour faire fonctionner les noyaux utilisant des doubles, mais avec la surcharge majeure de l'émulation logicielle :
export IGC_EnableDPEmulation=1export OverrideDefaultFP64Settings=1
Si votre appareil ne prend pas en charge l'émulation, vous pouvez ignorer ces tests en fournissant l'option -DSKIP_TESTS_WITH_DOUBLES=ON au moment de la configuration de cmake.
