-
Notifications
You must be signed in to change notification settings - Fork 113
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
Specification for cl_khr_extended_versioning #218
Merged
bashbaug
merged 3 commits into
KhronosGroup:master
from
kpet:extended-versioning-public
Nov 10, 2020
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,284 @@ | ||
// Copyright 2019 The Khronos Group. This work is licensed under a | ||
// Creative Commons Attribution 4.0 International License; see | ||
// http://creativecommons.org/licenses/by/4.0/ | ||
|
||
[[cl_khr_extended_versioning]] | ||
== Extended versioning | ||
|
||
This extension introduces new platform and device queries that return detailed | ||
version information to applications. It makes it possible to return the exact | ||
revision of the specification or intermediate languages supported by an | ||
implementation. It also enables implementations to communicate a version | ||
number for each of the extensions they support and remove the requirement | ||
for applications to process strings to test for the presence of an extension or | ||
intermediate language or built-in kernel. | ||
|
||
=== General information | ||
|
||
==== Name Strings | ||
|
||
`cl_khr_extended_versioning` | ||
|
||
==== Contributors | ||
|
||
Kévin Petit, Arm Ltd. + | ||
Ben Ashbaugh, Intel + | ||
Alastair Murray, Codeplay Software Ltd. + | ||
Einar Hov, Arm Ltd. | ||
|
||
==== Version history | ||
|
||
[cols="1,1,3",options="header",] | ||
|==== | ||
| *Date* | *Version* | *Description* | ||
| 2020-02-12 | 1.0.0 | Initial version. | ||
|==== | ||
|
||
==== Dependencies | ||
|
||
This extension is written against the OpenCL Specification | ||
Version 2.2, Revision 11. | ||
|
||
This extension requires OpenCL 1.0. | ||
|
||
=== New API Types | ||
|
||
==== Version | ||
|
||
This extension introduces a new scheme to encode detailed | ||
(major, minor, patch/revision) version information into a single 32-bit unsigned | ||
integer: | ||
|
||
* The major version is using bits 31-22 | ||
* The minor version is using bits 21-12 | ||
* The patch version is using bits 11-0 | ||
|
||
This scheme enables two versions to be ordered using the standard C/C++ operators. | ||
Macros are provided to extract individual fields or compose a full version | ||
from the individual fields. | ||
|
||
[source,c] | ||
---- | ||
|
||
typedef cl_uint cl_version_khr; | ||
|
||
#define CL_VERSION_MAJOR_BITS_KHR (10) | ||
#define CL_VERSION_MINOR_BITS_KHR (10) | ||
#define CL_VERSION_PATCH_BITS_KHR (12) | ||
kpet marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#define CL_VERSION_MAJOR_MASK_KHR ((1 << CL_VERSION_MAJOR_BITS_KHR) - 1) | ||
#define CL_VERSION_MINOR_MASK_KHR ((1 << CL_VERSION_MINOR_BITS_KHR) - 1) | ||
#define CL_VERSION_PATCH_MASK_KHR ((1 << CL_VERSION_PATCH_BITS_KHR) - 1) | ||
|
||
#define CL_VERSION_MAJOR_KHR(version) \ | ||
((version) >> (CL_VERSION_MINOR_BITS_KHR + CL_VERSION_PATCH_BITS_KHR)) | ||
#define CL_VERSION_MINOR_KHR(version) \ | ||
(((version) >> CL_VERSION_PATCH_BITS_KHR) & CL_VERSION_MINOR_MASK_KHR) | ||
#define CL_VERSION_PATCH_KHR(version) ((version) & CL_VERSION_PATCH_MASK_KHR) | ||
|
||
#define CL_MAKE_VERSION_KHR(major, minor, patch) \ | ||
((((major) & CL_VERSION_MAJOR_MASK_KHR) << (CL_VERSION_MINOR_BITS_KHR + CL_VERSION_PATCH_BITS_KHR)) | \ | ||
(((minor) & CL_VERSION_MINOR_MASK_KHR) << CL_VERSION_PATCH_BITS_KHR) | \ | ||
((patch) & CL_VERSION_PATCH_MASK_KHR)) | ||
---- | ||
|
||
==== Name and version | ||
|
||
This extension adds a structure that can be used to describe a combination of a | ||
name alongside a version number: | ||
|
||
[source,c] | ||
---- | ||
#define CL_NAME_VERSION_MAX_NAME_SIZE_KHR 64 | ||
kpet marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
typedef struct _cl_name_version_khr { | ||
cl_version_khr version; | ||
char name[CL_NAME_VERSION_MAX_NAME_SIZE_KHR]; | ||
} cl_name_version_khr; | ||
kpet marked this conversation as resolved.
Show resolved
Hide resolved
|
||
---- | ||
|
||
The `name` field is an array of `CL_NAME_VERSION_MAX_NAME_SIZE_KHR` bytes used as | ||
storage for a NUL-terminated string whose maximum length is therefore | ||
`CL_NAME_VERSION_MAX_NAME_SIZE_KHR - 1`. | ||
|
||
=== New API Enums | ||
|
||
Accepted value for the _param_name_ parameter to *clGetPlatformInfo*: | ||
|
||
[source,c] | ||
---- | ||
CL_PLATFORM_NUMERIC_VERSION_KHR | ||
CL_PLATFORM_EXTENSIONS_WITH_VERSION_KHR | ||
---- | ||
|
||
Accepted value for the _param_name_ parameter to *clGetDeviceInfo*: | ||
|
||
[source,c] | ||
---- | ||
CL_DEVICE_NUMERIC_VERSION_KHR | ||
CL_DEVICE_OPENCL_C_NUMERIC_VERSION_KHR | ||
CL_DEVICE_EXTENSIONS_WITH_VERSION_KHR | ||
CL_DEVICE_ILS_WITH_VERSION_KHR | ||
CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION_KHR | ||
---- | ||
|
||
=== Modifications to the OpenCL API Specification | ||
|
||
(Modify Section 4.1, *Querying Platform Info*) :: | ||
+ | ||
-- | ||
|
||
(Add the following to Table 3, _List of supported param_names by clGetPlatformInfo_) :: | ||
+ | ||
-- | ||
|
||
[cols="3,2,3",options="header"] | ||
|==== | ||
| cl_platform_info | ||
| Return Type | ||
| Description | ||
|
||
| `CL_PLATFORM_NUMERIC_VERSION_KHR` | ||
| `cl_version_khr` | ||
| Returns detailed (major, minor, patch) numeric version information. The major | ||
and minor version numbers returned must match those returned via | ||
`CL_PLATFORM_VERSION`. | ||
|
||
| `CL_PLATFORM_EXTENSIONS_WITH_VERSION_KHR` | ||
| `cl_name_version_khr[]` | ||
| Returns an array of description (name and version) structures. The same | ||
extension name must not be reported more than once. The list of extensions | ||
reported must match the list reported via `CL_PLATFORM_EXTENSIONS`. | ||
|
||
|==== | ||
|
||
(Modify Section 4.2, *Querying Devices*) :: | ||
+ | ||
-- | ||
|
||
(Add the following to Table 5, _List of supported param_names by clGetDeviceInfo_) :: | ||
+ | ||
-- | ||
|
||
[cols="3,2,3",options="header"] | ||
|==== | ||
| cl_device_info | ||
| Return Type | ||
| Description | ||
|
||
| `CL_DEVICE_NUMERIC_VERSION_KHR` | ||
| `cl_version_khr` | ||
| Returns detailed (major, minor, patch) numeric version information. The major | ||
and minor version numbers returned must match those returned via | ||
`CL_DEVICE_VERSION`. | ||
|
||
| `CL_DEVICE_OPENCL_C_NUMERIC_VERSION_KHR` | ||
kpet marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| `cl_version_khr` | ||
| Returns detailed (major, minor, patch) numeric version information. The major | ||
and minor version numbers returned must match those returned via | ||
`CL_DEVICE_OPENCL_C_VERSION`. | ||
|
||
| `CL_DEVICE_EXTENSIONS_WITH_VERSION_KHR` | ||
| `cl_name_version_khr[]` | ||
| Returns an array of description (name and version) structures. The same | ||
extension name must not be reported more than once. The list of extensions | ||
reported must match the list reported via `CL_DEVICE_EXTENSIONS`. | ||
|
||
| `CL_DEVICE_ILS_WITH_VERSION_KHR` | ||
| `cl_name_version_khr[]` | ||
| Returns an array of descriptions (name and version) for all supported | ||
Intermediate Languages. Intermediate Languages with the same name may be | ||
reported more than once but each name and major/minor version combination | ||
may only be reported once. The list of intermediate languages reported must | ||
match the list reported via `CL_DEVICE_IL_VERSION`. | ||
|
||
| `CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION_KHR` | ||
| `cl_name_version_khr[]` | ||
| Returns an array of descriptions for the built-in kernels supported by the device. | ||
Each built-in kernel may only be reported once. The list of reported kernels must | ||
match the list returned via `CL_DEVICE_BUILT_IN_KERNELS`. | ||
|
||
|==== | ||
|
||
-- | ||
-- | ||
|
||
=== Conformance tests | ||
|
||
. Each of the new queries described in this extension must be attempted and | ||
succeed. | ||
. It must be verified that the information returned by all queries that | ||
extend existing queries is consistent with the information returned | ||
by existing queries. | ||
. Some of the queries introduced by this extension impose uniqueness constraints | ||
on the list of returned values. It must be verified that these constraints are | ||
satisfied. | ||
|
||
=== Issues | ||
|
||
. What compatibility policy should we define? e.g. a _revision_ has to be | ||
backwards-compatible with previous ones | ||
+ | ||
-- | ||
*RESOLVED*: No general rules as that wouldn't be testable. Here's a recommended policy: | ||
|
||
- Patch version bump: only clarifications and small/obvious bugfixes. | ||
- Minor version bump: backwards-compatible changes only. | ||
- Major version bump: backwards compatibility may break. | ||
|
||
-- | ||
|
||
. Do we want versioning for built-in kernels as returned by `CL_DEVICE_BUILT_IN_KERNELS`? | ||
+ | ||
-- | ||
*RESOLVED*: No immediate use-case for versioning but being able to get a list of | ||
individual kernels without parsing a string is desirable. Adding | ||
`CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION_KHR`. | ||
-- | ||
|
||
. What is the behaviour of the queries that return an array of structures when | ||
there are no elements to return? | ||
+ | ||
-- | ||
*RESOLVED*: The query succeeds and the size returned is zero. | ||
-- | ||
|
||
. What value should be returned when version information is not available? | ||
+ | ||
-- | ||
*RESOLVED*: If a patch version is not available, it should be reported as 0. | ||
If no version information is available, 0.0.0 should be reported. | ||
These values have been chosen as they are guaranteed to be lower | ||
than or equal to any other version. | ||
-- | ||
|
||
. Should we add a query to report SPIR-V extended instruction sets? | ||
+ | ||
-- | ||
*RESOLVED*: It is unlikely that we will introduce many SPIR-V extended | ||
instruction sets without an accompanying API extension. Decided | ||
not to do this. | ||
-- | ||
|
||
. Should the queries for which the old-style query doesn't exist in a given | ||
OpenCL version be present (e.g. `CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION_KHR` | ||
prior to OpenCL 2.1 or without support for `cl_khr_il_program` or | ||
`CL_DEVICE_OPENCL_C_NUMERIC_VERSION_KHR` on OpenCL 1.0)? | ||
+ | ||
-- | ||
*RESOLVED*: All the queries are always present. | ||
`CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION_KHR` returns an empty set | ||
when Intermediate Languages are not supported. | ||
`CL_DEVICE_OPENCL_C_NUMERIC_VERSION_KHR` always returns 1.0 on an | ||
OpenCL 1.0 platform. | ||
-- | ||
|
||
. Is reporting multiple Intermediate Languages with the same name and major/minor | ||
versions but differing patch versions allowed? | ||
+ | ||
-- | ||
*RESOLVED*: No. This isn't aligned with the intended use for patch versions and | ||
makes it harder for implementations to guarantee consistency with | ||
the existing IL queries. | ||
-- | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
See previous comment regarding extension metadata like contributors, issues, etc. We haven't included this information in other KHR extensions. Is this a practice we want to continue into the future?
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.
I think my position hasn't changed here and I think we should do that for all extensions.