[SYCL][DOC] Describe process of prototyping KHR extensions #16883
Conversation
sycl/doc/developer/KHRExtensions.md
Outdated
| Note: merge of an extension proposal PR into KhronosGroup/SYCL-Docs repo is | ||
| **not** considered to be a publishing event. The extension specification has | ||
| to be available on the Khronos SYCL Registry website: | ||
| https://registry.khronos.org/SYCL/ |
There was a problem hiding this comment.
I'm not sure about this part. For changes to the SYCL specification, we usually consider a change to be "accepted" by the Khronos WG when the PR is merged to the SYCL-Docs repo. Why not follow the same strategy for KHRs?
More precisely, I think we should wait for the KHR to be merged / cherry-picked to the "sycl-2020" branch of SYCL-Docs. We don't do this until the KHR has been approved by the WG and also ratified by the Khronos board.
There was a problem hiding this comment.
I'm not sure about this part. For changes to the SYCL specification, we usually consider a change to be "accepted" by the Khronos WG when the PR is merged to the SYCL-Docs repo. Why not follow the same strategy for KHRs?
I guess my point was also to wait until the documentation is publicly available to end users in some friendly form. But I agree that this is not a critical thing so I'm fine with different wording here.
More precisely, I think we should wait for the KHR to be merged / cherry-picked to the "sycl-2020" branch of SYCL-Docs. We don't do this until the KHR has been approved by the WG and also ratified by the Khronos board.
Sure, I can apply that
There was a problem hiding this comment.
Reworded that bullet in 0588f7f
AlexeySachkov
deleted the
private/asachkov/dev-process-for-khr-extensions
branch
Functionality guarded by __DPCPP_ENABLE_UNFINISHED_KHR_EXTENSIONS, following the process introduced by intel#16883. Signed-off-by: John Pennycook <john.pennycook@intel.com>
|
Doesn't that apply to the changes to the SYCL specification itself? Should we extend that document to it as well? |
No description provided.