compile error on MAX 1100: level-zero-tests/utils/test_harness/src/test_harness_device.cpp:90:32: error: ‘zeDeviceGetRootDevice’ was not declared in this scope; did you mean ‘zeDeviceGetSubDevices’

[KevinYuk]

/home/dev/level-zero-tests/utils/test_harness/src/test_harness_device.cpp: In function ‘_ze_device_handle_t* level_zero_tests::get_root_device(ze_device_handle_t)’:
/home/dev/level-zero-tests/utils/test_harness/src/test_harness_device.cpp:90:32: error: ‘zeDeviceGetRootDevice’ was not declared in this scope; did you mean ‘zeDeviceGetSubDevices’?
90 | EXPECT_EQ(ZE_RESULT_SUCCESS, zeDeviceGetRootDevice(device, &root_device));
| ^~~~~~~~~~~~~~~~~~~~~
gmake[2]: *** [utils/test_harness/CMakeFiles/test_harness.dir/build.make:76: utils/test_harness/CMakeFiles/test_harness.dir/src/test_harness_device.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2063: utils/test_harness/CMakeFiles/test_harness.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

[christgau]

Same issue here, but because headers from the devel packages apparently do not match the version level-zero-tests expects. Unfortunately, the level-zero-tests repo here does not have tags, releases, or even branches (except for master and upstream) so one cannot check which version the commits are build.

What I see in my case it that oneapi-src/level-zero@5d1d2d5 introduced the call in question and also raised the API version to 1.17. However, headers from OS's devel package are at 1.16 (see enum _ze_api_version_t in ze_api.h).

So either build level_zero based on API version 1.17 by yourself or checkout an older commit of level_zero_tests. In the master branch you can guess when the previous "release" has been made, since commits from upstream appear to be moved into master in batches.

I just tried with 9f09c59 from here and devel package with API being at 1.16 (package version is 1.11.0 for whatever reason) and that worked.

[lisanna-dettwyler]

We're weighing the value of fixing backwards-compatibility issues for spec releases prior to 1.8. Is this particular issue still a concern?

[eero-t]

We're weighing the value of fixing backwards-compatibility issues for spec releases prior to 1.8. Is this particular issue still a concern?

@lisanna-dettwyler Besides header guards mentioned in #34, there should be pkg-config check for the minimum required L0 version [1].

---

[1] L0 spec v1.8 was first supported in Oct 2023 release of the L0 frontend: https://github.com/oneapi-src/level-zero/releases/tag/v1.15.1

As to versions of L0 backend & frontend in Linux distros:

• Fedora:
  • https://src.fedoraproject.org/rpms/oneapi-level-zero
  • https://src.fedoraproject.org/rpms/intel-compute-runtime
• Ubuntu:
  • https://packages.ubuntu.com/lunar/libze-dev
  • https://packages.ubuntu.com/source/focal/intel-compute-runtime
• Debian
  • https://packages.debian.org/bookworm/libze-dev
  • https://packages.debian.org/source/bookworm/intel-compute-runtime

Frontend versions are too old in Fedora 38, Debian stable and Ubuntu versions older than 24.04 LTS. But newer Fedora versions, Debian testing and Ubuntu 24.04 LTS do have new enough versions.

=> pkg-check for frontend version 1.15.1 could be fine.

---

As to older spec releases....

zesInit() used in this project came in L0 spec v1.5, which was supported only by L0 frontend v1.9.x (Jan 2023): https://github.com/oneapi-src/level-zero/releases/tag/v1.9.4

But Intel L0 backend had full support for it only since 23.26.26690.12 (Jul 2023): intel/compute-runtime#650

Versions in Debian 12 (Stable / bookworm) are both too old, but Trixie (Testing) versions are both new enough.

All Fedora versions have both new enough frontend & backend, so for Fedora & Debian it would be enough to check for >= 1.9 frontend version.

Ubuntu 23.10 is problematic, it has new enough frontend (1.12), but backend is way too old (22.x) [2]. I think that can be ignored though as it's soon out of support and in the new 24.04 LTS, both are new enough.

[2] So in 23.10, L0 backend would return "uninitialized" error when Sysman plugin calls frontend zesInit() function, whereas with zeInit() everything would work fine.

=> Supporting older versions does not seem worth the trouble, unless distros L0 backend versions for v1.8 spec could cause issues?