[SYCL][Docs] Add sycl_ext_oneapi_inter_process_communication

[steffenlarsen]

This commit adds a new extension for inter-process communicable SYCL object handles. As part of the initial version of this extension, only inter-process communicable memory is exposed.

[steffenlarsen]

@intel/dpcpp-tools-reviewers & @intel/llvm-reviewers-runtime - This should be ready for review!

[againull]

Implementation LGTM overall

[YuriPlyakhin]

No flags from tools perspective (just one nit).

[gmlueck]

What if the number of bytes is correct, but the content is garbage? Can we broaden this exception like this:

• An exception with the errc::invalid error code if the handle data handle_data does not represent a valid IPC handle for USM memory on this host system.

That would also cover the case when the handle had the wrong number of bytes.

[steffenlarsen]

I am reluctant to promise an error code if handle data is corrupt. The byte size is something we can check at a SYCL/UR level, but the validity of the data is up to UMF to decide and the API documentation doesn't specify which error is returned if the data is off. Maybe a precondition?

[gmlueck]

I think you should push this requirement down to the UMF and down to Level Zero if necessary. They should be able to define an error code for this.

[steffenlarsen]

I will open an issue against UMF, but I think it might be tricky. What happens if the data looks correct to UMF, but using it causes UB or invalid access in the implementation? I suppose that's something they can look into though.

[gmlueck]

UMF shouldn't look at the handle content at all. It should just pass it to the underlying driver API, and that API should return an error code if the handle content is invalid. This assumes that each driver is able to diagnose an error in such a case, but that seems quite reasonable to me. For example, cudaIpcOpenMemHandle is defined to return cudaErrorInvalidResourceHandle in this case. I don't see an error code listed for Level Zero, but that seems like a bug. They should be able to return an error code.

[steffenlarsen]

There may be some wrapper information in the UMF IPC handle, but I don't know the exact details. Maybe @vinser52 has some insight into this?

[gmlueck]

While looking at the Level Zero documentation, I saw that it says this:

Multiple calls to this function with the same IPC handle will return unique pointers

Therefore, I think we should change this note to say:

[Note: The open function can be called multiple times on the same handle
within the same process. Each call to open may return a unique pointer value
even for the same handle, therefore each call to open must have a matching call
to close.
{endnote}]

[steffenlarsen]

@vinser52 - Does UMF let the calls go through to Level Zero each time, or will repeat calls to open return the same UMF handle?

[gmlueck]

Does it matter what UMF currently does? Even if UMF "squashes" the repeated zeMemOpenIpcHandle calls now, it might not in the future. The proposed wording gives us the freedom to implement it either way.