[Mesa-dev] EXTERNAL: Re: Clover clEnqueue* function don't implement blocking?

[Dorrington, Albert]

> -----Original Message-----
> From: Francisco Jerez [mailto:currojerez at riseup.net]
> Sent: Monday, April 14, 2014 11:21 AM
> To: Dorrington, Albert; mesa-dev at lists.freedesktop.org
> Subject: EXTERNAL: Re: [Mesa-dev] Clover clEnqueue* function don't
> implement blocking?
> 
> "Dorrington, Albert" <albert.dorrington at lmco.com> writes:
> 
> > From reviewing api/transfer.cpp, it looks like all of the API calls that have a
> blocking parameter do not have anything that implement blocking
> functionality.
> >
> > clEnqueueReadBuffer(), clEnqueueWriteBuffer(),
> > clEnqueueReadBufferRect(), clEnqueueWriteBufferRect(),
> > clEnqueueReadImage(), clEnqueueWriteImage() clEnqueueMapBuffer(),
> > clEnqueueMapImage()
> >
> > For all of these functions, shouldn't there be a conditional wait on the
> event implemented, something like the following?
> >
> >   auto hev = create<hard_event>(...);
> >   ret_object(rd_ev, hev);
> >   if (blocking) { hev().wait(); }
> >   return CL_SUCCESS;
> >
> > My initial tests indicate this works, but I'm not sure if I'm missing something
> in the event handling/cleanup.
> >
> 
> Nope, that's usually not necessary.  The "blocking" parameter of some
> OpenCL entry points surprisingly doesn't imply that the enqueued operation
> itself should be blocking, it just determines whether the application is
> allowed to reuse the provided memory for other purposes after the call
> returns -- and in our implementation that's always the case because we don't
> do DMA from client addresses, as we discussed previously, so we can ignore
> the blocking parameter most of the time.
> 
> Note that this doesn't mean that buffer upload is necessarily synchronous
> [buffer download is, though], pipe drivers are free to keep the written bits in
> some temporary storage and perform the final copy asynchronously.
> 

Ah, ok - that makes sense - I was misinterpreting the OpenCL spec.

But when these events are queued, if there isn't a wait(), then what triggers their flush from the queued_events list?
That seems to only happen when the hard_event::wait() is called (assuming the status is queued)

Shouldn't something be flushing the queue as the events are processed (especially if nothing is pending on the events), well before the clFinish() call?