{intel-compute-runtime{,-legacy1},intel-graphics-compiler}: drop; opencl-clang: 15.0.1 -> 21.1.0#440272
{intel-compute-runtime{,-legacy1},intel-graphics-compiler}: drop; opencl-clang: 15.0.1 -> 21.1.0#440272emilazy wants to merge 3 commits intoNixOS:staging-nextfrom
Conversation
Per [the upstream issue], Intel only added support for LLVM 16 this January, and had not even moved their production builds to LLVM 15 at that point. LLVM 20 was out by then, LLVM 16 was almost 2 years old, and LLVM 15 was almost 3½ years old. That’s not a sustainable pace of development given LLVM’s support windows; even the latest Debian stable release only ships LLVM ≥ 17. [the upstream issue]: <intel/intel-graphics-compiler#289> A comment from July 2024 says: > We are committed to bringing IGC to latest LLVM versions, and we are > implementing a much more robust LLVM upgrade processes to accelerate > new versions integration. Until new processes are in place, we are > also working on LLVM 16 build compatibility in parallel. > We are expecting IGC to be LLVM 16 compatible mid-August, according > to experience from previous versions. Also as in previous efforts, > we will follow this with fixes to functional/performance quality > of the compiler which should happen much faster given new processes. Sadly, the quoted deadline for LLVM 16 ended up slipping by half a year, and they only switched their production builds to LLVM 15 in April. Their claimed LLVM 16 support also depends on [reverting an upstream commit] relating to the opaque pointers transition. [reverting an upstream commit]: <https://github.com/intel/intel-graphics-compiler/blob/c1d34755f1864409fa1f985aee6a741f9053e152/external/llvm/releases/16.0.0/patches_external/Reapply_hasSetOpaquePointersValue.patch> Hopefully, their stated commitment means this will improve at some point and they’ll keep up with the LLVMs we ship. For now, I think dropping is more friendly to users than marking the packages broken, as it means we can point them to Mesa’s Rusticl implementation as an alternative. The legacy version will presumably never get LLVM updates, anyway.
nixpkgs-ci
bot
added
10.rebuild-linux: 101-500
SuperSandro2000
left a comment
SuperSandro2000
left a comment
There was a problem hiding this comment.
I am greatly disappointed about the stance NixOS thinks about planned obsolescence and that my just ~5 year old hardware is to old to properly support all forms of hardware acceleration on it.
There was a problem hiding this comment.
opencl-clang only exists to support intel-graphics-compiler and when that is removed I wouldn't know a reason why we would want to keep this package. Also I only would want to build this package in a configuration which Intel doesn't fully support as I otherwise have no good trust to know it works. Also after this PR I do not know how to test this package and I wouldn't have a reason to maintain it if I am honest to myself.
| inotifyTools = inotify-tools; | ||
| insync-emblem-icons = throw "'insync-emblem-icons' has been removed, use 'insync-nautilus' instead"; # Added 2025-05-14 | ||
| inter-ui = throw "'inter-ui' has been renamed to/replaced by 'inter'"; # Converted to throw 2024-10-17 | ||
| intel-compute-runtime = throw "intel-graphics-compiler has been removed, as it does not build with supported LLVM versions; consider using Mesa’s Rusticl implementation of OpenCL"; # Added 2025-08-22 |
There was a problem hiding this comment.
I've spent way to much time already trying to support the GPU and CPU hardware acceleration features of my devices and from that I learned that things which should be compatible in theory are not always compatible in practice and there exist some programs which only work with one variant of hardware acceleration and not another one. I have a really hard time believing that this switch generally just works for all programs and think this is not a great migration path for all things.
There was a problem hiding this comment.
I concur. To my understanding, intel-compute-runtime provides not only OpenCL but is also the implementation for level-zero on Intel GPUs and thereby required to run e.g. SYCL programs.
It could fall back to OpenCL under the hood, but that loses out on performance and features (like hardware intrinsics).
There was a problem hiding this comment.
FWIW, my understanding is that Rusticl explicitly targets being able to run SYCL programs, but I don’t know the exact level of compatibility or performance there.
|
@SuperSandro2000 I'd much rather we look forward to how the proposed alternative works, before jumping to conclusions, which you now did. The proposed replacement looks something like this: hardware.graphics = {
enable = true;
extraPackages = with pkgs; [
mesa.opencl
];
extraPackages32 = with pkgs; [
driversi686Linux.mesa.opencl
];
};
environment.variables = {
# https://docs.mesa3d.org/envvars.html#rusticl-environment-variables
RUSTICL_ENABLE = "iris";
}; |
|
Also, I think this warrants a post into the unstable breaking changes thread. |
|
This is now the only outstanding PR that was blocking #440273. I’ve added a commit to mark it with |
|
Unfortunately rusticl also doesn't work for OpenVINO. Instead, it now just segfaults and we need time to report this upstream in hope of a fix. |
|
It seems like the patch I posted is the most viable path forward for now, then. I suppose whether Rusticl catches up or Intel starts tracking modern LLVM first is anyone's guess. |
4 participants
Per the upstream issue, Intel only added support for LLVM 16 this January, and had not even moved their production builds to LLVM 15 at that point. LLVM 20 was out by then, LLVM 16 was almost 2 years old, and LLVM 15 was almost 3½ years old. That’s not a sustainable pace of development given LLVM’s support windows; even the latest Debian stable release only ships LLVM ≥ 17.
A comment from July 2024 says:
Sadly, the quoted deadline for LLVM 16 ended up slipping by half a year, and they only switched their production builds to LLVM 15 in April. Their claimed LLVM 16 support also depends on reverting an upstream commit relating to the opaque pointers transition.
Hopefully, their stated commitment means this will improve at some point and they’ll keep up with the LLVMs we ship. For now, I think dropping is more friendly to users than marking the packages broken, as it means we can point them to Mesa’s Rusticl implementation as an alternative. The legacy version will presumably never get LLVM updates, anyway.
We can, at least, bump
opencl-clangto the latest LLVM, and the correspondingspirv-{headers,tools}bump to unblockspirv-llvm-translatorwill be required (because of Mesa) for the upcoming LLVM 21 default in #407738.Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.