Question

I have a situation where I (might) want to try using a std::vector (or more precisely its storage) as host pointer for an opencl buffer object with CL_MEM_USE_HOST_PTR. This has obviously problems if the vector is resized and therefore reallocates its memory. The modifications to my vector are during phases of the program, where the buffer is not used, so my idea is that I check if the host pointer of the buffer is identical to the pointer to the first element of the vector and recreate the buffer if that is not the case. My problem is that I haven’t been able to find out if it is legal to have a buffer, for which the host-pointer has already been deallocated, if the buffer isn’t used.

I could of course destroy the buffer at the end of the phase where it is used, however I don’t know in advance if the vector contents and/or length are modified and if they aren’t I would rather keep the old buffer, since afaik that would enable it to stay cached on the device, reducing the amout of data needed to be transferred over the pci-e bus.

My question is: Is it allowed to have an opencl buffer with CL_MEM_USE_HOST_PTR for which the host pointer has already host pointer been deleted, if the buffer object only exists, but isn’t used in a kernel.

For the record I’m currently developing against nvidias opencl implementation, using a Tesla 2070 as a gpu and the software will probably be ported to amd gpus/cpus in the near future (the later being the main reason to use CL_MEM_USE_HOST_PTR). So if the answer is implementation specific, those are the primary targets, though I’m really more interested in the general answer, since I don’t know what else it will run on at later times.

Answer 1

I believe it would be safer if you did not try to change the buffer underneath the OpenCL implementation. As you suggested this would likely bring problems. For instance:

vector<int> v(25);
cl_mem buf = clCreateBuffer(.v.data(),.CL_MEM_USE_HOST_PTR,...);
v.resize(1000); //Or some other way of changing the size of the stack
clReleaseMemObject(buf);

When the memory is released it will attempt to sync the data back to the original buffer (which has been deallocated) likely causing a segfault or some other nasty memory problems.

According to some discussion on this thread, it should be assumed that as soon as you call the clCreateBuffer with the CL_MEM_USE_HOST_PTR flag that you have ceded control of that memory to the OpenCL platform and you can only reclaim that memory with a call to release that memory buffer.

While it is possible that in your specific implementation this is not the case, I would think that overall it would be advisable to release the data. That way, if your underlying system changes in the future, you won’t see a bug associated with this behavior.

Optionally, you could possibly extend the vector class such that on resizes of the underlying data structure, you could release and reallocate data on the device. I’m not sure how difficult this would be, or how much it would affect the rest of your program, though.