Extension Dependencies on Specific OpenCL Versions

[bashbaug]

The current OpenCL extension spec requires specific OpenCL versions for several extensions:

1. The base-level cl_khr_semaphore extension and related external semaphore extensions requires OpenCL 1.2.
2. The cl_khr_command_buffer extension requires OpenCL 1.2.
3. The cl_khr_subgroup_rotate extension requires OpenCL 2.0.
   • Note: none of the other "extended subgroup extensions" requires OpenCL 2.0.
4. The cl_khr_work_group_uniform_arithmetic extension requires OpenCL 2.0.
5. Several extensions explicitly call out a requirement on OpenCL 1.0.

Questions are:

• Presumably these extensions require the stated OpenCL version or newer?
• For the OpenCL versions greater than 1.0 are these OpenCL versions actually required? If so, why? Should the reason be documented in the OpenCL extension spec?
• Is it helpful to describe a requirement on OpenCL 1.0? Or, should this be the default if no other OpenCL version is required?

For completeness, these extensions also have a dependency on a specific OpenCL version, but they also describe the reason why the OpenCL version is required:

1. cl_khr_external_memory and the related extensions require OpenCL 3.0 because they require specifying buffer and image creation properties.

[oddhack]

Tagging in to get notifications, since this feeds into the asciidoc integration work I'm doing.

[EwanC]

I think the main dependency on 1.2 for cl_khr_command_buffer is clEnqueueFillBuffer, clEnqueueFillImage, clEnqueueBarrierWithWaitList which there are analogous commands for.

However, the SVM fill/copy PR did add the text " Buffering of SVM commands requires OpenCL 2.0 or later." to this part of the extension.

[bashbaug]

I think the main dependency on 1.2 for cl_khr_command_buffer is clEnqueueFillBuffer, clEnqueueFillImage, clEnqueueBarrierWithWaitList which there are analogous commands for.

Ah, good point. Couple of options:

1. We keep the entire extension gated by OpenCL 1.2 or newer. It would be impossible to support the extension on an OpenCL 1.1 or earlier device. This requires very few changes - basically, we'd just document that the fill and barrier functionality requires OpenCL 1.2, so the extension also requires OpenCL 1.2.
2. We could define clCommandFillBufferKHR, clCommandFillImageKHR, and clCommandBarrierWithWaitListKHR so they are only supported if the device supports OpenCL 1.2 and newer. This would be consistent with the SVM commands, which require an OpenCL 2.0 or newer device. Note, to be most consistent the extension functions should exist, but they may return an error on pre-1.2 devices. Requires a few changes to the spec and tests, but hopefully not too bad.
3. We could require support for clCommandFillBufferKHR, clCommandFillImageKHR, and clCommandBarrierWithWaitListKHR for all devices supporting the extension, even if they are 1.0 or 1.1 devices. It might be a little weird that these functions are available via command buffers but not via ordinary command queues, but I think most devices could support them. Only requires a change to the spec to remove the 1.2 dependency.

I don't have a strong opinion among these three options, but if I had to choose my first preference would be (3), then (1), then (2). Do any OpenCL 1.0 or 1.1 device vendors plan to support this extension?

[bashbaug]

Discussed in the November 7th teleconference. My personal preference is to:

1. Remove as many required OpenCL version dependencies as possible. I expect some (most?) of the required versions can be eliminated.
2. Clearly document why the required OpenCL version dependency exists in the cases where the dependency cannot be removed.
3. Clarify in general that an extension is supportable on all OpenCL device versions when there is no other explicit dependency, then remove all of the explicit requirements on OpenCL 1.0.
4. Clarify that an OpenCL version dependency is for the stated OpenCL version and newer.

[oddhack]

@bashbaug I pushed a big update to #950 which, among other things, tries to pull in as much of this to the XML as possible, then uses those tags to drive autogeneration of the extension appendices. If you do a './makeAll apihtml' you can see how it deals with promotion, some dependencies (does not handle extension version dependencies), deprecation, etc. in the updated Appendix I. There will still be a need for some unusual dependencies to be handcoded, and to document why the dependency exists per #2, but not much. #3 / #4 can be captured in the boilerplate introduction language of Appendix I.

N.b. #950 now includes all the khr extension appendices, but the actual API/C language spec edits are mostly still to be integrated.