search

oneapi-src / oneMKL

oneAPI Math Kernel Library (oneMKL) Interfaces
Apache License 2.0
625 stars 160 forks source link

Using MKL::MKL to resolve the -fsycl issue with AdaptiveCpp fails. #567

Open lrpablo opened 2 months ago

lrpablo commented 2 months ago

Summary

Trying to link the examples when compiling with AdaptiveCpp using MKL::MKL as the target library fails.

Version

oneMKL version 0.2.0 githash = f4d6b1994eb110587ced0fc9777bac7550498874.

Environment

CMake Warning (dev) at cmake/FindcuBLAS.cmake:20 (find_package): Policy CMP0146 is not set: The FindCUDA module is removed. Run "cmake --help-policy CMP0146" for policy details. Use the cmake_policy command to set the policy and suppress this warning.

Call Stack (most recent call first): src/blas/backends/cublas/CMakeLists.txt:22 (find_package) This warning is for project developers. Use -Wno-dev to suppress it.

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE -- Found CUDA: /usr/local/cuda (found suitable version "12.5", minimum required is "10.0") -- Found cuBLAS: /usr/local/cuda/include -- ONEAPI_DEVICE_SELECTOR will be set to the following value(s): [opencl:cpu;cuda:gpu] for run-time dispatching examples -- Configuring done (0.7s) -- Generating done (0.0s) -- Build files have been written to: oneMKL/build

Steps to reproduce

Edit the file src/blas/backends/mklcpu/CMakeLists.txt

44c44,48
<   target_link_libraries(${LIB_OBJ} PUBLIC ONEMKL::SYCL::SYCL MKL::MKL_SYCL::BLAS)
---
>   if(ONEMKL_SYCL_IMPLEMENTATION STREQUAL "hipsycl")
>     target_link_libraries(${LIB_OBJ} PUBLIC ONEMKL::SYCL::SYCL MKL::MKL)
>   else()
>     target_link_libraries(${LIB_OBJ} PUBLIC ONEMKL::SYCL::SYCL MKL::MKL_SYCL::BLAS)
>   endif()
  cmake .. -DONEMKL_SYCL_IMPLEMENTATION=hipSYCL \
       -DhipSYCL_DIR=/home/pablo/usr/local/lib/cmake/hipSYCL \
       -DCMAKE_CXX_COMPILER=/home/pablo/usr/local/bin/acpp \
       -DENABLE_MKLGPU_BACKEND=False \
       -DENABLE_MKLCPU_BACKEND=True \
       -DENABLE_CUBLAS_BACKEND=True \
       -DENABLE_CURAND_BACKEND=True \
       -DBUILD_FUNCTIONAL_TESTS=False \
      -DBUILD_EXAMPLES=True \
      -DTARGET_DOMAINS="blas" \
      -DHIPSYCL_TARGETS=cuda:sm_75

Observed behavior

When using MKL::MKL as the target library in src/blas/backends/mklcpu/CMakeLists.txt, the issue with attempting to compile the examples with the -fsycl switch is resolved, but errors occurs when trying to link.

[ 90%] Linking CXX executable ../../../../bin/example_blas_gemm_usm_mklcpu_cublas
/usr/bin/ld: ../../../../lib/libonemkl_blas_mklcpu.so.0: undefined reference to `oneapi::mkl::blas::row_major::omatcopy(hipsycl::sycl::queue&, oneapi::mkl::transpose, long, long, std::complex<float>, hipsycl::sycl::buffer<std::complex<float>, 1, std::allocator<std::complex<float> > >&, long, hipsycl::sycl::buffer<std::complex<float>, 1, std::allocator<std::complex<float> > >&, long)'
...
...
...
/usr/bin/ld: ../../../../lib/libonemkl_blas_mklcpu.so.0: undefined reference to `oneapi::mkl::blas::column_major::trsm(hipsycl::sycl::queue&, oneapi::mkl::side, oneapi::mkl::uplo, oneapi::mkl::transpose, oneapi::mkl::diag, long, long, oneapi::mkl::value_or_pointer<float>, float const*, long, float*, long, std::vector<hipsycl::sycl::event, std::allocator<hipsycl::sycl::event> > const&)'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [examples/blas/compile_time_dispatching/level3/CMakeFiles/example_blas_gemm_usm_mklcpu_cublas.dir/build.make:105: bin/example_blas_gemm_usm_mklcpu_cublas] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:497: examples/blas/compile_time_dispatching/level3/CMakeFiles/example_blas_gemm_usm_mklcpu_cublas.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
Rbiessy commented 2 months ago

Note that the issue with AdaptiveCpp is a duplicate of https://github.com/oneapi-src/oneMKL/issues/478

The issue of undefined reference with the MKLCPU backend is surprising. It looks like you are trying a 2025.0 RC which we don't have access to. Do you know if this also fails with 2024.2?

lrpablo commented 2 months ago

Yes, it also fails with version 2024.2. And yes, it's related to issue #478, as the goal is to remove the attempt to compile with -fsycl, but in doing so, a new error occurs: the linking problem.