From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] drm/i915: Insert a command barrier on BLT/BSD cache flushes
Date: Mon, 09 Feb 2015 20:15:22 +0200 [thread overview]
Message-ID: <87twyv0x51.fsf@intel.com> (raw)
In-Reply-To: <20150209160709.GC9837@nuc-i3427.alporthouse.com>
On Mon, 09 Feb 2015, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Mon, Feb 09, 2015 at 06:00:25PM +0200, Jani Nikula wrote:
>> On Thu, 22 Jan 2015, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> > This looked like an odd regression from
>> >
>> > commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b
>> > Author: Chris Wilson <chris@chris-wilson.co.uk>
>> > Date: Thu Jun 12 10:28:55 2014 +0100
>> >
>> > drm/i915: Restrict GPU boost to the RCS engine
>> >
>> > but in reality it undercovered a much older coherency bug. The issue that
>> > boosting the GPU frequency on the BCS ring was masking was that we could
>> > wake the CPU up after completion of a BCS batch and inspect memory prior
>> > to the write cache being fully evicted. In order to serialise the
>> > breadcrumb interrupt (and so ensure that the CPU's view of memory is
>> > coherent) we need to perform a post-sync operation in the MI_FLUSH_DW.
>> >
>> > v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists).
>> >
>> > Testcase: gpuX-rcs-gpu-read-after-write
>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: stable@vger.kernel.org
>> > Acked-by: Daniel Vetter <daniel@ffwll.ch>
>> > ---
>> > drivers/gpu/drm/i915/intel_lrc.c | 20 +++++++++++---------
>> > drivers/gpu/drm/i915/intel_ringbuffer.c | 23 +++++++++++++++++++----
>> > 2 files changed, 30 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>> > index e405b61cdac5..8e71d8851c9a 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -1237,15 +1237,17 @@ static int gen8_emit_flush(struct intel_ringbuffer *ringbuf,
>> >
>> > cmd = MI_FLUSH_DW + 1;
>> >
>> > - if (ring == &dev_priv->ring[VCS]) {
>> > - if (invalidate_domains & I915_GEM_GPU_DOMAINS)
>> > - cmd |= MI_INVALIDATE_TLB | MI_INVALIDATE_BSD |
>> > - MI_FLUSH_DW_STORE_INDEX |
>> > - MI_FLUSH_DW_OP_STOREDW;
>> > - } else {
>> > - if (invalidate_domains & I915_GEM_DOMAIN_RENDER)
>> > - cmd |= MI_INVALIDATE_TLB | MI_FLUSH_DW_STORE_INDEX |
>> > - MI_FLUSH_DW_OP_STOREDW;
>> > + /* We always require a command barrier so that subsequent
>> > + * commands, such as breadcrumb interrupts, are strictly ordered
>> > + * wrt the contents of the write cache being flushed to memory
>> > + * (and thus being coherent from the CPU).
>> > + */
>> > + cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
>> > +
>> > + if (invalidate_domains & I915_GEM_GPU_DOMAINS) {
>>
>> Why do you change the mask from I915_GEM_DOMAIN_RENDER to
>> I915_GEM_GPU_DOMAINS for ring != VCS?
>
> My bad, I didn't notice that execlists was originally broken. The patch
> is correct.
I'll take your and Daniel's word for it. I hope I won't have to regret
not asking you to split this into two patches...
Pushed to drm-intel-next-fixes, thanks for the patch and ack.
BR,
Jani.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-02-09 18:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-22 13:13 [PATCH] drm/i915: Insert a command barrier on BLT/BSD cache flushes Chris Wilson
2015-01-22 13:24 ` [Intel-gfx] " Daniel Vetter
2015-01-22 13:32 ` Chris Wilson
2015-01-22 13:42 ` [PATCH v2] " Chris Wilson
2015-01-22 22:45 ` shuang.he
2015-02-09 16:00 ` [Intel-gfx] " Jani Nikula
2015-02-09 16:07 ` Chris Wilson
2015-02-09 18:15 ` Jani Nikula [this message]
2015-01-22 22:41 ` [PATCH] " shuang.he
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=87twyv0x51.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
/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.