[SYCL] Lookup versioned OpenCL adapter library as fallback #20229
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
force-pushed
the
private/udit/libur_adapter_ocl
branch
from
6f4c31d to
74c42b3
Compare
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
uditagarwal97
changed the title
libur_adapter_opencl.so.0 to match UR loader
uditagarwal97
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
This reverts commit 22a38f5.
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
uditagarwal97
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
kswiecicki
approved these changes
Sep 30, 2025
uditagarwal97
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
uditagarwal97
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
pushed a commit
to AlexeySachkov/llvm
that referenced
this pull request
Sep 30, 2025
) **Problem** SYCL RT loads `libur_adapter_opencl.so` (https://github.com/intel/llvm/blob/0ff1a5c2b4e4bc56799ec2dd17a89c3c57608890/sycl/include/sycl/detail/os_util.hpp#L129) while UR loads `libur_adapter_opencl.so.0` (https://github.com/intel/llvm/blob/0031df16e41bd0665e85af635b7bfd4e187ce7cd/unified-runtime/source/loader/ur_manifests.hpp#L35). Note that SYCL RT calls `dlopen()` with `RTLD_NOLOAD` flag, which causes `dlopen()` to fail if this library wasn’t loaded before. Now, in our Linux compiler packages, `libur_adapter_opencl.so` and `libur_adapter_opencl.so.0` are symlinked so they are the same file, that’s why call to `dlopen()` in SYCL RT succeeds. However, the problem happens with DPCPP PyPi package, which doesn’t support symlinked files, so call to dlopen() fails because these are two different files. **Proposed solution** Lookup `libur_adapter_opencl.so.0` as fallback. **Other potential solutions** 1. Why not just load `libur_adapter_opencl.so.0` always? Because that causes SYCL unit tests, which rely on mocked OpenCL adapter to fail. In unit tests, we actually want SYCL RT to load `libur_adapter_opencl.so` (mocked) and UR to load `libur_adapter_opencl.so.0`, both of which are different files. 2. Why not remove `RTLD_NOLOAD` flag? When using PyPi package, that can cause SYCL RT and UR to load two OpenCL adapters libraries. I'm not an expert on loaders, but that might lead to more bugs if, for example, OpenCL adapter functions that SYCL RT calls have side effects.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
SYCL RT loads
libur_adapter_opencl.so(llvm/sycl/include/sycl/detail/os_util.hpp
Line 129 in 0ff1a5c
libur_adapter_opencl.so.0(llvm/unified-runtime/source/loader/ur_manifests.hpp
Line 35 in 0031df1
dlopen()withRTLD_NOLOADflag, which causesdlopen()to fail if this library wasn’t loaded before.Now, in our Linux compiler packages,
libur_adapter_opencl.soandlibur_adapter_opencl.so.0are symlinked so they are the same file, that’s why call todlopen()in SYCL RT succeeds. However, the problem happens with DPCPP PyPi package, which doesn’t support symlinked files, so call to dlopen() fails because these are two different files.Proposed solution
Lookup
libur_adapter_opencl.so.0as fallback.Other potential solutions
libur_adapter_opencl.so.0always? Because that causes SYCL unit tests, which rely on mocked OpenCL adapter to fail. In unit tests, we actually want SYCL RT to loadlibur_adapter_opencl.so(mocked) and UR to loadlibur_adapter_opencl.so.0, both of which are different files.RTLD_NOLOADflag? When using PyPi package, that can cause SYCL RT and UR to load two OpenCL adapters libraries. I'm not an expert on loaders, but that might lead to more bugs if, for example, OpenCL adapter functions that SYCL RT calls have side effects.