KhronosGroup / KhronosGroup/OpenCL-Docs
Unclear semantics of clReImportSemaphoreSyncFdKHR in regards to clEnqueueWaitSemaphoresKHR and clEnqueueSignalSemaphoresKHR
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 421
- Forks
- 132
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 11
Description
At the moment the spec doesn't specify if clEnqueueSignalSemaphoresKHR and clEnqueueWaitSemaphoresKHR operate on the semaphore already imported at call time or the currently imported semaphore once the queue reaches those commands.
I'd assume it's meant to operate on the already imported semaphore and clReImportSemaphoreSyncFdKHR just affects future calls to those. But I think this is a valid assumption to make just reading the specification.
I think "Calling clReImportSemaphoreSyncFdKHR is equivalent to destroying sema_object and re-creating it with the original sema_props from clCreateSemaphoreWithPropertiesKHR" can be read this way, but I think it's better to explicitly state this.
Any thoughts?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the specification sections for clReImportSemaphoreSyncFdKHR, clEnqueueWaitSemaphoresKHR, and clEnqueueSignalSemaphoresKHR, including the statement about destroying and recreating the semaphore. Done means the specification explicitly defines whether queued operations use the semaphore imported at call time or the semaphore imported when the commands execute.
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
- Mostly clear
- Newbie friendliness
- 35/100