ur: add enqueue fill image about unified-runtime

[veselypeta]

Turns out this is already added to the spec, but does not appear in the generated header since it's not supported by level-zero
https://github.com/oneapi-src/unified-runtime/blob/main/scripts/core/enqueue.yml#L675

[kbenzie]

We should discuss why there are disabled entry points with the WG.

[kbenzie]

Along with urEnqueueMemImageFill, urEnqueueMemImageMap is also currently disabled.

[veselypeta]

• piEnqueueMemImageFill is only implemented in the OpenCL plugin
• piEnqueueMemImageMap does not exist it PI.

I suppose we do not need to add these entry-points

[kbenzie]

If these are necessary to implement SYCL 2020, they should be added to the UR spec.

[kbenzie]

Based on discussion with @AerialMantis it does not appear that these commands are required for SYCL 2020 because it is only possible to read() and write() images via the unsampled and sampled image accessors.

Resolution of this issue, should be to remove the currently disabled urMemImageFill entry point from the yaml file.

[aarongreig]

These entry points are still in the spec files. I would have already opened the PR to get them deleted but strangely MemImageFill does appear to get used in the sycl runtime: https://github.com/intel/llvm/blob/sycl/sycl/source/detail/memory_manager.cpp#L851 and not just in a sort of stubbed out helper function or whatever.

I think what's happening here is that SYCL has this fill function that takes an accessor, which is a potentially multi-dimensional array view type object that sits on top of an allocation. You can see there's a little bit of extra code where I linked in the "not image" branch that deals with it possibly being a > 1D operation for buffers. It looks like in the "yes image" branch they're taking advantage of the fact that there's this magic API for images that deals with that nonsense for them, it seems more like a use out of convenience than out of necessity.

Technically I think we could implement ImageFill for all the adapters that support images, but for everything that isn't opencl it would basically be a regular fill with the additional faff of keeping track of which mem_obj belongs to which image and figuring out what our pixel size and strides etc are. All that seems kind of pointless when that one use that I linked has that info on hand and leaves it out when it calls the ImageFill entry point instead of the BufferFill one.

Anyway we should probably bring this up to sycl maintainer people because if we delete ImageFill now we should also figure out how we can delete it from PI and memory_manager so it doesn't come back to bite us later when it's time to port.