SubBuffers & RefCounts of cl_mem about opencl-clhpp

[jrprice]

I'm not sure I understand the problem. When a cl::Buffer object corresponding to a sub buffer is destroyed, we call clReleaseMemObject on the sub buffer cl_mem, /not/ the parent buffer. In your example, when subbuf goes out of scope, the sub buffer that it wraps will be destroyed, but the parent buffer buf will still be valid.

Are you experiencing a problem with these APIs?

[tobwes]

The OpenCL documentation is not clear on that point, whether a subbuffer needs to be released. (Intuitively, I'd say there's no sense in releasing a subbuffer, because it owns no dedicated memory.)

Anyway, attached is an example that lets the subbuffer go out of scope before the kernel is running and then crashes with a segmentation fault (on both platforms, Clover and pocl). If I prevent the subbuffers from going out of scope (e.g. declare them static in lines 20ff., thus the destructor is not called and the memory is not released), the program runs just fine.

main.txt
(hint: I had to use .txt, because GitHub didn't let me upload a .cpp file.)

[jrprice]

I admit that It might not be crystal clear from the specification that sub-buffers should be released, but I'm afraid that is indeed the case. For example, if you look at the official OpenCL conformance tests, you can see that they call clReleaseMemObject on sub buffer objects when they are finished with them. An example of that is here, and you can see that the parent buffer is also released a few lines later.

Intuitively, I'd say there's no sense in releasing a subbuffer, because it owns no dedicated memory.

I understand where you're coming from, but I'd think about this slightly differently. When you release a sub buffer, you're not asking the runtime to deallocate the buffer memory, you're just saying that you are done with the sub buffer object. The sub buffer object is what contains information about where the sub buffer starts and ends, what the parent buffer is, etc. Releasing this object allows the runtime to free the memory used to hold this information - but it won't deallocate the memory used for the contents of buffer until you also release the parent buffer.

The OpenCL specification says this regarding clReleaseMemObject:

If memobj is a buffer object, memobj cannot be deleted until all sub-buffer objects associated with memobj are deleted.

How does the runtime know when the sub buffer objects have been deleted? Because the user has called clReleaseMemObject on them!

I hope this helps clarify things. I would certainly expect your example code to fail for the above reasons - you're destroying the sub buffer before it's used.

[jrprice]

Closing this as it was not deemed to be an issue with the headers.