[OpenCL] Add Command Buffer extension to OpenCL adapter.

[martygrant]

Adds implementations for the experimental Command Buffer entry points. Also fixes minor build error with missing namespace in enqueue.cpp.

Added companion intel-llvm PR which also updates many of the E2E tests to run against OpenCL - intel/llvm#11718

[EwanC]

This code LGTM, but I think this PR should have a companion change in DPC++. Once this UR commit get's pulled into DPC++ the SYCL-Graph extension will start reporting support for OpenCL with undocumented behaviour. Also without DPC++ testing, i'm not sure how to use this code path, given that I don't think there's UR CTS testing for experimental features.

What i'd imagine the companion DPC++ PR to cover:

• Add a OpenCL section to the design doc for SYCL-Graphs https://github.com/intel/llvm/blob/sycl/sycl/doc/design/CommandGraph.md#backend-implementation documenting the implementation on cl_khr_command_buffer, and explicitly documenting the types of nodes that aren't currently supported.
• Add opencl to the REQUIRES line of test-e2e/Graph tests which now pass with this change.
• Add a device.get_info<exp_ext::info::device::graph_support>(); check to all tests, skipping returning early for those which don't report support. As even for an OpenCL device, support is dependent on the cl_khr_command_buffer extension being available. This will probably be the case for all DPC++ CI testing, which I don't think uses a device with cl_khr_command_buffer support.

[martygrant]

Hey @EwanC, thanks for the really thorough review. That all sounds fine for a new PR into DPC++, I'll open up an issue with the details you've provided. Should one PR be merged before the other?

We're temporarily holding off merging any more stuff into the adapters branch here until a L0 issue is reverted but I'll have both of these changes ready to go once that's sorted.

[EwanC]

Hey @EwanC, thanks for the really thorough review. That all sounds fine for a new PR into DPC++, I'll open up an issue with the details you've provided. Should one PR be merged before the other?

We're temporarily holding off merging any more stuff into the adapters branch here until a L0 issue is reverted but I'll have both of these changes ready to go once that's sorted.

I think following the existing adapter change process is fine https://oneapi-src.github.io/unified-runtime/core/CONTRIB.html#adapter-change-process This will need to be merged first, but only after the DPC++ PR has been approved and CI passing.

[martygrant]

Have opened up an issue for the work required in DPC++ - intel/llvm#11599

[martygrant]

Corrected an error in urCommandBufferAppendKernelLaunchExp where the cl_command_queue command_queue parameter for clCommandNDRangeKernelKHR must be NULL. Given the extension function pointers more meaningful names instead of just F.

[EwanC]

LGTM 😃