Hi Natalia,
After some experiments, it seems that multiple mapping (with different offset) of same buffer is working as expected if the buffer is a zero-copy memory object (i.e. created with CL_MEM_USE_HOST_PTR or CL_MEM_ALLOC_HOST_PTR or CL_MEM_USE_PERSISTENT_MEM_AMD). Otherwise, i.e. when it's a normal device buffer, the buffer is mapped to same memory location irrespective of "offset" or "size" for both read and write. As I checked, the following code gave me similar observation as yours.
float *mapPtr1 = (float *)queue.enqueueMapBuffer(buffer, CL_TRUE, CL_MAP_READ, 0, size); float *mapPtr2 = (float *)queue.enqueueMapBuffer(buffer, CL_TRUE, CL_MAP_READ, size / 2, size / 2);
for (auto i = 0; i < N; i++) std::cout << mapPtr1 << " ";
for (auto i = 0; i < N; i++) std::cout << mapPtr2 << " ";
queue.enqueueUnmapMemObject(buff, mapPtr1);
queue.enqueueUnmapMemObject(buff, mapPtr2);
Anyway, I need to check with the runtime team before I can share more information regarding this.
BTW, in your case you may try CL_MEM_USE_PERSISTENT_MEM_AMD flag as an alternative of CL_MEM_USE_HOST_PTR. Because it will give you better performance if the buffer is heavily accessed by the GPU.
Regards,
HI Natalia
As I've come to know, this is indeed a runtime bug and they are working on the fix.
Regards,
Hi Dipak!
Thank you. I will wait for fixes.
Relative CL_MEM_USE_PERSISTENT_MEM_AMD, it doesn't work at any available for me machine. I have included CL/cl_ext.h, the code is compiled successfully, however, the correspondent clCreateBuffer returns -37-th error... I think, I will try to read some more about this... If everything is bad, I will write in a corresponding topic (I saw some of them, but they didn't help with -37-th error).
Update:
The issue has been resolved in the latest internal builds and the fix is expected to be released soon.