From: Chris Wilson <chris@chris-wilson.co.uk>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH 2/2] drm/i915: Perform object clflushing asynchronously
Date: Mon, 20 Feb 2017 20:44:05 +0000 [thread overview]
Message-ID: <20170220204405.GQ11809@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <CAM0jSHPn=AKmyfZP+yLA44fV3GPe8LwT6=pMD6V7zzZcx0whdQ@mail.gmail.com>
On Mon, Feb 20, 2017 at 06:41:04PM +0000, Matthew Auld wrote:
> On 17 February 2017 at 14:07, Chris Wilson <chris@chris-wilson.co.uk> 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@intel.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > +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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-02-20 20:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 14:07 [PATCH 1/2] drm/i915: Skip clflushes for all non-page backed objects Chris Wilson
2017-02-17 14:07 ` [PATCH 2/2] drm/i915: Perform object clflushing asynchronously Chris Wilson
2017-02-20 18:41 ` Matthew Auld
2017-02-20 20:44 ` Chris Wilson [this message]
2017-02-17 16:56 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Skip clflushes for all non-page backed objects Patchwork
2017-02-20 18:28 ` [PATCH 1/2] " Matthew Auld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170220204405.GQ11809@nuc-i3427.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.william.auld@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.