compute-runtime icon indicating copy to clipboard operation
compute-runtime copied to clipboard

Driver Updates for Fedora and CentOS 7

Open jjfumero opened this issue 2 years ago • 16 comments

Hi all, any reason why the driver updates for OpenCL and LevelZero pre-builts for Fedora and CentOS 7 have stopped? We used to get almost every week a new version of the driver and now it is stuck at 21.38.21026. Are there any other official alternatives?

Thank you, Juan

jjfumero avatar Mar 10 '22 12:03 jjfumero

Hi,

I am not sure about the source of packages you're talking about (maybe the copr maintained by @JacekDanecki ?) However, I've started work on packaging some intel packages into Fedora and eg. OpenCL is available in F36 and F37 (not useful much just yet due to https://github.com/intel/intel-graphics-compiler/issues/204 ).

frantisekz avatar Mar 10 '22 15:03 frantisekz

Hi @frantisekz , yes I was referring to the copr packages. Ok, any plans for Fedora 34, 35 as well?

jjfumero avatar Mar 10 '22 15:03 jjfumero

Hi @frantisekz , yes I was referring to the copr packages. Ok, any plans for Fedora 34, 35 as well?

Unfortunately no, just F36 and newer is planned (we're getting into dependency problems and abi/api breaks when I'd want to backport it older releases).

frantisekz avatar Mar 11 '22 21:03 frantisekz

I've upgraded the the (almost) Beta of Fedora 36 and saw that intel-opencl and related packages are now in Fedora! Awesome work! :tada:

However, OpenCL is currently not working with darktable (both intel-opencl, darktable, and necessary dependencies for both in Fedora 36), with this crash:

$ darktable
Abort was called at 39 line in file:
/builddir/build/BUILD/compute-runtime-22.08.22549/shared/source/gmm_helper/client_context/gmm_client_context.cpp
Aborted (core dumped)

(In case it matters: I'm using an Intel Corporation HD Graphics 620 (rev 02) on a Kaby Lake.)

Is this a known issue, related to the compiler updates in Fedora 36 (similar to the issue mentioned above) and the porting process? I would be happy to file this as a separate issue otherwise.

garrett avatar Mar 12 '22 20:03 garrett

I'm running Fedora Rawhide (currently fedora 37) and i'm running into the same exact issue (though it's when i go to use hashcat). I had to end up grabbing the old intel-gmmlib from koji and installing that with the packages from the COPR) CPU: Intel i5-8265U (8) @ 3.900GHz GPU: Intel WhiskeyLake-U GT2 [UHD Graphics 620]

ANeilan avatar Mar 19 '22 02:03 ANeilan

I've played a bit with igc and compute-runtime packaging, it gets further but still crashed on my Skylake iGPU. I'll poke it more in a few days: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4bea4c0834

frantisekz avatar Mar 20 '22 21:03 frantisekz

I've upgraded the the (almost) Beta of Fedora 36 and saw that intel-opencl and related packages are now in Fedora! Awesome work! 🎉

However, OpenCL is currently not working with darktable (both intel-opencl, darktable, and necessary dependencies for both in Fedora 36), with this crash:

$ darktable
Abort was called at 39 line in file:
/builddir/build/BUILD/compute-runtime-22.08.22549/shared/source/gmm_helper/client_context/gmm_client_context.cpp
Aborted (core dumped)

(In case it matters: I'm using an Intel Corporation HD Graphics 620 (rev 02) on a Kaby Lake.)

Is this a known issue, related to the compiler updates in Fedora 36 (similar to the issue mentioned above) and the porting process? I would be happy to file this as a separate issue otherwise.

It looks like gmmlib dependency mismatch, please ensure that you are opening correct gmmlib file.

JablonskiMateusz avatar Mar 21 '22 17:03 JablonskiMateusz

It looks like gmmlib dependency mismatch, please ensure that you are opening correct gmmlib file.

Yeah, I'll add tight gmmlib dependency to compute-runtime package with next update. However, the CL driver will still SIGSEGV until https://github.com/intel/intel-graphics-compiler/issues/204 is fixed unfortunately :(

frantisekz avatar Mar 23 '22 11:03 frantisekz

@frantisekz - I spent the weekend just ended trying to get pyopencl to work with my Comet Lake GT2 hardware. At first I got "No platform found," but I putzed around with it for a while and got that resolved, by placing the file intel-beignet.icd in my /etc/OpenCL/vendors directory. But I believe the file that leads to is too old - it properly reads my device id (9b41), but doesn't recognize it. So now it just fails on platform.get_devices() instead ot get_platform.

So, I feel like I'm awfully close - I feel like if I could just have that icd file target the right file, it would work. But - I'm a total noob at this and don't really thoroughly understand what I'm doing; I could be totally wrong. I think I need OpenCL 3.0, and that setup reports version 1.2 via get_platforms().

Anyway, it sounds like you've done some good work on this front; I thought you might have a file you could toss at me. I also went over to linux_hardware.org and used their "probe" feature to create a web page documenting my system - that is here:

https://linux-hardware.org/?probe=cd9d75f503

So, if you have any advice or files you could send me I'd be much obliged.

Oh, the file that intel-beignet.icd points to currently (that fails to recognize my device) is

/home/kipingram/anaconda3/lib/beignet/libcl.so

I did a little research and found a current package that said it provided libcl.so, installed it, and re-aimed the icd file at that (with high hopes) but all that did was get me back to the No Platform Found error.

Thanks, Kip

KipIngram avatar Apr 18 '22 19:04 KipIngram

@KipIngram Beignet is the legacy Intel CL driver project, for old Intel HW. Issues related to that do not belong to this project. This one (compute-runtime project / intel-opencl RPM package) provides driver for the current HW (Broadwell/Skylake and everything newer).

eero-t avatar Apr 19 '22 08:04 eero-t

Thanks eero-t. Then I guess I've found the right place - I just need to figure out how to get this project flying on my system. I tried building it a day or two ago, but ran into problems. It called for intel-graphics-compiler, so I went off to get that, and that build didn't like my llvm - apparently my llvm is too new to suit it. So that path dead-ended there. I came back here today to see if I could find a pre-built rpm for my system, but I'm on Fedora 34 and it looks like there isn't one for that. I considered trying to install the Fedora 36 rpm anyway, but honestly I was afraid I'd break something, and I really don't want to do that.

The good news I got from the comments above is that it looks like this is on its way to becoming a stock part of Fedora, so maybe the smart thing for me to do is just wait patiently. It's not like I have a project RIGHT NOW that requires this - it's mostly just a capability I'd like to have working. I found a little language a few days ago called futhark that will make python modules that use the GPU, and I figured if that worked then I could use that python code from Jupyter Notebook, and that would be a fairly cool setup. And definitely the "best I could do" on my personal hardware.

I wound up with two entire toolchains working - I got Cray's Chapel language all set up, and I got the futhark/Python/pyopencl path working - except for that last link in the chain; I got "No Platform Found" in both cases. So in an overall sense I'm "ready to go" - maybe now I just wait for Fedora to take care of the rest. At least finding the beignet stuff let me test one further step in the process - I now know that I have code that is trying to talk to my GPU, and succeeding, but just getting a result it doesn't know how to handle.

Anyway, thanks again - I will lurk here and keep tabs on how things are unfolding.

KipIngram avatar Apr 19 '22 14:04 KipIngram

Getting into Fedora 36, the OpenCL installation works with the corresponding packages:

intel-compute-runtime
intel-igc
intel-opencl

However, I can't find the drivers for Level Zero. I think it should be this one:

intel-level-zero-gpu

Am I missing something? Is there any way to obtain this package for Fedora 36?


[UPDATE] I segfaults when building an OpenCL program (clBuildProgram), I will investigate this further.

# C  [libLLVM-13.so+0xc986b4]  llvm::PointerType::get(llvm::Type*, unsigned int)+0x24

jjfumero avatar May 13 '22 09:05 jjfumero

@jjfumero I assume you're using packages from the Fedora repositories. Crash is Fedora bug, please file bug against Fedora.

They should build Intel compute stack with LLVM 11 or 12, as IGC does not support LLVM 13 yet: https://github.com/intel/intel-graphics-compiler/issues/204

FYI: support status for different LLVM versions is documented here: https://github.com/intel/intel-graphics-compiler/projects


As to level-zero support, upstream Fedora does not include level-zero headers, so their compute-runtime build will not enable level-zero support, only OpenCL.

Here's a generic bug about level-zero support in distros: https://github.com/oneapi-src/level-zero/issues/73

But if you're specifically interested about Fedora, please file a bug for enabling level-zero also to RedHat / Fedora.

Level-zero is trivial to build, and during past few years, I've never had issues with level-zero support being enabled in compute-runtime, so I do not see why they would not do it. E.g. latest release of Gromacs HPC application has already deprecated OpenCL support, and does certain GPU optimizations only with its Level-Zero backend, so it's IMHO high time for distros to start enabling level-zero support...

eero-t avatar May 13 '22 10:05 eero-t

Thanks @eero-t . Yes, I was using the packages from the Fedora repositories. I will file the bug. Hope this can be solved soon!

jjfumero avatar May 13 '22 10:05 jjfumero

Okay, I've managed to collect bunch of patches and built new igc and the CL runtime: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2c501774cf

It should hit f36 updates-testing repository tomorrow (and stable f36 updates in a few days). It seems to work well for me (clinfo, clpeak don't crash).

There may be some bugs as per https://github.com/intel/intel-graphics-compiler/pull/242#issuecomment-1132783827 the LLVM 14 support isn't complete.

I'll add level-zero support in the near future, but I don't have free cycles for it atm.

frantisekz avatar May 29 '22 11:05 frantisekz

I'll add level-zero support in the near future, but I don't have free cycles for it atm.

@frantisekz No changes are needed in compute-runtime building for that, level-zero lib + headers just need to be present, for L0 support to be automatically built.

For reference, this is what I use to build L0:

# 2022-05-18: https://github.com/oneapi-src/level-zero/releases
ARG TAG_LEVEL0=v1.8.1
# Install Level Zero API
RUN git clone --branch ${TAG_LEVEL0} https://github.com/oneapi-src/level-zero.gi
t  && \
    cd level-zero  &&  mkdir build  &&  cd build  &&  \
    cmake -LH -Wno-dev -G Ninja \
      -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} -DCMAKE_BUILD_TYPE=Release \
      ../  && \
    ninja  &&  ninja install  && \
    cd ../..  &&  rm -rf level-zero

Which produces:

-- Install configuration: "Release"
-- Installing: /usr/local/include/level_zero/ze_api.h
-- Installing: /usr/local/include/level_zero/ze_ddi.h
-- Installing: /usr/local/include/level_zero/zes_api.h
-- Installing: /usr/local/include/level_zero/zes_ddi.h
-- Installing: /usr/local/include/level_zero/zet_api.h
-- Installing: /usr/local/include/level_zero/zet_ddi.h
-- Installing: /usr/local/include/level_zero/layers/zel_tracing_api.h
-- Installing: /usr/local/include/level_zero/layers/zel_tracing_ddi.h
-- Installing: /usr/local/include/level_zero/layers/zel_tracing_register_cb.h
-- Installing: /usr/local/include/level_zero/loader/ze_loader.h
-- Installing: /usr/local/lib/libze_loader.so.1.8.1
-- Installing: /usr/local/lib/libze_loader.so.1
-- Installing: /usr/local/lib/libze_loader.so
-- Installing: /usr/local/lib/pkgconfig/libze_loader.pc
-- Installing: /usr/local/lib/pkgconfig/level-zero.pc
-- Installing: /usr/local/lib/libze_validation_layer.so.1.8.1
-- Installing: /usr/local/lib/libze_validation_layer.so.1
-- Installing: /usr/local/lib/libze_validation_layer.so
-- Installing: /usr/local/lib/libze_tracing_layer.so.1.8.1
-- Installing: /usr/local/lib/libze_tracing_layer.so.1
-- Installing: /usr/local/lib/libze_tracing_layer.so

With L0 files being present, compute-runtime installs:

-- Install configuration: "Release"
-- Installing: /etc/OpenCL/vendors/intel.icd
-- Installing: /usr/local/bin/ocloc
-- Installing: /usr/local/lib/libocloc.so
-- Installing: /usr/local/include/ocloc_api.h
-- Installing: /usr/local/lib/intel-opencl/libigdrcl.so
-- Installing: /usr/local/lib/libze_intel_gpu.so.1.3.0
-- Installing: /usr/local/lib/libze_intel_gpu.so.1

I.e. there are only 2 additional files you need to split into a separate package.

I looked for package naming and description to compute-runtime project's own RPM spec, and it builds L0 support separately: https://github.com/intel/compute-runtime/blob/master/scripts/packaging/l0_gpu_driver/rhel_8/SPECS/l0_gpu_driver.spec

From OpenCL support (both disable support for the other API): https://github.com/intel/compute-runtime/blob/master/scripts/packaging/opencl/rhel_8/SPECS/opencl.spec

But to save build time, I'm myself building both at the same time. I guess upstream distro packages could do the same?

PS. I have no idea what's the point of the extra %{_sharedstatedir}/libze_intel_gpu/* files that above L0 spec file installs. Ubuntu package includes those too, but when I installed that, they are zero sized...

eero-t avatar May 30 '22 08:05 eero-t

There are no plans for proactive enabling and distro adoption except for Ubuntu. We are open to accepting contributions (pull requests) that unblock support.

AdamCetnerowski avatar Nov 24 '22 08:11 AdamCetnerowski

@eero-t Level Zero is now enabled in Fedora 38 and 39 ( https://github.com/intel/compute-runtime/issues/601#issuecomment-1435533403 ).

frantisekz avatar Feb 18 '23 09:02 frantisekz