KhronosGroup / KhronosGroup/OpenCL-Docs
Semantics around clIcdSetPlatformDispatchDataKHR and clGetDeviceIDs needs further clarification
- Dominant language
- Python
- Stars
- 420
- Forks
- 131
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 11
Description
I'm trying to implement `cl_khr_icd` version 2.0.0 and I'm curious on the semantics of `clIcdSetPlatformDispatchDataKHR` in regards to `cl_device_id` objects.
The spec states that "The vendor driver is responsible for propagating the dispatch_data value when returning objects to users.", however implementations might not return new `cl_device_id` every time `clGetDeviceIDs` gets called and reuse them internally. At least I don't think there was a reason that prevented this.
Now with `cl_khr_icd` version 2.0.0 each object returned has this `dispatch_data` field, and an implementation may initialize the `cl_device_id` before or after the `clIcdSetPlatformDispatchDataKHR` call.
My assumption is, that the ICD loader will do so on its initialization routine, so an implementation could just update the `dispatch_data` field of all already created `cl_device_id` objects inside `clIcdSetPlatformDispatchDataKHR`.
What I'm more curious about is, is the ICD loader allowed to call `clIcdSetPlatformDispatchDataKHR` later on again? What if `clGetDeviceIDs` gets called again? Do the devices have to contain the updated `dispatch_data` value potentially updating it also for previously returned `cl_device_id` objects?
Is the assumption that `clIcdSetPlatformDispatchDataKHR` gets only called exactly once and none of those issues are of any concern? I'm assuming this was the intention, but I think it would be better to clarify the expectations here.
Contributor guide
Research direction
Review the cl_khr_icd 2.0.0 specification language for clIcdSetPlatformDispatchDataKHR, clGetDeviceIDs, and cl_device_id dispatch_data propagation. Trace the questions raised in this issue and its comment discussion, then identify the expected call timing and behavior for reused or previously returned device objects. Done means the specification expectations are stated unambiguously.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100