PDA

View Full Version : user event limitations



RlyDontKnow
05-08-2011, 11:44 PM
as per the standard the following limitation is put on custom user events:

NOTE: Enqueued commands that specify user events in the event_wait_list argument of
clEnqueue*** commands must ensure that the status of these user events being waited on are set
using clSetUserEventStatus before any OpenCL APIs that release OpenCL objects except for
event objects are called; otherwise the behavior is undefined.


Does this apply to all API calls that release objects or are there cases where it's fine to free an object while something waits on an user event (e.g. freeing an object in a different context (which may even be associated with a different platform))?

david.garcia
05-09-2011, 04:53 AM
Does this apply to all API calls that release objects or are there cases where it's fine to free an object while something waits on an user event (e.g. freeing an object in a different context (which may even be associated with a different platform))?

That restriction only applies to objects that are required by the particular clEnqueue*** calls that depend on a user event created by the application.

The idea is simple: wait until the user event is set before you destroy any objects that will be used once the event is set.

RlyDontKnow
05-09-2011, 05:07 AM
your statement clearly differs from the example in the spec, though:


For example, the following code sequence will result in undefined behavior of clReleaseMemObject.


ev1 = clCreateUserEvent(ctx, NULL);
clEnqueueWriteBuffer(cq, buf1, CL_FALSE, ..., 1, &ev1, NULL);
clEnqueueWriteBuffer(cq, buf2, CL_FALSE,...);
clReleaseMemObject(buf2);
clSetUserEventStatus(ev1, CL_COMPLETE);


The following code sequence, however, works correctly.


ev1 = clCreateUserEvent(ctx, NULL);
clEnqueueWriteBuffer(cq, buf1, CL_FALSE, ..., 1, &ev1, NULL);
clEnqueueWriteBuffer(cq, buf2, CL_FALSE,...);
clSetUserEventStatus(ev1, CL_COMPLETE);
clReleaseMemObject(buf2);



obviously the write to buf2 doesn't wait on the user event, yet that release has to occur after firing ev1 according to the examples given

david.garcia
05-09-2011, 05:32 AM
I should have been more clear: when I said "depend on a user event" I meant to say "depend on a user event, even transitively". The general idea is what I stated earlier.

RlyDontKnow
05-09-2011, 05:34 AM
I should have been more clear: when I said "depend on a user event" I meant to say "depend on a user event, even transitively". The general idea is what I stated earlier.

could you clarify how the write to buf2 depends on the event in the example of the spec? or is that example only valid the way it is if the queue used in that example is not an out-of-order queue? (if so this should be explicitly stated imo)

david.garcia
05-09-2011, 03:04 PM
could you clarify how the write to buf2 depends on the event in the example of the spec? or is that example only valid the way it is if the queue used in that example is not an out-of-order queue? (if so this should be explicitly stated imo)

Right, my assumption is that the example is using an in-order queue since it's the default.

I agree that the spec should be clearer in this regard. Feel free to create a bug report using http://www.khronos.org/bugzilla/ if you want it to be clarified.