Add Python bindings for SYCL IPC memory via dpctl

[zxue2]

Add inter-process communication (IPC) support for SYCL USM memory, enabling zero-copy GPU memory sharing across processes. It wraps sycl::ext::oneapi::experimental::ipc::memory (get/open/close/put).

C API (libsyclinterface):

• dpctl_sycl_ipc_memory_interface.h: declares DPCTLIPCMem_GetHandle, DPCTLIPCMem_OpenHandle, DPCTLIPCMem_CloseHandle, DPCTLIPCMem_FreeHandleData
• dpctl_sycl_ipc_memory_interface.cpp: implements the C API by calling the SYCL experimental ipc::memory functions; auto-discovered by CMake.

Cython declarations:

• _backend.pxd: extern block for the 4 new C functions

Python subpackage (dpctl.ipc):

• IPCMemoryHandle: Cython extension class wrapping IPC memory export/import init(usm_memory): calls get() + put(), stores handle as bytes to_bytes(): serializable payload for cross-process transport open(handle_bytes, device, nbytes): returns MemoryUSMDevice close_mapping(usm_memory): explicitly closes an IPC mapping

Test In Docker (oneAPI 2026.0 installed):

python -c "
import dpctl
from dpctl.memory import MemoryUSMDevice
from dpctl.ipc import IPCMemoryHandle
d = dpctl.SyclDevice('level_zero:gpu')
q = dpctl.SyclQueue(d)
mem = MemoryUSMDevice(4096, queue=q)
h = IPCMemoryHandle(mem)
raw = h.to_bytes()
print(f'IPC handle: {len(raw)} bytes')
mem2 = IPCMemoryHandle.open(raw, d, nbytes=4096)
print(f'Opened: {mem2.nbytes} bytes on {mem2.sycl_device.name}')
IPCMemoryHandle.close_mapping(mem2)
print('close OK')
"

IPC handle: 120 bytes
Opened: 4096 bytes on Intel(R) Arc(TM) Pro B60 Graphics
close OK

[coveralls]

coverage: 75.504% (-0.2%) from 75.677% — zxue2:enable_ipc_mem into IntelPython:master

[zxue2]

Is it better to use the new MemoryIPCDevice based on MemoryUSMDevice?

One more thing, I am fine with current implementation which can satisfy current demand. But restricting MemoryIPCDevice to base MemoryUSMDevice may lack extension for zeMemGetIpcHandleWithProperties that is with device or host memory allocation in future. May have a separate jira there for improvement in future.

[ndgrigorian]

I figured we can extend to add additional classes later for host/shared allocations, so yes