Change urDeviceCreateWithNativeHandle to take an adapter handle. #1953
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
github-actions
bot
added
loader
It currently takes a platform handle, which is problematic for the sycl RT because its make_device api only takes a native handle, so to figure out the correct platform handle to pass at best we'd need to do some backend specific querying of the native object, but even then that isn't always possible as not all backends have a platform equivalent. The platform handle does currently enable an optional (slightly) faster path to return the correct device in some adapter implementations but this isn't essential for them to work, so really its primary purpose is to serve as the wrapped UR handle for the loader to work. This purpose is equally well served by an adapter handle, which will also be a lot easier for the sycl rt to correctly provide.
aarongreig
force-pushed
the
aaron/changeDeviceCreateWithNativeParam
branch
from
f942502 to
a4c6e91
Compare
Contributor
Author
|
LLVM PR intel/llvm#15023 sycl-e2e jobs here will fail due to missing accompanying rt change |
Contributor
Author
|
ping @oneapi-src/unified-runtime-native-cpu-write @oneapi-src/unified-runtime-cuda-write @oneapi-src/unified-runtime-hip-write @oneapi-src/unified-runtime-level-zero-write @oneapi-src/unified-runtime-maintain this is necessary a fix for the release |
PietroGhg
approved these changes
Aug 14, 2024
keyradical
approved these changes
Aug 14, 2024
kbenzie
approved these changes
Aug 14, 2024
kbenzie
pushed a commit
that referenced
this pull request
Aug 20, 2024
…NativeParam Change urDeviceCreateWithNativeHandle to take an adapter handle.
53 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
It currently takes a platform handle, which is problematic for the sycl RT because its make_device api only takes a native handle, so to figure out the correct platform handle to pass at best we'd need to do some backend specific querying of the native object, but even then that isn't always possible as not all backends have a platform equivalent.
The platform handle does currently enable an optional (slightly) faster path to return the correct device in some adapter implementations but this isn't essential for them to work, so really its primary purpose is to serve as the wrapped UR handle for the loader to work. This purpose is equally well served by an adapter handle, which will also be a lot easier for the sycl rt to correctly provide.