Skip to content

[UR] [L0] Update UR to link the Loader as static #17104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 5 commits into from
Mar 3, 2025
Merged

[UR] [L0] Update UR to link the Loader as static #17104

merged 5 commits into from
Mar 3, 2025

Conversation

nrspruit
Copy link
Contributor

@nrspruit nrspruit requested a review from a team as a code owner February 20, 2025 19:50
@nrspruit nrspruit marked this pull request as draft February 20, 2025 19:50
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 858bf8e to ede56fc Compare February 20, 2025 20:02
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from f2acc4b to 21a5d24 Compare February 20, 2025 21:43
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 21a5d24 to 58af49a Compare February 21, 2025 00:24
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 58af49a to 2d50a46 Compare February 21, 2025 19:55
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 8813cf5 to 5111c42 Compare February 24, 2025 17:16
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch 2 times, most recently from 36184a8 to ca6e297 Compare February 27, 2025 22:41
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from ca6e297 to 5be38f0 Compare February 27, 2025 22:49
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 5be38f0 to 2594d84 Compare February 28, 2025 00:12
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 2594d84 to 6c3afe7 Compare February 28, 2025 00:27
@nrspruit
Copy link
Contributor Author

only failure so far is actually on opencl, not L0 after the last updates.

@nrspruit
Update UR to link the Loader as static
15910d2 
- [L0] Update to build L0 Adapter with static loader in all times
- Fix urKernelCreateWithNativeHandle to properly init L0 before use
- Fix v2 tests that directly link Loader which statically link

Signed-off-by: Neil R. Spruit <[email protected]>
@nrspruit
Add debug
eaae413 
Signed-off-by: Neil R. Spruit <[email protected]>
@nrspruit
Update to use offical master patch of Loader
6134512 
Signed-off-by: Neil R. Spruit <[email protected]>
@nrspruit
Use stype fixed loader repo
076dc68 
Signed-off-by: Neil R. Spruit <[email protected]>
@nrspruit
Delay L0 loader destruction and fix ZeCommandListImmediateAppendExt init
fe0d8a5 
Signed-off-by: Neil R. Spruit <[email protected]>
@nrspruit nrspruit force-pushed the UR_L0_STATIC_LOADER branch from 6c3afe7 to fe0d8a5 Compare February 28, 2025 17:43
@nrspruit nrspruit marked this pull request as ready for review February 28, 2025 20:25
@nrspruit nrspruit requested a review from a team as a code owner February 28, 2025 20:25
aelovikov-intel
aelovikov-intel reviewed Feb 28, 2025
View reviewed changes
Copy link
Contributor

@aelovikov-intel aelovikov-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add some UR folks to review "devops" part explicitly? I'm not sure what our long-term "CODEOWNERS" policy for UR-specific CI would be.

.github/workflows/ur-build-hw.yml
env:
ZE_ENABLE_LOADER_DEBUG_TRACE: 1
ZE_DEBUG: 1
run: env UR_CTS_ADAPTER_PLATFORM="${{matrix.adapter.platform}}" ctest -C ${{matrix.build_type}} --test-dir ${{github.workspace}}/build --output-on-failure -L "conformance" --timeout 600 -VV
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move UR_CTS_ADAPTER_PLATFORM to env: section as well?

Copy link
Contributor Author

@nrspruit nrspruit Feb 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that would be best added in a separate PR to improve the settings in the UR workflows. The additional L0 envs were for seeing when the loader is init in case of failures.

@nrspruit
Copy link
Contributor Author

nrspruit commented Mar 3, 2025

@intel/llvm-gatekeepers , since a member or UR team has approved these changes, can we have this merged? This only affects the UR code and CI. Thank you for your time!

@kbenzie
Copy link
Contributor

kbenzie commented Mar 3, 2025

This still requires approvall from @intel/dpcpp-devops-reviewers

@sarnex
Copy link
Contributor

sarnex commented Mar 3, 2025

luckily i am both in devops and gatekeepers :P

sarnex
sarnex approved these changes Mar 3, 2025
View reviewed changes
Copy link
Contributor

@sarnex sarnex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm assuming andrei's feedback is addressed in a separate pr

@sarnex sarnex merged commit f01edd3 into intel:sycl Mar 3, 2025
30 checks passed
This was referenced Mar 4, 2025
Closed
Merged
joeatodd pushed a commit to codeplaysoftware/cutlass-sycl that referenced this pull request Mar 4, 2025
@sommerlukas
Workaround DPCTL Level Zero issue (#242)
9a424b3 
The static linking of the Level Zero loader into the Level Zero adapter
in intel/llvm#17104 causes DPCTL's logic to
detect the name of the Level Zero loader library to fail:
IntelPython/dpctl#2022

This in turn causes the creation of a SYCL `kernel_bundle` from SPIR-V
in the Python interface to fail and leads to CI failures on unrelated
branches.

This PR brings a workaround for this issue, by using a CMake fix for
DPCTL.
taozha2 pushed a commit to taozha2/cutlass-fork that referenced this pull request Mar 6, 2025
@sommerlukas @taozha2
Workaround DPCTL Level Zero issue (codeplaysoftware#242)
cc0c37b 
The static linking of the Level Zero loader into the Level Zero adapter
in intel/llvm#17104 causes DPCTL's logic to
detect the name of the Level Zero loader library to fail:
IntelPython/dpctl#2022

This in turn causes the creation of a SYCL `kernel_bundle` from SPIR-V
in the Python interface to fail and leads to CI failures on unrelated
branches.

This PR brings a workaround for this issue, by using a CMake fix for
DPCTL.
tdeng5 pushed a commit to taozha2/cutlass-fork that referenced this pull request Mar 6, 2025
@sommerlukas @tdeng5
Workaround DPCTL Level Zero issue (codeplaysoftware#242)
41550f1 
The static linking of the Level Zero loader into the Level Zero adapter
in intel/llvm#17104 causes DPCTL's logic to
detect the name of the Level Zero loader library to fail:
IntelPython/dpctl#2022

This in turn causes the creation of a SYCL `kernel_bundle` from SPIR-V
in the Python interface to fail and leads to CI failures on unrelated
branches.

This PR brings a workaround for this issue, by using a CMake fix for
DPCTL.
tdeng5 pushed a commit to taozha2/cutlass-fork that referenced this pull request Mar 14, 2025
@sommerlukas @tdeng5
Workaround DPCTL Level Zero issue (codeplaysoftware#242)
25abeb4 
The static linking of the Level Zero loader into the Level Zero adapter
in intel/llvm#17104 causes DPCTL's logic to
detect the name of the Level Zero loader library to fail:
IntelPython/dpctl#2022

This in turn causes the creation of a SYCL `kernel_bundle` from SPIR-V
in the Python interface to fail and leads to CI failures on unrelated
branches.

This PR brings a workaround for this issue, by using a CMake fix for
DPCTL.
tdeng5 pushed a commit to taozha2/cutlass-fork that referenced this pull request Mar 14, 2025
@sommerlukas @tdeng5
Workaround DPCTL Level Zero issue (codeplaysoftware#242)
599fb24 
The static linking of the Level Zero loader into the Level Zero adapter
in intel/llvm#17104 causes DPCTL's logic to
detect the name of the Level Zero loader library to fail:
IntelPython/dpctl#2022

This in turn causes the creation of a SYCL `kernel_bundle` from SPIR-V
in the Python interface to fail and leads to CI failures on unrelated
branches.

This PR brings a workaround for this issue, by using a CMake fix for
DPCTL.
ndgrigorian added a commit to IntelPython/dpctl that referenced this pull request Mar 18, 2025
@ndgrigorian
Fix Level Zero Loader detection when statically linked
4b89b07 
SYCL nightly and future builds now link libur_adapter_level_zero to the level zero loader statically, so detecting through readelf is no longer possible

For this case, we instead set the default Level Zero Loader filename to be 'libze_loader.so.1,' which is likely to not change

See: intel/llvm#17104
@ndgrigorian ndgrigorian mentioned this pull request Mar 18, 2025
Merged
8 tasks
ndgrigorian added a commit to IntelPython/dpctl that referenced this pull request Mar 29, 2025
@ndgrigorian
Fix Level Zero Loader detection when statically linked
2f16546 
SYCL nightly and future builds now link libur_adapter_level_zero to the level zero loader statically, so detecting through readelf is no longer possible

For this case, we instead set the default Level Zero Loader filename to be 'libze_loader.so.1,' which is likely to not change

See: intel/llvm#17104
ndgrigorian added a commit to IntelPython/dpctl that referenced this pull request Mar 31, 2025
@ndgrigorian
Fix Level Zero Loader detection when statically linked
2b5f45d 
SYCL nightly and future builds now link libur_adapter_level_zero to the level zero loader statically, so detecting through readelf is no longer possible

For this case, we instead set the default Level Zero Loader filename to be 'libze_loader.so.1,' which is likely to not change

See: intel/llvm#17104
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aelovikov-intel aelovikov-intel aelovikov-intel left review comments

@sarnex sarnex sarnex approved these changes

@igchor igchor igchor approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@nrspruit @kbenzie @sarnex @igchor @aelovikov-intel