Memory Model

The oneIPL memory model uses the most efficient memory available for image processing. The memory of different layouts is used for image representation. The SYCL2020 standard defines an abstraction for image memory and lower-level C-style USM for linear layout. oneIPL operates with its own ipl::image abstraction over these memory types. oneIPL implementations shall choose the most efficient memory representation by available image formats and specify it during ipl::image creation via allocators.

Memory Tag Dispatching

The SYCL 2020 standard has a usm_allocator. USM allocations might be host, shared, or device memory, but usm_allocator does not support device allocation. oneIPL introduces allocator types to cover all possible memory types under the image abstraction.

Allocator type	Memory type
host_usm_allocator_t	host USM
device_usm_allocator_t	device USM
shared_usm_allocator_t	shared USM
image_allocator_t	image memory

With image memory, all data movement is handled by the SYCL runtime supporting both synchronous and asynchronous execution. With USM memory, allocation and copy operations are done in constructors and shared memory synchronization is handled by the runtime.

Image memory is recommended for 4-channel interleaved images if the GPU device is used. For all other formats, USM must be used as the default memory.

Device-only images are required for temporary device data, which are not transferred to the host. Host-only images are required for temporary data on the host. USM images are required to transfer the data from host to device and back.

Images are constructed by any supported pointer with mapping capability. If a USM pointer has the same type as an allocator (shared, host, device), then the image is constructed with zero-copy. In other cases, memory allocation and an explicit copy are done (until a more efficient mechanism is supported in the SYCL standard).

Synchronization

While the SYCL image and buffer model is capable of handling data dependencies, USM has no implicit dependency-handling mechanism. Such mechanisms are supported by the ipl::image abstraction. In addition, all functions support explicit dependency arguments to provide a mechanism to the user who might want to write custom kernels and synchronize them with the execution of oneIPL.