chipStar
v1.2.1
chipStar permite compilar e executar aplicativos HIP e CUDA em plataformas que suportam SPIR-V como representação intermediária do dispositivo. Ele suporta OpenCL e Level Zero como alternativas de tempo de execução de baixo nível.
Documentação do usuário
Documentação do desenvolvedor
Uma lista de recursos (não) suportados
O chipStar foi inicialmente construído combinando o trabalho de prototipagem realizado nos projetos (agora obsoletos) HIPCL e HIPLZ.
Se você deseja citar o chipStar em publicações acadêmicas, consulte o resumo do pôster HIPCL ao discutir o backend OpenCL e/ou o artigo da conferência HIPLZ ao mencionar o backend Level Zero. Os principais desenvolvedores do chipStar estão escrevendo um artigo adequado sobre o projeto chipStar integrado, mas ele está em andamento.
O nome chipStar vem de c uda e hip e da palavra Star que significa asterisco, um curinga típico do shell, denotando a intenção de fazer "aplicativos CUDA e HIP rodarem em qualquer lugar". O projeto era anteriormente denominado CHIP-SPV.
As seguintes bibliotecas foram portadas para funcionar em GPUs Intel via MKL:
hipBLAS (pode ser construído como parte do chipStar adicionando -DCHIP_BUILD_HIPBLAS=ON )
hipFTT (pode ser construído como parte do chipStar adicionando -DCHIP_BUILD_HIPFTT=ON )
hipSOLVER
hipCUB
As seguintes bibliotecas foram portadas e devem funcionar em qualquer plataforma:
rocRAND
rocPRIM
Se houver uma biblioteca que você precisa e que ainda não é suportada, abra um problema informando quais bibliotecas você precisa e qual aplicativo você está tentando construir.
O chipStar foi testado até agora usando os seguintes aplicativos:
libCEED Nosso fork inclui algumas soluções alternativas.
O código fonte do GAMESS não é público.
Benchmarks CUDA do HeCBench.
A maneira mais rápida de começar é usar um contêiner Docker pré-construído. Consulte o README do Docker. Se quiser construir tudo sozinho, você pode seguir um guia detalhado de primeiros passos
Embora o chipStar 1.1 já possa ser usado para executar vários aplicativos HPC grandes com sucesso, ele ainda está em modo de desenvolvimento, com muitos problemas conhecidos e recursos não implementados. Existem também otimizações conhecidas de baixo desempenho que ainda precisam ser feitas. No entanto, consideramos o chipStar pronto para testes mais amplos e recebemos contribuições da comunidade na forma de relatórios de bugs reproduzíveis e solicitações pull de boa qualidade.
Notas de lançamento para 1.1, 1.0 e 0.9.
Cmake >= 3.20.0
Clang e LLVM 17 (Clang/LLVM 15 e 16 também podem funcionar)
Pode ser instalado, por exemplo, adicionando o repositório Debian/Ubuntu do LLVM e instalando os pacotes 'clang-17 llvm-17 clang-tools-17'.
Para obter os melhores resultados, instale o Clang/LLVM a partir de uma ramificação chipStar LLVM/Clang que possui correções que ainda não estão no projeto upstream do LLVM. Veja abaixo uma maneira de criar e instalar as versões corrigidas com script.
SPIRV-LLVM-Translator de uma ramificação correspondente à versão principal do LLVM: (por exemplo, llvm_release_170 para LLVM 17), llvm-spirv.
Certifique-se de que o binário llvm-spirv construído esteja instalado no mesmo caminho do binário clang, caso contrário, o clang poderá encontrar e usar um llvm-spirv diferente, causando erros.
É recomendado usar o fork chipStar do LLVM que possui alguns patches ainda não atualizados. Para isso você pode usar um script incluído no repositório chipStar:
./scripts/configure_llvm.sh Uso: ./configure_llvm.sh --version <versão> --install-dir <dir> --link-type static(default)/dynamic --only-necessary-spirv-exts <on|off> --binutils- localização do cabeçalho <caminho>--versão: LLVM versão 15, 16, 17, 18, 19 --install-dir: diretório de instalação --link-type: estático ou dinâmico (padrão: estático) --only-necessary-spirv-exts: ativado ou desativado (padrão: desativado) --binutils-header-location: caminho para o cabeçalho binutils (padrão: vazio) ./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 você pode executar as etapas manualmente:
git clone --profundidade 1 https://github.com/CHIP-SPV/llvm-project.git -b chipStar-llvm-17cd llvm-project/llvm/projects git clone --profundidade 1 https://github.com/CHIP-SPV/SPIRV-LLVM-Translator.git -b chipStar-llvm-17cd ../..# DLLVM_ENABLE_PROJECTS="clang;openmp" OpenMP é opcional, mas muitos aplicativos usam# DLLVM_TARGETS_TO_BUILD Acelere a compilação construindo apenas o destino de host da CPU necessário# CMAKE_INSTALL_PREFIX Onde instalar LLVMcmake -S llvm -B compilação -DCMAKE_BUILD_TYPE=Liberar -DLLVM_ENABLE_PROJECTS="clang;openmp" -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_INSTALL_PREFIX=$HOME/local/llvm-17 make -C build -j8 tudo instalado
Um driver OpenCL 2.0 ou 3.0 com pelo menos os seguintes recursos suportados:
Memória virtual compartilhada (SVM) com buffer de granulação grossa
Entrada SPIR-V
Espaço de endereço genérico
Variáveis de escopo do programa
Outras extensões ou recursos OpenCL podem ser necessários dependendo do aplicativo CUDA/HIP compilado. Por exemplo, para suportar warp-primitivos, o driver OpenCL deve suportar também recursos adicionais de subgrupo, como embaralhamento, cédulas e cl_intel_required_subgroup_size.
Intel Compute Runtime ou oneAPI
Carregador oneAPI de nível zero
Para interoperabilidade HIP-SYCL e HIP-MKL: oneAPI
Você pode baixar e descompactar o pacote fonte mais recente lançado ou clonar o branch de desenvolvimento via git. Nosso objetivo é manter estável o ramo de desenvolvimento main , mas ele pode ter problemas de estabilidade durante o ciclo de desenvolvimento.
Para clonar as fontes do Github:
clone git https://github.com/CHIP-SPV/chipStar.gitcd chipStar atualização do submódulo git --init --recursive
mkdir build && cd build# LLVM_CONFIG_BIN é opcional se o LLVM puder ser encontrado em PATH ou se não estiver usando um binário # com versão suficiente (por exemplo, llvm-config-17)cmake ..
-DLLVM_CONFIG_BIN=/caminho/para/llvm-config
-DCMAKE_INSTALL_PREFIX=/caminho/para/instalar
faça todos os build_tests instalarem -j8 | Você também pode compilar e instalar hipBLAS adicionando -DCHIP_BUILD_HIPBLAS=ON
NOTA: Se você não tiver o libOpenCL.so (por exemplo, do pacote ocl-icd-opencl-dev ), mas apenas o libOpenCL.so.1 instalado, o CMake não conseguirá encontrá-lo e desabilitará o backend do OpenCL. Este problema descreve uma solução alternativa.
Para construir o chipStar para uso com uma GPU ARM Mali G52, siga estas etapas:
construir LLVM e SPIRV-LLVM-Translator conforme descrito acima
construir chipStar com -DCHIP_MALI_GPU_WORKAROUNDS=ON opção cmake
Existem algumas limitações - kernels que usam tipo duplo não funcionarão e kernels que usam subgrupos podem não funcionar.
Observe que o chipStar depende da implementação proprietária do OpenCL fornecida pela ARM. Conseguimos compilar e executar o chipStar com um dispositivo Odroid N2, usando Ubuntu 22.04.2 LTS, com versão do driver OpenCL 3.0 v1.r40p0-01eac0.
Para construir o chipStar para uso com uma GPU PowerVR, as etapas padrão podem ser seguidas. Há uma solução alternativa automática aplicada para um problema na implementação do OpenCL do PowerVR.
Existem algumas limitações: kernels que usam tipo duplo não funcionarão, kernels que usam subgrupos podem não funcionar, você também pode encontrar erros OpenCL inesperados como CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST e outros problemas.
Observe que o chipStar depende da implementação proprietária do OpenCL fornecida pela Imagination Technologies. Conseguimos compilar e executar o chipStar com um dispositivo VisionFive2, usando a imagem Debian pré-construída 202403 do VisionFive2, versão do driver 1.19. Outros SBCs podem exigir soluções alternativas adicionais.
Existe um script check.py que pode ser usado para executar testes de unidade e que filtra testes com falhas conhecidas para diferentes plataformas. Seu uso é o seguinte.
BUILD_DIR={caminho para construir o diretório. Certifique-se de que o destino build_tests foi criado}
BACKEND={opencl/level0}
^ Qual backend/driver/plataforma você deseja testar:"opencl" = tempo de execução Intel OpenCL, "level0" = tempo de execução Intel LevelZero
DEVICE={cpu,igpu,dgpu,pocl} # Que tipo de dispositivo testar.^ Isso seleciona as listas de aprovação de teste esperadas. 'igpu' é um iGPU Intel Iris Xe, 'dgpu' um típico dGPU Intel recente, como a série Data Center GPU Max ou um Arc.export CHIP_PLATFORM=N # Se houver várias plataformas OpenCL presentes no sistema, selecione qual delas usar .Você sempre pode verificar qual dispositivo está sendo usado pelo chipStar:
CHIP_LOGLEVEL=info./build/hipInfo python3 $SOURCE_DIR/scripts/check.py $BUILD_DIR $DEVICE $BACKEND
Consulte a documentação do usuário para obter instruções sobre como usar o chipStar instalado para construir programas CUDA/HIP.
CHIP_BE=<opencl/level0> # Seleciona o backend a ser usado. Se o Nível Zero e o OpenCL estiverem disponíveis, o Nível Zero será usado por padrãoCHIP_PLATFORM=<N> # Se houver múltiplas plataformas presentes no sistema, selecione qual delas usar. O padrão é 0CHIP_DEVICE=<N> # Se houver vários dispositivos presentes no sistema, selecione qual deles usar. O padrão é 0CHIP_DEVICE_TYPE=<gpu/cpu/accel/fpga> ou vazio # Seleciona qual tipo de dispositivo usar. O padrão é vazio.CHIP_LOGLEVEL=<trace/debug/info/warn/err/crit> # Define o nível de log. Se compilado em RELEASE, apenas err/crit estão disponíveisCHIP_DUMP_SPIRV=<ON/OFF(default)> # Despeja o código SPIR-V gerado em um arquivoCHIP_JIT_FLAGS=<flags> # Sinalizadores JIT adicionaisCHIP_L0_COLLECT_EVENTS_TIMEOUT=<N(30s padrão)> # Tempo limite em segundos para coletar o Nível Zero eventsCHIP_L0_EVENT_TIMEOUT=<N(0 padrão) # Tempo limite em segundos para quanto tempo o Nível Zero deve esperar em um evento antes de atingir o tempo limiteCHIP_SKIP_UNINIT=<ON/OFF(default)> # Se habilitado, ignora a não inicialização dos objetos backend do chipStar no encerramento do programaCHIP_MODULE_CACHE_DIR=/ path/to/desired/dir # Diretório de cache do módulo/programa. O padrão é $HOME/.cache/chipStar, se o armazenamento em cache for indesejado, defina como uma string vazia, ou seja, export CHIP_MODULE_CACHE_DIR=
Exemplo:
╭─pvelesko@cupcake ~╰─$ clinfo -l Plataforma #0: Intel(R) OpenCL Graphics `-- Dispositivo #0: Intel(R) Arc(TM) A380 GraphicsPlataforma #1: Intel(R) OpenCL Graphics `-- Dispositivo #0: Intel(R) UHD Graphics 770
Com base nesses valores, se quisermos rodar em OpenCL iGPU:
exportar CHIP_BE=openclexport CHIP_PLATFORM=1exportar CHIP_DEVICE=0
NOTA: O Nível Zero não possui um equivalente em Clinfo. Normalmente se você tiver mais de um dispositivo Nível Zero, haverá apenas uma única plataforma, então defina CHIP_PLATFORM=0 e então CHIP_DEVICE para o dispositivo que você deseja usar. *Você pode verificar o nome do dispositivo executando um exemplo que imprime o nome, como build/samples/0_MatrixMultiply/MatrixMultiply
Isso ocorre frequentemente quando a versão mais recente do GCC instalada não inclui libstdc++, e o Clang++, por padrão, escolhe a versão mais recente encontrada, independentemente, e acaba falhando ao vincular programas C++. O problema é discutido aqui.
O problema pode ser resolvido definindo um arquivo de configuração Clang++ que força o GCC a fazer o que queremos. Exemplo:
echo --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 > ~/local/llvm-17/bin/x86_64-unknown-linux-gnu-clang++.cfg
Ao executar os testes em dispositivos OpenCL que não suportam flutuadores de precisão dupla, haverá vários testes que apresentarão erros.
Pode ser possível habilitar a emulação de software de flutuadores de precisão dupla para iGPUs Intel, definindo duas variáveis de ambiente para fazer os kernels usando duplos funcionarem, mas com a maior sobrecarga da emulação de software:
exportar IGC_EnableDPEmulation=1exportar OverrideDefaultFP64Settings=1
Se o seu dispositivo não suportar emulação, você pode pular esses testes fornecendo a opção -DSKIP_TESTS_WITH_DOUBLES=ON no momento da configuração do cmake.
