Closed eero-t closed 3 years ago
Same problem with the new "21.27.20266" release.
Have you build IGC with system llvm, or with llvm sources?
It's system LLVM from Ubuntu.
What about opencl-clang and SPIRV-LLVM-Translator? Have you built them or used from the system? If you built them yourself what method did you use? (In-tree build or Out-of-tree build)
Those are also from the system.
Same problem also with latest IGC (igc-1.0.8517) and compute-runtime (21.34.20767).
Compute-runtime (still) does not build with LLVM v10 (in Ubuntu 20.10) any more:
apt install clang-10 libopencl-clang-dev opencl-headers llvm-10-dev liblld-10-dev llvm-spirv libllvmspirvlib-dev
but it does build with LLVM v11 (in Ubuntu 21.04):
apt install clang-11 libopencl-clang-dev opencl-headers llvm-11-dev liblld-11-dev llvm-spirv libllvmspirvlib-dev
(Using -DIGC_OPTION__LLVM_PREFERRED_VERSION=11
instead of -DIGC_OPTION__LLVM_PREFERRED_VERSION=10
, with -DINSTALL_SPIRVDLL=0
option naturally still remaining with IGC. )
This is not Neo problem, but how opencl-clang library was compiled on Ubuntu, and I suppose the same is on FreeBSD. To workaround this issue you need to recompile opencl-clang and llvm-spriv-translator with llvm sources using In-tree method. You don't have to recompile IGC after opencl-clang/llvm-spirv-translator build. This is not specific to llvm10, but was observed in previous llvm versions. Similar issues were observed in another projects using llvm static libraries on Ubuntu.
This is not specific to llvm10, but was observed in previous llvm versions. Similar issues were observed in another projects using llvm static libraries on Ubuntu.
Any idea why it worked earlier with the same Ubuntu (20.10) version of LLVM v10, and still works with Ubuntu (21.04) LLVM v11?
As the issue is on compiler side, transferring it to IGC project.
This is not Neo problem, but how opencl-clang library was compiled on Ubuntu, and I suppose the same is on FreeBSD. To workaround this issue you need to recompile opencl-clang and llvm-spriv-translator with llvm sources using In-tree method.
With LLVM sources? But the whole point of this bug is using system libraries, to avoid compiling the world (faster builds, smaller binaries and memory usage when multiple things share the same libs, easier security updates etc).
Bugs for other projects with similar issues seem to be because they link multiple versions of LLVM, either different versions, or both dynamic & static versions. In my case there's only single LLVM version installed in the build container, but the LLVM dev packages brings in both dynamic & static libraries.
@JacekDanecki Are you saying that when being requested to use system versions of libraries, IGC / compute-runtime choose to use static libraries, whereas Debian/Ubuntu packages use dynamic libraries?
If yes, how things then work with Ubuntu (21.04) LLVM v11? Nothing in that respect should have changed, new Debian/Unbuntu packages have just dropped their last patches for these projects:
Or if you just mean that newer versions of opencl-clang & llvm spriv lib are needed, then that's compute-runtime bug of not checking versions of its dependencies...
Compute runtime doesn't use llvm directly, it loads IGC libraries. This is why I've moved this issue to IGC project. IGC and its dependencies can be compiled using different methods (with llvm sources, dynamic or static libraries), but for some reasons under Ubuntu there are problems with opencl-clang when it is compiled separately with system libraries. I've not observed such issues on another distributions. I understand you want to use system libraries for many reasons, so I've only provided workaround with compiling opencl-clang with llvm sources. Real fix should be provided by opencl-clang or IGC team. Compute runtime was tested with specific IGC version and its dependencies, and this list is provided in Neo release notes. Deb packages provided on Neo github have set specific gmmlib and IGC versions, as these are main Neo dependencies. opencl-clang and llvm-spirv versions used to build IGC with llvm sources are provided in IGC release notes. In case of llvm11 let's wait for answer from compiler teams.
This is an issue in LLVM 10. It is fixed in LLVM 11 by https://reviews.llvm.org/D75579 Please check the commit message for details.
opencl-clang and IGC libraries link to both libclang-cpp.so.10 and libLLVM-10.so.1, thus there is double registration of "mc-relax-all"
Cherry-picking it to llvm-10 requires cherry-picking https://reviews.llvm.org/D68063 as well and solving a couple of merge conflicts. After these changes, the error is gone and compute-runtime/build/bin/built_ins/x64/gen12lp/bindful_copy_buffer_rect_Gen12LPlp.spv is successfully generated.
I'm closing this one as it was identified as external issue. We now offer full LLVM 11 support, so you can use such configuration to avoid the problem.
I'm closing this one as it was identified as external issue. We now offer full LLVM 11 support, so you can use such configuration to avoid the problem.
IMHO CMake could check that LLVM is supported version i.e. explicitly reject too old (or new) versions.
And Top level README.md could point out the LLVM support info, e.g. in the Depenencies section, like this:
compute-runtime "21.26.20194" release build fails to incorrect LLVM (v10) CLI options usage:
In case it matters, this build happens in Ubuntu 20.10 container with latest IGC release "igc-1.0.7862" built using LLVM v10 just before it (which requires workaround for https://github.com/intel/intel-graphics-compiler/issues/186 bug).
Here's more of the output before that error: