Kernel Swap¶
This example shows how host can swap the kernels and share same buffer between two kernels which are exist in separate binary containers. Dynamic platforms does not persist the buffer data so host has to migrate data from device to host memory before swapping the next kernel. After kernel swap, host has to migrate the buffer back to device.
KEY CONCEPTS: Handling Buffer sharing across multiple binaries, Multiple Kernel Binaries
KEYWORDS: enqueueMigrateMemObjects, CL_MIGRATE_MEM_OBJECT_HOST
This example shows how host can swap the kernels and share the same buffer between two kernels which exist in separate binary containers. All the Vitis platforms do not persist the buffer data if device is reprogrammed by different binary. So host has to migrate data from device to host memory before swapping the next binary. After re-programming the binary, host has to migrate the buffer back to device for next kernel operation.
In design, host application first programs the device using binary
containing krnl_vmult
and executes the operation.
Pointer h_temp
in host is used to store the result of first kernel
and provide the data to next kernel operation.
During first kernel call, d_mul
buffer is created using h_temp
buffer.
cl::Buffer d_mul(context, CL_MEM_USE_HOST_PTR | CL_MEM_READ_WRITE, sizeof(int) * LENGTH, h_temp.data(), &err);
Once kernel finishes the operation, result of the kernel will be read
from device to host into h_temp
buffer.
q.enqueueMigrateMemObjects({d_mul},CL_MIGRATE_MEM_OBJECT_HOST);
After this, Host is ready to reprogram the 2nd Binary.
cl::Program program(context, devices, vadd_bins);
After reprogramming with new binary, a new buffer d_temp
will be
created using same h_temp
host pointer.
cl::Buffer d_temp(context, CL_MEM_USE_HOST_PTR | CL_MEM_READ_ONLY, sizeof(int) * LENGTH, h_temp.data());
And data will be transfered from host to device for 2nd kernel’s execution.
q.enqueueMigrateMemObjects({d_temp}, 0/* 0 means from host*/);
EXCLUDED PLATFORMS¶
Platforms containing following strings in their names are not supported for this example :
zc
DESIGN FILES¶
Application code is located in the src directory. Accelerator binary files will be compiled to the xclbin directory. The xclbin directory is required by the Makefile and its contents will be filled during compilation. A listing of all the files in this example is shown below
src/host.cpp
src/krnl_vadd.cpp
src/krnl_vmul.cpp
COMMAND LINE ARGUMENTS¶
Once the environment has been configured, the application can be executed by
./vmulvadd <krnl_vmul XCLBIN> <krnl_vadd XCLBIN>