CK_BUILD_JIT_LIB issue

[jinz2014]

CK_BUILD_JIT_LIB seems a required option for building migraphx (shown below). However, the variable seems removed in your main library. Must I switch to a branch of your library for building migraphx ? Thanks for your comment and suggestion.

CMake Error at composable_kernel-install/lib/cmake/composable_kernel/composable_kernelConfig.cmake:24 (include):
  include could not find requested file:

    /path/to/composable_kernel-install/lib/cmake/composable_kernel/composable_kerneljit_libraryTargets.cmake
Call Stack (most recent call first):
  src/targets/gpu/CMakeLists.txt:36 (find_package)


CMake Error at src/targets/gpu/CMakeLists.txt:36 (find_package):
  Found package configuration file:

    /path/to/composable_kernel-install/lib/cmake/composable_kernel/composable_kernelConfig.cmake

  but it set composable_kernel_FOUND to FALSE so package "composable_kernel"
  is considered to be NOT FOUND.  Reason given by package:

  Unsupported component: jit_library

[Madouura]

Getting the same issue on 5.7.0

[tpkessler]

I'm running into the same issue with ROCm 6.0.0. Migraphx skips the composable kernel integration only if building on windows. There's four branches in this repo that contain jit and migx, likely a reference to migraphx. But it's unclear which branch to pick and compile and whether this conforms with miopen.

[tpkessler]

MIGraphX points to a commit in the migraphx branch of this repo. And this branch does have a CK_BUILD_JIT_LIB option. As the maintainer of the Arch Linux packages I'd like to avoid to package/compile CK twice. I would really appreciate some input from the devs of the library.

[xuantengh]

I'm wondering if there any updates about the JIT option for CK? Still cannot build MIOpen with ROCm 6.0.0 as for now.

Edit: currently the workaround is pass -DMIGRAPHX_ENABLE_GPU=ON -DMIGRAPHX_USE_COMPOSABLEKERNEL=OFF -DMIGRAPHX_ENABLE_MLIR=OFF to CMake when building MIGraphX.

[ppanchad-amd]

@jinz2014 Internal ticket has been created to investigate this issue. Thanks!

[schung-amd]

Hi all, I was able to reproduce this issue. Following the instructions to build migraphx with cmake at https://github.com/ROCm/AMDMIGraphX, I saw the same error while running the command CXX=/opt/rocm/llvm/bin/clang++ cmake .. -DGPU_TARGETS=$(/opt/rocm/bin/rocminfo | grep -o -m1 'gfx.*').

On the systems you're experiencing this on, did you already have composable_kernel installed? In addition, was this on a clean install, or did you install some of the required packages outside of using rbuild prepare -d depend as instructed by the readme at https://github.com/ROCm/AMDMIGraphX? On my repro, cmake was unable to locate protobuf and pybind11 even after installing the dependencies with rbuild, and I had to install these externally before cmake was able to progress far enough to emit the composable_kernel error.

What I suspect is happening here is that the dependencies are not being built in a way that cmake can find them, and cmake is pulling in the existing composable_kernel install on my system which is not the specific commit that is required. By passing -DCMAKE_TOOLCHAIN_FILE=../depend/cget/cget.cmake to the cmake command, cmake was able to locate the dependencies where they were installed by rbuild, and I was able to build with cmake without issue. This flag is present when the rbuild instructions invoke cmake, and I'm reaching out to the internal team to see why there's a discrepancy in the documented install processes.

I will also inquire about the duplicate composable_kernel requirement for systems which already have composable_kernel installed but not the specific version migraphx is looking for, to see if we can avoid needing to package/compile twice.

[schung-amd]

I've reached out to the MIGraphX team, and we do currently rely on the specific commit of composable_kernel being pulled in, as it has features that were not added into the main branch. We are currently working on a solution to make MIGraphX compatible with the tip of composable_kernel, so this issue should be resolved in the future, but for now this commit is necessary. This update should also fix the cmake failure being observed, but for now the workarounds @xuantengh or myself have provided can be used.