description for CL_MEM_USE_HOST_PTR on the use of host_ptr

For clCreateBuffer( ), the spec says that for CL_MEM_USE_HOST_PTR, if we supply host_ptr during the call to clCreateBuffer( ), the OpenCL implementation would use the memory bits used by host_ptr while creating the buffer object.

But following this paragraph, it says, the result of OpenCL commands that operate on multiple buffer objects created with the same host_ptr or overlapping host regions is considered to be undefined.

Isn’t the second para a direct contradiction to what is specified initially. While creating the buffer object, the memory data from the host_ptr would be used in the buffer object. Once the buffer object has been created, it has nothing to do with the host_ptr from which it was created or vice versa. So if multiple buffers are created with the same host_ptr, it shouldn’t matter at all, isn’t it? Can someone please clear this to me? I guess I am missing some thing here. Thanks a lot.

When you use CL_MEM_USE_HOST_PTR you are pretty much giving your memory over to OpenCL to manage, but telling it to keep the data there when it is done. This means that you can’t just modify it because you don’t know if OpenCL has copied it to a device or not, in which case your data will be out of sync. (There are a few special cases where you can be sure of this, but in general you can’t.) To get around this, you need to call clEnqueueMap/UnMap to get access to the data you’ve given to OpenCL with CL_MEM_USE_HOST_PTR. Once you’ve done that (and those calls have finished!) you can modify the data locally.

Given that, it should be clear why you can’t use the same host pointer for two mem objects with CL_MEM_USE_HOST_PTR as they would both be trying to use the same backing store for two separate objects.

Ah Right. I mistook USE_HOST_PTR with COPY_HOST_PTR. It is quite clear and obvious now. Thank dbs2.