Begin integration of EXT extensions into the unified specification

[kpet]

• Add a khr+ext spec type to makeSpec and cover in CI
• Document the version and dependencies of all EXT extensions in the XML
• Integrate cl_ext_cxx_for_opencl into the unified specification
• Add placeholder descriptions for all EXT extensions linking to either core/KHR features that supersede old extensions that were never part of the specification or the OpenCL Extensions document.

This enables us to integrate EXT extensions incrementally and integrate future EXT extensions directly into the unified specification.

Change-Id: Ic634ce000ad3ebfb56e56bce91f9c0de3e786383

[EwanC]

LGTM

After building this my main thought would be whether it's worth splitting the appendix of supported extensions into separate KHR and EXT lists, as the single list is already quite long (although it is ordered to make the EXTs easy to find in that list)

[EwanC]

This extension is described in the OpenCL Extensions document.

Providing a link here (and in similar descriptions) would be helpful to the reader.

[kpet]

Agree but it's hard to provide a link that's valid regardless of the spec you're looking at. Links would be different for published PDF or HTML versions of the spec and different again for the dev versions. I felt this was a bit too hard for a "temporary" (tm) problem.

[EwanC]

cool, we can leave this out of it isn't trivial.

[bashbaug]

Note, the EXT extensions actually aren't currently in the OpenCL Extensions document, and they're documented in standalone extension docs on the registry, similar to vendor extensions. For example:

https://registry.khronos.org/OpenCL/extensions/ext/cl_ext_float_atomics.html

Until this changes, maybe it is possible to put a stable link to the appropriate extension document?

[kpet]

I was looking at the PDF when writing this. The spec tooling generates:

• out/pdf/OpenCL_Ext.pdf titled "The OpenCL Extension Specification"
• out/pdf/extensions.pdf titled "OpenCL Extensions"

It's the latter that this refers to and that one does include EXT extensions. I agree there is potential for confusion and the real fix IMO is to get rid of both these documents :).

We could do what you propose but this would always link to the latest pulished version of the specification in HTML form. It would likely be useful to a good number of users but would at the same time potentially point to the wrong document for some others.

[bashbaug]

The tooling generates "extensions.pdf", but AFAIK we don't publish it. We still do publish "OpenCL_Ext.pdf", but we might not do so for long - see #1111.

What's the disadvantage of linking to the HTML spec? The way I look at it, if we don't put any link, readers looking for more information about the extension are either going to get frustrated and give up, or they're going to search for the name of the extension, which will (hopefully!) point them to the HTML spec on the registry. If that's the case, why not give them the link directly?

[kpet]

Beyond having PDFs link to the HTML specs, the main issue I have with adding these links is that the version linked would not be the one aligned to the document linking to it. It's not an issue for published versions of the specification but if I package a set of PDFs generated from an arbitrary SHA for example, the link would potentially point to the wrong spec text. This mostly affects IHVs so maybe not a good reason to deprive OpenCL users of a helpful link even if only temporary so. I'll add the links with text stating that they point to the "latest published" version of the specifications.

[bashbaug]

Thank you for doing this!

[kpet]

@bashbaug I think I've addressed all your comments, PTAL. Note that we need to merge KhronosGroup/OpenCL-Registry#156 too (seems we never published that one on the registry; can't wait for this to become unnecessary :))

[bashbaug]

Merging as discussed in the August 13th teleconference.

[SunSerega]

Can you please explain what it means, to have 2 different versions of core in the depends attribute?

Given coma, IG it means this extension can be supported if either:

• OpenCL is 2.0 and cl_khr_extended_versioning is supported.
• OpenCL is 3.0 is supported.

This is my best guess, but this is the first time coma was used in depends and the explanation in registry.rnc is still pretty surface-lvl:

# Boolean expression of core version and extension names using (),+ operators
Depends = attribute depends { text }

Before I thought the coma here is not an operator but a separator between () and + operators...

---

Also below:

        <extension name="cl_ext_float_atomics" revision="1.0.0" depends="CL_VERSION_2_0,CL_VERSION_3_0" supported="opencl">

Wouldn't CL_VERSION_3_0 here just be redundant?

[kpet]

Given coma, IG it means this extension can be supported if either: [...]

You got it!

Wouldn't CL_VERSION_3_0 here just be redundant?

I don't think so. OpenCL 3.0 is not a strict superset of OpenCL 2.0. The dependency is on "OpenCL C 2.0 atomic syntax" (according to https://registry.khronos.org/OpenCL/extensions/ext/cl_ext_float_atomics.html) which is available in the 2.x versions and 3.0. (I'm sure we could improve the tooling to express better dependencies but given where things are I think it's the best way of representing the dependency).