The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

That is, the copy construction of a cl::Context is properly calling clRetainContext to increment the reference count, but the queue.getInfo<CL_QUEUE_CONTEXT>() call is not. This causes an extra clReleaseContext call to occur, which crashes the Apple implementation sometimes (which it shouldn't, but that's a separate issue).

So should a clGet*Info call that returns another cl_* type automatically increment that reference. I haven't found anything in the standard stating one way or the other.

Re: Should clGet*Info increment the reference to the cl_* type?

FYI, I added the following two more printfs about the reference counts. It appears creating the CommandQueue increments the reference count of the context. Does the AMD implementation have an alternative mechanism to keep the cl_context around if there's a command queue that needs it?

Re: Should clGet*Info increment the reference to the cl_* type?

I think the issue is the use of the vector assign operator in get*Info helper function. One possible fix is to replace this with a for loop and construct from the wrapper, forcing a increment in the ref count. I have not had time to try it yet.

Re: Should clGet*Info increment the reference to the cl_* type?

The problem isn't limited to the getInfo overload for vector returns. As the problem occurred in my example for with the queue.getInfo<CL_QUEUE_CONTEXT>() template method which returns a straight cl::Context. This method eventually drops into this template helper struct:

I can't get the compiler to recognize that it should fall into that specialization when getting passed a cl::Context object.
It calls the retain method of detail::Wrapper, which is currently protected, and probably should remain so.

I don't like this for two reasons. It will require a lot of code duplication, though I can refactor the GetInfoHelper specialization into a macro. The tricky part was that the specialization has to be declared after cl::Context was fully specified because of the sizeof operator being used.

The next reason I don't like this is I had to make the object_ member of detail::Wrapper public. This seemed slightly less egregious then making the retain method public. Though what would you think about making a cl::Context (and friends) constructor that simply takes the cl_type it is associated with and calls retain on it? This adds a constructor to the public interface, though theoretically this could have utility outside of the C++ bindings. For example, if using another third party library returns cl_* types, then the C++ bindings could be used to wrap around those returned values (properly calling the clRetain* function).