chipStar permite compilar y ejecutar aplicaciones HIP y CUDA en plataformas que admiten SPIR-V como representación intermedia del dispositivo. Admite OpenCL y Level Zero como alternativas de tiempo de ejecución de bajo nivel.
Documentación de usuario
Documentación del desarrollador
Una lista de funciones (no) compatibles
chipStar se construyó inicialmente combinando el trabajo de creación de prototipos realizado en los (ahora obsoletos) proyectos HIPCL y HIPLZ.
Si desea citar chipStar en publicaciones académicas, consulte el resumen del póster de HIPCL cuando analice el backend de OpenCL y/o el documento de la conferencia HIPLZ cuando mencione el backend de Level Zero. Los desarrolladores principales de chipStar están escribiendo un artículo adecuado sobre el proyecto chipStar integrado, pero está en progreso.
El nombre chipStar proviene de c
uda y hip
y la palabra Star
, que significa asterisco, un comodín típico de shell, que denota la intención de hacer que "las aplicaciones CUDA y HIP se ejecuten en todas partes". El proyecto se llamaba anteriormente CHIP-SPV.
Las siguientes bibliotecas se han adaptado para funcionar en GPU Intel a través de MKL:
hipBLAS (se puede construir como parte de chipStar agregando -DCHIP_BUILD_HIPBLAS=ON
)
hipFTT (se puede construir como parte de chipStar agregando -DCHIP_BUILD_HIPFTT=ON
)
caderaSOLVER
caderaCUB
Las siguientes bibliotecas han sido portadas y deberían funcionar en cualquier plataforma:
rocRAND
rocPRIM
Si hay una biblioteca que necesita y que aún no es compatible, abra un problema que indique qué bibliotecas necesita y qué aplicación está intentando crear.
Hasta ahora, chipStar ha sido probado utilizando las siguientes aplicaciones:
libCEED Nuestra bifurcación incluye algunas soluciones.
GAMESS El código fuente no es público.
Puntos de referencia HeCBench CUDA.
La forma más rápida de comenzar es utilizar un contenedor Docker prediseñado. Consulte Docker README. Si desea crear todo usted mismo, puede seguir una guía detallada de introducción.
Si bien chipStar 1.1 ya se puede utilizar para ejecutar con éxito varias aplicaciones HPC de gran tamaño, todavía se encuentra en gran medida en modo de desarrollo con muchos problemas conocidos y características no implementadas. También hay optimizaciones conocidas de bajo rendimiento que aún están por realizarse. Sin embargo, consideramos que chipStar está listo para pruebas de mayor alcance y agradecemos las contribuciones de la comunidad en forma de informes de errores reproducibles y solicitudes de extracción de buena calidad.
Notas de la versión 1.1, 1.0 y 0.9.
Cmake>= 3.20.0
Clang y LLVM 17 (Clang/LLVM 15 y 16 también podrían funcionar)
Se puede instalar, por ejemplo, agregando el repositorio Debian/Ubuntu de LLVM e instalando los paquetes 'clang-17 llvm-17 clang-tools-17'.
Para obtener mejores resultados, instale Clang/LLVM desde una rama chipStar LLVM/Clang que tenga correcciones que aún no se encuentran en el proyecto ascendente de LLVM. Consulte a continuación una forma mediante script de crear e instalar las versiones parcheadas.
SPIRV-LLVM-Translator de una rama que coincida con la versión principal de LLVM: (por ejemplo, llvm_release_170 para LLVM 17), llvm-spirv.
Asegúrese de que el binario llvm-spirv integrado esté instalado en la misma ruta que el binario clang; de lo contrario, clang podría encontrar y utilizar un llvm-spirv diferente, lo que provocaría errores.
Se recomienda utilizar la bifurcación chipStar de LLVM que tiene algunos parches aún no actualizados. Para ello puedes utilizar un script incluido en el repositorio de chipStar:
./scripts/configure_llvm.sh Uso: ./configure_llvm.sh --version <versión> --install-dir <dir> --link-type static(predeterminado)/dynamic --only-necessary-spirv-exts <on|off> --binutils- ubicación del encabezado <ruta>--versión: LLVM versión 15, 16, 17, 18, 19 --install-dir: directorio de instalación --tipo de enlace: estático o dinámico (predeterminado: estático) --only-necessary-spirv-exts: activado o desactivado (predeterminado: desactivado) --binutils-header-location: ruta al encabezado de binutils (predeterminado: vacío) ./scripts/configure_llvm.sh --versión 17 --install-dir /opt/install/llvm/17.0cd llvm-project/llvm/build_17 hacer -j 16<sudo> hacer instalar
O puedes hacer los pasos manualmente:
git clone --profundidad 1 https://github.com/CHIP-SPV/llvm-project.git -b chipStar-llvm-17cd llvm-project/llvm/projects git clone --profundidad 1 https://github.com/CHIP-SPV/SPIRV-LLVM-Translator.git -b chipStar-llvm-17cd ../..# DLLVM_ENABLE_PROJECTS="clang;openmp" OpenMP es opcional pero muchos las aplicaciones lo usan# DLLVM_TARGETS_TO_BUILD Acelere la compilación construyendo solo el objetivo de host de CPU necesario# CMAKE_INSTALL_PREFIX Dónde instalar LLVMcmake -S llvm -B compilación -DCMAKE_BUILD_TYPE=Liberar -DLLVM_ENABLE_PROJECTS="clang;openmp" -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_INSTALL_PREFIX=$HOME/local/llvm-17 hacer -C construir -j8 todo instalar
Un controlador OpenCL 2.0 o 3.0 con al menos las siguientes características compatibles:
Memoria virtual compartida (SVM) de búfer de grano grueso
Entrada SPIR-V
Espacio de direcciones genérico
Variables de alcance del programa
Es posible que se necesiten más extensiones o funciones de OpenCL según la aplicación CUDA/HIP compilada. Por ejemplo, para admitir primitivas warp, el controlador OpenCL también debe admitir funciones de subgrupo adicionales, como reproducción aleatoria, votaciones y cl_intel_required_subgroup_size.
Intel Compute Runtime o oneAPI
Cargador de nivel cero oneAPI
Para interoperabilidad HIP-SYCL y HIP-MKL: oneAPI
Puede descargar y descomprimir el paquete fuente más reciente lanzado o clonar la rama de desarrollo a través de git. Nuestro objetivo es mantener estable la rama de desarrollo main
, pero puede tener problemas de estabilidad durante el ciclo de desarrollo.
Para clonar las fuentes de Github:
clon de git https://github.com/CHIP-SPV/chipStar.gitcd chipStar Actualización del submódulo git --init --recursive
mkdir build && cd build# LLVM_CONFIG_BIN es opcional si LLVM se puede encontrar en PATH o si no se utiliza un binario # de versión suficiente (por ejemplo, llvm-config-17)cmake .. -DLLVM_CONFIG_BIN=/ruta/a/llvm-config -DCMAKE_INSTALL_PREFIX=/ruta/a/instalar hacer que todos los build_tests instalen -j8
| También puedes compilar e instalar hipBLAS agregando -DCHIP_BUILD_HIPBLAS=ON
NOTA: Si no tiene libOpenCL.so (por ejemplo, del paquete ocl-icd-opencl-dev
), pero solo tiene instalado libOpenCL.so.1, CMake no lo encuentra y deshabilita el backend de OpenCL. Este problema describe una solución alternativa.
Para compilar chipStar para usarlo con una GPU ARM Mali G52, siga estos pasos:
construir LLVM y SPIRV-LLVM-Translator como se describe arriba
compilar chipStar con la opción -DCHIP_MALI_GPU_WORKAROUNDS=ON cmake
Existen algunas limitaciones: los núcleos que utilizan tipo doble no funcionarán y es posible que los núcleos que utilicen subgrupos no funcionen.
Tenga en cuenta que chipStar se basa en la implementación patentada de OpenCL proporcionada por ARM. Hemos logrado compilar y ejecutar chipStar con éxito con un dispositivo Odroid N2, usando Ubuntu 22.04.2 LTS, con la versión del controlador OpenCL 3.0 v1.r40p0-01eac0.
Para construir chipStar para usarlo con una GPU PowerVR, se pueden seguir los pasos predeterminados. Se ha aplicado una solución alternativa automática a un problema en la implementación de OpenCL de PowerVR.
Existen algunas limitaciones: los kernels que usan tipo doble no funcionarán, los kernels que usan subgrupos pueden no funcionar, también puede encontrarse con errores inesperados de OpenCL como CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST y otros problemas.
Tenga en cuenta que chipStar se basa en la implementación patentada de OpenCL proporcionada por Imagination Technologies. Hemos logrado compilar y ejecutar chipStar con éxito con un dispositivo VisionFive2, utilizando la imagen Debian preconstruida 202403 de VisionFive2, versión del controlador 1.19. Otros SBC pueden requerir soluciones adicionales.
Hay un script check.py
que se puede utilizar para ejecutar pruebas unitarias y que filtra las pruebas fallidas conocidas para diferentes plataformas. Su uso es el siguiente.
BUILD_DIR={ruta al directorio de compilación. Asegúrese de que se haya creado el objetivo build_tests} BACKEND={opencl/nivel0} ^ Qué backend/controlador/plataforma desea probar: "opencl" = tiempo de ejecución Intel OpenCL, "level0" = tiempo de ejecución Intel LevelZero DEVICE={cpu,igpu,dgpu,pocl} # Qué tipo de dispositivo probar.^ Esto selecciona las listas de aprobación de prueba esperadas. 'igpu' es una iGPU Intel Iris Xe, 'dgpu' una dGPU Intel reciente típica, como la serie Data Center GPU Max o Arc.export CHIP_PLATFORM=N # Si hay varias plataformas OpenCL presentes en el sistema, selecciona cuál usar .Siempre puedes verificar qué dispositivo está utilizando chipStar de la siguiente manera: CHIP_LOGLEVEL=info ./build/hipInfo
python3 $SOURCE_DIR/scripts/check.py $BUILD_DIR $DEVICE $BACKEND
Consulte la documentación del usuario para obtener instrucciones sobre cómo utilizar el chipStar instalado para crear programas CUDA/HIP.
CHIP_BE=<opencl/level0> # Selecciona el backend a usar. Si tanto el nivel cero como OpenCL están disponibles, el nivel cero se usa de forma predeterminadaCHIP_PLATFORM=<N> # Si hay varias plataformas presentes en el sistema, selecciona cuál usar. El valor predeterminado es 0CHIP_DEVICE=<N> # Si hay varios dispositivos presentes en el sistema, selecciona cuál usar. El valor predeterminado es 0CHIP_DEVICE_TYPE=<gpu/cpu/accel/fpga> o vacío # Selecciona qué tipo de dispositivo usar. El valor predeterminado es vacío.CHIP_LOGLEVEL=<trace/debug/info/warn/err/crit> # Establece el nivel de registro. Si se compila en RELEASE, solo están disponibles err/critCHIP_DUMP_SPIRV=<ON/OFF(predeterminado)> # Vuelca el código SPIR-V generado en un archivoCHIP_JIT_FLAGS=<flags> # Indicadores JIT adicionalesCHIP_L0_COLLECT_EVENTS_TIMEOUT=<N(30s predeterminado)> # Tiempo de espera en segundos para recolectar el Nivel Cero eventsCHIP_L0_EVENT_TIMEOUT=<N(0 predeterminado) # Tiempo de espera en segundos para cuánto tiempo debe esperar el Nivel Cero en un evento antes de que se agote el tiempoCHIP_SKIP_UNINIT=<ON/OFF(predeterminado)> # Si está habilitado, omite la desinicialización de los objetos backend de chipStar al finalizar el programaCHIP_MODULE_CACHE_DIR=/ ruta/al/deseado/dir # Módulo/directorio de caché del programa. El valor predeterminado es $HOME/.cache/chipStar; si no desea el almacenamiento en caché, configúrelo en una cadena vacía, es decir, exporte CHIP_MODULE_CACHE_DIR=
Ejemplo:
╭─pvelesko@cupcake ~╰─$ clinfo -l Plataforma #0: Gráficos Intel(R) OpenCL `-- Dispositivo #0: Gráficos Intel(R) Arc(TM) A380Plataforma #1: Gráficos Intel(R) OpenCL `-- Dispositivo #0: Gráficos Intel(R) UHD 770
En base a estos valores, si queremos ejecutar OpenCL iGPU:
exportar CHIP_BE=openclexport CHIP_PLATFORM=1exportar CHIP_DEVICE=0
NOTA: Level Zero no tiene un equivalente clinfo. Normalmente, si tiene más de un dispositivo Level Zero, solo habrá una plataforma, así que configure CHIP_PLATFORM=0 y luego CHIP_DEVICE en el dispositivo que desea usar. *Puedes comprobar el nombre del dispositivo ejecutando una muestra que imprima el nombre, como build/samples/0_MatrixMultiply/MatrixMultiply
Esto ocurre a menudo cuando la última versión de GCC instalada no incluye libstdc++, y Clang++ de forma predeterminada elige la última encontrada de todos modos y termina sin poder vincular los programas de C++. El problema se discute aquí.
El problema se puede resolver definiendo un archivo de configuración de Clang++ que fuerce al GCC a hacer lo que queremos. Ejemplo:
echo --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 > ~/local/llvm-17/bin/x86_64-unknown-linux-gnu-clang++.cfg
Al ejecutar las pruebas en dispositivos OpenCL que no admiten flotaciones de doble precisión, habrá varias pruebas que generarán errores.
Podría ser posible habilitar la emulación de software de flotantes de doble precisión para iGPU Intel configurando dos variables de entorno para hacer que los núcleos que usan dobles funcionen pero con la mayor sobrecarga de la emulación de software:
exportar IGC_EnableDPEmulation=1exportar OverrideDefaultFP64Settings=1
Si su dispositivo no admite la emulación, puede omitir estas pruebas proporcionando la opción -DSKIP_TESTS_WITH_DOUBLES=ON
en el momento de configurar cmake.