[Intel-gfx] [PATCH] drm/i915: Serialise the fill BLT with the vma pinning

[Chris Wilson]

Quoting Matthew Auld (2019-08-21 12:00:07)
> On 20/08/2019 14:52, Chris Wilson wrote:
> > Make sure that we wait for the vma to be pinned prior to telling the GPU
> > to fill the pages through that vma.
> > 
> > However, since our async operations fight over obj->resv->excl_fence we
> > must manually order them. This makes it much more fragile, and gives an
> > outside observer the chance to see the intermediate fences. To be
> > discussed!
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld at intel.com>
> > ---
> >   .../gpu/drm/i915/gem/i915_gem_client_blt.c    | 46 ++++++++++++++-----
> >   1 file changed, 35 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > index 3502071e1391..bbbc10499099 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > @@ -71,10 +71,30 @@ static struct i915_sleeve *create_sleeve(struct i915_address_space *vm,
> >               goto err_free;
> >       }
> >   
> > +     /*
> > +      * XXX fix scheduling with get_pages & clear workers
> > +      *
> > +      * The complication is that we end up overwriting the same
> > +      * obj->resv->excl_fence for each stage of the operation. That fence
> > +      * should be set on scheduling the work, and only signaled upon
> > +      * completion of the entire workqueue.
> > +      *
> > +      * Within the workqueue, we use the fence to schedule each individual
> > +      * task. Each individual task knows to use obj->resv->fence.
> > +      *
> > +      * To an outsider, they must wait until the end and so the
> > +      * obj->resv->fence must be the composite.
> > +      *
> > +      * Ideas?
> > +      */
> 
> I don't have any good ideas...
> 
> Are we meant to somehow have a "shadow" resv obj that we use for our 
> intermediate pipelined ops, such that we don't leak anything?

A sketch I haven't put any code to is a struct chain_fence {
	struct dma_fence base;
	struct dma_fence *prev;
	struct dma_fence_cb cb;
	/* if only dma_chain_fence wan't already taken, maybe dma_composite_fence */
 }; that we insert as dma_resv_add_excl_fence() and then
pass to all the async operations that then chain to. It means more work
in making sure we have the fence available at all times, all the way
down the chain, but it should work (now and in the future)... Give or
take various factors to make sure we don't wait on the same fence while
building it (eviction and shrinking).
-Chris