Compiling v25.27.34303.5 with IGC v2.14.1

[michel2323]

The release notes state that IGC v2.14.1 is the desired version. However, during the build process I get the following assertion:

ninja: job failed: cd /workspace/srcdir/compute-runtime/shared/source/built_ins/kernels && /usr/bin/cmake -E env LD_LIBRARY_PATH=/usr/lib/csl-musl-x86_64:/usr/lib/csl-glibc-x86_64:/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:/lib64:/lib:/workspace/x86_64-linux-musl-cxx11/destdir/lib:/workspace/x86_64-linux-musl-cxx11/destdir/lib64:/opt/x86_64-linux-musl/x86_64-linux-musl/lib64:/opt/x86_64-linux-musl/x86_64-linux-musl/lib:/opt/x86_64-linux-gnu/x86_64-linux-gnu/lib64:/opt/x86_64-linux-gnu/x86_64-linux-gnu/lib:/workspace/destdir/lib64:/workspace/destdir/lib::/workspace/srcdir/compute-runtime/build/bin /workspace/srcdir/compute-runtime/build/bin/ocloc-25.27.1 -q -file /workspace/srcdir/compute-runtime/build/bin/built_ins/x64/xe3_core/bindless_fill_image1d_ptl.spv -spirv_input -device 30.3.0 -heapless_mode disable -force_stos_opt -64 -stateful_address_mode bindless -output bindless_fill_image1d_30_3_0 -output_no_suffix -out_dir /workspace/srcdir/compute-runtime/build/bin/built_ins/x64/xe3_core -internal_options -cl-intel-use-bindless-mode\ -cl-intel-use-bindless-advanced-mode -options -cl-kernel-arg-info

ocloc-25.27.1: /workspace/srcdir/intel-graphics-compiler/IGC/Compiler/igc_workaround_linux.cpp:221: void IGC::SetWorkaroundTable(SKU_FEATURE_TABLE*, IGC::CPlatform*): Assertion `0' failed.

Going to that line in IGC v2.14.1, it seems that the device (maybe XE3_LPG_3003) is not in the list.
https://github.com/intel/intel-graphics-compiler/blob/8044f62975eafe840d09ed00560385dab0bf9854/IGC/Compiler/igc_workaround_linux.cpp#L221

I am pretty confident that I used the right dependency versions listed in the IGC release notes. In IGC v2.15.3, I do see the missing device. I wanted to try that; however, there is no release page to guide me to the right dependency versions. I then tried to build without Xe3 support, but there are still device IDs that don't match.

[JablonskiMateusz]

@michel2323 please ensure you are using proper IGC libraries
Can you repro the issue using the cmdline that ninja is using? If so, please capture strace log and see if proper libigc library is used

[michel2323]

Here is a detailed way how we build the libraries.

https://github.com/michel2323/build_intel_stack

I could reproduce the error on Ubuntu 22.04, Ubuntu 25.04, and of course the Julia Yggdrasil build system.

It'd be great if you can help us. This is the last blocker for using the latest libraries for oneAPI.jl GPU programming in Julia (and Julia on Aurora).

Let me know if you need more info.

cc: @maleadt, @giordano

[michel2323]

It looks to me like the latest NEO release was compiled with a different version of IGC than documented (v2.14.1 seems to old), since the device IDs don't match. I followed the documentation as closely as possible.

[michel2323]

Fixed this issue. I had to cherry-pick these to commits into v1.12.1 of IGC to build NEO. This is counter to the ICG requirement mentioned here: https://github.com/intel/compute-runtime/releases/tag/25.27.34303.5

intel/intel-graphics-compiler@4185ee4

intel/intel-graphics-compiler@09046b0

[JablonskiMateusz]

@michel2323 Thanks for catching the issue.
The missing IGC commits are in the v2.15 release, they will be available in our next GitHub release - 25.31

[JablonskiMateusz]

@michel2323 could you confirm the issue is gone with the recent release https://github.com/intel/compute-runtime/releases/tag/25.31.34666.3 ?

[michel2323]

I will check it out.

[michel2323]

The release page lists oneapi-src/level-zero@v1.23.1, which is a pre-release. We currently distribute with v.1.22.4 (also API 1.13). Should we switch to the pre-release version or wait?

[JablonskiMateusz]

@michel2323 do you build all the components within your project or reuse binaries from level-zero repo?

[michel2323]

It's the binaries that are distributed with oneAPI.jl, so users in Julia don't have to install anything and don't use system libraries. This makes also reproducing easier. We package each component according to the repositories. So level-zero, OpenCL, IGC,... and can deploy/ship each one separately, while keeping track of version dependencies.

I've still not build NEO, but the IGC builds all passed. I'll keep you posted.

[JablonskiMateusz]

There is significant difference between build and runtime dependency of L0 loader.

NEO requires L0 headers for building, if you point too old headers, some definitions may be not available and build will fail.
However, even if NEO is built against some recent pre-release L0 loader, it should work independently on installed L0 loader version.

1. Older loader won't call any newer API
2. Newer loader verifies if L0 runtime provided implementation for newer API.

If you prefer to distribute with stable L0 loader releases, it should work fine, but if you build NEO you should point L0 headers as per NEO dependency.