4 Replies Latest reply on Sep 17, 2012 10:33 PM by levyfan

    when to call clReleaseEvent()

    levyfan

      cl_event event;

      clEnqueueNDRangeKernel(secondaryQueue, ..., 0, NULL, &event);   //kernel1

      clEnqueueNDRangeKernel(queue, ..., 1, &event, NULL);                   //kernel2

      clReleaseEvent(event);

       

      is the code above right?

      or we need to release event after kernel2 is completed?

        • Re: when to call clReleaseEvent()
          Wenju

          You'd better add

          while(eventStatus != CL_COMPLETE)

              {

                  status = clGetEventInfo(

                                  event,

                                  CL_EVENT_COMMAND_EXECUTION_STATUS,

                                  sizeof(cl_int),

                                  &eventStatus,

                                  NULL);

                  CHECK_OPENCL_ERROR(status, "clGetEventInfo failed.");

              }

          after kernel1, then release it. Define event2, release it.

            • Re: when to call clReleaseEvent()
              levyfan

              so you mean:

               

              cl_event event;

              clEnqueueNDRangeKernel(secondaryQueue, ..., 0, NULL, &event);   //kernel1

              clEnqueueNDRangeKernel(queue, ..., 1, &event, NULL);                   //kernel2

              while(eventStatus != CL_COMPLETE) {

                  status = clGetEventInfo(event, CL_EVENT_COMMAND_EXECUTION_STATUS, sizeof(cl_int),&eventStatus,NULL);

                  CHECK_OPENCL_ERROR(status, "clGetEventInfo failed.");

              }

              clReleaseEvent(event);

               

              right?

            • Re: when to call clReleaseEvent()
              LeeHowes

              Yes, that's correct. It's a retain/release reference counting API. When you call clEnqueueNDRangeKernel it takes a reference to the event. When you release it you decrease the reference. So in that code if you watched the reference count you'd see it go 1, 2, 3, 1 (unless the kernel completes in the meantime in which case it may drop faster). Or, possibly, as the first enqueue actually creates the event you start at 2. In any case both the host API and the runtime itself have references to objects.