[weifengpy]

Problem

On Linux, pyzes loads the Level Zero loader from a hardcoded path:

libName = "/usr/lib/x86_64-linux-gnu/lib" + libName + ".so.1"

When the loader the runtime actually uses lives somewhere else in the standard search path (for example a newer loader installed under /usr/local or shipped with oneAPI), pyzes pins the distro copy instead. A zesInit issued through that mismatched loader copy leaves the process in a state where the oneAPI Unified Runtime no longer enumerates the Level Zero platform at all. Any consumer that queries Sysman before initializing the runtime is then broken for the rest of the process lifetime.

Reproduction

Machine: Intel Arc B580 (Battlemage), NEO 26.40.40196.8, two coexisting loaders:

• /usr/lib/x86_64-linux-gnu/libze_loader.so.1 — 1.16 (Ubuntu libze1 package)
• /usr/local/lib/libze_loader.so.1 — 1.35 (built from this repo), the copy the SYCL runtime resolves

PyTorch (both the 2.15.0+xpu wheel and a source build) routes torch.xpu.device_count() through pyzes before XPU initialization:

import torch
torch.xpu.is_available()            # True
torch.xpu.device_count()            # 1 (via pyzes / Sysman)
torch.xpu.get_device_properties(0)  # RuntimeError: No XPU devices are available.
                                    # preceded by "XPU device count is zero!"

Calling get_device_properties first works fine. A minimal SYCL probe confirms the mechanism outside PyTorch: after dlopen of the distro loader plus zesInit/zesDriverGet/zesDeviceGet through it, sycl::platform::get_platforms() no longer lists the Level Zero platform; doing the same through the runtime's loader, or not calling zesInit at all, leaves enumeration intact. Replacing the distro loader file's contents with the newer loader also makes the failure disappear, confirming the trigger is which loader copy serves the Sysman calls.

Fix

Load libze_loader.so.1 by SONAME on Linux so the dynamic linker resolves it through the standard search path (LD_LIBRARY_PATH, the ld.so cache, default directories) — the same copy every other consumer gets. The distro location remains reachable that way, so no supported configuration loses access to the loader.

Testing

On the system above, with the distro 1.16 loader restored so both loaders coexist:

• Before the fix: the PyTorch sequence above fails as shown.
• After the fix (patched pyzes on PYTHONPATH): pyzes.gpuLib._name is libze_loader.so.1, the same sequence returns the B580 from get_device_properties, and an XPU matmul runs correctly.

This PR was prepared with the assistance of an AI coding tool and reviewed by the author.

[weifengpy]

Downstream report with the full investigation and reproduction details: pytorch/pytorch#204338

[guangyey]

@shubskmr Could you please help review this code change?

[shubskmr]

lgtm