chipStar
v1.2.1
chipStar ermöglicht das Kompilieren und Ausführen von HIP- und CUDA-Anwendungen auf Plattformen, die SPIR-V als Gerätezwischendarstellung unterstützen. Es unterstützt OpenCL und Level Zero als Low-Level-Laufzeitalternativen.
Benutzerdokumentation
Entwicklerdokumentation
Eine Liste der (nicht) unterstützten Funktionen
chipStar wurde ursprünglich durch die Kombination der Prototyping-Arbeiten der (inzwischen veralteten) HIPCL- und HIPLZ-Projekte gebaut.
Wenn Sie chipStar in wissenschaftlichen Veröffentlichungen zitieren möchten, lesen Sie bitte die Zusammenfassung des HIPCL-Posters, wenn Sie das OpenCL-Backend diskutieren, und/oder das HIPLZ-Konferenzpapier, wenn Sie das Level-Zero-Backend erwähnen. Die Hauptentwickler von chipStar schreiben einen richtigen Artikel über das integrierte ChipStar-Projekt, dieser ist jedoch in Arbeit.
Der Name chipStar kommt von c uda und hip und dem Wort Star , was Sternchen bedeutet, ein typischer Shell-Platzhalter, der die Absicht bezeichnet, „CUDA- und HIP-Anwendungen überall laufen zu lassen“. Das Projekt hieß zuvor CHIP-SPV.
Die folgenden Bibliotheken wurden für die Arbeit auf Intel-GPUs über MKL portiert:
hipBLAS (Kann als Teil von chipStar erstellt werden, indem -DCHIP_BUILD_HIPBLAS=ON hinzugefügt wird)
hipFTT (Kann als Teil von chipStar erstellt werden, indem -DCHIP_BUILD_HIPFTT=ON hinzugefügt wird)
hipSOLVER
hipCUB
Die folgenden Bibliotheken wurden portiert und sollten auf jeder Plattform funktionieren:
rocRAND
rocPRIM
Wenn Sie eine Bibliothek benötigen, die noch nicht unterstützt wird, öffnen Sie bitte ein Problem und geben Sie an, welche Bibliotheken Sie benötigen und welche Anwendung Sie erstellen möchten.
chipStar wurde bisher mit folgenden Anwendungen getestet:
libCEED Unser Fork enthält einige Workarounds.
Der Quellcode von GAMESS ist nicht öffentlich.
HeCBench CUDA Benchmarks.
Der schnellste Einstieg ist die Verwendung eines vorgefertigten Docker-Containers. Bitte beachten Sie die Docker-README-Datei. Wenn Sie alles selbst erstellen möchten, können Sie einem ausführlichen Getting Started folgen
Obwohl chipStar 1.1 bereits für die erfolgreiche Ausführung verschiedener großer HPC-Anwendungen verwendet werden kann, befindet es sich immer noch stark im Entwicklungsmodus mit zahlreichen bekannten Problemen und nicht implementierten Funktionen. Es sind auch Optimierungen bei geringer Leistung bekannt, die noch durchgeführt werden müssen. Wir sind jedoch der Ansicht, dass chipStar für umfassendere Tests bereit ist und begrüßen Community-Beiträge in Form reproduzierbarer Fehlerberichte und qualitativ hochwertiger Pull-Requests.
Versionshinweise für 1.1, 1.0 und 0.9.
Cmake >= 3.20.0
Clang und LLVM 17 (Clang/LLVM 15 und 16 funktionieren möglicherweise auch)
Kann beispielsweise installiert werden, indem das Debian/Ubuntu-Repository der LLVM hinzugefügt und die Pakete „clang-17 llvm-17 clang-tools-17“ installiert werden.
Um die besten Ergebnisse zu erzielen, installieren Sie Clang/LLVM von einem chipStar LLVM/Clang-Zweig, der Fixes enthält, die noch nicht im LLVM-Upstream-Projekt enthalten sind. Unten finden Sie eine Skriptmethode zum Erstellen und Installieren der gepatchten Versionen.
SPIRV-LLVM-Translator aus einem Zweig, der der LLVM-Hauptversion entspricht: (z. B. llvm_release_170 für LLVM 17), llvm-spirv.
Stellen Sie sicher, dass die erstellte llvm-spirv-Binärdatei im selben Pfad wie die Clang-Binärdatei installiert ist, da Clang sonst möglicherweise eine andere llvm-spirv-Datei findet und verwendet, was zu Fehlern führt.
Es wird empfohlen, den chipStar-Zweig von LLVM zu verwenden, der über einige Patches verfügt, die noch nicht hochgeladen wurden. Hierzu können Sie ein im chipStar-Repository enthaltenes Skript verwenden:
./scripts/configure_llvm.sh Verwendung: ./configure_llvm.sh --version <version> --install-dir <dir> --link-type static(default)/dynamic --only-necessary-spirv-exts <on|off> --binutils- header-location <path>--version: LLVM-Version 15, 16, 17, 18, 19 --install-dir: Installationsverzeichnis --link-type: statisch oder dynamisch (Standard: statisch) --only-necessary-spirv-exts: ein oder aus (Standard: aus) --binutils-header-location: Pfad zum Binutils-Header (Standard: leer) ./scripts/configure_llvm.sh --version 17 --install-dir /opt/install/llvm/17.0cd llvm-project/llvm/build_17 make -j 16<sudo> make install
Oder Sie können die Schritte manuell ausführen:
git clone -- Depth 1 https://github.com/CHIP-SPV/llvm-project.git -b chipStar-llvm-17cd llvm-project/llvm/projects git clone -- Depth 1 https://github.com/CHIP-SPV/SPIRV-LLVM-Translator.git -b chipStar-llvm-17cd ../..# DLLVM_ENABLE_PROJECTS="clang;openmp" OpenMP ist optional, aber viele Apps verwenden es# DLLVM_TARGETS_TO_BUILD Beschleunigen Sie die Kompilierung, indem Sie nur das erforderliche CPU-Hostziel erstellen# CMAKE_INSTALL_PREFIX Wo soll LLVMcmake -S llvm -B build installiert werden? -DCMAKE_BUILD_TYPE=Freigeben -DLLVM_ENABLE_PROJECTS="clang;openmp" -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_INSTALL_PREFIX=$HOME/local/llvm-17 make -C build -j8 all install
Ein OpenCL 2.0- oder 3.0-Treiber mit mindestens den folgenden unterstützten Funktionen:
Grobkörniger gemeinsam genutzter virtueller Pufferspeicher (SVM)
SPIR-V-Eingang
Allgemeiner Adressraum
Programmbereichsvariablen
Abhängig von der kompilierten CUDA/HIP-Anwendung sind möglicherweise weitere OpenCL-Erweiterungen oder -Funktionen erforderlich. Um beispielsweise Warp-Primitive zu unterstützen, sollte der OpenCL-Treiber auch zusätzliche Untergruppenfunktionen wie Shuffles, Ballots und cl_intel_required_subgroup_size unterstützen.
Intel Compute Runtime oder oneAPI
oneAPI Level Zero Loader
Für HIP-SYCL- und HIP-MKL-Interoperabilität: oneAPI
Sie können das neueste veröffentlichte Quellpaket herunterladen und entpacken oder den Entwicklungszweig über Git klonen. Unser Ziel ist es, den main stabil zu halten, es kann jedoch während des Entwicklungszyklus zu Stabilitätsproblemen kommen.
So klonen Sie die Quellen von Github:
Git-Klon https://github.com/CHIP-SPV/chipStar.gitcd chipStar Git-Submodul-Update --init --recursive
mkdir build && cd build# LLVM_CONFIG_BIN ist optional, wenn LLVM im PATH gefunden werden kann oder wenn keine Versions-ausreichende# Binärdatei (z. B. llvm-config-17) cmake verwendet wird.
-DLLVM_CONFIG_BIN=/path/to/llvm-config
-DCMAKE_INSTALL_PREFIX=/path/to/install
Lassen Sie alle build_tests -j8 installieren | Sie können hipBLAS auch kompilieren und installieren, indem Sie -DCHIP_BUILD_HIPBLAS=ON hinzufügen
HINWEIS: Wenn Sie libOpenCL.so nicht haben (zum Beispiel aus dem Paket ocl-icd-opencl-dev ), sondern nur libOpenCL.so.1 installiert haben, kann CMake es nicht finden und deaktiviert das OpenCL-Backend. Dieses Problem beschreibt eine Problemumgehung.
Führen Sie die folgenden Schritte aus, um chipStar für die Verwendung mit einer ARM Mali G52-GPU zu erstellen:
Erstellen Sie LLVM und SPIRV-LLVM-Translator wie oben beschrieben
Erstellen Sie ChipStar mit der cmake-Option -DCHIP_MALI_GPU_WORKAROUNDS=ON
Es gibt einige Einschränkungen: Kernel, die den Doppeltyp verwenden, funktionieren nicht, und Kernel, die Untergruppen verwenden, funktionieren möglicherweise nicht.
Beachten Sie, dass ChipStar auf der proprietären OpenCL-Implementierung von ARM basiert. Es ist uns gelungen, chipStar mit einem Odroid N2-Gerät unter Verwendung von Ubuntu 22.04.2 LTS und der Treiberversion OpenCL 3.0 v1.r40p0-01eac0 erfolgreich zu kompilieren und auszuführen.
Um chipStar für die Verwendung mit einer PowerVR-GPU zu erstellen, können die Standardschritte befolgt werden. Für ein Problem in der OpenCL-Implementierung von PowerVR wird eine automatische Problemumgehung angewendet.
Es gibt einige Einschränkungen: Kernel, die den doppelten Typ verwenden, funktionieren nicht, Kernel, die Untergruppen verwenden, funktionieren möglicherweise nicht. Außerdem können unerwartete OpenCL-Fehler wie CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST und andere Probleme auftreten.
Beachten Sie, dass chipStar auf der proprietären OpenCL-Implementierung von Imagination Technologies basiert. Es ist uns gelungen, chipStar mit einem VisionFive2-Gerät zu kompilieren und auszuführen, wobei wir das vorgefertigte Debian-Image 202403 von VisionFive2, Treiberversion 1.19, verwendet haben. Andere SBCs erfordern möglicherweise zusätzliche Problemumgehungen.
Es gibt ein Skript check.py , mit dem Unit-Tests ausgeführt werden können und das bekannte fehlgeschlagene Tests für verschiedene Plattformen herausfiltert. Seine Verwendung ist wie folgt.
BUILD_DIR={Pfad zum Build-Verzeichnis. Stellen Sie sicher, dass das Ziel build_tests erstellt wurde}
BACKEND={opencl/level0}
^ Welches Backend/welcher Treiber/welche Plattform Sie testen möchten: „opencl“ = Intel OpenCL-Laufzeitumgebung, „level0“ = Intel LevelZero-Laufzeitumgebung
DEVICE={cpu,igpu,dgpu,pocl} # Welche Art von Gerät getestet werden soll.^ Dadurch werden die erwarteten Testdurchlauflisten ausgewählt. „igpu“ ist eine Intel Iris .Sie können jederzeit überprüfen, welches Gerät von chipStar verwendet wird, indem Sie:
CHIP_LOGLEVEL=info ./build/hipInfo python3 $SOURCE_DIR/scripts/check.py $BUILD_DIR $DEVICE $BACKEND
Anweisungen zur Verwendung des installierten chipStar zum Erstellen von CUDA/HIP-Programmen finden Sie in der Benutzerdokumentation.
CHIP_BE=<opencl/level0> # Wählt das zu verwendende Backend aus. Wenn sowohl Level Zero als auch OpenCL verfügbar sind, wird standardmäßig Level Zero verwendet. CHIP_PLATFORM=<N> # Wenn auf dem System mehrere Plattformen vorhanden sind, wird ausgewählt, welche verwendet werden soll. Der Standardwert ist 0CHIP_DEVICE=<N> # Wenn auf dem System mehrere Geräte vorhanden sind, wird ausgewählt, welches verwendet werden soll. Der Standardwert ist 0CHIP_DEVICE_TYPE=<gpu/cpu/accel/fpga> oder leer. # Wählt aus, welcher Gerätetyp verwendet werden soll. Der Standardwert ist empty.CHIP_LOGLEVEL=<trace/debug/info/warn/err/crit> # Legt die Protokollebene fest. Wenn in RELEASE kompiliert, sind nur err/crit verfügbarCHIP_DUMP_SPIRV=<ON/OFF(default)> # Speichert den generierten SPIR-V-Code in einer DateiCHIP_JIT_FLAGS=<flags> # Zusätzliche JIT-FlagsCHIP_L0_COLLECT_EVENTS_TIMEOUT=<N(30s default)> # Timeout in Sekunden für das Sammeln von Level Null eventsCHIP_L0_EVENT_TIMEOUT=<N(0 Standard) # Timeout in Sekunden, wie lange Level Zero auf ein Ereignis warten soll, bevor es abläuft. CHIP_SKIP_UNINIT=<ON/OFF(Standard)> # Wenn aktiviert, überspringt es die Nichtinitialisierung der Backend-Objekte von chipStar bei Programmbeendigung.CHIP_MODULE_CACHE_DIR=/ path/to/desired/dir # Modul-/Programm-Cache-Verzeichnis. Der Standardwert ist $HOME/.cache/chipStar. Wenn Caching unerwünscht ist, setzen Sie ihn auf eine leere Zeichenfolge, z. B. exportieren Sie CHIP_MODULE_CACHE_DIR=
Beispiel:
╭─pvelesko@cupcake ~╰─$ clinfo -l Plattform #0: Intel(R) OpenCL Graphics `-- Gerät #0: Intel(R) Arc(TM) A380 GraphicsPlattform #1: Intel(R) OpenCL Graphics `-- Gerät #0: Intel(R) UHD Graphics 770
Basierend auf diesen Werten, wenn wir auf OpenCL iGPU laufen wollen:
export CHIP_BE=openclexport CHIP_PLATFORM=1export CHIP_DEVICE=0
HINWEIS: Für Level Zero gibt es kein clinfo-Äquivalent. Wenn Sie mehr als ein Level-Zero-Gerät haben, gibt es normalerweise nur eine einzige Plattform. Stellen Sie daher CHIP_PLATFORM=0 und dann CHIP_DEVICE auf das Gerät ein, das Sie verwenden möchten. *Sie können den Namen des Geräts überprüfen, indem Sie ein Beispiel ausführen, das den Namen ausgibt, z. B. build/samples/0_MatrixMultiply/MatrixMultiply
Dies tritt häufig auf, wenn die neueste installierte GCC-Version libstdc++ nicht enthält und Clang++ standardmäßig trotzdem die zuletzt gefundene Version auswählt und am Ende die Verknüpfung von C++-Programmen fehlschlägt. Das Problem wird hier besprochen.
Das Problem kann gelöst werden, indem eine Clang++-Konfigurationsdatei definiert wird, die den GCC zu dem zwingt, was wir wollen. Beispiel:
echo --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 > ~/local/llvm-17/bin/x86_64-unknown-linux-gnu-clang++.cfg
Wenn Sie die Tests auf OpenCL-Geräten ausführen, die Gleitkommazahlen mit doppelter Genauigkeit nicht unterstützen, treten bei mehreren Tests Fehler auf.
Es könnte möglich sein, die Software-Emulation von Floats mit doppelter Genauigkeit für Intel iGPUs zu ermöglichen, indem zwei Umgebungsvariablen festgelegt werden, damit Kernel, die Doubles verwenden, funktionieren, allerdings mit dem größten Overhead der Software-Emulation:
export IGC_EnableDPEmulation=1export OverrideDefaultFP64Settings=1
Wenn Ihr Gerät die Emulation nicht unterstützt, können Sie diese Tests überspringen, indem Sie zum Zeitpunkt der cmake-Konfiguration die Option -DSKIP_TESTS_WITH_DOUBLES=ON bereitstellen.
