Accessing buffer from accessor having different buffer_location property

[lforg37]

Hello,

While working on an accessor property similar to intel::property::buffer_location but adapted for Xilinx HLS backend, we faced the issue of having accessor with different value of the property targeting the same buffer.

It can be useful if the usage of the buffer is not the same between kernels.

For instance, a first kernel can permute the values of the buffer, before the resulting values are processed sequentially by a second kernel.

According to FPGA SDK for OpenCL Best Practices Guide having buffer data on QDR SDRAM would be more adapted for first kernel and on DDR SRAM for second kernel.

That means a copy of the buffer from device to device should be scheduled between the execution of the two kernels.

Is this case supported by the compiler yet ?

[bader]

Tagging @GarveyJoe.

[GarveyJoe]

Yes, this case is supported with the extra copy that you described. If you've seen any evidence to the contrary, please let me know so we can fix it.

[lforg37]

Thanks for the quick reply !
Actually I was wondering where the support occurs.
In the the sycl graph builder I only find a path that does the move with an intermediate copy on the host, and I don't understand where the property of the target memory type is stored.

[lforg37]

Or is this handled directly by the OpenCL FPGA runtime ?
I suppose it can be done by tracking the usage of the buffer replicates and perform the copy each time a replicate used by a kernel is not the last modified one.
But with this solution, is not some encoding in the kernel required in order not to loose the information about read only access on arguments ?

[GarveyJoe]

Yes, you've got it. In our implementation it's the responsibility of the low level runtime to do the extra copy and it's the responsibility of the compiler to inform it about the buffer_location (by embedding some information in the device binary itself) so that it can determine if the copy is necessary. In other words, we have no API call that the SYCL runtime makes to the OpenCL/level 0 runtime to tell it about the buffer_location.

[lforg37]

Ok, Thank you for the precision !

[keryell]

Interesting.
I would have thought that Level 0, like other recent runtimes à la Vulkan, has not this high-level behavior to avoid annoyance like hidden unexpected allocation time or an exploding memory allocation for some innocent operations like starting a kernel or setting an argument.
Since in SYCL the concrete buffer management is handles with a big-picture plan due to the single-source + implicit dataflow graph from the accessors, it does not really make a difference between managing the concrete buffers across different devices or across various memories in the same device, since at the end it will be P2P operations, intra- or inter-devices.
So the SYCL runtime could cache the per-device heterogeneous memory buffers, recycle them and find a global schedule to reduce memory footprint and/or the P2P buffer operations.