Memory Model#

The oneIPL memory model shall use the most efficient memory available for image processing. The memory of different layout shall be used for image representation. SYCL2020 standard defines abstraction for image memory and lower level C-style USM for linear layout. oneIPL APIs operate with own ipl::image abstraction over these memory types. Implementation shall choose the most efficient memory representation by available image formats and specify it on ipl::image creation stage via allocators.

The Memory tag dispatching#

Also SYCL 2020 standard has usm_allocator. USM allocation might be host/shared/device, but usm_allocator doesn’t support device allocation. oneIPL introduces allocator types to cover all possible memory types under the image abstraction.

Allocator type

Memory type


host USM


device USM


shared USM


image memory

With the image memory, all data movement is handled by the SYCL runtime supporting both synchronous and asynchronous execution. With USM memory allocation and copy operations shall be done in construction, shared memory type synchronization shall be handled by runtime. Image memory is recommended for 4-channel interleaved images if the GPU device is used. For all other formats, USM implementation must be used and also shared USM shall be a default memory used for images in oneIPL. Device-only images are required for temporary data on device, which shall not be transferred to host. Host-only images are required for temporary data on host. Shared USM images are required to transfer the data from host to device and back.

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


While the SYCL image and buffer model is capable to handle data dependencies, USM has no implicit dependencies handling mechanism. Such mechanism shall be supported by ipl::image abstraction. In addition, all APIs shall support explicit dependencies arguments to provide mechanism to the user who might want to write own kernels and synchronize execution of IPL routines with their own routines.