[Mesa-dev] [PATCH v3 1/1] clover: Wait for requested operation if blocking flag is set
Jan Vesely
jan.vesely at rutgers.edu
Fri Aug 18 22:08:23 UTC 2017
On Fri, 2017-08-18 at 14:19 -0700, Francisco Jerez wrote:
> Jan Vesely <jan.vesely at rutgers.edu> writes:
>
> > v2: wait in map_buffer and map_image as well
> > v3: use event::wait instead of wait (skips fence wait for hard_event)
> >
>
> Unfortunately this won't wait for the event action to be executed, only
> for all dependencies of the event to become signalled, so there's a
> possibility for a race condition in a multi-threaded environment. Using
> wait_signalled as I suggested earlier would address this issue.
There's no wait_signalled() function.
event::signalled() returns !wait_count.
event::wait()
{
--- This should wait for dependencies
for (event &ev : deps)
ev.wait();
--- This should wait for signalled, no? at least the condition is
identical
std::unique_lock<std::mutex> lock(mutex);
cv.wait(lock, [=]{ return !wait_count; });
}
am I missing something?
Jan
>
> > Signed-off-by: Jan Vesely <jan.vesely at rutgers.edu>
> > ---
> > src/gallium/state_trackers/clover/api/transfer.cpp | 30 ++++++++++++++++++++--
> > 1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/clover/api/transfer.cpp b/src/gallium/state_trackers/clover/api/transfer.cpp
> > index f7046253be..6f1ac4b931 100644
> > --- a/src/gallium/state_trackers/clover/api/transfer.cpp
> > +++ b/src/gallium/state_trackers/clover/api/transfer.cpp
> > @@ -295,6 +295,9 @@ clEnqueueReadBuffer(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> > &mem, obj_origin, obj_pitch,
> > region));
> >
> > + if (blocking)
> > + hev().event::wait();
> > +
> > ret_object(rd_ev, hev);
> > return CL_SUCCESS;
> >
> > @@ -325,6 +328,9 @@ clEnqueueWriteBuffer(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> > ptr, {}, obj_pitch,
> > region));
> >
> > + if (blocking)
> > + hev().event::wait();
> > +
> > ret_object(rd_ev, hev);
> > return CL_SUCCESS;
> >
> > @@ -362,6 +368,9 @@ clEnqueueReadBufferRect(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> > &mem, obj_origin, obj_pitch,
> > region));
> >
> > + if (blocking)
> > + hev().event::wait();
> > +
> > ret_object(rd_ev, hev);
> > return CL_SUCCESS;
> >
> > @@ -399,6 +408,9 @@ clEnqueueWriteBufferRect(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> > ptr, host_origin, host_pitch,
> > region));
> >
> > + if (blocking)
> > + hev().event::wait();
> > +
> > ret_object(rd_ev, hev);
> > return CL_SUCCESS;
> >
> > @@ -504,6 +516,9 @@ clEnqueueReadImage(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> > &img, src_origin, src_pitch,
> > region));
> >
> > + if (blocking)
> > + hev().event::wait();
> > +
> > ret_object(rd_ev, hev);
> > return CL_SUCCESS;
> >
> > @@ -538,6 +553,9 @@ clEnqueueWriteImage(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> > ptr, {}, src_pitch,
> > region));
> >
> > + if (blocking)
> > + hev().event::wait();
> > +
> > ret_object(rd_ev, hev);
> > return CL_SUCCESS;
> >
> > @@ -667,7 +685,11 @@ clEnqueueMapBuffer(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> >
> > void *map = mem.resource(q).add_map(q, flags, blocking, obj_origin, region);
> >
> > - ret_object(rd_ev, create<hard_event>(q, CL_COMMAND_MAP_BUFFER, deps));
> > + auto hev = create<hard_event>(q, CL_COMMAND_MAP_BUFFER, deps);
> > + if (blocking)
> > + hev().event::wait();
> > +
> > + ret_object(rd_ev, hev);
> > ret_error(r_errcode, CL_SUCCESS);
> > return map;
> >
> > @@ -695,7 +717,11 @@ clEnqueueMapImage(cl_command_queue d_q, cl_mem d_mem, cl_bool blocking,
> >
> > void *map = img.resource(q).add_map(q, flags, blocking, origin, region);
> >
> > - ret_object(rd_ev, create<hard_event>(q, CL_COMMAND_MAP_IMAGE, deps));
> > + auto hev = create<hard_event>(q, CL_COMMAND_MAP_IMAGE, deps);
> > + if (blocking)
> > + hev().event::wait();
> > +
> > + ret_object(rd_ev, hev);
> > ret_error(r_errcode, CL_SUCCESS);
> > return map;
> >
> > --
> > 2.13.5
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170818/99252774/attachment.sig>
More information about the mesa-dev
mailing list