Add Intel "OneAPI" support to Blender 3.3 to accelerate rendering using new Intel ARC "Alchemist" graphics cards Reproducible: Always
Blender has stated that the 3.3 "LTS" release supports these new GPU's for both datacenter and consumer "ARC Alchemist" graphics cards https://code.blender.org/2022/09/intel-arc-gpu-support-for-cycles/ Reading through the build documentation, it looks like this can be added fairly trivially by adding something like "oneapi" as a USE flag and adding the following lines to the configure flags, similar to Nvidia CUDA or AMD ROCM -DWITH_CYCLES_DEVICE=ONEAPI=$(usex oneapi) -DWITH_CYCLES_ONEAPI_BINARIES=$(usex oneapi)
Do you have any Intel GPUs you can test this with? I don't personally have any so I can't really test if things are working correctly. Because of this, I don't really want to add in support for it into the ebuild without having anyone actually test if it works first.
I do have an Intel "ARC" A380 GPU. They're about $140 USD online. Happy to test or provide a VM with the card for verifying the feature works It may end up similar to https://bugs.gentoo.org/590752 where there's still pieces of the kernel stack waiting to be implemented in 6.2, but the Blender 3.3 nightly builds seem to offer the feature in the list of Rendering engines
I've talked to one of the Cycles developers. He is not 100% sure, but he told me that the official build should just work with OneAPI out of the box on intel hardware on linux without needing any extra libraries installed on the system. For building it is a bit more involved, but should be doable. I'm unsure if everything we need is in the main portage tree, but we need: OpenAPI (SyCL), LevelZero, and Ocloc. Ocloc needs to be pointed to with `OCLOC_INSTALL_DIR`. I think all of these might be provided by the `dev-libs/intel-compute-runtime` package? If so, could you try to add the cmake flags and deps to the ebuild and test? If you compile blender without `WITH_CYCLES_ONEAPI_BINARIES`, then you do not need ocloc as compile time, but it is then needed at run time as Blender will then try to build the cycles kernels on demand.
I'll take a swing at it either today or tomorrow (whee, busy thanksgiving! :( ) OCLOC_INSTALL_DIR is something I hadn't seen before and might be the missing piece to get everything together. I did install the dev-libs/intel-compute-runtime and enabled the oneapi method, but in the configuration it spits out "oneAPI or Level Zero not found, disabling WITH_CYCLES_DEVICE_ONEAPI" I'll need to see where it's looking for those components with respect to the compute-runtime If I can get it working I'll post a basic edited ebuild and any makefile patch if needed. May also be worth version bumping it to 3.3.1 as well? That seems to be the current LTS release
I guess it might be missing Sycl. The error message is from intern/cycles/cmake/external_libs.cmake The "find sycl" command runs build_files/cmake/Modules/FindSYCL.cmake and that seems to look for dpcpp. If you look for `DPCPP` in build_files/build_environment/cmake/versions.cmake, you can see that the official builds seems to get it from https://github.com/intel/llvm (the sycl branch). The versions.cmake file is what Blender uses to build the libraries for the official builds. So the versions of libraries listed in there is not a hard requirement. I don't know if sycl is already provided with some other package in gentoo or you might already have it installed and need to modify the "Find" cmake scripts.
And yes, bumping to 3.3.1 would be good as well :) I haven't had time to get around to that yet, so that is why we are a bit behind.
Did you have any luck?
>Did you have any luck? I've not yet had time to tackle it unfortunately. Holiday period + work and such :( I'll try to tackle it either toward the end of the year or early in the new year if I can
I took a swing at it for a bit yesterday. Commenting out some old patches was enough to make the latest 3.4.1 Blender release merge and build without issue I'm completely out of my depth on getting SyCL/Ocloc/DPC++ configured correctly however. Intel's documentation for all that seems to be scattered marketing and not much else at this time. If someone more skilled than I am would like to get the relevant pieces together for testing I'd be happy to provide a VM or something with the Intel ARC card passed through to test with.
What exactly do you have issues with regarding SyCL/Ocloc/DPC++ ? I'm guessing you get Blender to compile with openapi support, but then it fails during runtime?
>What exactly do you have issues with regarding SyCL/Ocloc/DPC++ ? I could not make heads-or-tails of how Intel expects one to *install* the software. The Github repo for it is not very forthcoming unfortunately https://github.com/intel/llvm/ >I'm guessing you get Blender to compile with openapi support, but then it fails during runtime? I was able to version bump Blender to 3.4 as-is, but was not able to get OneAPI support to enable during the build configuration. I assume SyCL/Ocloc/DPC++ needs to be installed into the system and passed to the configuration during build time but I could not find any relevant documentation for getting that software to install correctly. Intel does seemingly ship it for Ubuntu LTS 22.04 but does not provide build instructions for other distributions
Do you not get those binaries when building the source code of the llvm fork? The build instruction seems to be here: https://github.com/intel/llvm/blob/sycl/sycl/doc/GetStartedGuide.md#build-dpc-toolchain To convert that into an ebuild it seems like you might just have to look at what the python scripts are doing and do the same in the ebuild.
I ended up installing the whole Intel oneapi suite into /opt/intel After that I asked a friend more versed in C++ (and especially cmake) to help me figure out Blender's..."interesting" build system :) A whole lot of LD_LIBRARY_PATH-ing later and I eventually got it to *build* with OneAPI enabled, but attempting to render anything just seems to quit without any error messages (and I'm unclear of how to enable debugging via the command line) I took one final swing at it and attached strace to it only to have it print out a 1MB~ stack trace from that silent quit operation. After that point the both of us gave up for now. But we were able to get it to *build* the git version of Blender at least
> I don't know if sycl is already provided with some other package in gentoo or you might already have it installed and need to modify the "Find" cmake scripts. > I could not make heads-or-tails of how Intel expects one to *install* the software. The Github repo for it is not very forthcoming unfortunately Btw, there is a working ebuild for DPC++/SYCL in the ::science repository: dev-lang/DPC++. With the latest version of this and related packages I finally got the whole stack working to the extent where I can actually use dpnp (which is like numpy but on the GPU). This is *not* ready for ::gentoo though. Adding this to ::gentoo should probably be coordinated with the toolchain project. But from what I understand Intel still intends to upstream this into main llvm/clang, so maybe it is not worth the effort to add the DPC++ ebuild to ::gentoo at this time. As we speak I am also working on a rpm-wrapper approach over at ::natinst. Basically I have adapted my script there to run on intel's oneapi repository, it is still running though.
I've been messing around with this and I finally ended up with a working build using the official binaries from Intel. These cmake arguments were all that was needed to get blender to build with oneAPI support: "-DWITH_CYCLES_DEVICE_ONEAPI=ON -DWITH_CYCLES_ONEAPI_BINARIES=ON -DSYCL_ROOT_DIR=/opt/intel/oneapi/2024.0 -DOCLOC_INSTALL_DIR=/usr/bin" I've had it crash when attempting to render something at first, but after running in headless mode once (blender-4.0 -b <file>, which worked fine), the GUI also started working (maybe because blender caches the compiled GPU binaries after the first run?). I can't seem to reproduce this now, though. I've tested a couple of scenes and all seem to render on my GPU (Arc 770) without issues. I've tried using the DPC++ ebuild from ::science as well, but that attempt just crashed when I tried to select oneAPI in blender's preferences.
You could try to remove ~/.config/blender/4.0/cache and try again. I would add oneapi to the -9999, same as hip before for now, if you tell me the DEPENDS.
(In reply to Paul Zander from comment #17) > You could try to remove ~/.config/blender/4.0/cache and try again. I believe those files are cached in ~/.cache/libsycl_cache, I couldn't find anything related to oneAPI in ~/.config/blender, ~/.cache/blender or ~/.cache/cycles. It still worked without crashing after I deleted libsycl_cache. My solution currently uses the binaries from Intel's official installer [1], so those wouldn't be available in portage. Maybe an ebuild for the latest version of DPC++ is all that's needed, but there might also be some other incompatibilities with the oneAPI libraries from portage that are causing blender to crash (since that's what happened when using DPC++ installed from ::science). [1] https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6cd4df04768cadea66b4a027ca7ed83aa4138ef7 commit 6cd4df04768cadea66b4a027ca7ed83aa4138ef7 Author: Paul Zander <negril.nx+gentoo@gmail.com> AuthorDate: 2024-04-23 15:27:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-04-23 21:00:03 +0000 media-gfx/blender: 4.0.2-r1 bugfixes; add initial oneapi support Drop python3.12 support. Will reappear in 4.1.1. Use wayland_dynload to avoid problems with libdecor-plugin.h. Bump openvdb required version to 11 from 10. oneAPI support might be broken. But we got to start somewhere... Bug: https://bugs.gentoo.org/882645 Closes: https://bugs.gentoo.org/930397 Closes: https://bugs.gentoo.org/930412 Signed-off-by: Paul Zander <negril.nx+gentoo@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> media-gfx/blender/blender-4.0.2-r1.ebuild | 89 +++++++++++++++++++++++-------- media-gfx/blender/metadata.xml | 10 ++++ profiles/arch/amd64/package.use.mask | 2 +- profiles/arch/base/package.use.mask | 2 +- profiles/features/musl/package.use.mask | 8 +++ 5 files changed, 86 insertions(+), 25 deletions(-)
Paul, Sam, I very much doubt that will work without DPC++ from ::sci, or the binary version from ::natinst, to provide the sycl library.
Hello! Sorry for not updating this for a while. I've finally had some time today to play more with Blender + Intel ARC/DG2. I tried building the latest blender but seem to still be hitting a wall on building it. The dev-lang/DPC++ package seems to be rather outdated (December 2022?) and errors out during build. Reading through the comments here it sounds like upstream is merging it all into LLVM directly instead? I git cloned SyCL from https://github.com/intel/llvm built and copied it into the system path instead. It seems to find SyCL and other components successfully which is excellent, however Blender immediately errors out during the configure step with the below output -- Found SYCL: /usr/lib/libsycl.so (found version "8.0.0") -- Found LevelZero: /usr/lib64/libze_loader.so -- oneAPI ocloc not found in /usr/lib/llvm/18/lib/ocloc. A different ocloc directory can be set using OCLOC_INSTALL_DIR cmake variable. CMake Error at build_files/cmake/macros.cmake:1408 (message): ocloc required but not found Call Stack (most recent call first): intern/cycles/cmake/external_libs.cmake:125 (set_and_warn_library_found) intern/cycles/CMakeLists.txt:23 (include) This *seems* to be built by dev-libs/intel-compute-runtime, though is installed as /bin/ocloc-$version copying ocloc-$version to /lib/llvm/18/lib/ocloc fixes the check and allows llvm to begin building, but terminates shortly after with FAILED: intern/cycles/kernel/libcycles_kernel_oneapi_aot.so /var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2_build/intern/cycles/kernel/libcycles_kernel_oneapi_aot.so cd /var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2_build/intern/cycles/kernel && /usr/bin/cmake -E env LD_LIBRARY_PATH=/usr/lib/llvm/18/bin/../lib:/usr/lib/llvm/18/lib/ocloc/lib:/usr/lib/llvm/18/lib/igc/lib PATH=/usr/lib/llvm/18/lib/ocloc/bin:/usr/lib/llvm/18/bin:/var/tmp/portage/media-gfx/blender-4.2.2/temp/python3.11/bin:/usr/lib/portage/python3.11/ebuild-helpers/xattr:/usr/lib/portage/python3.11/ebuild-helpers:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/18/bin:/usr/lib/llvm/17/bin:/usr/lib/llvm/15/bin /usr/lib/llvm/18/bin/clang++ /var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2/intern/cycles/kernel/device/oneapi/kernel.cpp -fsycl -fsycl-unnamed-lambda -fdelayed-template-parsing -mllvm -inlinedefault-threshold=250 -mllvm -inlinehint-threshold=350 -fsycl-device-code-split=per_kernel -fsycl-max-parallel-link-jobs=1 -shared -DWITH_ONEAPI -O2 -fno-fast-math -ffp-contract=fast -fassociative-math -freciprocal-math -fno-signed-zeros -ffinite-math-only -D__KERNEL_LOCAL_ATOMIC_SORT__ -o"/var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2_build/intern/cycles/kernel/libcycles_kernel_oneapi_aot.so" -I"/var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2/intern/cycles/kernel/.." -fsycl-targets=spir64,spir64_gen -Xsycl-target-backend=spir64 "-options '-ze-opt-large-register-file -ze-opt-regular-grf-kernel integrator_intersect -ze-opt-large-grf-kernel shade -ze-opt-no-local-to-generic'" -Xsycl-target-backend=spir64_gen "--format zebin -options '-ze-opt-large-register-file -ze-opt-regular-grf-kernel integrator_intersect -ze-opt-large-grf-kernel shade -ze-opt-no-local-to-generic'" -DWITH_NANOVDB -fPIC -fvisibility=hidden -fhonor-nans -Wl,-rpath,'$ORIGIN' -DNDEBUG -g clang++: error: unknown argument: '-fsycl-unnamed-lambda' clang++: error: unknown argument: '-fsycl-device-code-split=per_kernel' clang++: error: unknown argument: '-fsycl-max-parallel-link-jobs=1' clang++: error: unknown argument: '-fsycl-targets=spir64,spir64_gen' clang++: error: unknown argument: '-Xsycl-target-backend=spir64' clang++: error: unknown argument: '-Xsycl-target-backend=spir64_gen' On a hunch I tried adding LLVM_TARGETS="SPIRV ARC" and rebuilding Clang+LLVM but that did not seem to make any difference. I suspect there may be some mismatch with the way I built and installed SyCL nightly directly from git. I'm going to take a look at the ::natinst overlay to see if I can get further in building Blender and will update accordingly
> The dev-lang/DPC++ package seems to be rather outdated (December 2022?) and errors out during build. That actually is the latest real "release", since 2022-12 we've had nothing but "dailies". Contributions in this area are very welcome if you're interested. It's extremely difficult to a) get this compiler to build, and then also b) get that compiler to do what it is supposed to do for projects that require sycl (there are several in the ::science repository). Once I actually got the whole chain to work and was able to use gpu accelerated numpy (dpnp), only to find that it is not even near feature parity with regular numpy and was therefore unsuitable for what I wanted to do. I have not touched this since, so I expect that by now things will be broken again. > Reading through the comments here it sounds like upstream is merging it all into LLVM directly instead? As I understand it, this was the idea yes, but this effort has stalled unfortunately[1]. [1] https://github.com/intel/llvm/issues/49
> On a hunch I tried adding LLVM_TARGETS="SPIRV ARC" and rebuilding Clang+LLVM > but that did not seem to make any difference. I suspect there may be some > mismatch with the way I built and installed SyCL nightly directly from git. The LLVM_TARGET "ARC" actually has nothing to do with the Intel ARC GPUs. It's for the ARC (Argonaut RISC Core) embedded CPUs. (confusing indeed) > I'm going to take a look at the ::natinst overlay to see if I can get further > in building Blender and will update accordingly Note that these packages are likely also outdated (I keep sci-ni/ and sci-pt/ up to date regularly but have been slacking with intel-oneapi/). There is a script in that directory that should help you re-generate the whole thing, note that this is very slow. If you do end up regenerating it, then please open a new Pull Requests with those changes, that will save me a lot of time.
> clang++: error: unknown argument: '-fsycl-unnamed-lambda' > clang++: error: unknown argument: '-fsycl-device-code-split=per_kernel' > clang++: error: unknown argument: '-fsycl-max-parallel-link-jobs=1' > clang++: error: unknown argument: '-fsycl-targets=spir64,spir64_gen' > clang++: error: unknown argument: '-Xsycl-target-backend=spir64' > clang++: error: unknown argument: '-Xsycl-target-backend=spir64_gen' This means you are not using the DPC++ compiler. The DPC++ package provides a fork of llvm which includes the sycl library, but to actually use this you must also use the forked compiler. I.e. you have to set CC and CXX for blender to the path of the llvm compiler that you built.
I appreciate all the clarification! This whole area is very new to me so thank you in advance for your patience with me :) Which packages in the intel-oneapi repo would be required to get DPC++ and SyCL imported for Blender? (if said packages already exist). I can see several "dpcpp" related packages but I'm unclear on exact requirements. I'm running the ebuild update script right now, though it looks like it indeed will be *a while* before it completes (3MB/s on a gigabit fiber line here in Seattle. Thanks Intel CDN!) Should I also report the build failure I encountered with dev-lang/DPC++ 2022 to the ::sci overlay team?
(In reply to Cursed Silicon from comment #25) > I appreciate all the clarification! This whole area is very new to me so > thank you in advance for your patience with me :) > > Which packages in the intel-oneapi repo would be required to get DPC++ and > SyCL imported for Blender? (if said packages already exist). I can see > several "dpcpp" related packages but I'm unclear on exact requirements. I think intel-oneapi/intel_oneapi_compiler_dpcpp_cpp should pull in everything that is required. > Should I also report the build failure I encountered with dev-lang/DPC++ > 2022 to the ::sci overlay team? Yes please!
>I think intel-oneapi/intel_oneapi_compiler_dpcpp_cpp should pull in everything that is required. Small heads up. Am still waiting on the ebuild update. Currently at 490GB and counting Will test the latest dpcpp_cpp package and file the bugs against ::sci after that's all completed
I was able to get the ebuild list updated, with some caveats I kept getting OpenPGP errors (I assume some of these packages are so old their signing keys expired?) so I had to re-run ebuild manifest on some (but not all!) packages while emerging intel-oneapi/intel_oneapi_compiler_dpcpp_cpp and its dependencies Should I submit a git pull of the (broken) ebuild list and let it be manually re-manifested? Otherwise, unfortunately even with the package above installed it looks like I'm still running into the same build error. FAILED: intern/cycles/kernel/libcycles_kernel_oneapi_aot.so /var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2_build/intern/cycles/kernel/libcycles_kernel_oneapi_aot.so cd /var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2_build/intern/cycles/kernel && /usr/bin/cmake -E env LD_LIBRARY_PATH=/usr/lib/llvm/18/bin/../lib:/usr/lib/llvm/18/lib/ocloc/lib:/usr/lib/llvm/18/lib/igc/lib PATH=/usr/lib/llvm/18/lib/ocloc/bin:/usr/lib/llvm/18/bin:/var/tmp/portage/media-gfx/blender-4.2.2/temp/python3.11/bin:/usr/lib/portage/python3.11/ebuild-helpers/xattr:/usr/lib/portage/python3.11/ebuild-helpers:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/18/bin:/usr/lib/llvm/17/bin:/usr/lib/llvm/15/bin /usr/lib/llvm/18/bin/clang++ /var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2/intern/cycles/kernel/device/oneapi/kernel.cpp -fsycl -fsycl-unnamed-lambda -fdelayed-template-parsing -mllvm -inlinedefault-threshold=250 -mllvm -inlinehint-threshold=350 -fsycl-device-code-split=per_kernel -fsycl-max-parallel-link-jobs=1 -shared -DWITH_ONEAPI -O2 -fno-fast-math -ffp-contract=fast -fassociative-math -freciprocal-math -fno-signed-zeros -ffinite-math-only -D__KERNEL_LOCAL_ATOMIC_SORT__ -o"/var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2_build/intern/cycles/kernel/libcycles_kernel_oneapi_aot.so" -I"/var/tmp/portage/media-gfx/blender-4.2.2/work/blender-4.2.2/intern/cycles/kernel/.." -fsycl-targets=spir64,spir64_gen -Xsycl-target-backend=spir64 "-options '-ze-opt-large-register-file -ze-opt-regular-grf-kernel integrator_intersect -ze-opt-large-grf-kernel shade -ze-opt-no-local-to-generic'" -Xsycl-target-backend=spir64_gen "--format zebin -options '-ze-opt-large-register-file -ze-opt-regular-grf-kernel integrator_intersect -ze-opt-large-grf-kernel shade -ze-opt-no-local-to-generic'" -DWITH_NANOVDB -fPIC -fvisibility=hidden -fhonor-nans -Wl,-rpath,'$ORIGIN' -DNDEBUG -g clang++: error: unknown argument: '-fsycl-unnamed-lambda' clang++: error: unknown argument: '-fsycl-device-code-split=per_kernel' clang++: error: unknown argument: '-fsycl-max-parallel-link-jobs=1' clang++: error: unknown argument: '-fsycl-targets=spir64,spir64_gen' clang++: error: unknown argument: '-Xsycl-target-backend=spir64' clang++: error: unknown argument: '-Xsycl-target-backend=spir64_gen' clang++: error: unknown argument: '--format zebin -options '-ze-opt-large-register-file -ze-opt-regular-grf-kernel integrator_intersect -ze-opt-large-grf-kernel shade -ze-opt-no-local-to-generic''
(In reply to Cursed Silicon from comment #28) > I was able to get the ebuild list updated, with some caveats > > I kept getting OpenPGP errors (I assume some of these packages are so old > their signing keys expired?) so I had to re-run ebuild manifest on some (but > not all!) packages while emerging > intel-oneapi/intel_oneapi_compiler_dpcpp_cpp and its dependencies > > Should I submit a git pull of the (broken) ebuild list and let it be > manually re-manifested? Yes please. The distfiles are not signed, they are only hashed. So it's a bit weird that the manifest changed, it would mean that intel changed the rpm without bumping the version. > Otherwise, unfortunately even with the package above installed it looks like > I'm still running into the same build error. You're still compiling with llvm-18. The dpcpp package will have installed somewhere in /opt/intel/oneapi, you'll have to manually instruct the blender ebuild to use that compiler instead by setting CC and CXX to the path to dpcpp using /etc/portage/package.env. There is some script that is supposed to help with this: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2023-0/specifying-the-location-of-compiler-components.html
>Yes please. The distfiles are not signed, they are only hashed. So it's a bit weird that the manifest changed, it would mean that intel changed the rpm without bumping the version. Git pull request submitted (hopefully correctly!) https://github.com/gentoo-mirror/natinst/pull/1 >There is some script that is supposed to help with this: Running that script does seem to work, though I run into the same wall I was at before where it can't find "ocloc" anymore Copying ocloc from /bin/ocloc into /opt/intel/oneapi/compiler/2024.2/lib/ocloc eventually errors out when invoking it I'm currently going through the oneapi packages to find the "matching" package for dev-libs/intel-compute-runtime which seems to be the provider of the existing install
No success finding a package that puts ocloc into the expected /opt/intel/oneapi/compiler/2024.2/lib/ocloc "Vtune" puts the same binary into /opt/intel/oneapi/vtune/2024.3/bin64/gma/GTPin/Profilers/ocloc/Bin/intel64/ocloc however copying that over to the other compiler dir results in a build failure again. Both copying the binary from /bin/ocloc (dev-libs/intel-compute-runtime) and using the vtune one result in the exact same build failure. Due to file size limitations I've uploaded the full build log here https://cursedsilicon.net/build.log (4.8MB)
(In reply to Cursed Silicon from comment #30) > >Yes please. The distfiles are not signed, they are only hashed. So it's a bit weird that the manifest changed, it would mean that intel changed the rpm without bumping the version. > > > Git pull request submitted (hopefully correctly!) > https://github.com/gentoo-mirror/natinst/pull/1 Thanks, but this is the mirror repository, I cannot merge from there. Could you please open the Pull Request against this repository instead: https://github.com/AndrewAmmerlaan/natinst I'll also see if I can get this to work (or at least build) on my end when I have time. We might need some ebuild level fix for this to find ocloc in the proper location. CC'ing the maintainers of the intel-compute-runtime.
>Could you please open the Pull Request against this repository instead Done, my apologies :) >I'll also see if I can get this to work (or at least build) on my end when I have time. We might need some ebuild level fix for this to find ocloc in the proper location. CC'ing the maintainers of the intel-compute-runtime. I'm not sure if it's a bug in Blender's build process or something on our side. I suspect since I'm able to copy two different ocloc's to the same location and get the same build failure that it may be a deeper bug
