-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce extension macros #251
Conversation
This extension adds the revision field to the XML tag for extensions. This allows a version macro to be generated with: * KhronosGroup/OpenCL-Headers#251 * KhronosGroup/OpenCL-Headers#248 Marked as **Draft** as I have a couple of open questions: * Should we be adding this to vendor & ext extension entries in the XML too? Some vendor extensions aren't semantically versioned and are instead a value that's incremented, we could use this as the major value in semantic versioning. * Should this revision entry be used to generate any part of the human readable specification? This would keep the values in sync rather than the specification revision being bumped and then the XML revision being forgotten about.
8eaabe8
to
e6597c3
Compare
This extension adds the revision field to the XML tag for extensions. This allows a version macro to be generated with: * KhronosGroup/OpenCL-Headers#251 * KhronosGroup/OpenCL-Headers#248 Marked as **Draft** as I have a couple of open questions: * Should we be adding this to vendor & ext extension entries in the XML too? Some vendor extensions aren't semantically versioned and are instead a value that's incremented, we could use this as the major value in semantic versioning. * Should this revision entry be used to generate any part of the human readable specification? This would keep the values in sync rather than the specification revision being bumped and then the XML revision being forgotten about.
e6597c3
to
f442d65
Compare
This extension adds the revision field to the XML tag for extensions. This allows a version macro to be generated with: * KhronosGroup/OpenCL-Headers#251 * KhronosGroup/OpenCL-Headers#248 KHR extensions are given a revision based on the semantic version of the spec. However other extensions don't use semantic versioning, and so are given a placeholder `0.0.0` value until they can be updated by the owner. The XML schema is also updated to make the revision field mandatory in the XML entry for extensions and the existence of the macro this enables is advertised to users in the spec.
This extension adds the revision field to the XML tag for extensions. This allows a version macro to be generated with: * KhronosGroup/OpenCL-Headers#251 * KhronosGroup/OpenCL-Headers#248 KHR extensions are given a revision based on the semantic version of the spec. However other extensions don't use semantic versioning, and so are given a placeholder `0.0.0` value until they can be updated by the owner. The XML schema is also updated to make the revision field mandatory in the XML entry for extensions and the existence of the macro this enables is advertised to users in the spec.
05de75f
to
b2adfe1
Compare
@@ -1776,21 +1903,12 @@ clEnqueueReleaseExternalMemObjectsKHR( | |||
#define CL_KHR_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME \ | |||
"cl_khr_external_memory_dma_buf" | |||
|
|||
/* cl_external_memory_handle_type_khr */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cl_khr_external_memory_dx
has dissapeared after copying over cl_ext.h
wholesale from the gen_headers.py
output - However it looks like this was intended KhronosGroup/OpenCL-Docs#1160
@@ -1864,23 +1992,17 @@ clGetSemaphoreHandleForTypeKHR( | |||
|
|||
#endif /* !defined(CL_NO_NON_ICD_DISPATCH_EXTENSION_PROTOTYPES) */ | |||
|
|||
/*************************************************************** | |||
* cl_khr_external_semaphore_dx_fence |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cl_khr_external_semaphore_dx_fence
has dissapeared after copying over cl_ext.h
wholesale from the gen_headers.py
output - However it looks like this was intended KhronosGroup/OpenCL-Docs#1160
This extension adds the revision field to the XML tag for extensions. This allows a version macro to be generated with: * KhronosGroup/OpenCL-Headers#251 * KhronosGroup/OpenCL-Headers#248 KHR extensions are given a revision based on the semantic version of the spec. However other extensions don't use semantic versioning, and so are given a placeholder `0.0.0` value until they can be updated by the owner. The XML schema is also updated to make the revision field mandatory in the XML entry for extensions and the existence of the macro this enables is advertised to users in the spec.
Implement idea from KhronosGroup#248 to add an version macro to the extension headers so that users can guard application code using the macro to ensure the correct APIs are being used. Extensions can then increment the version when they change the APIs without breaking user code. See [CL_MAKE_VERSION](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_MAKE_VERSION) for how the macro version is defined.
Clang format changes and other fixes
b2adfe1
to
45a04ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I think cl_ext.h
is going to change slightly when/if we remove the automated formatting checks - see #253 - but no need to hold up this PR until the automated formatting checks are merged. It'll just make for a few more diffs next time we re-generate headers.
Un-guarding CL_MAKE_VERSION
means that a pre-OpenCL 3.0 application that uses CL_MAKE_VERSION
intentionally or unintentially (say, if it meant to use CL_MAKE_VERSION_KHR
instead) would build with newer headers and fail to build with older headers, but the risk of that happening is probably low enough that we shouldn't worry too much about it. I don't have a better solution, anyhow.
Merging as discussed in the June 18th teleconference. |
Implement idea from #248 to add an version macro to the extension headers so that users can guard application code using the macro to ensure the correct APIs are being used. This uses the XML from KhronosGroup/OpenCL-Docs#1161 which forces extension to set a revision value.
Extensions can then increment the version when they change the APIs without breaking user code, providing applications have guarded their usage.
See CL_MAKE_VERSION for how the macro version is defined. Note that the definitions of this macro and
cl_version
have been taken out of theCL_VERSION_3_0
version guard to allow them to always be used by an application. This is because there functionality is implemented in the headers and not affected in any way by the OpenCL implementation being used, and the OpenCL version that implementation supports.