[UR][OpenCL][EnqueueCommandBuffer] use sync points even if command buffer's internal queue is in-order

[wenju-he]

This is partial revert of 988c477
sycl queue is out-of-order by default. When graph is in-order, the
command buffer is created with an internal in-order queue, however,
the out-of-order queue is used for EnqueueCommandBuffer.
This PR restores using sync points for this case that out-of-order
queue is used for executing the command buffer.

Currently it seems there is no mechanism to wait for the internal
in-order queue, therefore, we can't use the queue for EnqueueCommandBuffer.

[EwanC]

sycl queue is out-of-order by default. When graph is in-order, the
command buffer is created with an internal in-order queue, however,
the out-of-order queue is used for EnqueueCommandBuffer.

Enqueing an OpenCL in-order created opencl command-buffer to an out-of-order command-queue is valid API usage. There is a CTS test for it (test_queue_substitute_out_of_order) added in KhronosGroup/OpenCL-CTS#2230 to verify this. Could you elaborate on why this is causing problems?

[wenju-he]

Enqueing an OpenCL in-order created opencl command-buffer to an out-of-order command-queue is valid API usage. There is a CTS test for it (test_queue_substitute_out_of_order) added in KhronosGroup/OpenCL-CTS#2230 to verify this. Could you elaborate on why this is causing problems?

I just took a look at RecordOutOfOrderCommandBuffer function in KhronosGroup/OpenCL-CTS#2230 and it has set sync points, so I think that is why it is working fine.

However, the scenario is different for sycl test https://github.com/intel/llvm/blob/sycl/sycl/test-e2e/Graph/Inputs/compile_time_local_memory.cpp which has two kernels which should be executed sequentially due to the second kernel depending on the first kernel.
In UR, sync points are ignored prior to this PR because command buffer created with an internal in-order queue.
The command buffer is enqueued to the sycl out-of-order queue. Then there is no synchronization between the two kernels any more and the two kernels can execute in arbitrary order in the out-of-order queue.

This PR adds sync points back so that the dependency is kept.

[EwanC]

I just took a look at RecordOutOfOrderCommandBuffer function in KhronosGroup/OpenCL-CTS#2230 and it has set sync points, so I think that is why it is working fine.

That's not my reading, test_queue_substitute_out_of_order instantiates the fixture class such that is_ooo_test is true. Resulting in RecordInOrderCommandBuffer being called which appends command-buffer commands without sync points.

In UR, sync points are ignored prior to this PR because command buffer created with an internal in-order queue.
The command buffer is enqueued to the sycl out-of-order queue. Then there is no synchronization between the two kernels any more and the two kernels can execute in arbitrary order in the out-of-order queue.

I'm not following " Then there is no synchronization between the two kernels any more and the two kernels can execute in arbitrary order in the out-of-order queue." When a command-buffer is finalized the command dependencies are set in the command-buffer, whether the command-buffer is then submitted to an in-order or out-of-order queue has no effect on the internal command dependencies.

[wenju-he]

When a command-buffer is finalized the command dependencies are set in the command-buffer

is this an update on 0.9.6 or 0.9.7?

[wenju-he]

Thanks @EwanC we'll fix the issue in the backend. Close this PR.
But It isn't clear to me why we need a queue to construct command buffer and use queue's in-order/out-of-order to decide whether commands in the command buffer is in-order. We can do that with a property, right?