Archives Discussions

[dipak]

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,

[dipak]

HI Natalia

As I've come to know, this is indeed a runtime bug and they are working on the fix.

Regards,

[natasha]

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).

[dipak]

Update:

The issue has been resolved in the latest internal builds and the fix is expected to be released soon.