From: Jani Nikula <jani.nikula@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
James Ausmus <james.ausmus@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Disable caches for Global GTT.
Date: Thu, 06 Nov 2014 18:40:58 +0200 [thread overview]
Message-ID: <87bnokjn8l.fsf@intel.com> (raw)
In-Reply-To: <1415235396-13034-1-git-send-email-rodrigo.vivi@intel.com>
On Thu, 06 Nov 2014, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
> So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
>
> MOCS can still be used though. But if userspace is trusting PTE for
> cache selection the safest thing to do is to let caches disabled.
>
> BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry,
> so RTL will always use the value corresponding to pat_sel = 000"
>
> - System agent ggtt writes (i.e. cpu gtt mmaps) already work before
> this patch, i.e. the same uncached + snooping access like on gen6/7
> seems to be in effect.
> - So this just fixes blitter/render access. Again it looks like it's
> not just uncached access, but uncached + snooping. So we can still
> hold onto all our assumptions wrt cpu clflushing on LLC machines.
>
> v2: Cleaner patch as suggested by Chris.
> v3: Add Daniel's comment
>
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: James Ausmus <james.ausmus@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Stable@vger.kernel.org
> Tested-by: James Ausmus <james.ausmus@intel.com>
> Reviewed-by: James Ausmus <james.ausmus@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Pushed this one to drm-intel-fixes as-is, thanks for the patch, review,
and bikeshedding. :p
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index cb7adab..6d3fb3c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1920,6 +1920,22 @@ static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv)
> GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2)) |
> GEN8_PPAT(7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
>
> + if (!USES_PPGTT(dev_priv->dev))
> + /* Spec: "For GGTT, there is NO pat_sel[2:0] from the entry,
> + * so RTL will always use the value corresponding to
> + * pat_sel = 000".
> + * So let's disable cache for GGTT to avoid screen corruptions.
> + * MOCS still can be used though.
> + * - System agent ggtt writes (i.e. cpu gtt mmaps) already work
> + * before this patch, i.e. the same uncached + snooping access
> + * like on gen6/7 seems to be in effect.
> + * - So this just fixes blitter/render access. Again it looks
> + * like it's not just uncached access, but uncached + snooping.
> + * So we can still hold onto all our assumptions wrt cpu
> + * clflushing on LLC machines.
> + */
> + pat = GEN8_PPAT(0, GEN8_PPAT_UC);
> +
> /* XXX: spec defines this as 2 distinct registers. It's unclear if a 64b
> * write would work. */
> I915_WRITE(GEN8_PRIVATE_PAT, pat);
> --
> 1.9.3
>
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-11-06 16:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 16:18 [PATCH] drm/i915: Disable caches for Global GTT Rodrigo Vivi
2014-10-31 7:44 ` Chris Wilson
2014-10-31 10:14 ` Ville Syrjälä
2014-10-31 10:20 ` Chris Wilson
2014-10-31 12:27 ` Rodrigo Vivi
2014-10-31 21:38 ` Ausmus, James
2014-11-04 18:29 ` Ausmus, James
2014-11-05 11:11 ` Daniel Vetter
2014-11-06 0:56 ` Rodrigo Vivi
2014-11-06 16:40 ` Jani Nikula [this message]
2014-11-06 10:55 ` Chris Wilson
2014-11-06 19:09 ` Ville Syrjälä
2014-11-06 20:53 ` Ville Syrjälä
2014-11-06 21:55 ` Rodrigo Vivi
2014-11-07 9:33 ` Daniel Vetter
2014-11-07 9:51 ` Chris Wilson
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=87bnokjn8l.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=Stable@vger.kernel.org \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=james.ausmus@intel.com \
--cc=rodrigo.vivi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox