Requires an Intel® Arc™ GPU. The implementation is primarily focused on this architecture and future Intel GPUs.
Only supported on Windows currently, with driver version 101.1660 or newer.
Kernels are compiled when rendering for the first time. Currently this can be slow, for example 15 minutes. We are working to bundle compiled kernels with Blender for the final release instead.
Linux support is being worked on for the final release. This will require driver version 22.10.22597 or newer.
Thanks for sharing these reviews!
The weird performance of A750 in Junkshop is fixed in latest drivers (101.3430+). It can still happen if there isn’t enough GPU memory available.
We’re investigating the speckles in lone monk. So far I can say that increasing Sun Size in Nishita Sky Texture from 1.0° to 1.5° works around it.
Hello,
I have an Intel Arc A750. However, my GPU is still not detected by Blender as a compatible Cycles Render Device in the oneAPI tab. This issue is present in version 3.3.1 and 3.4 (nightly) of Blender.
I’m on Linux running the latest available version of the Intel Compute Runtime (22.30.23789), which is above the required version (xx.xx.23904).
Oh, my bad. You are right, of course. I just tried with version 22.35.24055 of intel-compute-runtime, but the detection still fails.
Same issue with the very latest version available from intel currently, 22.42.24548.
This is the relevant output of clinfo to confirm the driver version:
Platform Name Intel(R) OpenCL HD Graphics
Number of devices 1
Device Name Intel(R) Graphics [0x56a1]
Device Vendor Intel(R) Corporation
Device Vendor ID 0x8086
Device Version OpenCL 3.0 NEO
Device UUID 86800000-a156-0000-0000-000000000000
Driver UUID 32322e34-322e-3234-3534-380000000000
Valid Device LUID No
Device LUID c004-2fc5ff7f0000
Device Node Mask 0
Device Numeric Version 0xc00000 (3.0.0)
Driver Version 22.42.24548
It’s a little strange that it says “Intel(R) OpenCL HD Graphics”. Is it possible that the blender check fails because the device is falsely reported as an HD Graphics GPU?
I have tested this with different Distros (Arch, Fedora) and driver versions / versions of Blender now and none of the combinations worked. I think there might be a bug in Blender that prevents successful detection of Intel Arc GPUs on Linux.
Have there been any reports of Linux users being able to use oneAPI with Cycles yet?
Proper names recently landed in mesa so it’s expected to not get these with current kernels and it’s not an issue. Blender is not using OpenCL and isn’t checking any platform/device strings.
It’s using level-zero. Permissions should be fine if you can run clinfo but maybe you’re missing intel-level-zero-gpu library from compute-runtime?
A good next debugging step on compute devices enumeration is to run “sycl-ls”, you can get it precompiled from https://github.com/intel/llvm/releases/download/sycl-nightly%2F20221023/dpcpp-compiler.tar.gz:
ro run this way: LD_LIBRARY_PATH=../lib ./sycl-ls
On a working configuration, its output will contain a line similar to this one: [ext_oneapi_level_zero:gpu:0] Intel(R) Level-Zero, Intel(R) Graphics [0x56a1] 1.3 [1.3.23937]
Since I am not using Ubuntu, I could not follow every step of the installation instructions. For example I am using Kernel 6.1 not the OEM Kernel with DKMS modules. But I can use the card in 3D applications so this is not the issue.
I have added my user to the render group as per the instructions, but this didn’t change anything. The packages intel-compute-runtime on Arch and Fedora should include everything that is required for Compute API support (oneAPI Level Zero and OpenCL™ Driver). clinfo confirms that a recent enough version is installed on both Arch and Fedora.
Unfortunately, running blender with --debug-cycles doesn’t print an error message in the terminal for oneAPI.
Good your setup on Arch looks fine.
To confirm we’re not filtering your config out by mistake on Blender side on Arch, can you try again with this environment variable CYCLES_ONEAPI_ALL_DEVICES=1 ? It will let you list any level-zero gpu in preferences, not just the supported ones.
Running with --debug-cycles --verbose 6 and going to preferences doesn’t output anything related to oneapi?
If that doesn’t help, please share logs with SYCL_PI_TRACE=2 environment variable.
Unfortunately, none of those work. The environment variables CYCLES_ONEAPI_ALL_DEVICES=1 and SYCL_PI_TRACE=2 do not have any effect, with or without running blender with --debug-cycles --verbose 6
No devices are listed in the preferences for oneAPI.
Only HIP and OptiX give error messages. The message refering to Intel is thrown out by every 3D application and should not be related to oneAPI.
Read prefs: /home/alex/.config/blender/3.4/config/userpref.blend
../mesa/src/intel/isl/isl.c:2228: FINISHME: ../mesa/src/intel/isl/isl.c:isl_surf_supports_ccs: CCS for 3D textures is disabled, but a workaround is available.
I1024 11:30:34.814394 25898 device.cpp:56] HIPEW initialization failed: Error opening HIP dynamic library
I wish there was more device feedback by Linux users who are not using the officially supported Ubuntu release. I guess we’ll have to wait a bit until those arrive.
I wish there was more device feedback by Linux users who are not using the officially supported Ubuntu release. I guess we’ll have to wait a bit until those arrive.
Me as well! As you’re one of the first to face these issues it’d be really great if we can find what went wrong with your setup.
If you don’t even see ---> piPlatformsGet( <unknown> : 0 <nullptr> <unknown> : 0x7ffe954e66e4 ) ---> pi_result : PI_SUCCESS when using SYCL_PI_TRACE=2 environment variable I’m not sure what to think actually. Unless another libsycl library ended up getting used over libs packaged in blender… but it should have failed in different ways in my view.
Still, can you check what ldd blender reports for libpi_level_zero.so and libsycl.so ?
also at runtime after opening up the preferences:
Actually, it doesn’t report anything for libpi_level_zero.so. Just tested with the latest nightly build of Blender 3.4.0 Alpha (not installed system-wide):
Only for libcycles_kernel_oneapi_aot.so and libsycl.so.6
blender 22850 alex mem REG 0,35 4755628 /home/alex/Downloads/blender-3.4.0-alpha+master.93afc50ac3ef-linux.x86_64-release/lib/libsycl.so.6.1.0-0 (path dev=0,36)
blender 22850 alex mem REG 0,35 2793634 /usr/lib/libpipewire-0.3.so.0.359.0 (path dev=0,58)
libpipewire is obviously not what we are looking for
I should mention that I’m running Arch in a container through distrobox on my Fedora Host System. But that shouldn’t be the the problem here?
Also my CPU is an AMD Ryzen 5 3600. But an Intel CPU should not be a requirement for oneAPI?
Thanks. Not getting libpi_level_zero.so from ldd is expected since libsycl.so will look for it lazily in its directory at runtime. Not getting it from lsof is unexpected.
Can you try again with SYCL_PI_TRACE=-1 ? libsycl should really log something.
Intel CPU isn’t a requirement. distrobox could be an issue - does it do any virtualization or it’s more like debian’s chroot?
Distrobox doesn’t do any virtualization, as far as I know. It only allows to run a different Linux install in a docker container sharing the Kernel with the Host OS while using the libraries and drivers installed within the container. I might actually try to run Ubuntu 22.04 this way and see what results I’m getting there.
With SYCL_PI_TRACE=-1 I’m finally getting new terminal output when running blender:
SYCL_PI_TRACE[-1]: dlopen(/home/alex/Downloads/blender-3.4.0-alpha+master.93afc50ac3ef-linux.x86_64-release/lib/libpi_level_zero.so)
failed with <libze_loader.so.1: cannot open shared object file: No such file or directory>
SYCL_PI_TRACE[all]: Check if plugin is present. Failed to load plugin: libpi_level_zero.so
that’s good progress, now we can see what’s wrong: /home/alex/Downloads/blender-3.4.0-alpha+master.93afc50ac3ef-linux.x86_64-release/lib/libpi_level_zero.so can’t load since libze_loader.so.1 isn’t found.
It comes from level-zero package: https://github.com/oneapi-src/level-zero/
Since your previous test with sycl-ls worked, it’s surprising to see a different outcome here. Where is this lib on your system?
You should be able to work around this issue by adding its path to LD_LIBRARY_PATH.
You can check ldd /home/alex/Downloads/blender-3.4.0-alpha+master.93afc50ac3ef-linux.x86_64-release/lib/libpi_level_zero.so succeeds before trying again with blender.
Actually libze_loader.so.1 is nowhere on my system, except for the Download folder where I put dpcpp_compiler. I think sycl-ls worked earlier because I used LD_LIBRARY_PATH=../lib/ as an environment variable, forcing syscl-ls to use the lib from the Download folder and not from the system (where it doesn’t seem to be part of intel-compute-runtime package)
I’ll investigate which package might provide libze_loader.so.1 for system-wide use (though I think it should probably really be supplied by intel-compute-runtime).
I tried to run blender with LD_LIBRARY_PATH=~/Downloads/dpcpp_compiler/lib/ as an environment variable, but that made blender crash immediately when opening the Cycles settings.
Okay, got it. On Arch libze_loader.so.1 is provided by the package level-zero-loader (which I’m actually sure I had installed previously). I reinstalled the package and now it works. My A750 shows as “Intel Graphics [0x56a1]” under oneAPI. Will test later if it actually works in production and report any issues.
Now I will only have to figure out how to get it working on Fedora, too.
Thank you very much for your help and sorry for wasting your time by basically just missing to install one package…
Edit
Blender crashes (both 3.3 and 3.4) when switching to Cycles (with GPU rendering) in the viewport:
terminate called after throwing an instance of 'sycl::_V1::runtime_error'
what(): Native API failed. Native API returns: -997 (The plugin has emitted a backend specific error) -997 (The plugin has emitted a backend specific error)
That was worth trying but the github prebuilts are built with C++11 ABI while Blender 3.3/3.4 is using older C++ ABI, issues are definitely expected in that case.
No worries, I’m sure the steps we went through will be useful to others.
The intent of level-zero is to get it used by more vendors and devices than just Intel/GPUs, it makes sense to have it exist on its own.
For the crash you get now, you can share logs from --debug-cycles --verbose 6. A runtime error like that could come from incompatibilities across pieces of intel driver you have. If you can, I recommend sticking with version numbers/tags listed in an official stable release for Arc: https://dgpu-docs.intel.com/releases/index.html
