Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Beckett <bob.beckett@collabora.com>
To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	kernel@collabora.com, "Matthew Auld" <matthew.auld@intel.com>,
	linux-kernel@vger.kernel.org
Subject: [Intel-gfx] [PATCH v10 03/11] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level
Date: Thu,  7 Jul 2022 20:02:21 +0000	[thread overview]
Message-ID: <20220707200230.1657555-4-bob.beckett@collabora.com> (raw)
In-Reply-To: <20220707200230.1657555-1-bob.beckett@collabora.com>

By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 4c1de0b4a10f..40249fa28a7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -46,7 +46,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 		     struct ttm_tt *ttm)
 {
-	return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+	bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+	return ((HAS_LLC(i915) || can_snoop) &&
 		!i915_ttm_gtt_binds_lmem(res) &&
 		ttm->caching == ttm_cached) ? I915_CACHE_LLC :
 		I915_CACHE_NONE;
-- 
2.25.1


  parent reply	other threads:[~2022-07-07 20:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07 20:02 [Intel-gfx] [PATCH v10 00/11] drm/i915: ttm for stolen Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 01/11] drm/i915/ttm: dont trample cache_level overrides during ttm move Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 02/11] drm/i915: limit ttm to dma32 for i965G[M] Robert Beckett
2022-07-07 20:02 ` Robert Beckett [this message]
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 04/11] drm/i915/gem: selftest should not attempt mmap of private regions Robert Beckett
2022-07-08  7:53   ` Matthew Auld
2022-07-08 13:22     ` Robert Beckett
2022-07-08 13:27       ` Matthew Auld
2022-07-08 13:31         ` Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 05/11] drm/i915: instantiate ttm ranger manager for stolen memory Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 06/11] drm/i915: sanitize mem_flags for stolen buffers Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 07/11] drm/i915: ttm move/clear logic fix Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 08/11] drm/i915/ttm: add buffer pin on alloc flag Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 09/11] drm/i915/selftest: don't attempt engine reset of guc submission engines Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 10/11] drm/i915/selftest: wait for requests during engine reset selftest Robert Beckett
2022-07-07 20:02 ` [Intel-gfx] [PATCH v10 11/11] drm/i915: stolen memory use ttm backend Robert Beckett
2022-07-07 21:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: ttm for stolen (rev8) Patchwork
2022-07-07 21:25 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-07-08 15:38 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=20220707200230.1657555-4-bob.beckett@collabora.com \
    --to=bob.beckett@collabora.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.auld@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tvrtko.ursulin@linux.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