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.
