I am trying to allocate several SVM buffers and pass them to an OpenCL kernel using the following method. The kernel is run on Intel HD Graphics 530 and NVIDIA GTX 950M. I get different results on these GPUs, and I am not sure which behavior is correct (maybe, both?)
- Initialize OpenCL.
- Allocate 3 buffers (
data0,data1,pointers) with 3 clSVMAlloc() calls. - Check the results for NULL (no failure here).
- Map all the buffers using blocking clEnqueueSVMMap() calls + check for CL_SUCCESS (no failure here).
- Fill
data0anddata1with data, andpointerswith pointers todata0anddata1, so thatpointers[0] == data0andpointers[1] == data1. - Unmap all the buffers using clEnqueueSVMUnmap() + check for CL_SUCCESS (no failure here).
- Set the 1st kernel argument using clSetKernelArgSVMPointer(...,
data0) + check for CL_SUCCESS (no failure here). - Set the 2nd kernel argument using clSetKernelArgSVMPointer(...,
pointers) + check for CL_SUCCESS (no failure here). - Run the kernel and test results.
On NVIDIA card, the data is available through both pointers[0] and pointers[1]. This is the expected behavior.
On Intel chip, memory behind pointers[0] is available (because data0 has been set as kernel argument), but memory behind pointers[1] is all zeroes. If I set data1 as kernel argument, then it becomes available through pointers[1] and memory behind pointers[0] becomes zeroes.
The question is: is Intel approach a bug or a feature? I have not found any related information in the OpenCL 3.0 specification.