[testing] match dpctl attribute get_device_id
attribute in backend SyclDevice
object
#2292
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.
Description
Device id is very important for
__dlpack__
support (used in #2275). The device id is given by dlpack and not queues. Therefore we must reliably construct a queue with the proper matching dlpack device (using a function previously implementedget_queue_by_device_id
located in sycl_interfaces.cpp). This function is currently dead code that will be brought back to life in dlpack support. The device_id for this function come from theget_device_id
which is exposed as an attribute to the backendSyclDevice
(see sycl.cpp), which must be verified to be correct. We usedpctl
as a reference for checking that our device id's are correct in python testing.This will be important for the array_api rollout with SYCL gpu queues. This logic: (https://github.com/uxlfoundation/scikit-learn-intelex/blob/main/onedal/_device_offload.py#L86) must be adapted for SYCL device dlpack data (when the queue is hard to acquire, make it into a device comparison).
NOTE: This dpctl attribute is not yet in a release, so this is pre-emptively matching for the next release.
PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability
Testing
Performance