cl_khr_command_buffer access to read-only memory objects

[joshqti]

clCommandFillImageKHR and similar should restrict target images to be write or read-write. clEnqueueFillImage permits fills of read-only images, which may not be implemented in a performant way in the context of command buffers.

[EwanC]

I'd need to double check the exact mapping in of sycl::buffer objects to cl_mem creation flags in DPC++, but I think in SYCL-Graphs we could use buffers created with the read only flag in the OpenCL cl_khr_command_buffer backend.

[bashbaug]

Even though the current behavior is non-intuitive, I think it would be more confusing if the command buffer behavior (clCommandFillImageKHR) deviated from the command queue behavior (clEnqueueFillImage).

Could we solve this via the immutable memory object extension, which would disallow updating the memory object through both paths? #1280

[bashbaug]

Discussed in the February 11th teleconference, without a conclusion:

• There is a potential issue for both read-only buffers and read-only images.
• Note, there is also a request to provide even more host access via, see: Add buffer read/write commands to command-buffer extension #1281
• Philosophically, do we want to disallow functionality like this that may be useful but may harm performance?
• Additionally, do we want command buffer behavior to be consistent with command queue behavior, or are we comfortable if the command buffer behavior and the command queue behavior deviate?

[joshqti]

Can we make writing with calls such as fill image or copy image, to read-only images optional, as determined by a device info query?