"Dorrington, Albert" <albert.dorring...@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. > Al Dorrington > Software Engineer Sr > Lockheed Martin, Mission Systems and Training > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgp_0cKxxqjLV.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
