Comments (12)
There is definitely one bug that needs fixed here in the loader. It needs a proper error message when not finding a value driver, segfaulting is not a great error message.
from level-zero.
Is there an intel-level-zero-gpu package installed? This is more likely a bug in not finding the associated runtime. Above you are showing the OpenCL driver, but that is not a driver for Level Zero.
Do you have package similar to this installed:
intel-level-zero-gpu_0.8.16259_amd64.deb
Since I am not that familiar with ArchLinux it would be worth mentioning if this is installed, where the actual shared library got installed (i.e. show the path) and the SONAME.
If you don't have this package or similar then this is the bug. :-)
from level-zero.
I assumed the compute runtime contained a level zero driver after intel/compute-runtime@27f4bce, if not where do I get it from? I'm currently using the Arch packages to do some initial experimentation, but for the Julia oneAPI support I'm working on I plan to redistribute necessary dependencies myself.
from level-zero.
That SHA should be fine yes... Question is how and what did you install? The repository is capable of building both Level Zero and OpenCL. https://github.com/intel/compute-runtime/releases/tag/20.12.16259 Please note that OpenCL and Level Zero are different packages.
Can you show me a list of all the level zero packages current installed in the system?
If this was Debian i'd ask for : dpkg --list | grep "level-zero"
but I am not sure what ArchLinux uses for package manager, or if you built installed yourself, then what list of binaries did you get and install? Hopefully you have a libze_intel_gpu.so.0.8.16259 someplace in the searchable runtime paths.
$ cd /
find . | grep libze_intel_gpu
from level-zero.
There isn't a specific level zero package on Arch, just the compute runtime built like this: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/intel-compute-runtime -- maybe it is incorrectly built, or doesn't install the level zero driver?
I have version 20.12.16259 of that package, and thus the runtime, which should include the hash I linked to as per the Github UI.
EDIT: ah, didn't properly read your comment, no it does not ship libze_intel_gpu. I'll build it myself.
from level-zero.
Also not sure who maintains the inclusion into the ArchLinux for compute-runtime, but it may be worth pinging them and letting them know that Level Zero uses different standard versioning, i.e. SEMVER vs the date based versioning schema for the OpenCL packages. This may not work so well going forward them using a singular package for both different products.
from level-zero.
Rebuilding the package gave me a libze_intel_gpu, strange how it wasn't included in the Arch package. I filed a bug.
On a related note, why isn't the level zero driver included in the intelopencl/intel-opencl:ubuntu-18.04-ppa docker images?
from level-zero.
On a related note, why isn't the level zero driver included in the intelopencl/intel-opencl:ubuntu-18.04-ppa docker images?
Or, related I guess, why the level-zero package isn't available on the ppa that is used in the docker images: https://launchpad.net/~intel-opencl/+archive/ubuntu/intel-opencl
from level-zero.
On a related note, why isn't the level zero driver included in the intelopencl/intel-opencl:ubuntu-18.04-ppa docker images?
Level Zero and OpenCL as a product are not the same. Today only the Intel and OpenCL specific implementations share a chunk of common code for gpu implementation, but their interfaces, specifications, ABI/API's and products that support that are completely different. Level Zero is a vendor agnostic loader. No single vendor should be shipping it inside a specific HW implementation package. This is not to dissimilar to the the loader that OpenCL uses. This package should eventually support any number of vendors and HW implementations. This it should not belong inside any of them or you will have package collisions.
Also Linux standards from major distro's call out that stand alone shared libraries should ALWAYS ship in a single package that is named and versioned per the share library being contained. FYI, This is something that ArchLinux seems to consistently violate and it makes vendor support very very difficult... Having these stand alone shared library packages is very necessary to manage package dependencies at install time, through things like yum, dnf, yast, yast2, dpkg, etc...
If you have time here is a great read:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries
Without policies like this being followed it becomes nearly impossible to upgrade things. Imagine having to replace your entire /usr/ partition each time glibc patched itself. This is the model we are trying to avoid with good practices.
from level-zero.
I get all that, and I'm not asking anything about packages, but why the example Docker images built on the "Intel(R) Graphics Compute Runtime" PPA don't include a Level Zero driver (not installed, but also not available in the PPA). I had hoped to be able to use that image for CI purposes.
This is something that ArchLinux seems to consistently violate and it makes vendor support very very difficult...
I'm not an Arch developer, just a user...
FWIW, for the Julia package I'm developing I was hoping to ship the Level Zero loader and (if applicable) the matching NEO implementation myself, but apparently opencl-clang, as required by the intel-graphics-compiler, isn't cross-compilable, and Julia's infrastructure for building binaries for users is based on cross compilation. So for now I'm using my distro's packages.
from level-zero.
So there are a lot of things that likely will come along in the near future. This current release is a early preview, hence the pre-1.0 version schema both for the loader and today for the intel-level-zero-gpu package. If you are putting this into production, do realize things will be changing from an API compatibility perspective fairly rapidly. SEMVER isn't a solid guarantee pre-1.0.
There are some preliminary plans to get some kind of CI online for the public, which could then be borrowed, this is still being worked. Perhaps in the future a docker image will exist for oneAPI and/or Level Zero related content. However, it should be noted here that CI for the Level Zero (loader) will not include vendor specific stacks.
Level Zero is part of the oneAPI industry initiative, today OpenCL is not, so it doesn't make sense from a specification standpoint to merge these goals or products.
https://spec.oneapi.com/versions/latest/index.html
but apparently opencl-clang, as required by the intel-graphics-compiler, isn't cross-compilable,
I would encourage filing this issue over in the www.github.com/intel/compute-runtime
Thank you for the feedback. It is good to receive the pain points and how the community is using this.
from level-zero.
However, it should be noted here that CI for the Level Zero (loader) will not include vendor specific stacks.
Sure, I just asked the question here since I had an issue open :-) Thanks for the replies!
from level-zero.
Related Issues (20)
- Preferred abbreviation: ZE or L0? HOT 1
- [Error] Don't get kernel HOT 1
- v1.15.1: Debs Prefix/Install Paths Appear to Be Wrong in Release Artifacts HOT 7
- Incorrect libdir in pkg-config files
- `zesMemoryGetState` only works under root user HOT 4
- Convenience method for error processing
- Can't find binaries for windows
- TEST 'IMEX :: Integration/Dialect/XeGPU/gemm_4kx4kx4k_f16_f16_f16_w_8x32xf16_stores.mlir' FAILED HOT 1
- Error when loading level_zero lib for `zesInit()` on windows client HOT 2
- Conflict with DLLs already in system32
- `zesDeviceEnumFabricPorts` and `subdevice`
- Finding the cause for ZE_RESULT_ERROR_UNINITIALIZED HOT 2
- Support static version of ZE loader library
- Missing ze_loader.dll HOT 2
- The level zero laoder should look into LIBRARY_PATH to find shared objects HOT 2
- [question] How to know if there are pending commands in a command list/queue
- WSL: zesInit segfaults HOT 1
- Compilation fails with sytem spdlog and libfmt HOT 1
- Intel level zero Compute is broken for my Intel Arc A750LE with linux kernel version 6.6.27 and above HOT 5
- Compilation fails for GCC 14.0.1 and Fedora 40
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from level-zero.