Link cl_khronos_vendor_id enums to OpenCL 3.0 in cl.xml

[alycm]

See script to check for orphans in #730

The type was adding in OpenCL 3.0, the actual enums are independent of a specific OpenCL version, but they're also not part of extensions. The 3.0 section seems the most natural.

[bashbaug]

I'm OK with this as-is, and we are not currently generating the core API headers, but because the vendor ID defines are not currently protected by any OpenCL version checks it may be most consistent to assign these enums to OpenCL 1.0.

https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl.h#L914

I see also that we have not included the POCL vendor ID in the upstream headers - I'll file an issue to fix this.

[alycm]

That makes sense, I've made that change.

I also moved the cl_khronos_vendor_id type to 1.0. This is obviously "wrong", and as far as I can tell none of the tooling cares about enums being attached to a type from a later version, and it shouldn't affect the headers either. It just seemed tidier to me.

[bashbaug]

I'm OK moving cl_khronos_vendor_id also, though it currently is guarded by an OpenCL 3.0 version check in the headers:

https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl.h#L114

Is that right?

FWIW cl_khronos_vendor_id isn't used in any of the OpenCL APIs, and the query for CL_DEVICE_VENDOR_ID is specified to return a cl_uint, so it's not entirely clear to me when and where the type should be used.

[kpet]

Fine with this change. I was thinking we'd introduce a dedicated subtree with special tags (I think we'll also need this for some of the reserved enums BTW) for the vendor IDs to decouple them from all versions but this works.

[alycm]

I'm OK moving cl_khronos_vendor_id also, though it currently is guarded by an OpenCL 3.0 version check in the headers:

https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl.h#L114

Is that right?

Yes, it is correct because the type didn't exist before OpenCL 3.0.

FWIW cl_khronos_vendor_id isn't used in any of the OpenCL APIs, and the query for CL_DEVICE_VENDOR_ID is specified to return a cl_uint, so it's not entirely clear to me when and where the type should be used.

I tried to dig up something, there is internal issue 216, which references GitHub PR #203, but there is no clear rationale. I suspect that the term cl_khronos_vendor_id got used due to matching Vulkan's process, which has VkVendorId. Then once the term was used the type was added.

The specification does say for CL_DEVICE_VENDOR_ID

Otherwise, the value returned must be a valid Khronos vendor ID represented by type cl_khronos_vendor_id.

But it doesn't mean much as it's a cl_uint either way. In retrospect the cl_khronos_vendor_id type never needed to exist, some descriptive name could have just been written in the name="" section.

So, to merge this I think:

1. Leave cl_khronos_vendor_id in 3.0 as it was originally so that in the future auto-generated headers don't allow a compatibility issue for anyone creating an OpenCL application targeting <3.0.
2. Have the vendor IDs in the 1.0 section because it has always been possible to have a non PCI vendor ID. We can live with the logical disconnect of 1.0 enums using a 3.0 type because neither implementers nor developers should ever really have a reason to type cl_khronos_vendor_id.

[bashbaug]

So, to merge this I think:

1. Leave cl_khronos_vendor_id in 3.0 as it was originally so that in the future auto-generated headers don't allow a compatibility issue for anyone creating an OpenCL application targeting <3.0.
   ...

Works for me. I'll wait for an update to move cl_khronos_vendor_id back to 3.0 before merging then. Thanks!

[alycm]

Done as described in previous message.