All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem
@ 2021-06-25 12:27 ` Matthew Auld
  0 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-25 12:27 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Hellström, dri-devel, Daniel Vetter

This is already the case for our kernel internal mappings, and since we
now only support a single mode this should always be WC if the object
can be placed in lmem.

v2: rebase and also update set_domain

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c |  6 ++++++
 drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  9 +++++++++
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 21 +++++++++++++++++++++
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  4 ++++
 4 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 073822100da7..d0c91697bb22 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -571,6 +571,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 	if (READ_ONCE(obj->write_domain) == read_domains)
 		goto out_unpin;
 
+	if (i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL) &&
+	    read_domains != I915_GEM_DOMAIN_WC) {
+		err = -EINVAL;
+		goto out_unpin;
+	}
+
 	if (read_domains & I915_GEM_DOMAIN_WC)
 		err = i915_gem_object_set_to_wc_domain(obj, write_domain);
 	else if (read_domains & I915_GEM_DOMAIN_GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index a90f796e85c0..f3586b36dd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -688,6 +688,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 	    !i915_gem_object_has_iomem(obj))
 		return -ENODEV;
 
+	/*
+	 * Note that even if the object can also be placed in smem then we still
+	 * map as WC here, since we can only support a single mode. On DG1 this
+	 * sucks since we can't turn off snooping for this case.
+	 */
+	if (mmap_type != I915_MMAP_TYPE_WC &&
+	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
+		return -ENODEV;
+
 	mmo = mmap_offset_attach(obj, mmap_type, file);
 	if (IS_ERR(mmo))
 		return PTR_ERR(mmo);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..326956c18f76 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,27 @@ bool i915_gem_object_has_iomem(const struct drm_i915_gem_object *obj)
 	return obj->mem_flags & I915_BO_FLAG_IOMEM;
 }
 
+/**
+ * i915_gem_object_placements_contain_type - Check whether the object can be
+ * placed at certain memory type
+ * @obj: Pointer to the object
+ * @type: The memory type to check
+ *
+ * Return: True if the object can be placed in @type. False otherwise.
+ */
+bool i915_gem_object_placements_contain_type(struct drm_i915_gem_object *obj,
+					     enum intel_memory_type type)
+{
+	unsigned int i;
+
+	for (i = 0; i < obj->mm.n_placements; i++) {
+		if (obj->mm.placements[i]->type == type)
+			return true;
+	}
+
+	return false;
+}
+
 void i915_gem_init__objects(struct drm_i915_private *i915)
 {
 	INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ea3224a480c4..e1daa58bc225 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -12,6 +12,7 @@
 #include <drm/drm_device.h>
 
 #include "display/intel_frontbuffer.h"
+#include "intel_memory_region.h"
 #include "i915_gem_object_types.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_ww.h"
@@ -597,6 +598,9 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
 
 bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
 
+bool i915_gem_object_placements_contain_type(struct drm_i915_gem_object *obj,
+					     enum intel_memory_type type);
+
 #ifdef CONFIG_MMU_NOTIFIER
 static inline bool
 i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
-- 
2.26.3


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [Intel-gfx] [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem
@ 2021-06-25 12:27 ` Matthew Auld
  0 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-25 12:27 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Hellström, dri-devel, Daniel Vetter

This is already the case for our kernel internal mappings, and since we
now only support a single mode this should always be WC if the object
can be placed in lmem.

v2: rebase and also update set_domain

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c |  6 ++++++
 drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  9 +++++++++
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 21 +++++++++++++++++++++
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  4 ++++
 4 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 073822100da7..d0c91697bb22 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -571,6 +571,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 	if (READ_ONCE(obj->write_domain) == read_domains)
 		goto out_unpin;
 
+	if (i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL) &&
+	    read_domains != I915_GEM_DOMAIN_WC) {
+		err = -EINVAL;
+		goto out_unpin;
+	}
+
 	if (read_domains & I915_GEM_DOMAIN_WC)
 		err = i915_gem_object_set_to_wc_domain(obj, write_domain);
 	else if (read_domains & I915_GEM_DOMAIN_GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index a90f796e85c0..f3586b36dd53 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -688,6 +688,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 	    !i915_gem_object_has_iomem(obj))
 		return -ENODEV;
 
+	/*
+	 * Note that even if the object can also be placed in smem then we still
+	 * map as WC here, since we can only support a single mode. On DG1 this
+	 * sucks since we can't turn off snooping for this case.
+	 */
+	if (mmap_type != I915_MMAP_TYPE_WC &&
+	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
+		return -ENODEV;
+
 	mmo = mmap_offset_attach(obj, mmap_type, file);
 	if (IS_ERR(mmo))
 		return PTR_ERR(mmo);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..326956c18f76 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,27 @@ bool i915_gem_object_has_iomem(const struct drm_i915_gem_object *obj)
 	return obj->mem_flags & I915_BO_FLAG_IOMEM;
 }
 
+/**
+ * i915_gem_object_placements_contain_type - Check whether the object can be
+ * placed at certain memory type
+ * @obj: Pointer to the object
+ * @type: The memory type to check
+ *
+ * Return: True if the object can be placed in @type. False otherwise.
+ */
+bool i915_gem_object_placements_contain_type(struct drm_i915_gem_object *obj,
+					     enum intel_memory_type type)
+{
+	unsigned int i;
+
+	for (i = 0; i < obj->mm.n_placements; i++) {
+		if (obj->mm.placements[i]->type == type)
+			return true;
+	}
+
+	return false;
+}
+
 void i915_gem_init__objects(struct drm_i915_private *i915)
 {
 	INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ea3224a480c4..e1daa58bc225 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -12,6 +12,7 @@
 #include <drm/drm_device.h>
 
 #include "display/intel_frontbuffer.h"
+#include "intel_memory_region.h"
 #include "i915_gem_object_types.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_ww.h"
@@ -597,6 +598,9 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
 
 bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
 
+bool i915_gem_object_placements_contain_type(struct drm_i915_gem_object *obj,
+					     enum intel_memory_type type);
+
 #ifdef CONFIG_MMU_NOTIFIER
 static inline bool
 i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
-- 
2.26.3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
  2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
@ 2021-06-25 12:27   ` Matthew Auld
  -1 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-25 12:27 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Hellström, dri-devel, Daniel Vetter

We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.

I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
for DGFX, so hopefully can also be safely rejected.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
 drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d0c91697bb22..e3459a524e64 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 		goto out_unpin;
 	}
 
+	if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
+	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM) &&
+	    read_domains != I915_GEM_DOMAIN_CPU) {
+		err = -EINVAL;
+		goto out_unpin;
+	}
+
 	if (read_domains & I915_GEM_DOMAIN_WC)
 		err = i915_gem_object_set_to_wc_domain(obj, write_domain);
 	else if (read_domains & I915_GEM_DOMAIN_GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index f3586b36dd53..afc9f3dc38b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 		     enum i915_mmap_type mmap_type,
 		     u64 *offset, struct drm_file *file)
 {
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
 	struct i915_mmap_offset *mmo;
 
 	if (i915_gem_object_never_mmap(obj))
@@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
 		return -ENODEV;
 
+	/*
+	 * For smem only placements on DGFX we need to default to WB. On DG1
+	 * everything is snooped always, so should always be coherent.
+	 */
+	 if (IS_DGFX(i915) &&
+	     mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
+	     i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM))
+		return -ENODEV;
+
 	mmo = mmap_offset_attach(obj, mmap_type, file);
 	if (IS_ERR(mmo))
 		return PTR_ERR(mmo);
-- 
2.26.3


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
@ 2021-06-25 12:27   ` Matthew Auld
  0 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-25 12:27 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Hellström, dri-devel, Daniel Vetter

We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.

I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
for DGFX, so hopefully can also be safely rejected.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
 drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d0c91697bb22..e3459a524e64 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 		goto out_unpin;
 	}
 
+	if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
+	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM) &&
+	    read_domains != I915_GEM_DOMAIN_CPU) {
+		err = -EINVAL;
+		goto out_unpin;
+	}
+
 	if (read_domains & I915_GEM_DOMAIN_WC)
 		err = i915_gem_object_set_to_wc_domain(obj, write_domain);
 	else if (read_domains & I915_GEM_DOMAIN_GTT)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index f3586b36dd53..afc9f3dc38b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 		     enum i915_mmap_type mmap_type,
 		     u64 *offset, struct drm_file *file)
 {
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
 	struct i915_mmap_offset *mmo;
 
 	if (i915_gem_object_never_mmap(obj))
@@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
 		return -ENODEV;
 
+	/*
+	 * For smem only placements on DGFX we need to default to WB. On DG1
+	 * everything is snooped always, so should always be coherent.
+	 */
+	 if (IS_DGFX(i915) &&
+	     mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
+	     i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM))
+		return -ENODEV;
+
 	mmo = mmap_offset_attach(obj, mmap_type, file);
 	if (IS_ERR(mmo))
 		return PTR_ERR(mmo);
-- 
2.26.3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
  2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
  (?)
  (?)
@ 2021-06-25 13:18 ` Patchwork
  -1 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2021-06-25 13:18 UTC (permalink / raw)
  To: Matthew Auld; +Cc: intel-gfx

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
URL   : https://patchwork.freedesktop.org/series/91921/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
02ac31b35505 drm/i915/gem: only allow WC for lmem
ebe44a5c829b drm/i915/gem: only allow WB for smem only placements
-:59: WARNING:TABSTOP: Statements should start on a tabstop
#59: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:705:
+	 if (IS_DGFX(i915) &&

total: 0 errors, 1 warnings, 0 checks, 35 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
  2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
                   ` (2 preceding siblings ...)
  (?)
@ 2021-06-25 13:20 ` Patchwork
  -1 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2021-06-25 13:20 UTC (permalink / raw)
  To: Matthew Auld; +Cc: intel-gfx

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
URL   : https://patchwork.freedesktop.org/series/91921/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:    expected struct i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:    got void [noderef] __iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
  2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
                   ` (3 preceding siblings ...)
  (?)
@ 2021-06-25 13:49 ` Patchwork
  -1 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2021-06-25 13:49 UTC (permalink / raw)
  To: Matthew Auld; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 4112 bytes --]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
URL   : https://patchwork.freedesktop.org/series/91921/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10281 -> Patchwork_20470
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/index.html

Known issues
------------

  Here are the changes found in Patchwork_20470 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_cs_nop@fork-compute0:
    - fi-ivb-3770:        NOTRUN -> [SKIP][1] ([fdo#109271]) +31 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-ivb-3770/igt@amdgpu/amd_cs_nop@fork-compute0.html

  * igt@gem_exec_fence@basic-busy@bcs0:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][2] ([fdo#109271]) +14 similar issues
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@gem_exec_fence@basic-busy@bcs0.html

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html

  * igt@i915_selftest@live@gt_pm:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][4] ([i915#1886] / [i915#2291])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-hpd-fast:
    - fi-ivb-3770:        NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-ivb-3770/igt@kms_chamelium@dp-hpd-fast.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s0:
    - {fi-tgl-1115g4}:    [FAIL][8] ([i915#1888]) -> [PASS][9]
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/fi-tgl-1115g4/igt@gem_exec_suspend@basic-s0.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/fi-tgl-1115g4/igt@gem_exec_suspend@basic-s0.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (40 -> 38)
------------------------------

  Additional (2): fi-kbl-soraka fi-ivb-3770 
  Missing    (4): fi-ilk-m540 fi-hsw-4200u fi-bdw-samus fi-bsw-n3050 


Build changes
-------------

  * Linux: CI_DRM_10281 -> Patchwork_20470

  CI-20190529: 20190529
  CI_DRM_10281: de45b368328acbdfd194032621c175a65930a8a0 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20470: ebe44a5c829ba27f84838227d0ed9cdfaaa53971 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ebe44a5c829b drm/i915/gem: only allow WB for smem only placements
02ac31b35505 drm/i915/gem: only allow WC for lmem

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/index.html

[-- Attachment #1.2: Type: text/html, Size: 5314 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
  2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
                   ` (4 preceding siblings ...)
  (?)
@ 2021-06-25 16:45 ` Patchwork
  -1 siblings, 0 replies; 20+ messages in thread
From: Patchwork @ 2021-06-25 16:45 UTC (permalink / raw)
  To: Matthew Auld; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 30289 bytes --]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem
URL   : https://patchwork.freedesktop.org/series/91921/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10281_full -> Patchwork_20470_full
====================================================

Summary
-------

  **WARNING**

  Minor unknown changes coming with Patchwork_20470_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20470_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_20470_full:

### IGT changes ###

#### Warnings ####

  * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1:
    - shard-iclb:         [SKIP][1] ([i915#658]) -> [SKIP][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb5/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-1.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_eio@suspend:
    - {shard-rkl-1}:      NOTRUN -> [FAIL][3] +47 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@gem_eio@suspend.html

  * igt@gem_eio@unwedge-stress:
    - {shard-rkl-1}:      NOTRUN -> [TIMEOUT][4]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_parallel@fds@rcs0:
    - {shard-rkl-6}:      NOTRUN -> [INCOMPLETE][5]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@gem_exec_parallel@fds@rcs0.html

  * igt@gem_exec_suspend@basic-s3-devices:
    - {shard-rkl-6}:      NOTRUN -> [FAIL][6] +2 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@gem_exec_suspend@basic-s3-devices.html

  * igt@gem_mmap_wc@set-cache-level:
    - {shard-rkl-2}:      NOTRUN -> [SKIP][7] +78 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-2/igt@gem_mmap_wc@set-cache-level.html

  * {igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs}:
    - {shard-rkl-2}:      NOTRUN -> [FAIL][8] +39 similar issues
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-2/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html

  * {igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs}:
    - {shard-rkl-6}:      NOTRUN -> [SKIP][9] +9 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@kms_ccs@pipe-b-crc-primary-basic-yf_tiled_ccs.html

  * {igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc}:
    - {shard-rkl-5}:      NOTRUN -> [FAIL][10] +42 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-5/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
    - {shard-rkl-1}:      NOTRUN -> [INCOMPLETE][11] +2 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
    - {shard-rkl-5}:      NOTRUN -> [INCOMPLETE][12]
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-5/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs.html

  * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
    - {shard-rkl-1}:      NOTRUN -> [SKIP][13] +236 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-1/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render.html

  * igt@kms_hdr@static-toggle-dpms:
    - {shard-rkl-6}:      NOTRUN -> [DMESG-WARN][14]
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-6/igt@kms_hdr@static-toggle-dpms.html

  * igt@kms_plane@plane-position-hole-dpms@pipe-b-planes:
    - {shard-rkl-5}:      NOTRUN -> [SKIP][15] +94 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-rkl-5/igt@kms_plane@plane-position-hole-dpms@pipe-b-planes.html

  
Known issues
------------

  Here are the changes found in Patchwork_20470_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_create@create-massive:
    - shard-snb:          NOTRUN -> [DMESG-WARN][16] ([i915#3002])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb2/igt@gem_create@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
    - shard-snb:          NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#1099]) +5 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb5/igt@gem_ctx_persistence@legacy-engines-mixed.html

  * igt@gem_eio@in-flight-contexts-1us:
    - shard-tglb:         [PASS][18] -> [TIMEOUT][19] ([i915#3063])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-tglb1/igt@gem_eio@in-flight-contexts-1us.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-tglb5/igt@gem_eio@in-flight-contexts-1us.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
    - shard-tglb:         [PASS][20] -> [FAIL][21] ([i915#2842])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-tglb2/igt@gem_exec_fair@basic-none-share@rcs0.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-tglb2/igt@gem_exec_fair@basic-none-share@rcs0.html

  * igt@gem_fenced_exec_thrash@no-spare-fences:
    - shard-snb:          NOTRUN -> [INCOMPLETE][22] ([i915#2055])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb5/igt@gem_fenced_exec_thrash@no-spare-fences.html

  * igt@gem_huc_copy@huc-copy:
    - shard-apl:          NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#2190])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@gem_huc_copy@huc-copy.html

  * igt@gem_ppgtt@blt-vs-render-ctx0:
    - shard-tglb:         [PASS][24] -> [INCOMPLETE][25] ([i915#750])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-tglb8/igt@gem_ppgtt@blt-vs-render-ctx0.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-tglb8/igt@gem_ppgtt@blt-vs-render-ctx0.html

  * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled:
    - shard-kbl:          NOTRUN -> [SKIP][26] ([fdo#109271]) +73 similar issues
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl2/igt@gem_render_copy@yf-tiled-to-vebox-x-tiled.html

  * igt@gem_workarounds@suspend-resume:
    - shard-apl:          NOTRUN -> [DMESG-WARN][27] ([i915#180]) +1 similar issue
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@gem_workarounds@suspend-resume.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-apl:          [PASS][28] -> [DMESG-WARN][29] ([i915#180]) +1 similar issue
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-apl3/igt@gem_workarounds@suspend-resume-context.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@gem_workarounds@suspend-resume-context.html

  * igt@gen9_exec_parse@batch-invalid-length:
    - shard-snb:          NOTRUN -> [SKIP][30] ([fdo#109271]) +344 similar issues
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb6/igt@gen9_exec_parse@batch-invalid-length.html

  * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp:
    - shard-apl:          NOTRUN -> [SKIP][31] ([fdo#109271] / [i915#1937])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp.html

  * igt@i915_suspend@debugfs-reader:
    - shard-kbl:          [PASS][32] -> [DMESG-WARN][33] ([i915#180])
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-kbl7/igt@i915_suspend@debugfs-reader.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl4/igt@i915_suspend@debugfs-reader.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-skl:          [PASS][34] -> [INCOMPLETE][35] ([i915#198])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl7/igt@i915_suspend@fence-restore-untiled.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl10/igt@i915_suspend@fence-restore-untiled.html

  * igt@kms_async_flips@alternate-sync-async-flip:
    - shard-skl:          [PASS][36] -> [FAIL][37] ([i915#2521])
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl2/igt@kms_async_flips@alternate-sync-async-flip.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip.html

  * igt@kms_chamelium@dp-hpd-storm-disable:
    - shard-skl:          NOTRUN -> [SKIP][38] ([fdo#109271] / [fdo#111827])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl6/igt@kms_chamelium@dp-hpd-storm-disable.html

  * igt@kms_color_chamelium@pipe-a-ctm-0-75:
    - shard-kbl:          NOTRUN -> [SKIP][39] ([fdo#109271] / [fdo#111827]) +4 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl3/igt@kms_color_chamelium@pipe-a-ctm-0-75.html

  * igt@kms_color_chamelium@pipe-a-ctm-limited-range:
    - shard-apl:          NOTRUN -> [SKIP][40] ([fdo#109271] / [fdo#111827]) +21 similar issues
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl3/igt@kms_color_chamelium@pipe-a-ctm-limited-range.html

  * igt@kms_color_chamelium@pipe-c-ctm-limited-range:
    - shard-snb:          NOTRUN -> [SKIP][41] ([fdo#109271] / [fdo#111827]) +20 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb2/igt@kms_color_chamelium@pipe-c-ctm-limited-range.html

  * igt@kms_content_protection@atomic-dpms:
    - shard-apl:          NOTRUN -> [TIMEOUT][42] ([i915#1319])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@kms_content_protection@atomic-dpms.html

  * igt@kms_content_protection@srm:
    - shard-kbl:          NOTRUN -> [TIMEOUT][43] ([i915#1319])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl3/igt@kms_content_protection@srm.html

  * igt@kms_content_protection@uevent:
    - shard-apl:          NOTRUN -> [FAIL][44] ([i915#2105])
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl8/igt@kms_content_protection@uevent.html

  * igt@kms_cursor_legacy@flip-vs-cursor-legacy:
    - shard-skl:          [PASS][45] -> [FAIL][46] ([i915#2346])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl5/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html

  * igt@kms_cursor_legacy@pipe-d-single-bo:
    - shard-kbl:          NOTRUN -> [SKIP][47] ([fdo#109271] / [i915#533]) +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl3/igt@kms_cursor_legacy@pipe-d-single-bo.html

  * igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled:
    - shard-glk:          [PASS][48] -> [DMESG-WARN][49] ([i915#118] / [i915#95])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-glk1/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-glk4/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled.html

  * igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-ytiled:
    - shard-skl:          [PASS][50] -> [DMESG-WARN][51] ([i915#1982]) +4 similar issues
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl8/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-ytiled.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl4/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-ytiled.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
    - shard-skl:          [PASS][52] -> [FAIL][53] ([i915#79])
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html

  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
    - shard-apl:          NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#2672])
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs.html

  * igt@kms_frontbuffer_tracking@fbcpsr-farfromfence-mmap-gtt:
    - shard-skl:          NOTRUN -> [SKIP][55] ([fdo#109271]) +8 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl6/igt@kms_frontbuffer_tracking@fbcpsr-farfromfence-mmap-gtt.html

  * igt@kms_hdr@bpc-switch-dpms:
    - shard-skl:          [PASS][56] -> [FAIL][57] ([i915#1188])
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl2/igt@kms_hdr@bpc-switch-dpms.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl10/igt@kms_hdr@bpc-switch-dpms.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence:
    - shard-apl:          NOTRUN -> [SKIP][58] ([fdo#109271] / [i915#533]) +2 similar issues
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl8/igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
    - shard-kbl:          NOTRUN -> [FAIL][59] ([fdo#108145] / [i915#265]) +1 similar issue
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl3/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb:
    - shard-apl:          NOTRUN -> [FAIL][60] ([i915#265])
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
    - shard-apl:          NOTRUN -> [FAIL][61] ([fdo#108145] / [i915#265]) +1 similar issue
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [PASS][62] -> [FAIL][63] ([fdo#108145] / [i915#265]) +1 similar issue
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl6/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
    - shard-apl:          NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#2733])
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1:
    - shard-kbl:          NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#658]) +2 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1.html

  * igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2:
    - shard-apl:          NOTRUN -> [SKIP][66] ([fdo#109271] / [i915#658]) +2 similar issues
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-2.html

  * igt@kms_psr@psr2_cursor_plane_move:
    - shard-iclb:         [PASS][67] -> [SKIP][68] ([fdo#109441]) +1 similar issue
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb6/igt@kms_psr@psr2_cursor_plane_move.html

  * igt@kms_setmode@basic:
    - shard-snb:          NOTRUN -> [FAIL][69] ([i915#31])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-snb5/igt@kms_setmode@basic.html

  * igt@kms_setmode@clone-exclusive-crtc:
    - shard-skl:          NOTRUN -> [WARN][70] ([i915#2100])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl6/igt@kms_setmode@clone-exclusive-crtc.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - shard-kbl:          [PASS][71] -> [INCOMPLETE][72] ([i915#155])
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl4/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@kms_vblank@pipe-d-wait-forked-hang:
    - shard-apl:          NOTRUN -> [SKIP][73] ([fdo#109271]) +231 similar issues
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@kms_vblank@pipe-d-wait-forked-hang.html

  * igt@perf@polling:
    - shard-skl:          [PASS][74] -> [FAIL][75] ([i915#1542])
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl3/igt@perf@polling.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl1/igt@perf@polling.html

  * igt@sysfs_clients@fair-3:
    - shard-kbl:          NOTRUN -> [SKIP][76] ([fdo#109271] / [i915#2994]) +1 similar issue
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl2/igt@sysfs_clients@fair-3.html
    - shard-apl:          NOTRUN -> [SKIP][77] ([fdo#109271] / [i915#2994])
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl8/igt@sysfs_clients@fair-3.html

  
#### Possible fixes ####

  * igt@gem_exec_fair@basic-throttle@rcs0:
    - shard-glk:          [FAIL][78] ([i915#2842]) -> [PASS][79]
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-glk6/igt@gem_exec_fair@basic-throttle@rcs0.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-glk7/igt@gem_exec_fair@basic-throttle@rcs0.html
    - shard-iclb:         [FAIL][80] ([i915#2842]) -> [PASS][81]
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb7/igt@gem_exec_fair@basic-throttle@rcs0.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb7/igt@gem_exec_fair@basic-throttle@rcs0.html

  * igt@gem_mmap_gtt@big-copy-odd:
    - shard-skl:          [FAIL][82] ([i915#307]) -> [PASS][83]
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl8/igt@gem_mmap_gtt@big-copy-odd.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl5/igt@gem_mmap_gtt@big-copy-odd.html
    - shard-glk:          [FAIL][84] ([i915#307]) -> [PASS][85]
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-glk5/igt@gem_mmap_gtt@big-copy-odd.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-glk9/igt@gem_mmap_gtt@big-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
    - shard-iclb:         [FAIL][86] ([i915#307]) -> [PASS][87]
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb8/igt@gem_mmap_gtt@cpuset-basic-small-copy-odd.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb4/igt@gem_mmap_gtt@cpuset-basic-small-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-big-copy-odd:
    - shard-iclb:         [FAIL][88] ([i915#2428]) -> [PASS][89]
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb4/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb1/igt@gem_mmap_gtt@cpuset-big-copy-odd.html

  * igt@kms_big_fb@linear-32bpp-rotate-0:
    - shard-glk:          [DMESG-WARN][90] ([i915#118] / [i915#95]) -> [PASS][91]
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-glk9/igt@kms_big_fb@linear-32bpp-rotate-0.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-glk6/igt@kms_big_fb@linear-32bpp-rotate-0.html

  * igt@kms_big_fb@x-tiled-32bpp-rotate-180:
    - shard-glk:          [DMESG-WARN][92] ([i915#118] / [i915#1982] / [i915#95]) -> [PASS][93]
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-glk9/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-glk6/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html

  * igt@kms_color@pipe-b-ctm-negative:
    - shard-skl:          [DMESG-WARN][94] ([i915#1982]) -> [PASS][95] +1 similar issue
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl6/igt@kms_color@pipe-b-ctm-negative.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl9/igt@kms_color@pipe-b-ctm-negative.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-apl:          [DMESG-WARN][96] ([i915#180]) -> [PASS][97]
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-apl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2:
    - shard-glk:          [FAIL][98] ([i915#79]) -> [PASS][99]
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-glk5/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-glk9/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2.html

  * igt@kms_flip@plain-flip-ts-check@c-edp1:
    - shard-skl:          [FAIL][100] ([i915#2122]) -> [PASS][101]
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl6/igt@kms_flip@plain-flip-ts-check@c-edp1.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl9/igt@kms_flip@plain-flip-ts-check@c-edp1.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-kbl:          [DMESG-WARN][102] ([i915#180]) -> [PASS][103] +4 similar issues
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-kbl4/igt@kms_hdr@bpc-switch-suspend.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-kbl3/igt@kms_hdr@bpc-switch-suspend.html
    - shard-skl:          [FAIL][104] ([i915#1188]) -> [PASS][105]
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl9/igt@kms_hdr@bpc-switch-suspend.html
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl8/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
    - shard-skl:          [FAIL][106] ([fdo#108145] / [i915#265]) -> [PASS][107]
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl6/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [SKIP][108] ([fdo#109441]) -> [PASS][109] +1 similar issue
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html

  
#### Warnings ####

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
    - shard-tglb:         [FAIL][110] ([i915#2851]) -> [FAIL][111] ([i915#2842])
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-tglb1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-tglb5/igt@gem_exec_fair@basic-pace-solo@rcs0.html

  * igt@i915_pm_rc6_residency@rc6-fence:
    - shard-iclb:         [WARN][112] ([i915#2684]) -> [WARN][113] ([i915#1804] / [i915#2684])
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb5/igt@i915_pm_rc6_residency@rc6-fence.html
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb3/igt@i915_pm_rc6_residency@rc6-fence.html

  * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
    - shard-iclb:         [SKIP][114] -> [SKIP][115] ([i915#658]) +1 similar issue
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-iclb2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-iclb6/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html

  * igt@runner@aborted:
    - shard-apl:          ([FAIL][116], [FAIL][117], [FAIL][118]) ([i915#1610] / [i915#1814] / [i915#2292] / [i915#3002] / [i915#3363]) -> ([FAIL][119], [FAIL][120], [FAIL][121], [FAIL][122]) ([fdo#109271] / [i915#180] / [i915#3363])
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-apl1/igt@runner@aborted.html
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-apl3/igt@runner@aborted.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-apl3/igt@runner@aborted.html
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl3/igt@runner@aborted.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl1/igt@runner@aborted.html
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl2/igt@runner@aborted.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-apl3/igt@runner@aborted.html
    - shard-skl:          ([FAIL][123], [FAIL][124]) ([i915#1814] / [i915#3002] / [i915#3363]) -> [FAIL][125] ([i915#3002] / [i915#3363])
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl7/igt@runner@aborted.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10281/shard-skl7/igt@runner@aborted.html
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/shard-skl1/igt@runner@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
  [fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109288]: https://bugs.freedesktop.org/show_bug.cgi?id=109288
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#109302]: https://bugs.freedesktop.org/show_bug.cgi?id=109302
  [fdo#109303]: https://bugs.freedesktop.org/show_bug.cgi?id=109303
  [fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#109312]: https://bugs.freedesktop.org/show_bug.cgi?id=109312
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109502]: https://bugs.freedesktop.org/show_bug.cgi?id=109502
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#110254]: https://bugs.freedesktop.org/show_bug.cgi?id=110254
  [fdo#110542]: https://bugs.freedesktop.org/show_bug.cgi?id=110542
  [fdo#111314]: https://bugs.freedesktop.org/show_bug.cgi?id=111314
  [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111656]: https://bugs.freedesktop.org/show_bug.cgi?id=111656
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [fdo#112022]: https://bugs.freedesktop.org/show_bug.cgi?id=112022
  [fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
  [fdo#112306]: https://bugs.freedesktop.org/show_bug.cgi?id=112306
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1099]: https://gitlab.freedesktop.org/drm/intel/issues/1099
  [i915#1140]: https://gitlab.freedesktop.org/drm/intel/issues/1140
  [i915#1149]: https://gitlab.freedesktop.org/drm/intel/issues/1149
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#132]: https://gitlab.freedesktop.org/drm/intel/issues/132
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1804]: https://gitlab.freedesktop.org/drm/intel/issues/1804
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#1902]: https://gitlab.freedesktop.org/drm/intel/issues/1902
  [i915#1911]: https://gitlab.freedesktop.org/drm/intel/issues/1911
  [i915#1937]: https://gitlab.freedesktop.org/drm/intel/issues/1937
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2055]: https://gitlab.freedesktop.org/drm/intel/issues/2055
  [i915#2100]: https://gitlab.freedesktop.org/drm/inte

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20470/index.html

[-- Attachment #1.2: Type: text/html, Size: 33451 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem
  2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
@ 2021-06-28  7:31   ` Thomas Hellström
  -1 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28  7:31 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel


On 6/25/21 2:27 PM, Matthew Auld wrote:
> This is already the case for our kernel internal mappings, and since we
> now only support a single mode this should always be WC if the object
> can be placed in lmem.
>
> v2: rebase and also update set_domain
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>

A couple of questions:

1) Since this now becomes uapi, are we completely sure that we are not 
going to want to map these bos cached when they are evicted or migrated. 
If we think we are going to want to do that, we should probably just 
silently accept any mapping mode user-space wants and then have the 
kernel override user-space's wishes.

Ping Daniel about this as well.

2) How are we going to handle kernel maps to make sure we don't use a 
different kernel map caching mode to these objects. Will that be a later 
series? Seems like we at least need to modify "i915_coherent_map_type"

Apart from this, code looks good to me.

/Thomas



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem
@ 2021-06-28  7:31   ` Thomas Hellström
  0 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28  7:31 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel


On 6/25/21 2:27 PM, Matthew Auld wrote:
> This is already the case for our kernel internal mappings, and since we
> now only support a single mode this should always be WC if the object
> can be placed in lmem.
>
> v2: rebase and also update set_domain
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>

A couple of questions:

1) Since this now becomes uapi, are we completely sure that we are not 
going to want to map these bos cached when they are evicted or migrated. 
If we think we are going to want to do that, we should probably just 
silently accept any mapping mode user-space wants and then have the 
kernel override user-space's wishes.

Ping Daniel about this as well.

2) How are we going to handle kernel maps to make sure we don't use a 
different kernel map caching mode to these objects. Will that be a later 
series? Seems like we at least need to modify "i915_coherent_map_type"

Apart from this, code looks good to me.

/Thomas


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
  2021-06-25 12:27   ` [Intel-gfx] " Matthew Auld
@ 2021-06-28  7:41     ` Thomas Hellström
  -1 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28  7:41 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel


On 6/25/21 2:27 PM, Matthew Auld wrote:
> We only support single mode and this should be immutable. For smem only
> placements on DGFX this should be WB. On DG1 everything is snooped,
> always, and so should be coherent.
>
> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
> for DGFX, so hopefully can also be safely rejected.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>   2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index d0c91697bb22..e3459a524e64 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
>   		goto out_unpin;
>   	}
>   
> +	if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
> +	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM) &&
> +	    read_domains != I915_GEM_DOMAIN_CPU) {
> +		err = -EINVAL;
> +		goto out_unpin;
> +	}
> +
>   	if (read_domains & I915_GEM_DOMAIN_WC)
>   		err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>   	else if (read_domains & I915_GEM_DOMAIN_GTT)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index f3586b36dd53..afc9f3dc38b9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>   		     enum i915_mmap_type mmap_type,
>   		     u64 *offset, struct drm_file *file)
>   {
> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
>   	struct i915_mmap_offset *mmo;
>   
>   	if (i915_gem_object_never_mmap(obj))
> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>   	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
>   		return -ENODEV;
>   
> +	/*
> +	 * For smem only placements on DGFX we need to default to WB. On DG1
> +	 * everything is snooped always, so should always be coherent.
> +	 */
> +	 if (IS_DGFX(i915) &&
> +	     mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
> +	     i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM))
> +		return -ENODEV;
> +

Same thing here as in the previous patch.

Also do we need to modify i915_coherent_map_type() to also include 
HAS_SNOOP()?

While we're at it, that "always_coherent" argument to 
i915_coherent_map_type() appears scary to me and probably needs some 
documentation. It seems used for page-tables. Is it because we know 
those are always snooped?

/Thomas


>   	mmo = mmap_offset_attach(obj, mmap_type, file);
>   	if (IS_ERR(mmo))
>   		return PTR_ERR(mmo);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
@ 2021-06-28  7:41     ` Thomas Hellström
  0 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28  7:41 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel


On 6/25/21 2:27 PM, Matthew Auld wrote:
> We only support single mode and this should be immutable. For smem only
> placements on DGFX this should be WB. On DG1 everything is snooped,
> always, and so should be coherent.
>
> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
> for DGFX, so hopefully can also be safely rejected.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>   2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index d0c91697bb22..e3459a524e64 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
>   		goto out_unpin;
>   	}
>   
> +	if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
> +	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM) &&
> +	    read_domains != I915_GEM_DOMAIN_CPU) {
> +		err = -EINVAL;
> +		goto out_unpin;
> +	}
> +
>   	if (read_domains & I915_GEM_DOMAIN_WC)
>   		err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>   	else if (read_domains & I915_GEM_DOMAIN_GTT)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index f3586b36dd53..afc9f3dc38b9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>   		     enum i915_mmap_type mmap_type,
>   		     u64 *offset, struct drm_file *file)
>   {
> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
>   	struct i915_mmap_offset *mmo;
>   
>   	if (i915_gem_object_never_mmap(obj))
> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>   	    i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_LOCAL))
>   		return -ENODEV;
>   
> +	/*
> +	 * For smem only placements on DGFX we need to default to WB. On DG1
> +	 * everything is snooped always, so should always be coherent.
> +	 */
> +	 if (IS_DGFX(i915) &&
> +	     mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
> +	     i915_gem_object_placements_contain_type(obj, INTEL_MEMORY_SYSTEM))
> +		return -ENODEV;
> +

Same thing here as in the previous patch.

Also do we need to modify i915_coherent_map_type() to also include 
HAS_SNOOP()?

While we're at it, that "always_coherent" argument to 
i915_coherent_map_type() appears scary to me and probably needs some 
documentation. It seems used for page-tables. Is it because we know 
those are always snooped?

/Thomas


>   	mmo = mmap_offset_attach(obj, mmap_type, file);
>   	if (IS_ERR(mmo))
>   		return PTR_ERR(mmo);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
  2021-06-28  7:41     ` [Intel-gfx] " Thomas Hellström
@ 2021-06-28  9:12       ` Matthew Auld
  -1 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-28  9:12 UTC (permalink / raw)
  To: Thomas Hellström, intel-gfx; +Cc: Daniel Vetter, dri-devel

On 28/06/2021 08:41, Thomas Hellström wrote:
> 
> On 6/25/21 2:27 PM, Matthew Auld wrote:
>> We only support single mode and this should be immutable. For smem only
>> placements on DGFX this should be WB. On DG1 everything is snooped,
>> always, and so should be coherent.
>>
>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
>> for DGFX, so hopefully can also be safely rejected.
>>
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>   2 files changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> index d0c91697bb22..e3459a524e64 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, 
>> void *data,
>>           goto out_unpin;
>>       }
>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
>> +        i915_gem_object_placements_contain_type(obj, 
>> INTEL_MEMORY_SYSTEM) &&
>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>> +        err = -EINVAL;
>> +        goto out_unpin;
>> +    }
>> +
>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index f3586b36dd53..afc9f3dc38b9 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>>                enum i915_mmap_type mmap_type,
>>                u64 *offset, struct drm_file *file)
>>   {
>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>       struct i915_mmap_offset *mmo;
>>       if (i915_gem_object_never_mmap(obj))
>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>> *obj,
>>           i915_gem_object_placements_contain_type(obj, 
>> INTEL_MEMORY_LOCAL))
>>           return -ENODEV;
>> +    /*
>> +     * For smem only placements on DGFX we need to default to WB. On DG1
>> +     * everything is snooped always, so should always be coherent.
>> +     */
>> +     if (IS_DGFX(i915) &&
>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
>> +         i915_gem_object_placements_contain_type(obj, 
>> INTEL_MEMORY_SYSTEM))
>> +        return -ENODEV;
>> +
> 
> Same thing here as in the previous patch.
> 
> Also do we need to modify i915_coherent_map_type() to also include 
> HAS_SNOOP()?
> 
> While we're at it, that "always_coherent" argument to 
> i915_coherent_map_type() appears scary to me and probably needs some 
> documentation. It seems used for page-tables. Is it because we know 
> those are always snooped?

Yeah, it's either because the caller has/will mark the pages as 
coherent(which translates to some special ppGTT bits), or we manually 
flush ourselves. In i915_coherent_map_type() we should account for DG1 
somehow.

Historically I don't think we enabled snooping by default since it's 
considered slow compared to shared LLC. On DG1 this is a different story 
though.

Also the pin_map() interface is pretty much only for kernel internal 
objects, so I don't think we have any users which try to map userspace 
objects with that interface. Ok, except for vm_access it seems, but that 
should hopefully be a simple fix to use the correct caching mode? We can 
maybe add some sanity checking there if someone tries to map a userspace 
object?

For all the other callers of pin_map() which should all be kernel 
internal do we still need to force WB for system memory? By design we 
only support a single mm.mapping there. For lmem we already use WC only.

> 
> /Thomas
> 
> 
>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>       if (IS_ERR(mmo))
>>           return PTR_ERR(mmo);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
@ 2021-06-28  9:12       ` Matthew Auld
  0 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-28  9:12 UTC (permalink / raw)
  To: Thomas Hellström, intel-gfx; +Cc: Daniel Vetter, dri-devel

On 28/06/2021 08:41, Thomas Hellström wrote:
> 
> On 6/25/21 2:27 PM, Matthew Auld wrote:
>> We only support single mode and this should be immutable. For smem only
>> placements on DGFX this should be WB. On DG1 everything is snooped,
>> always, and so should be coherent.
>>
>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
>> for DGFX, so hopefully can also be safely rejected.
>>
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>   2 files changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> index d0c91697bb22..e3459a524e64 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, 
>> void *data,
>>           goto out_unpin;
>>       }
>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 1 &&
>> +        i915_gem_object_placements_contain_type(obj, 
>> INTEL_MEMORY_SYSTEM) &&
>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>> +        err = -EINVAL;
>> +        goto out_unpin;
>> +    }
>> +
>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index f3586b36dd53..afc9f3dc38b9 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>>                enum i915_mmap_type mmap_type,
>>                u64 *offset, struct drm_file *file)
>>   {
>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>       struct i915_mmap_offset *mmo;
>>       if (i915_gem_object_never_mmap(obj))
>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>> *obj,
>>           i915_gem_object_placements_contain_type(obj, 
>> INTEL_MEMORY_LOCAL))
>>           return -ENODEV;
>> +    /*
>> +     * For smem only placements on DGFX we need to default to WB. On DG1
>> +     * everything is snooped always, so should always be coherent.
>> +     */
>> +     if (IS_DGFX(i915) &&
>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 1 &&
>> +         i915_gem_object_placements_contain_type(obj, 
>> INTEL_MEMORY_SYSTEM))
>> +        return -ENODEV;
>> +
> 
> Same thing here as in the previous patch.
> 
> Also do we need to modify i915_coherent_map_type() to also include 
> HAS_SNOOP()?
> 
> While we're at it, that "always_coherent" argument to 
> i915_coherent_map_type() appears scary to me and probably needs some 
> documentation. It seems used for page-tables. Is it because we know 
> those are always snooped?

Yeah, it's either because the caller has/will mark the pages as 
coherent(which translates to some special ppGTT bits), or we manually 
flush ourselves. In i915_coherent_map_type() we should account for DG1 
somehow.

Historically I don't think we enabled snooping by default since it's 
considered slow compared to shared LLC. On DG1 this is a different story 
though.

Also the pin_map() interface is pretty much only for kernel internal 
objects, so I don't think we have any users which try to map userspace 
objects with that interface. Ok, except for vm_access it seems, but that 
should hopefully be a simple fix to use the correct caching mode? We can 
maybe add some sanity checking there if someone tries to map a userspace 
object?

For all the other callers of pin_map() which should all be kernel 
internal do we still need to force WB for system memory? By design we 
only support a single mm.mapping there. For lmem we already use WC only.

> 
> /Thomas
> 
> 
>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>       if (IS_ERR(mmo))
>>           return PTR_ERR(mmo);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
  2021-06-28  9:12       ` [Intel-gfx] " Matthew Auld
@ 2021-06-28  9:38         ` Thomas Hellström
  -1 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28  9:38 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel

Hi,

On 6/28/21 11:12 AM, Matthew Auld wrote:
> On 28/06/2021 08:41, Thomas Hellström wrote:
>>
>> On 6/25/21 2:27 PM, Matthew Auld wrote:
>>> We only support single mode and this should be immutable. For smem only
>>> placements on DGFX this should be WB. On DG1 everything is snooped,
>>> always, and so should be coherent.
>>>
>>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
>>> for DGFX, so hopefully can also be safely rejected.
>>>
>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>>   2 files changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>> index d0c91697bb22..e3459a524e64 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device 
>>> *dev, void *data,
>>>           goto out_unpin;
>>>       }
>>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 
>>> 1 &&
>>> +        i915_gem_object_placements_contain_type(obj, 
>>> INTEL_MEMORY_SYSTEM) &&
>>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>>> +        err = -EINVAL;
>>> +        goto out_unpin;
>>> +    }
>>> +
>>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> index f3586b36dd53..afc9f3dc38b9 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>> *obj,
>>>                enum i915_mmap_type mmap_type,
>>>                u64 *offset, struct drm_file *file)
>>>   {
>>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>       struct i915_mmap_offset *mmo;
>>>       if (i915_gem_object_never_mmap(obj))
>>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>> *obj,
>>>           i915_gem_object_placements_contain_type(obj, 
>>> INTEL_MEMORY_LOCAL))
>>>           return -ENODEV;
>>> +    /*
>>> +     * For smem only placements on DGFX we need to default to WB. 
>>> On DG1
>>> +     * everything is snooped always, so should always be coherent.
>>> +     */
>>> +     if (IS_DGFX(i915) &&
>>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 
>>> 1 &&
>>> +         i915_gem_object_placements_contain_type(obj, 
>>> INTEL_MEMORY_SYSTEM))
>>> +        return -ENODEV;
>>> +
>>
>> Same thing here as in the previous patch.
>>
>> Also do we need to modify i915_coherent_map_type() to also include 
>> HAS_SNOOP()?
>>
>> While we're at it, that "always_coherent" argument to 
>> i915_coherent_map_type() appears scary to me and probably needs some 
>> documentation. It seems used for page-tables. Is it because we know 
>> those are always snooped?
>
> Yeah, it's either because the caller has/will mark the pages as 
> coherent(which translates to some special ppGTT bits), or we manually 
> flush ourselves. In i915_coherent_map_type() we should account for DG1 
> somehow.
>
> Historically I don't think we enabled snooping by default since it's 
> considered slow compared to shared LLC. On DG1 this is a different 
> story though.
>
> Also the pin_map() interface is pretty much only for kernel internal 
> objects, so I don't think we have any users which try to map userspace 
> objects with that interface. Ok, except for vm_access it seems, but 
> that should hopefully be a simple fix to use the correct caching mode? 
> We can maybe add some sanity checking there if someone tries to map a 
> userspace object?
I'm not fully sure that's sufficient, see below.
>
> For all the other callers of pin_map() which should all be kernel 
> internal do we still need to force WB for system memory? By design we 
> only support a single mm.mapping there. For lmem we already use WC only.

We're only allowed to map with the same caching mode as the linear 
kernel mapping for discrete. Otherwise things may blow up on non-intel 
architectures. We can probably update 195_ttm_select_tt_caching to 
always use WB for system pages for kernel objects, but then we must make 
sure we don't try to map these WC.

/Thomas


>
>>
>> /Thomas
>>
>>
>>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>>       if (IS_ERR(mmo))
>>>           return PTR_ERR(mmo);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
@ 2021-06-28  9:38         ` Thomas Hellström
  0 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28  9:38 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel

Hi,

On 6/28/21 11:12 AM, Matthew Auld wrote:
> On 28/06/2021 08:41, Thomas Hellström wrote:
>>
>> On 6/25/21 2:27 PM, Matthew Auld wrote:
>>> We only support single mode and this should be immutable. For smem only
>>> placements on DGFX this should be WB. On DG1 everything is snooped,
>>> always, and so should be coherent.
>>>
>>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
>>> for DGFX, so hopefully can also be safely rejected.
>>>
>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>>   2 files changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>> index d0c91697bb22..e3459a524e64 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device 
>>> *dev, void *data,
>>>           goto out_unpin;
>>>       }
>>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 
>>> 1 &&
>>> +        i915_gem_object_placements_contain_type(obj, 
>>> INTEL_MEMORY_SYSTEM) &&
>>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>>> +        err = -EINVAL;
>>> +        goto out_unpin;
>>> +    }
>>> +
>>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> index f3586b36dd53..afc9f3dc38b9 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>> *obj,
>>>                enum i915_mmap_type mmap_type,
>>>                u64 *offset, struct drm_file *file)
>>>   {
>>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>       struct i915_mmap_offset *mmo;
>>>       if (i915_gem_object_never_mmap(obj))
>>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>> *obj,
>>>           i915_gem_object_placements_contain_type(obj, 
>>> INTEL_MEMORY_LOCAL))
>>>           return -ENODEV;
>>> +    /*
>>> +     * For smem only placements on DGFX we need to default to WB. 
>>> On DG1
>>> +     * everything is snooped always, so should always be coherent.
>>> +     */
>>> +     if (IS_DGFX(i915) &&
>>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 
>>> 1 &&
>>> +         i915_gem_object_placements_contain_type(obj, 
>>> INTEL_MEMORY_SYSTEM))
>>> +        return -ENODEV;
>>> +
>>
>> Same thing here as in the previous patch.
>>
>> Also do we need to modify i915_coherent_map_type() to also include 
>> HAS_SNOOP()?
>>
>> While we're at it, that "always_coherent" argument to 
>> i915_coherent_map_type() appears scary to me and probably needs some 
>> documentation. It seems used for page-tables. Is it because we know 
>> those are always snooped?
>
> Yeah, it's either because the caller has/will mark the pages as 
> coherent(which translates to some special ppGTT bits), or we manually 
> flush ourselves. In i915_coherent_map_type() we should account for DG1 
> somehow.
>
> Historically I don't think we enabled snooping by default since it's 
> considered slow compared to shared LLC. On DG1 this is a different 
> story though.
>
> Also the pin_map() interface is pretty much only for kernel internal 
> objects, so I don't think we have any users which try to map userspace 
> objects with that interface. Ok, except for vm_access it seems, but 
> that should hopefully be a simple fix to use the correct caching mode? 
> We can maybe add some sanity checking there if someone tries to map a 
> userspace object?
I'm not fully sure that's sufficient, see below.
>
> For all the other callers of pin_map() which should all be kernel 
> internal do we still need to force WB for system memory? By design we 
> only support a single mm.mapping there. For lmem we already use WC only.

We're only allowed to map with the same caching mode as the linear 
kernel mapping for discrete. Otherwise things may blow up on non-intel 
architectures. We can probably update 195_ttm_select_tt_caching to 
always use WB for system pages for kernel objects, but then we must make 
sure we don't try to map these WC.

/Thomas


>
>>
>> /Thomas
>>
>>
>>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>>       if (IS_ERR(mmo))
>>>           return PTR_ERR(mmo);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
  2021-06-28  9:38         ` [Intel-gfx] " Thomas Hellström
@ 2021-06-28 10:20           ` Matthew Auld
  -1 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-28 10:20 UTC (permalink / raw)
  To: Thomas Hellström, intel-gfx; +Cc: Daniel Vetter, dri-devel

On 28/06/2021 10:38, Thomas Hellström wrote:
> Hi,
> 
> On 6/28/21 11:12 AM, Matthew Auld wrote:
>> On 28/06/2021 08:41, Thomas Hellström wrote:
>>>
>>> On 6/25/21 2:27 PM, Matthew Auld wrote:
>>>> We only support single mode and this should be immutable. For smem only
>>>> placements on DGFX this should be WB. On DG1 everything is snooped,
>>>> always, and so should be coherent.
>>>>
>>>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
>>>> for DGFX, so hopefully can also be safely rejected.
>>>>
>>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> ---
>>>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>>>   2 files changed, 17 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>> index d0c91697bb22..e3459a524e64 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device 
>>>> *dev, void *data,
>>>>           goto out_unpin;
>>>>       }
>>>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 
>>>> 1 &&
>>>> +        i915_gem_object_placements_contain_type(obj, 
>>>> INTEL_MEMORY_SYSTEM) &&
>>>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>>>> +        err = -EINVAL;
>>>> +        goto out_unpin;
>>>> +    }
>>>> +
>>>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> index f3586b36dd53..afc9f3dc38b9 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>>> *obj,
>>>>                enum i915_mmap_type mmap_type,
>>>>                u64 *offset, struct drm_file *file)
>>>>   {
>>>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>>       struct i915_mmap_offset *mmo;
>>>>       if (i915_gem_object_never_mmap(obj))
>>>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>>> *obj,
>>>>           i915_gem_object_placements_contain_type(obj, 
>>>> INTEL_MEMORY_LOCAL))
>>>>           return -ENODEV;
>>>> +    /*
>>>> +     * For smem only placements on DGFX we need to default to WB. 
>>>> On DG1
>>>> +     * everything is snooped always, so should always be coherent.
>>>> +     */
>>>> +     if (IS_DGFX(i915) &&
>>>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 
>>>> 1 &&
>>>> +         i915_gem_object_placements_contain_type(obj, 
>>>> INTEL_MEMORY_SYSTEM))
>>>> +        return -ENODEV;
>>>> +
>>>
>>> Same thing here as in the previous patch.
>>>
>>> Also do we need to modify i915_coherent_map_type() to also include 
>>> HAS_SNOOP()?
>>>
>>> While we're at it, that "always_coherent" argument to 
>>> i915_coherent_map_type() appears scary to me and probably needs some 
>>> documentation. It seems used for page-tables. Is it because we know 
>>> those are always snooped?
>>
>> Yeah, it's either because the caller has/will mark the pages as 
>> coherent(which translates to some special ppGTT bits), or we manually 
>> flush ourselves. In i915_coherent_map_type() we should account for DG1 
>> somehow.
>>
>> Historically I don't think we enabled snooping by default since it's 
>> considered slow compared to shared LLC. On DG1 this is a different 
>> story though.
>>
>> Also the pin_map() interface is pretty much only for kernel internal 
>> objects, so I don't think we have any users which try to map userspace 
>> objects with that interface. Ok, except for vm_access it seems, but 
>> that should hopefully be a simple fix to use the correct caching mode? 
>> We can maybe add some sanity checking there if someone tries to map a 
>> userspace object?
> I'm not fully sure that's sufficient, see below.
>>
>> For all the other callers of pin_map() which should all be kernel 
>> internal do we still need to force WB for system memory? By design we 
>> only support a single mm.mapping there. For lmem we already use WC only.
> 
> We're only allowed to map with the same caching mode as the linear 
> kernel mapping for discrete. Otherwise things may blow up on non-intel 
> architectures. We can probably update 195_ttm_select_tt_caching to 
> always use WB for system pages for kernel objects, but then we must make 
> sure we don't try to map these WC.

Ok, do you think that should be a separate series? It looks like our 
internal objects don't use ttm(?). Should it? If so should we make a 
region for it, or can we just make create_internal use the ttm system 
region? It should be pretty much the same, except we don't want 
swapping, clearing or eviction, and ideally we would have some way of 
marking the pages as volatile(I think we can just keep IS_SHRINKABLE for 
that).

Or can we keep create_internal as is and then it's just a case of 
dealing with all the pin_map() callers?

> 
> /Thomas
> 
> 
>>
>>>
>>> /Thomas
>>>
>>>
>>>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>>>       if (IS_ERR(mmo))
>>>>           return PTR_ERR(mmo);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
@ 2021-06-28 10:20           ` Matthew Auld
  0 siblings, 0 replies; 20+ messages in thread
From: Matthew Auld @ 2021-06-28 10:20 UTC (permalink / raw)
  To: Thomas Hellström, intel-gfx; +Cc: Daniel Vetter, dri-devel

On 28/06/2021 10:38, Thomas Hellström wrote:
> Hi,
> 
> On 6/28/21 11:12 AM, Matthew Auld wrote:
>> On 28/06/2021 08:41, Thomas Hellström wrote:
>>>
>>> On 6/25/21 2:27 PM, Matthew Auld wrote:
>>>> We only support single mode and this should be immutable. For smem only
>>>> placements on DGFX this should be WB. On DG1 everything is snooped,
>>>> always, and so should be coherent.
>>>>
>>>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
>>>> for DGFX, so hopefully can also be safely rejected.
>>>>
>>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> ---
>>>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>>>   2 files changed, 17 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>> index d0c91697bb22..e3459a524e64 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device 
>>>> *dev, void *data,
>>>>           goto out_unpin;
>>>>       }
>>>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements == 
>>>> 1 &&
>>>> +        i915_gem_object_placements_contain_type(obj, 
>>>> INTEL_MEMORY_SYSTEM) &&
>>>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>>>> +        err = -EINVAL;
>>>> +        goto out_unpin;
>>>> +    }
>>>> +
>>>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> index f3586b36dd53..afc9f3dc38b9 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>>> *obj,
>>>>                enum i915_mmap_type mmap_type,
>>>>                u64 *offset, struct drm_file *file)
>>>>   {
>>>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>>       struct i915_mmap_offset *mmo;
>>>>       if (i915_gem_object_never_mmap(obj))
>>>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct drm_i915_gem_object 
>>>> *obj,
>>>>           i915_gem_object_placements_contain_type(obj, 
>>>> INTEL_MEMORY_LOCAL))
>>>>           return -ENODEV;
>>>> +    /*
>>>> +     * For smem only placements on DGFX we need to default to WB. 
>>>> On DG1
>>>> +     * everything is snooped always, so should always be coherent.
>>>> +     */
>>>> +     if (IS_DGFX(i915) &&
>>>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements == 
>>>> 1 &&
>>>> +         i915_gem_object_placements_contain_type(obj, 
>>>> INTEL_MEMORY_SYSTEM))
>>>> +        return -ENODEV;
>>>> +
>>>
>>> Same thing here as in the previous patch.
>>>
>>> Also do we need to modify i915_coherent_map_type() to also include 
>>> HAS_SNOOP()?
>>>
>>> While we're at it, that "always_coherent" argument to 
>>> i915_coherent_map_type() appears scary to me and probably needs some 
>>> documentation. It seems used for page-tables. Is it because we know 
>>> those are always snooped?
>>
>> Yeah, it's either because the caller has/will mark the pages as 
>> coherent(which translates to some special ppGTT bits), or we manually 
>> flush ourselves. In i915_coherent_map_type() we should account for DG1 
>> somehow.
>>
>> Historically I don't think we enabled snooping by default since it's 
>> considered slow compared to shared LLC. On DG1 this is a different 
>> story though.
>>
>> Also the pin_map() interface is pretty much only for kernel internal 
>> objects, so I don't think we have any users which try to map userspace 
>> objects with that interface. Ok, except for vm_access it seems, but 
>> that should hopefully be a simple fix to use the correct caching mode? 
>> We can maybe add some sanity checking there if someone tries to map a 
>> userspace object?
> I'm not fully sure that's sufficient, see below.
>>
>> For all the other callers of pin_map() which should all be kernel 
>> internal do we still need to force WB for system memory? By design we 
>> only support a single mm.mapping there. For lmem we already use WC only.
> 
> We're only allowed to map with the same caching mode as the linear 
> kernel mapping for discrete. Otherwise things may blow up on non-intel 
> architectures. We can probably update 195_ttm_select_tt_caching to 
> always use WB for system pages for kernel objects, but then we must make 
> sure we don't try to map these WC.

Ok, do you think that should be a separate series? It looks like our 
internal objects don't use ttm(?). Should it? If so should we make a 
region for it, or can we just make create_internal use the ttm system 
region? It should be pretty much the same, except we don't want 
swapping, clearing or eviction, and ideally we would have some way of 
marking the pages as volatile(I think we can just keep IS_SHRINKABLE for 
that).

Or can we keep create_internal as is and then it's just a case of 
dealing with all the pin_map() callers?

> 
> /Thomas
> 
> 
>>
>>>
>>> /Thomas
>>>
>>>
>>>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>>>       if (IS_ERR(mmo))
>>>>           return PTR_ERR(mmo);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
  2021-06-28 10:20           ` [Intel-gfx] " Matthew Auld
@ 2021-06-28 10:55             ` Thomas Hellström
  -1 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28 10:55 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel


On 6/28/21 12:20 PM, Matthew Auld wrote:
> On 28/06/2021 10:38, Thomas Hellström wrote:
>> Hi,
>>
>> On 6/28/21 11:12 AM, Matthew Auld wrote:
>>> On 28/06/2021 08:41, Thomas Hellström wrote:
>>>>
>>>> On 6/25/21 2:27 PM, Matthew Auld wrote:
>>>>> We only support single mode and this should be immutable. For smem 
>>>>> only
>>>>> placements on DGFX this should be WB. On DG1 everything is snooped,
>>>>> always, and so should be coherent.
>>>>>
>>>>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now 
>>>>> gone
>>>>> for DGFX, so hopefully can also be safely rejected.
>>>>>
>>>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> ---
>>>>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>>>>   2 files changed, 17 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>>> index d0c91697bb22..e3459a524e64 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device 
>>>>> *dev, void *data,
>>>>>           goto out_unpin;
>>>>>       }
>>>>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements 
>>>>> == 1 &&
>>>>> +        i915_gem_object_placements_contain_type(obj, 
>>>>> INTEL_MEMORY_SYSTEM) &&
>>>>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>>>>> +        err = -EINVAL;
>>>>> +        goto out_unpin;
>>>>> +    }
>>>>> +
>>>>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>>>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>>>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>>> index f3586b36dd53..afc9f3dc38b9 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct 
>>>>> drm_i915_gem_object *obj,
>>>>>                enum i915_mmap_type mmap_type,
>>>>>                u64 *offset, struct drm_file *file)
>>>>>   {
>>>>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>>>       struct i915_mmap_offset *mmo;
>>>>>       if (i915_gem_object_never_mmap(obj))
>>>>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct 
>>>>> drm_i915_gem_object *obj,
>>>>>           i915_gem_object_placements_contain_type(obj, 
>>>>> INTEL_MEMORY_LOCAL))
>>>>>           return -ENODEV;
>>>>> +    /*
>>>>> +     * For smem only placements on DGFX we need to default to WB. 
>>>>> On DG1
>>>>> +     * everything is snooped always, so should always be coherent.
>>>>> +     */
>>>>> +     if (IS_DGFX(i915) &&
>>>>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements 
>>>>> == 1 &&
>>>>> +         i915_gem_object_placements_contain_type(obj, 
>>>>> INTEL_MEMORY_SYSTEM))
>>>>> +        return -ENODEV;
>>>>> +
>>>>
>>>> Same thing here as in the previous patch.
>>>>
>>>> Also do we need to modify i915_coherent_map_type() to also include 
>>>> HAS_SNOOP()?
>>>>
>>>> While we're at it, that "always_coherent" argument to 
>>>> i915_coherent_map_type() appears scary to me and probably needs 
>>>> some documentation. It seems used for page-tables. Is it because we 
>>>> know those are always snooped?
>>>
>>> Yeah, it's either because the caller has/will mark the pages as 
>>> coherent(which translates to some special ppGTT bits), or we 
>>> manually flush ourselves. In i915_coherent_map_type() we should 
>>> account for DG1 somehow.
>>>
>>> Historically I don't think we enabled snooping by default since it's 
>>> considered slow compared to shared LLC. On DG1 this is a different 
>>> story though.
>>>
>>> Also the pin_map() interface is pretty much only for kernel internal 
>>> objects, so I don't think we have any users which try to map 
>>> userspace objects with that interface. Ok, except for vm_access it 
>>> seems, but that should hopefully be a simple fix to use the correct 
>>> caching mode? We can maybe add some sanity checking there if someone 
>>> tries to map a userspace object?
>> I'm not fully sure that's sufficient, see below.
>>>
>>> For all the other callers of pin_map() which should all be kernel 
>>> internal do we still need to force WB for system memory? By design 
>>> we only support a single mm.mapping there. For lmem we already use 
>>> WC only.
>>
>> We're only allowed to map with the same caching mode as the linear 
>> kernel mapping for discrete. Otherwise things may blow up on 
>> non-intel architectures. We can probably update 
>> 195_ttm_select_tt_caching to always use WB for system pages for 
>> kernel objects, but then we must make sure we don't try to map these WC.
>
> Ok, do you think that should be a separate series? It looks like our 
> internal objects don't use ttm(?). Should it? If so should we make a 
> region for it, or can we just make create_internal use the ttm system 
> region? It should be pretty much the same, except we don't want 
> swapping, clearing or eviction, and ideally we would have some way of 
> marking the pages as volatile(I think we can just keep IS_SHRINKABLE 
> for that).
>
> Or can we keep create_internal as is and then it's just a case of 
> dealing with all the pin_map() callers?
>
For now, I think, the internal objects don't really need to use ttm, and 
if we want to move them over, as you say, it's just a matter of reusing 
the SYSTEM region with suitable flags. I think we should restrict this 
to deal with pin_map() for now, and a separate series would work fine.

Although there seem to be callers, at least in selftests, that use 
pin_map with create_shmem() which maps to TTM system on discrete.

/Thomas


>>
>> /Thomas
>>
>>
>>>
>>>>
>>>> /Thomas
>>>>
>>>>
>>>>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>>>>       if (IS_ERR(mmo))
>>>>>           return PTR_ERR(mmo);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements
@ 2021-06-28 10:55             ` Thomas Hellström
  0 siblings, 0 replies; 20+ messages in thread
From: Thomas Hellström @ 2021-06-28 10:55 UTC (permalink / raw)
  To: Matthew Auld, intel-gfx; +Cc: Daniel Vetter, dri-devel


On 6/28/21 12:20 PM, Matthew Auld wrote:
> On 28/06/2021 10:38, Thomas Hellström wrote:
>> Hi,
>>
>> On 6/28/21 11:12 AM, Matthew Auld wrote:
>>> On 28/06/2021 08:41, Thomas Hellström wrote:
>>>>
>>>> On 6/25/21 2:27 PM, Matthew Auld wrote:
>>>>> We only support single mode and this should be immutable. For smem 
>>>>> only
>>>>> placements on DGFX this should be WB. On DG1 everything is snooped,
>>>>> always, and so should be coherent.
>>>>>
>>>>> I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now 
>>>>> gone
>>>>> for DGFX, so hopefully can also be safely rejected.
>>>>>
>>>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>>>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> ---
>>>>>   drivers/gpu/drm/i915/gem/i915_gem_domain.c |  7 +++++++
>>>>>   drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 10 ++++++++++
>>>>>   2 files changed, 17 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>>> index d0c91697bb22..e3459a524e64 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>>>>> @@ -577,6 +577,13 @@ i915_gem_set_domain_ioctl(struct drm_device 
>>>>> *dev, void *data,
>>>>>           goto out_unpin;
>>>>>       }
>>>>> +    if (IS_DGFX(to_i915(obj->base.dev)) && obj->mm.n_placements 
>>>>> == 1 &&
>>>>> +        i915_gem_object_placements_contain_type(obj, 
>>>>> INTEL_MEMORY_SYSTEM) &&
>>>>> +        read_domains != I915_GEM_DOMAIN_CPU) {
>>>>> +        err = -EINVAL;
>>>>> +        goto out_unpin;
>>>>> +    }
>>>>> +
>>>>>       if (read_domains & I915_GEM_DOMAIN_WC)
>>>>>           err = i915_gem_object_set_to_wc_domain(obj, write_domain);
>>>>>       else if (read_domains & I915_GEM_DOMAIN_GTT)
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>>> index f3586b36dd53..afc9f3dc38b9 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>>>>> @@ -673,6 +673,7 @@ __assign_mmap_offset(struct 
>>>>> drm_i915_gem_object *obj,
>>>>>                enum i915_mmap_type mmap_type,
>>>>>                u64 *offset, struct drm_file *file)
>>>>>   {
>>>>> +    struct drm_i915_private *i915 = to_i915(obj->base.dev);
>>>>>       struct i915_mmap_offset *mmo;
>>>>>       if (i915_gem_object_never_mmap(obj))
>>>>> @@ -697,6 +698,15 @@ __assign_mmap_offset(struct 
>>>>> drm_i915_gem_object *obj,
>>>>>           i915_gem_object_placements_contain_type(obj, 
>>>>> INTEL_MEMORY_LOCAL))
>>>>>           return -ENODEV;
>>>>> +    /*
>>>>> +     * For smem only placements on DGFX we need to default to WB. 
>>>>> On DG1
>>>>> +     * everything is snooped always, so should always be coherent.
>>>>> +     */
>>>>> +     if (IS_DGFX(i915) &&
>>>>> +         mmap_type != I915_MMAP_TYPE_WB && obj->mm.n_placements 
>>>>> == 1 &&
>>>>> +         i915_gem_object_placements_contain_type(obj, 
>>>>> INTEL_MEMORY_SYSTEM))
>>>>> +        return -ENODEV;
>>>>> +
>>>>
>>>> Same thing here as in the previous patch.
>>>>
>>>> Also do we need to modify i915_coherent_map_type() to also include 
>>>> HAS_SNOOP()?
>>>>
>>>> While we're at it, that "always_coherent" argument to 
>>>> i915_coherent_map_type() appears scary to me and probably needs 
>>>> some documentation. It seems used for page-tables. Is it because we 
>>>> know those are always snooped?
>>>
>>> Yeah, it's either because the caller has/will mark the pages as 
>>> coherent(which translates to some special ppGTT bits), or we 
>>> manually flush ourselves. In i915_coherent_map_type() we should 
>>> account for DG1 somehow.
>>>
>>> Historically I don't think we enabled snooping by default since it's 
>>> considered slow compared to shared LLC. On DG1 this is a different 
>>> story though.
>>>
>>> Also the pin_map() interface is pretty much only for kernel internal 
>>> objects, so I don't think we have any users which try to map 
>>> userspace objects with that interface. Ok, except for vm_access it 
>>> seems, but that should hopefully be a simple fix to use the correct 
>>> caching mode? We can maybe add some sanity checking there if someone 
>>> tries to map a userspace object?
>> I'm not fully sure that's sufficient, see below.
>>>
>>> For all the other callers of pin_map() which should all be kernel 
>>> internal do we still need to force WB for system memory? By design 
>>> we only support a single mm.mapping there. For lmem we already use 
>>> WC only.
>>
>> We're only allowed to map with the same caching mode as the linear 
>> kernel mapping for discrete. Otherwise things may blow up on 
>> non-intel architectures. We can probably update 
>> 195_ttm_select_tt_caching to always use WB for system pages for 
>> kernel objects, but then we must make sure we don't try to map these WC.
>
> Ok, do you think that should be a separate series? It looks like our 
> internal objects don't use ttm(?). Should it? If so should we make a 
> region for it, or can we just make create_internal use the ttm system 
> region? It should be pretty much the same, except we don't want 
> swapping, clearing or eviction, and ideally we would have some way of 
> marking the pages as volatile(I think we can just keep IS_SHRINKABLE 
> for that).
>
> Or can we keep create_internal as is and then it's just a case of 
> dealing with all the pin_map() callers?
>
For now, I think, the internal objects don't really need to use ttm, and 
if we want to move them over, as you say, it's just a matter of reusing 
the SYSTEM region with suitable flags. I think we should restrict this 
to deal with pin_map() for now, and a separate series would work fine.

Although there seem to be callers, at least in selftests, that use 
pin_map with create_shmem() which maps to TTM system on discrete.

/Thomas


>>
>> /Thomas
>>
>>
>>>
>>>>
>>>> /Thomas
>>>>
>>>>
>>>>>       mmo = mmap_offset_attach(obj, mmap_type, file);
>>>>>       if (IS_ERR(mmo))
>>>>>           return PTR_ERR(mmo);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-06-28 10:56 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-25 12:27 [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem Matthew Auld
2021-06-25 12:27 ` [Intel-gfx] " Matthew Auld
2021-06-25 12:27 ` [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements Matthew Auld
2021-06-25 12:27   ` [Intel-gfx] " Matthew Auld
2021-06-28  7:41   ` Thomas Hellström
2021-06-28  7:41     ` [Intel-gfx] " Thomas Hellström
2021-06-28  9:12     ` Matthew Auld
2021-06-28  9:12       ` [Intel-gfx] " Matthew Auld
2021-06-28  9:38       ` Thomas Hellström
2021-06-28  9:38         ` [Intel-gfx] " Thomas Hellström
2021-06-28 10:20         ` Matthew Auld
2021-06-28 10:20           ` [Intel-gfx] " Matthew Auld
2021-06-28 10:55           ` Thomas Hellström
2021-06-28 10:55             ` [Intel-gfx] " Thomas Hellström
2021-06-25 13:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem Patchwork
2021-06-25 13:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-25 13:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-25 16:45 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-06-28  7:31 ` [PATCH v2 1/2] " Thomas Hellström
2021-06-28  7:31   ` [Intel-gfx] " Thomas Hellström

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.