Jerome Glisse wrote: > Hi again Thomas, > > It seems that if a fence is created with a userobject in superioctl, > one ref on the fence from one of the associated bo (the EXE bo i think) > is not properly unreferenced automagicly by kernel on program exit > if program never wait or ask for the status on each BO. So for instance > -SIOCTL CMD BUFFER, BO_DATA1, BO_DATA2 > - create fence & emit (fence refcount = 1) > - associate buffer & fence (fence refcount = 4 3buffers) > - program exit (doesn't do any more thing) > - fence wait & flush > - fence fully signaled > - bo data1 & data2 deref the fence (fence refcount = 2) > - fence is destructed (fence refcount = 1 so no destruction) > (i am not showing temporary refcounting which happen while the fence > is in use by a function) > > You end up with a fence signaled but still referenced by a BO, it looks like > that drm doesn't properly unreference the fence from the associated EXE BO. > Shouldn't the BO associated with a fence deref this fence in fence_handler ? > Or where should i look to find why one of the BO is not properly derefing > the fence. > > Cheers, > Jerome Glisse <[EMAIL PROTECTED]> > A signaled fence doesn't automatically trigger an action associated with that, like for example buffer object idle. Such things happens on-demand. This is partly because we want to avoid unnecessary flushes, partly because there are other objects than buffer objects that depend on fences.
When a buffer object reaches refcount 0, it's placed on the delayed delete list, and the corresponding fence is flushed to make sure it will eventually signal. The delayed delete list is looped through to check whether a buffer is idle which means it's OK to destroy it. The other option is to hang all objects waiting for a fence to be deleted on a list originating from that fence, but I've not pursued that option since the aboved-mentioned implementation appears to work just fine. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
