GPU Coder tries to minimize copies between CPU and GPU. CPU/GPU copies purely depend on data access patterns.
To access the relevant documentation, execute the following command in the MATLAB R2020b command window:
>> web(fullfile(docroot, 'gpucoder/ug/gpu-memory-allocation-and-minimization.html'))
If you generate code for kernelfun1 and kernelfun2 separately (i.e., you call 'codegen' twice) and then try to call the generated mex functions like kernelfun1(b) .* kernelfun2(c), and kernelfun1 or kernelfun2 attempt to return a 'half' data type, a transfer to the CPU will occur to perform the multiplication. This is a current limitation of MATLAB because 'gpuArray' does not support the half data type. However, if you perform the multiplication in a wrapper function, e.g.:
function a = kernelfun3(b,c)
coder.gpu.kernelfun;
a = kernelfun1(b) .* kernelfun2(c);
end
and only call 'codegen' on func3, then GPU Coder will generate code such that the multiplication is performed on the GPU.
The limitation above does not apply if the returned data type of kernelfun1 and kernelfun2 is 'single' or some other datatype supported by gpuArray. In that case, the following multiplication will be performed on the GPU:
kernelfun1(b) .* kernelfun2(c)
CPU Coder tries to fuse the kernels as much as possible, so with the example above, you may find that the generated code contains a single GPU kernel instead of three separate ones for kernelfun1, kernelfun2, and kernelfun3. The effectiveness of this optimization depends on program structure and dataflow. However, we have noticed this optimization not happening in some cases. We recommend trying out code generation on your design and examining the generated code to see whether the coder performed this optimization. If not, you can try altering your design to achieve the desired results.
Please use the below link to search for the required information in the current release:
