KhronosGroup / KhronosGroup/SYCL-Docs

OpenCL make_device ownership of native device should be uniqued?

Open
#266 12 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.