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_allocator_t |
host USM |
device_usm_allocator_t |
device USM |
shared_usm_allocator_t |
shared USM |
image_allocator_t |
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. For all other formats, USM implementation must be used as fallback. 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.
Synchronization¶
While the SYCL image and buffer model is powerful and elegantly expresses 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.