All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org,
	Kenneth Graunke <kenneth@whitecape.org>
Subject: Re: [PATCH] drm/i915: Use Write-Through cacheing for the display plane on Iris
Date: Wed, 31 Jul 2013 18:16:14 +0300	[thread overview]
Message-ID: <20130731151614.GF5004@intel.com> (raw)
In-Reply-To: <20130731133639.GA3637@cantiga.alporthouse.com>

On Wed, Jul 31, 2013 at 02:36:39PM +0100, Chris Wilson wrote:
> On Wed, Jul 31, 2013 at 04:16:40PM +0300, Ville Syrjälä wrote:
> > Also while looking through BSpec I noticed a slightly worrying note.
> > Apparently, on HSW at least, L3/not-LLC cacheable surfaces can
> > still evict dirty lines from L3 to LLC. The IVB flow diagrams leave me to
> > think IVB could behave the same way, even though it's not really spelled
> > out there. This would only be an issue when using MOCS since you can't
> > configure such a caching mode through the PTEs alone.
> 
> Afaict, the render write flush is sufficient to write the dirty cache
> lines to LLC/UC memory, so from the kernel/CPU perspective it never has
> to worry about L3.

The problem would only occur when we have a an non-LLC cached scanout buffer
which gets marked as L3 cacheable via MOCS. BSpec says that if stuff is evicted
from L3 it may land in LLC regardless of the LLC cacheability bits. The data
would then remain in LLC and would not get flushed to memory as that
would require an explicit clflush. And in the end we'd scan out some stale
garbage.

That's for HSW at least. For IVB I'm not sure. It may be that L3 and LLC
are supposed to be inclusive so if you have something in L3 it must also
be present in LLC. I've seen some old training material about MLC that
stated as much, but I don't know if that design was actually carried over
to IVB.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-07-31 15:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-30 16:58 [PATCH 1/2] drm/i915: Use the same pte_encoding for ppgtt as for gtt Chris Wilson
2013-07-30 16:58 ` [PATCH 2/2] drm/i915: Use Write-Through cacheing for the display plane on Iris Chris Wilson
2013-07-30 17:19   ` Ville Syrjälä
2013-07-30 17:36     ` Chris Wilson
2013-07-30 18:01       ` Ville Syrjälä
2013-07-30 18:10         ` Chris Wilson
2013-07-30 18:29           ` Chris Wilson
2013-07-30 17:45     ` [PATCH] " Chris Wilson
2013-07-30 19:25       ` Chris Wilson
2013-07-31 13:16         ` Ville Syrjälä
2013-07-31 13:36           ` Chris Wilson
2013-07-31 15:16             ` Ville Syrjälä [this message]
2013-07-31 15:26               ` Chris Wilson
2013-07-31 15:54                 ` Ville Syrjälä
2013-07-31 16:14                   ` Chris Wilson
2013-07-30 17:39   ` [PATCH 2/2] " Kenneth Graunke
2013-07-30 17:39 ` [PATCH 1/2] drm/i915: Use the same pte_encoding for ppgtt as for gtt Kenneth Graunke
2013-07-30 18:04 ` [PATCH] " Chris Wilson
2013-07-31  7:42   ` Ben Widawsky

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=20130731151614.GF5004@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kenneth@whitecape.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.