On Thu, Jun 28, 2012 at 03:47:23PM +0200, Francisco Jerez wrote: > Tom Stellard <thomas.stell...@amd.com> writes: > > > On Thu, Jun 28, 2012 at 01:09:20AM +0200, Francisco Jerez wrote: > >> Tom Stellard <tstel...@gmail.com> writes: > >> > >> > We need to increment the reference count for objects, like cl_event, > >> > that the user is responsible for destroying when they are returned from > >> > the API. Otherwise, the object will be destroyed when clover is done > >> > with > >> > it, even though the user will still have a reference to it. For example: > >> > > >> > 1. clEnqueueNDRangeKernel(queue, ... , &event) > >> > - create an event object > >> > - refcount = 1 > >> > > >> > 2. clFlush(queue) > >> > - event object is removed from the queue and its reference count is > >> > decremented. > >> > - refcount = 0, event is deleted > >> > > >> > 3. clGetEventInfo(event, ...) > >> > - segfault > >> > >> I don't think this could cause the problem you've seen... After step 1 > >> the event object ends up queued in queue->queued_events, a ref_ptr<> > >> list that holds additional references to each object it contains, so, > >> after step 1 refcount is supposed to be 2 already... You're probably > >> hitting something more subtle, try the attached patch. > >> > > > > I missed that part about ref_ptr. I'll have to look at that again. > > However that sequence is causing a segfault in clGetEventInfo in all > > of the AMD OpenCL SDK examples (or at least all of them that make it > > that far), and it is because the event is being deleted too early. > > > Yes, probably because the user-defined copy constructor of > ref_ptr<hard_event> is not being used by the event queue because it's > defined as a template, try the patch I attached. > > >[...]
Your patch works. Thanks. -Tom _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
