I’m using Blender 3.4.1 stable, downloaded from the official site. Build info from “Save System Info”: version: 3.4.1, branch: makepkg (modified), commit date: 2022-12-20 08:50, hash: ef9ca44dee7f, type: Release
On your screenshots there is no oneAPI choice at all, that actually means your build was done without it.
“official site” is actually your linux distribution repository?
I’ve just checked with 3.4.1 from builder.blender.org and if oneAPI stack is broken, I get this UI:
Build info: version: 3.4.1, branch: blender-v3.4-release, commit date: 2022-12-20 08:50, hash: ef9ca44dee7f, type: release
while for your build, branch is “makepkg (modified)”
You are correct, I actually used the one from AUR. Using the “real official” build you linked works, I can use oneAPI and select my device. Thank you very much for your input and for opening an issue for the AUR package!
I can also confirm my A750 now working in Blender 3.4 and 3.5 on Arch Linux. Cycles rendering performance/speed seems to be pretty good, though I have nothing to compare it againt - except CPU rendering, of course, which it beats by orders of magnitude. The only odd thing is, I still have to pass CYCLES_ONEAPI_ALL_DEVICES=1 every time I launch blender for my A750 to be listed under rendering devices - otherwise it just doesn’t get detected. I’m on Kernel 6.2 RC7.
Hello very interesting benchmark by Rob Williams for Blender 3.4 where Cycles perform very well ( it will be interesting to see results with Ray Tracing enabled in future ) :
While Eevee performance ( a bit off topic ) seems oddly very low :
I’ve been eyeing Arc development for some time now, and its great to see that the drivers and support are improving. Especially with the release of hardware rt.
I wonder how feasible would be to run A770 under Debian unstable with 6.3 kernel?
Since Ubuntu is downstream from Debian I’d try those drivers. Adding repo is nicely laid out in the official docs: 1. Installation — Intel® software for general purpose GPU capabilities documentation
I’m not a Debian maintainer or packager, but I can help with testing drivers on that OS if anyone would be willing to package them in the future. If I pull the trigger on Arc that said.
I have couple more specific questions:
What should I expect when it comes to future of Linux drivers and support? What I fear the most is a situation when an issue with unsupported distro reported upstream to Intel will be ‘wontfixed’ or forgotten/ignored for months. That is a huge deal for me, as I want to use the GPUs for actual 3D work.
Is dkms module required to run compute and graphics workloads? Are there any plans to develop oneAPI against main Linux kernel and drop dkms requirement for consumer platforms?
Is multi GPU rendering supported or planned for Axxx series GPUs? Haven’t found anything about that and Blender OpenData doesn’t have multi device listed unfortunately.
Should I expect any serious issues with running Arc GPUs on AMD TRX40 platform?
I wonder how feasible would be to run A770 under Debian unstable with 6.3 kernel?
Arc support landed in 6.2 kernel and all the required components (intel-compute-runtime, intel-graphics-compiler, etc) are in debian repos, so it should go smooth - with that said I don’t have a debian install myself to confirm 100%, maybe other users can advise. If you want to run Blender 3.6 you’ll need newer packages than what’s in testing, but I’ve checked and they’re already in experimental, so shouldn’t take too long.
What should I expect when it comes to future of Linux drivers and support? What I fear the most is a situation when an issue with unsupported distro reported upstream to Intel will be ‘wontfixed’ or forgotten/ignored for months. That is a huge deal for me, as I want to use the GPUs for actual 3D work.
All issues are considered, nothing will be ignored on purpose because a distribution is “not on some list”. You can make your opinion by looking at the activity on Intel’s bug trackers like GitHub - intel/intel-graphics-compiler
Is dkms module required to run compute and graphics workloads? Are there any plans to develop oneAPI against main Linux kernel and drop dkms requirement for consumer platforms?
As of upstream 6.2, it seems the dkms module is practically required only for GPU debugging.
Is multi GPU rendering supported or planned for Axxx series GPUs? Haven’t found anything about that and Blender OpenData doesn’t have multi device listed unfortunately.
Yes it is supported!
Should I expect any serious issues with running Arc GPUs on AMD TRX40 platform?
If you have resizeable bar support you have good chances for it to run fine, but I haven’t seen it being officially supported: From my own experience with problematic motherboards, it may have a hard time booting up (sporadically or always).
That is great to hear. I’ll definitely look into github repo.
Do you know how multi-gpu performance scaling looks? Is it more or less linear, or is there any substantial penalty for running 2 or 3 identical GPUs?
I have support for rebar on this platform, so this looks fine in theory.
Is there any Arc-specific monitoring or logging software to troubleshoot that kind of boot problems?
Performance scaling across multiple devices will likely be very similar to other backends (CUDA, OptiX, HIP).
That is to say, running multiple GPUs that are mis-matched in performance will some times give weird performance scaling, potentially decreasing performance.
Running multiple identical GPUs will give you something close to linear performance scaling up until about 4 GPUs where the performance scaling is less than ideal. Although you may obverse less than ideal performance scaling with fewer GPUs depending on the specific scene you’re rendering and the settings you’re using.
Note 1: This is assuming you’re using all GPUs to render the same frame and letting Cycles manage load balancing. (E.G. Opened up Blender, selected all the GPUs in the Cycles settings, and pressed render)
Note 2: This information is based on my understanding of performance scaling across GPUs in Cycles-X. Changes may of been made to Cycles-X to improve performance scaling across multiple GPUs and this may not be a issue any more.
If you were to run multiple GPUs in a situation where you do “manual load balancing”, then you will get close to linear performance scaling no matter how many GPUs you have (assuming scene initialization isn’t long and render times are long). Manual load balancing can be done by rendering an animation and assigning one frame per GPU.
Alaska answered perfectly on the scaling question.
If the display doesn’t show anything or the motherboard beeps annoyingly when powering it on, the trouble is then identified, but it’s a low-level issue that tend to require a motherboard bios update
What I have included below is the minimum versions for Blender 3.6 and 4.0 at the time of writing.
if sys.platform.startswith("win"):
driver_version = "101.4314"
col.label(text="Requires Intel GPU with Xe-HPG architecture", icon='BLANK1')
col.label(text=iface_("and Windows driver version %s or newer") % driver_version, icon='BLANK1', translate=False)
elif sys.platform.startswith("linux"):
driver_version = "1.3.25812"
col.label(text="Requires Intel GPU with Xe-HPG architecture and", icon='BLANK1')
col.label(text=iface_(" - intel-level-zero-gpu version %s or newer") % driver_version, icon='BLANK1', translate=False)
col.label(text=" - oneAPI Level-Zero Loader", icon='BLANK1')
On Windows that means you need driver 101.4314 or newer. On Linux that means you need intel-level-zero-gpu version 1.3.25812 or newer.
The linux packages are a bit confusing for me. So wait for a response from Xavier on the exact packages you need.
But if you’re on Debain, I think you need to install the intel-opencl-icd package. And only the experimental version is new enough to work properly with Blender: Debian -- Details of package intel-opencl-icd in experimental (Version 23.13.26032.7 is newer than the version needed for Blender which is 23.09.25812.14)
A question for @xavier, why are only partial version numbers provided for the Windows driver and intel-level-zero-gpu packages in the Blender UI?
For example, the minimum Windows GPU driver listed in Blender is 101.4314, but there’s no Windows GPU driver by that version number. It’s most likely driver version 31.0.101.4314
As for Linux, it’s a bit confusing.
The minimum supported intel-level-zero-gpu version is 1.3.25812. And that exact package does exist (intel-level-zero-gpu_1.3.25812.14 from here).
But most package managers don’t offer intel-level-zero-gpu as a stand alone package. They seem to bundle it as part of intel-open-icd or the intel-compute-runtime packages which have a different version number (23.09.25812.14).
And once those are installed, I couldn’t find a way to get the version number of intel-level-zero-gpu without going to the exact location where the files were installed, or by going to the Compute Runtime GitHub repo and comparing version numbers between the package manger version of intel-compute-runtime and what the listed intel-level-zero-gpu package was on the Gihub Repo. (This is mostly just double checking as it seems the last part of intel-level-zero-gpu package has the same version number as the last part of intel-compute-runtime. 1.3.25812 and 23.09.25812 both have 25812 on the end)
Is this just a mis-match between Intel and package maintainers? As in package maintainers should be offering intel-level-zero-gpu as a standalone package, but most don’t? Or is this intentional?
Is it better to list the intel-compute-runtime version number in the Blender UI? Or maybe both in something like this:
Requires Intel GPU with Xe-HPG architecture and intel-compute-runtime X.X.X.X
with intel-level-zero-gpu X.X.X
Or maybe:
Requires Intel GPU with Xe-HPG architecture and intel-level-zero-gpu X.X.X,
typically available through the intel-compute-runtime X.X.X.X package
Requires Intel GPU with Xe-HPG architecture and intel-level-zero-gpu X.X.X,
typically available through the intel-compute-runtime X.X.X.X package
sounds good. intel-opencl-icd is not used by Blender 3.x at all, it goes through Level-Zero instead, so really only intel-level-zero-gpu is needed and if it doesn’t exist, it should be provided by intel-compute-runtime that provides both Level-Zero and OpenCL GPU runtimes.
I’ve provided only the last part of the version numbers because that’s how they work.
Windows Drivers versioning scheme: Understanding the Intel® Graphics Driver Version Number only the two last parts correspond to an actual version number, first part is about windows WDDM version.
Same for level-zero, the 1.3 part corresponds to the level-zero API version number, not the actual driver version.
And again for compute-runtime, where the first part is the year + week number of the branch.
A way to get the intel-level-zero-gpu version is to query it using the level-zero API. That’s what sycl-ls tool does but it’s not part of these packages, so it’s a bit inconvenient… checking on libze_intel_gpu.so suffix or package manager info is easier.
It seems Debian may have the name wrong here then. Because it seems intel-opencl-icd is their name for intel-compute-runtime. For example the intel-opencl-icd package originates from the intel-compute-runtime source code, and has support for level zero. Although I could be mis-understanding something here.
So in theory there could be a 30.0.101.4314 and a 31.0.101.4314. Both of them have the same “oneAPI support” but different support for the Windows desktop. In which case I feel like the version number listed in the Blender UI should be:
XX.X.101.4314 (Where obviously the XX.X means those numbers aren’t important if all you’re interested in is oneAPI support), I bring this up because most people will look at the required driver version, 101.4314, and believe they need to look for driver 101.4314 or 101.4314.X.X because most people won’t know about the Intel GPU driver naming scheme until after they read the resource you provided.
If that sounds good to you, then I’ll let you make a pull request for it. You have a better understanding of the exact versioning scheme than I do.
It’s kind of wrong in debian yes. I’ve checked: intel-compute-runtime is a source package, intel-opencl-icd the only binary package for it. before level-zero existed, it made sense as OpenCL was the only provided implementation but I believe they should add an additional intel-level-zero-gpu or intel-compute-runtime binary package.
Ok I agree with your proposal, I’ll do the change.
Ok, so I’ve got my hands on two A770. I needed to reinstall the entire system because ReBAR does not work with CSM/legacy BIOS only UEFI. After that and installing firmware binaries I have a working GPU.
I’ve installed intel-opencl-icd version 22.43.24595.41 from Debian repo. I know that this is not enough for Blender 3.5, 3.6 and 4.0, but Blender 3.4 have clear requirements with xx.xx.23904 or newer driver. So the one I have should be enough, but Blender still does not show any oneAPI devices:
Have you also installed libze1 (sudo apt install libze1)? I believe this is the level zero loader that is listed as the other requirement for oneAPI to work in Cycles.
Rendering in Cycles (3.4) works and the performance is comparable with the OpenData benchmarks. Viewport also works fine, even with bigger scenes.
I’d say so far so good. I hope new drivers drop in the repos soon.
The first pull request aims to improve the initialization time when rendering with multiple GPUs, the second pull request aims to improve work balancing when rendering with multiple GPUs.
