[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg-devel
Subject:    Re: [PATCH v2 0/3] present: various fixes
From:       Chris Wilson <chris () chris-wilson ! co ! uk>
Date:       2014-05-31 7:59:33
Message-ID: 20140531075932.GH10916 () nuc-i3427 ! alporthouse ! com
[Download RAW message or body]

On Sat, May 31, 2014 at 08:32:50AM +0100, Chris Wilson wrote:
> On Wed, May 28, 2014 at 05:40:28PM +0100, Frank Binns wrote:
> > This is v2 of some present fixes for issues discovered when adding
> > DRI3+present support to the PVR video driver.
> > 
> > Patch 1 has been reworked to now always restore the screen pixmap
> > at the point a pending flip is marked as aborted. Previously it
> > only did this in one place and only for the root window.
> > 
> > Patch 2 is new and deals with the same problem, but in in different
> > way, as the old patch 2. Essentially both patches attempt to deal
> > with resource leaks related to flipping. The old patch did this by
> > preventing any pending flip, associated with the window being
> > destroyed, from being aborted and destroyed during window
> > destruction. However, this relied on the DDX waiting for all kernel
> > events to arrive and be processed so that the necessary resource
> > clean up was triggered. The new patch just does the clean up at
> > the point the window is destroyed.
> > 
> > Patch 3 is identical to the old patch 4 (as patch 3 has now been
> > dropped).
> > 
> > Some issues still remain but these are fixed by the following patches
> > that are currently on the list but not in master:
> > - [PATCH] present: Queue flips for later execution
> > - [PATCH 3/6] present: Reorder Window teardown to avoid use-after-free
> > 
> > Frank Binns (3):
> >   present: restore screen pixmap when aborting a flip
> >   present: clean up all current flip resources on window destruction
> >   present: sync flips unless requested not to
> 
> This fixes the issues I was seeing earlier, notably the dangling vblank
> after applications quit.

However, it does introduce an issue where a fence won't be signalled if
the associated drawable is already freed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[prev in list] [next in list] [prev in thread] [next in thread]