KhronosGroup / KhronosGroup/SYCL-Docs
OpenCL make_device ownership of native device should be uniqued?
- Dominant language
- JavaScript
- Stars
- 158
- Forks
- 80
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 5
Description
https://github.com/intel/llvm/issues/6055 raised the issue that some implementations may allow `make_device` to return a duplicate sycl::device if there is already a `sycl::device` owning the specified native device provided as an argument to `make_device`. One implication of this is that there can be multiple `sycl::device`s that independently reference count a single native device and therefore there can be multiple independent `sycl::device` responsible for destruction of a single native device. A draft "fix" for this is here : https://github.com/intel/llvm/pull/6204.
Assuming that sycl::device is stateless in every backend the request made in https://github.com/intel/llvm/issues/6055 that `sycl::device`s be "uniqued" seems reasonable to me. However I don't see anything covering this in either "4.5.1. Backend interoperability" section of the SYCL 2020 rev 5 spec, or in Appendix "C.7.1. Construct SYCL objects from OpenCL ones".
I would like to clarify which of the following is true (unless there is another option)?
1. Behaviour of `make_device` is implementation defined with regard to "uniqueing" devices. (This is the current state of affairs if we assume that if something isn't mentioned in the spec it is implementation defined).
2. `make_device` should return an existing sycl::device if one already exists with the specified native device.
3. `make_device` should return a new (non "uniqued") sycl::device even if one already exists with the specified native device.
Thanks
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the SYCL 2020 rev. 5 sections cited in the issue: 4.5.1, “Backend interoperability,” and Appendix C.7.1, “Construct SYCL objects from OpenCL ones.” Compare their wording with intel/llvm issues 6055 and pull request 6204; done means the specification’s intended make_device uniqueness behavior is clarified.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100