[Doc] Remove the OpenCL USM spec draft

[bashbaug]

The OpenCL USM specification is now final and tracked on the Khronos OpenCL registry. Rather than maintaining the content in both places, remove the OpenCL USM specification.

Signed-off-by: Ben Ashbaugh [email protected]

[bader]

@bashbaug, I would remove the document completely and put new status to the commit message.

[bashbaug]

There could still be links to the previous spec draft so I would prefer not to remove it completely, but I definitely don't want to have stale content or maintain it in two places. Signposting to the final version seemed like a good compromise solution.

What have we done in the past for extensions or other features after they are final?

[bader]

What have we done in the past for extensions or other features after they are final?

I don't think we have a common process. James created a signpost for USM in a7ffe03 and Greg is removing it in #5381.
#5381 removes a lot of other extensions moved to core specification w/o adding a signpost.

[bashbaug]

OK, no problem, especially if #5381 is shuffling things around anyhow. Maybe this will help nudge search engines to pick up the OpenCL registry specification instead!

@gmlueck you may want to remove the USM directory entirely from your PR then, since it won't have any useful content anymore.

[gmlueck]

In some cases, we have a SYCL design document that points to the related OpenCL or SPIR-V extension specifications. For example, we do this in DeviceGlobal.md. In cases like that, we can update the link in the design doc to point to the final OpenCL/SPIR-C spec that is in the registry.

In this case, there is no USM design doc, so there is no link to update. I think it's OK to just remove the OpenCL spec in this case with no signpost. It's not clear why people would go looking for an OpenCL extension specification in the llvm repo.

[bashbaug]

It's not clear why people would go looking for an OpenCL extension specification in the llvm repo.

To be clear, I'm fine removing the spec, but consider:

• For me at least, the top search result for "cl_intel_unified_shared_memory" is this repo.
• Because this was the only public specification draft for some time, various documents (e.g. within Khronos) may be referring to this repo.

These all should be updated to refer to the extension specification on the registry instead, but it will take some time for these updates to occur.

[gmlueck]

Yes, for me the top google hit is also the "intel/llvm" repo. However, the third hit is the Khronos registry.

I could put a signpost in the new directory in "intel/llvm" that will hold the WIP OpenCL extension specifications. However, this will not be the same location that "cl_intel_unified_shared_memory.asciidoc" resided in before. Do we think that's useful?

[bashbaug]

Could we maybe add a generic signpost to the effect of "if you're looking for a previous WIP draft that is now final, look for the final specificiations in the (Khronos registries? oneAPI docs?)"? I don't think this is OpenCL-specific, and we likely have (or will have soon) a bunch of SPIR-V extensions that should be tracked in Khronos repos rather than here.

[gmlueck]

Yes, I like that. I'll add text like that to a README file in each of the folders that contain WIP OpenCL and SPIR-V specs. I'll also include links to the roots of the respective Khronos registries.

[bader]

@gmlueck, does it look okay to you?

[gmlueck]

@bader

@gmlueck, does it look okay to you?

Yes, I just approved. Thanks for the ping.