clCreateUserEvent

From 5.9 Event Objects

The execution status of an enqueued command at any given point in time can be CL_QUEUED (command has been enqueued in the command-queue), CL_SUBMITTED (enqueued command has been submitted by the host to the device associated with the command-queue), CL_RUNNING (device is currently executing this command), CL_COMPLETE (command has successfully completed) or the appropriate error code if the command was abnormally terminated (this may be caused by a bad memory access etc.).

The function cl_event clCreateUserEvent (cl_context context, cl_int *errcode_ret)

The execution status of the user event object created is set to CL_SUBMITTED.

The function cl_int clSetUserEventStatus (cl_event event, cl_int execution_status) sets the execution status of a user event object.

If user created event is set to CL_SUBMITTED, then what if anything should be set for CL_QUEUED? I’m under the impression that the order of those events is strictly linear, i.e., CL_QUEUED -> CL_SUBMITTED -> CL_RUNNING -> CL_COMPLETED, possibly terminating with an error at any point. So what happens if someone queries CL_QUEUED? It doesn’t make sense to set the status (which also records the time?) of CL_QUEUED after CL_SUBMITTED has been set.

Also, if a function is passed a list of events to wait on, should that function internally retain each event in that list and then release them before returning?

I had to re-read the first questions a couple of times to understand what you are asking for.

If your question is “What happens if I pass a user event and CL_QUEUED when I call clSetUserEventStatus?” then the answer is: CL_INVALID_VALUE because the only allowed values are either CL_COMPLETE or a negative integer.

Is that what you were asking about?

Also, if a function is passed a list of events to wait on, should that function internally retain each event in that list and then release them before returning?

From the application’s point of view, OpenCL APIs do not perform implicit retains of CL objects except when indicated in the spec (this only happens in constructors).

If your question is “What happens if I pass a user event and CL_QUEUED when I call clSetUserEventStatus?” then the answer is: CL_INVALID_VALUE because the only allowed values are either CL_COMPLETE or a negative integer.

That kind of answers my question. I had missed the part about the only allowed values. But what I was hoping for was that we could set each of those state values. If a function is passed a waitlist and event, how do we set the profiling information for the event properly? I would like the function to return in the event info about when it was called (CL_QUEUED or CL_SUBMITTED, I don’t know which is best at the moment), when it was released from the waitlist (CL_RUNNING), and immediately prior to returning (CL_COMPLETE). I guess right now this isn’t possible?

It is not possible for the application to set event profiling information. It is also not possible to query profiling info for user events, clGetEventProfilingInfo will return CL_PROFILING_INFO_NOT_AVAILABLE. User events are not associated with a command queue or a device, so there is nothing for the runtime to profile.