On Mon, Feb 20, 2017 at 06:41:04PM +0000, Matthew Auld wrote:
> On 17 February 2017 at 14:07, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> > Flushing the cachelines for an object is slow, can be as much as 100ms
> > for a large framebuffer. We currently do this under the struct_mutex BKL
> > on execution or on pageflip. But now with the ability to add fences to
> > obj->resv for both flips and execbuf (and we naturally wait on the fence
> > before CPU access), we can move the clflush operation to a workqueue and
> > signal a fence for completion, thereby doing the work asynchronously and
> > not blocking the driver or its clients.
> >
> > Suggested-by: Akash Goel <akash.goel@xxxxxxxxx>
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> > Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
> > +static void i915_clflush_release(struct dma_fence *fence)
> > +{
> > + struct clflushf *f = container_of(fence, typeof(*f), dma);
> > +
> > + i915_sw_fence_fini(&f->wait);
> > + dma_fence_free(&f->dma);
> Don't we need a kfree(f) somewhere?
It's a fence subclass, the dma_fence_free() frees the block of memory.
> Also CI didn't look very happy, is this series meant to be standalone,
> or is there something else waiting in the wings?
The different timings on CI uncovered a genuine bug, in the race between
the fence and the worker. Took me by surprise sa it had passed in the
past, but that was before we added debugobject support to the swfences.
It paid off!
Now there's just a fbc failure on bxt which is more likely to be a bug
in the tracking.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
