[Intel-gfx] [PATCH] drm/i915: Do an optimistic is-busy? check first

[Chris Wilson]

On Thu, Sep 05, 2013 at 06:37:42PM +0200, Daniel Vetter wrote:
> On Thu, Sep 5, 2013 at 6:30 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > It also a confusion that the kernel can't prevent.
> >
> > lock_mutex
> > A checks bo, reports it idle
> > unlock_mutex
> >
> > lock_mutex
> > B renders to bo
> > unlock_mutex
> >
> > lock_mutex
> > A uses bo, stalls
> > unlock_mutex
> >
> > Whether or not the checking of the bo is locked is irrelevant as it can
> > be gazzumped at anytime between the check and the use.
> 
> 
> Nope, I'm talking about a different kind of confusion.
> 
> Object A is busy on the RCS with seqno 1.
> Some other guy submits a bit of work to the blitter with seqno 2.
> Blitter finishes work, so signalled seqno is 2, RCS is still busy.
> 
> dri client sends a buffer swap request to the display server with object A.
> 
> Display server does pageflip/blit/whatever, just something which will
> force the kernel to move object A to the ring. After that object A is
> busy on the BLT with seqno 3.
> 
> Concurrently our dri client runs the busy ioctl and reads ring ==
> blitter, seqno == 1 and concludes that the object not busy. And this
> can happen while the RCS hasn't even finished rendering the original
> request from the client for object A. And that broken and will be
> prevented by locking.

That's incorrect, the client will be told the object is busy.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre