* [PATCH v8 0/5] discrete card 64K page support
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Intel GFX, dri-devel
Cc: Robert Beckett, Matthew Auld, Stuart Summers, thomas.hellstrom
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for lmem buffers
- enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert
- expand vma reservation to round up to 2MB on DG2 in i915_vma_insert
- add alignment test
v2: rebase and fix for async vma that landed
v3:
* fix uapi doc typos
* add needs_compact_pt flag patch
* cleanup vma expansion to use vm->min_alignment instead of hard coding
v4:
* fix err return in igt_ppgtt_compact test
* placate ci robot with explicit enum conversion in misaligned_pin
* remove some blank lines
v5:
* fix obj alignment requirements querying for internal buffers that
have no memory region associated. (fixes v3 bug)
v6:
* use NEEDS_COMPACT_PT inead of hard coding in misalignment test
* tiled_blits_create correctly pick largest required alignment
* minor doc formatting
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* fix misalignment test corner case for uninitialized stolen smem
* fix misalignment test corner case for single page gtt hole
* fix array overflow in i915_vm_min_alignment for mock region
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Matthew Auld (3):
drm/i915: enforce min GTT alignment for discrete cards
drm/i915: support 64K GTT pages for discrete cards
drm/i915/uapi: document behaviour for DG2 64K support
Ramalingam C (1):
drm/i915: add needs_compact_pt flag
Robert Beckett (1):
drm/i915: add gtt misalignment test
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 +++++
.../i915/gem/selftests/i915_gem_client_blt.c | 21 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 ++++++++-
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 25 ++
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 11 +-
drivers/gpu/drm/i915/i915_pci.c | 2 +
drivers/gpu/drm/i915/i915_vma.c | 9 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 222 +++++++++++++++---
include/uapi/drm/i915_drm.h | 44 +++-
12 files changed, 464 insertions(+), 52 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Intel-gfx] [PATCH v8 0/5] discrete card 64K page support
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Intel GFX, dri-devel; +Cc: Matthew Auld, thomas.hellstrom
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for lmem buffers
- enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert
- expand vma reservation to round up to 2MB on DG2 in i915_vma_insert
- add alignment test
v2: rebase and fix for async vma that landed
v3:
* fix uapi doc typos
* add needs_compact_pt flag patch
* cleanup vma expansion to use vm->min_alignment instead of hard coding
v4:
* fix err return in igt_ppgtt_compact test
* placate ci robot with explicit enum conversion in misaligned_pin
* remove some blank lines
v5:
* fix obj alignment requirements querying for internal buffers that
have no memory region associated. (fixes v3 bug)
v6:
* use NEEDS_COMPACT_PT inead of hard coding in misalignment test
* tiled_blits_create correctly pick largest required alignment
* minor doc formatting
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* fix misalignment test corner case for uninitialized stolen smem
* fix misalignment test corner case for single page gtt hole
* fix array overflow in i915_vm_min_alignment for mock region
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Matthew Auld (3):
drm/i915: enforce min GTT alignment for discrete cards
drm/i915: support 64K GTT pages for discrete cards
drm/i915/uapi: document behaviour for DG2 64K support
Ramalingam C (1):
drm/i915: add needs_compact_pt flag
Robert Beckett (1):
drm/i915: add gtt misalignment test
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 +++++
.../i915/gem/selftests/i915_gem_client_blt.c | 21 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 ++++++++-
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 25 ++
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 11 +-
drivers/gpu/drm/i915/i915_pci.c | 2 +
drivers/gpu/drm/i915/i915_vma.c | 9 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 222 +++++++++++++++---
include/uapi/drm/i915_drm.h | 44 +++-
12 files changed, 464 insertions(+), 52 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v8 1/5] drm/i915: add needs_compact_pt flag
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
(?)
@ 2022-02-08 20:34 ` Robert Beckett
-1 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Robert Beckett, Thomas Hellström, intel-gfx, linux-kernel,
dri-devel, Matthew Auld
From: Ramalingam C <ramalingam.c@intel.com>
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
* minor doc formatting
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++++++++---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
*/
#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+ func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [Intel-gfx] [PATCH v8 1/5] drm/i915: add needs_compact_pt flag
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Thomas Hellström, intel-gfx, linux-kernel, dri-devel, Matthew Auld
From: Ramalingam C <ramalingam.c@intel.com>
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
* minor doc formatting
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++++++++---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
*/
#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+ func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 1/5] drm/i915: add needs_compact_pt flag
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Ramalingam C, Matthew Auld, Robert Beckett,
Thomas Hellström, intel-gfx, dri-devel, linux-kernel
From: Ramalingam C <ramalingam.c@intel.com>
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
* minor doc formatting
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++++++++---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
*/
#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+ func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 2/5] drm/i915: enforce min GTT alignment for discrete cards
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
(?)
@ 2022-02-08 20:34 ` Robert Beckett
-1 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Robert Beckett, Thomas Hellström, intel-gfx, linux-kernel,
dri-devel, Matthew Auld
From: Matthew Auld <matthew.auld@intel.com>
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
v3:
* use needs_compact_pt flag to discriminate between
64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment
v8:
* i915_vm_min_alignment protect against array overflow for mock region
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
.../i915/gem/selftests/i915_gem_client_blt.c | 21 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 22 +++++
drivers/gpu/drm/i915/i915_vma.c | 9 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ++++++++++++-------
5 files changed, 119 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(&t->ce->vm->mutex);
memset(&hole, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(&t->ce->vm->mm, &hole,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
- &t->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+ &t->buffers[2], t->hole + t->align,
&t->buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space *vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(&vm->mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+ ARRAY_SIZE(vm->min_alignment));
+
+ if (HAS_64K_PAGES(vm->i915) && NEEDS_COMPACT_PT(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_2M;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] = I915_GTT_PAGE_SIZE_2M;
+ } else if (HAS_64K_PAGES(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_64K;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] = I915_GTT_PAGE_SIZE_64K;
+ }
+
vm->mm.head_node.color = I915_COLOR_UNEVICTABLE;
INIT_LIST_HEAD(&vm->bound_list);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 8073438b67c8..6cd518a3277c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -29,6 +29,8 @@
#include "i915_selftest.h"
#include "i915_vma_resource.h"
#include "i915_vma_types.h"
+#include "i915_params.h"
+#include "intel_memory_region.h"
#define I915_GFP_ALLOW_FAIL (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
@@ -223,6 +225,7 @@ struct i915_address_space {
struct device *dma;
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
+ u64 min_alignment[INTEL_MEMORY_STOLEN_LOCAL + 1];
unsigned int bind_async_flags;
@@ -384,6 +387,25 @@ i915_vm_has_scratch_64K(struct i915_address_space *vm)
return vm->scratch_order == get_order(I915_GTT_PAGE_SIZE_64K);
}
+static inline u64 i915_vm_min_alignment(struct i915_address_space *vm,
+ enum intel_memory_type type)
+{
+ /* avoid INTEL_MEMORY_MOCK overflow */
+ if ((int)type >= ARRAY_SIZE(vm->min_alignment))
+ type = INTEL_MEMORY_SYSTEM;
+
+ return vm->min_alignment[type];
+}
+
+static inline u64 i915_vm_obj_min_alignment(struct i915_address_space *vm,
+ struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+ enum intel_memory_type type = mr ? mr->type : INTEL_MEMORY_SYSTEM;
+
+ return i915_vm_min_alignment(vm, type);
+}
+
static inline bool
i915_vm_has_cache_coloring(struct i915_address_space *vm)
{
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 845cd88f8313..3558b16a929c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -757,6 +757,14 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
end = min_t(u64, end, (1ULL << 32) - I915_GTT_PAGE_SIZE);
GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE));
+ alignment = max(alignment, i915_vm_obj_min_alignment(vma->vm, vma->obj));
+ /*
+ * for compact-pt we round up the reservation to prevent
+ * any smaller pages being used within the same PDE
+ */
+ if (NEEDS_COMPACT_PT(vma->vm->i915))
+ size = round_up(size, alignment);
+
/* If binding the object/GGTT view requires more space than the entire
* aperture has, reject it early before evicting everything in a vain
* attempt to find space.
@@ -769,6 +777,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
}
color = 0;
+
if (i915_vm_has_cache_coloring(vma->vm))
color = vma->obj->cache_level;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fba1c8be1649..b80788a2b7f9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -238,6 +238,8 @@ static int lowlevel_hole(struct i915_address_space *vm,
u64 hole_start, u64 hole_end,
unsigned long end_time)
{
+ const unsigned int min_alignment =
+ i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
I915_RND_STATE(seed_prng);
struct i915_vma_resource *mock_vma_res;
unsigned int size;
@@ -251,9 +253,10 @@ static int lowlevel_hole(struct i915_address_space *vm,
I915_RND_SUBSTATE(prng, seed_prng);
struct drm_i915_gem_object *obj;
unsigned int *order, count, n;
- u64 hole_size;
+ u64 hole_size, aligned_size;
- hole_size = (hole_end - hole_start) >> size;
+ aligned_size = max_t(u32, ilog2(min_alignment), size);
+ hole_size = (hole_end - hole_start) >> aligned_size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
hole_size = KMALLOC_MAX_SIZE / sizeof(u32);
count = hole_size >> 1;
@@ -274,8 +277,8 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
GEM_BUG_ON(!order);
- GEM_BUG_ON(count * BIT_ULL(size) > vm->total);
- GEM_BUG_ON(hole_start + count * BIT_ULL(size) > hole_end);
+ GEM_BUG_ON(count * BIT_ULL(aligned_size) > vm->total);
+ GEM_BUG_ON(hole_start + count * BIT_ULL(aligned_size) > hole_end);
/* Ignore allocation failures (i.e. don't report them as
* a test failure) as we are purposefully allocating very
@@ -298,10 +301,10 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
intel_wakeref_t wakeref;
- GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
+ GEM_BUG_ON(addr + BIT_ULL(aligned_size) > vm->total);
if (igt_timeout(end_time,
"%s timed out before %d/%d\n",
@@ -344,7 +347,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
mock_vma_res->bi.pages = obj->mm.pages;
- mock_vma_res->node_size = BIT_ULL(size);
+ mock_vma_res->node_size = BIT_ULL(aligned_size);
mock_vma_res->start = addr;
with_intel_runtime_pm(vm->gt->uncore->rpm, wakeref)
@@ -355,7 +358,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
i915_random_reorder(order, count, &prng);
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
intel_wakeref_t wakeref;
GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
@@ -399,8 +402,10 @@ static int fill_hole(struct i915_address_space *vm,
{
const u64 hole_size = hole_end - hole_start;
struct drm_i915_gem_object *obj;
+ const unsigned int min_alignment =
+ i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
const unsigned long max_pages =
- min_t(u64, ULONG_MAX - 1, hole_size/2 >> PAGE_SHIFT);
+ min_t(u64, ULONG_MAX - 1, (hole_size / 2) >> ilog2(min_alignment));
const unsigned long max_step = max(int_sqrt(max_pages), 2UL);
unsigned long npages, prime, flags;
struct i915_vma *vma;
@@ -441,14 +446,17 @@ static int fill_hole(struct i915_address_space *vm,
offset = p->offset;
list_for_each_entry(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
err = i915_vma_pin(vma, 0, 0, offset | flags);
@@ -470,22 +478,25 @@ static int fill_hole(struct i915_address_space *vm,
i915_vma_unpin(vma);
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
if (!drm_mm_node_allocated(&vma->node) ||
@@ -506,22 +517,25 @@ static int fill_hole(struct i915_address_space *vm,
}
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry_reverse(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
err = i915_vma_pin(vma, 0, 0, offset | flags);
@@ -543,22 +557,25 @@ static int fill_hole(struct i915_address_space *vm,
i915_vma_unpin(vma);
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry_reverse(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
if (!drm_mm_node_allocated(&vma->node) ||
@@ -579,9 +596,9 @@ static int fill_hole(struct i915_address_space *vm,
}
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
}
@@ -611,6 +628,7 @@ static int walk_hole(struct i915_address_space *vm,
const u64 hole_size = hole_end - hole_start;
const unsigned long max_pages =
min_t(u64, ULONG_MAX - 1, hole_size >> PAGE_SHIFT);
+ unsigned long min_alignment;
unsigned long flags;
u64 size;
@@ -620,6 +638,8 @@ static int walk_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
for_each_prime_number_from(size, 1, max_pages) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -638,7 +658,7 @@ static int walk_hole(struct i915_address_space *vm,
for (addr = hole_start;
addr + obj->base.size < hole_end;
- addr += obj->base.size) {
+ addr += round_up(obj->base.size, min_alignment)) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
pr_err("%s bind failed at %llx + %llx [hole %llx- %llx] with err=%d\n",
@@ -690,6 +710,7 @@ static int pot_hole(struct i915_address_space *vm,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+ unsigned int min_alignment;
unsigned long flags;
unsigned int pot;
int err = 0;
@@ -698,6 +719,8 @@ static int pot_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
obj = i915_gem_object_create_internal(vm->i915, 2 * I915_GTT_PAGE_SIZE);
if (IS_ERR(obj))
return PTR_ERR(obj);
@@ -710,13 +733,13 @@ static int pot_hole(struct i915_address_space *vm,
/* Insert a pair of pages across every pot boundary within the hole */
for (pot = fls64(hole_end - 1) - 1;
- pot > ilog2(2 * I915_GTT_PAGE_SIZE);
+ pot > ilog2(2 * min_alignment);
pot--) {
u64 step = BIT_ULL(pot);
u64 addr;
- for (addr = round_up(hole_start + I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE;
- addr <= round_down(hole_end - 2*I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE;
+ for (addr = round_up(hole_start + min_alignment, step) - min_alignment;
+ addr <= round_down(hole_end - (2 * min_alignment), step) - min_alignment;
addr += step) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
@@ -761,6 +784,7 @@ static int drunk_hole(struct i915_address_space *vm,
unsigned long end_time)
{
I915_RND_STATE(prng);
+ unsigned int min_alignment;
unsigned int size;
unsigned long flags;
@@ -768,15 +792,18 @@ static int drunk_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
/* Keep creating larger objects until one cannot fit into the hole */
for (size = 12; (hole_end - hole_start) >> size; size++) {
struct drm_i915_gem_object *obj;
unsigned int *order, count, n;
struct i915_vma *vma;
- u64 hole_size;
+ u64 hole_size, aligned_size;
int err = -ENODEV;
- hole_size = (hole_end - hole_start) >> size;
+ aligned_size = max_t(u32, ilog2(min_alignment), size);
+ hole_size = (hole_end - hole_start) >> aligned_size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
hole_size = KMALLOC_MAX_SIZE / sizeof(u32);
count = hole_size >> 1;
@@ -816,7 +843,7 @@ static int drunk_hole(struct i915_address_space *vm,
GEM_BUG_ON(vma->size != BIT_ULL(size));
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
@@ -868,11 +895,14 @@ static int __shrink_hole(struct i915_address_space *vm,
{
struct drm_i915_gem_object *obj;
unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ unsigned int min_alignment;
unsigned int order = 12;
LIST_HEAD(objects);
int err = 0;
u64 addr;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
/* Keep creating larger objects until one cannot fit into the hole */
for (addr = hole_start; addr < hole_end; ) {
struct i915_vma *vma;
@@ -913,7 +943,7 @@ static int __shrink_hole(struct i915_address_space *vm,
}
i915_vma_unpin(vma);
- addr += size;
+ addr += round_up(size, min_alignment);
/*
* Since we are injecting allocation faults at random intervals,
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [Intel-gfx] [PATCH v8 2/5] drm/i915: enforce min GTT alignment for discrete cards
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Thomas Hellström, intel-gfx, linux-kernel, dri-devel, Matthew Auld
From: Matthew Auld <matthew.auld@intel.com>
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
v3:
* use needs_compact_pt flag to discriminate between
64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment
v8:
* i915_vm_min_alignment protect against array overflow for mock region
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
.../i915/gem/selftests/i915_gem_client_blt.c | 21 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 22 +++++
drivers/gpu/drm/i915/i915_vma.c | 9 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ++++++++++++-------
5 files changed, 119 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(&t->ce->vm->mutex);
memset(&hole, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(&t->ce->vm->mm, &hole,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
- &t->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+ &t->buffers[2], t->hole + t->align,
&t->buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space *vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(&vm->mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+ ARRAY_SIZE(vm->min_alignment));
+
+ if (HAS_64K_PAGES(vm->i915) && NEEDS_COMPACT_PT(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_2M;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] = I915_GTT_PAGE_SIZE_2M;
+ } else if (HAS_64K_PAGES(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_64K;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] = I915_GTT_PAGE_SIZE_64K;
+ }
+
vm->mm.head_node.color = I915_COLOR_UNEVICTABLE;
INIT_LIST_HEAD(&vm->bound_list);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 8073438b67c8..6cd518a3277c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -29,6 +29,8 @@
#include "i915_selftest.h"
#include "i915_vma_resource.h"
#include "i915_vma_types.h"
+#include "i915_params.h"
+#include "intel_memory_region.h"
#define I915_GFP_ALLOW_FAIL (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
@@ -223,6 +225,7 @@ struct i915_address_space {
struct device *dma;
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
+ u64 min_alignment[INTEL_MEMORY_STOLEN_LOCAL + 1];
unsigned int bind_async_flags;
@@ -384,6 +387,25 @@ i915_vm_has_scratch_64K(struct i915_address_space *vm)
return vm->scratch_order == get_order(I915_GTT_PAGE_SIZE_64K);
}
+static inline u64 i915_vm_min_alignment(struct i915_address_space *vm,
+ enum intel_memory_type type)
+{
+ /* avoid INTEL_MEMORY_MOCK overflow */
+ if ((int)type >= ARRAY_SIZE(vm->min_alignment))
+ type = INTEL_MEMORY_SYSTEM;
+
+ return vm->min_alignment[type];
+}
+
+static inline u64 i915_vm_obj_min_alignment(struct i915_address_space *vm,
+ struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+ enum intel_memory_type type = mr ? mr->type : INTEL_MEMORY_SYSTEM;
+
+ return i915_vm_min_alignment(vm, type);
+}
+
static inline bool
i915_vm_has_cache_coloring(struct i915_address_space *vm)
{
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 845cd88f8313..3558b16a929c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -757,6 +757,14 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
end = min_t(u64, end, (1ULL << 32) - I915_GTT_PAGE_SIZE);
GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE));
+ alignment = max(alignment, i915_vm_obj_min_alignment(vma->vm, vma->obj));
+ /*
+ * for compact-pt we round up the reservation to prevent
+ * any smaller pages being used within the same PDE
+ */
+ if (NEEDS_COMPACT_PT(vma->vm->i915))
+ size = round_up(size, alignment);
+
/* If binding the object/GGTT view requires more space than the entire
* aperture has, reject it early before evicting everything in a vain
* attempt to find space.
@@ -769,6 +777,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
}
color = 0;
+
if (i915_vm_has_cache_coloring(vma->vm))
color = vma->obj->cache_level;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fba1c8be1649..b80788a2b7f9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -238,6 +238,8 @@ static int lowlevel_hole(struct i915_address_space *vm,
u64 hole_start, u64 hole_end,
unsigned long end_time)
{
+ const unsigned int min_alignment =
+ i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
I915_RND_STATE(seed_prng);
struct i915_vma_resource *mock_vma_res;
unsigned int size;
@@ -251,9 +253,10 @@ static int lowlevel_hole(struct i915_address_space *vm,
I915_RND_SUBSTATE(prng, seed_prng);
struct drm_i915_gem_object *obj;
unsigned int *order, count, n;
- u64 hole_size;
+ u64 hole_size, aligned_size;
- hole_size = (hole_end - hole_start) >> size;
+ aligned_size = max_t(u32, ilog2(min_alignment), size);
+ hole_size = (hole_end - hole_start) >> aligned_size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
hole_size = KMALLOC_MAX_SIZE / sizeof(u32);
count = hole_size >> 1;
@@ -274,8 +277,8 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
GEM_BUG_ON(!order);
- GEM_BUG_ON(count * BIT_ULL(size) > vm->total);
- GEM_BUG_ON(hole_start + count * BIT_ULL(size) > hole_end);
+ GEM_BUG_ON(count * BIT_ULL(aligned_size) > vm->total);
+ GEM_BUG_ON(hole_start + count * BIT_ULL(aligned_size) > hole_end);
/* Ignore allocation failures (i.e. don't report them as
* a test failure) as we are purposefully allocating very
@@ -298,10 +301,10 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
intel_wakeref_t wakeref;
- GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
+ GEM_BUG_ON(addr + BIT_ULL(aligned_size) > vm->total);
if (igt_timeout(end_time,
"%s timed out before %d/%d\n",
@@ -344,7 +347,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
mock_vma_res->bi.pages = obj->mm.pages;
- mock_vma_res->node_size = BIT_ULL(size);
+ mock_vma_res->node_size = BIT_ULL(aligned_size);
mock_vma_res->start = addr;
with_intel_runtime_pm(vm->gt->uncore->rpm, wakeref)
@@ -355,7 +358,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
i915_random_reorder(order, count, &prng);
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
intel_wakeref_t wakeref;
GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
@@ -399,8 +402,10 @@ static int fill_hole(struct i915_address_space *vm,
{
const u64 hole_size = hole_end - hole_start;
struct drm_i915_gem_object *obj;
+ const unsigned int min_alignment =
+ i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
const unsigned long max_pages =
- min_t(u64, ULONG_MAX - 1, hole_size/2 >> PAGE_SHIFT);
+ min_t(u64, ULONG_MAX - 1, (hole_size / 2) >> ilog2(min_alignment));
const unsigned long max_step = max(int_sqrt(max_pages), 2UL);
unsigned long npages, prime, flags;
struct i915_vma *vma;
@@ -441,14 +446,17 @@ static int fill_hole(struct i915_address_space *vm,
offset = p->offset;
list_for_each_entry(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
err = i915_vma_pin(vma, 0, 0, offset | flags);
@@ -470,22 +478,25 @@ static int fill_hole(struct i915_address_space *vm,
i915_vma_unpin(vma);
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
if (!drm_mm_node_allocated(&vma->node) ||
@@ -506,22 +517,25 @@ static int fill_hole(struct i915_address_space *vm,
}
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry_reverse(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
err = i915_vma_pin(vma, 0, 0, offset | flags);
@@ -543,22 +557,25 @@ static int fill_hole(struct i915_address_space *vm,
i915_vma_unpin(vma);
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry_reverse(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
if (!drm_mm_node_allocated(&vma->node) ||
@@ -579,9 +596,9 @@ static int fill_hole(struct i915_address_space *vm,
}
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
}
@@ -611,6 +628,7 @@ static int walk_hole(struct i915_address_space *vm,
const u64 hole_size = hole_end - hole_start;
const unsigned long max_pages =
min_t(u64, ULONG_MAX - 1, hole_size >> PAGE_SHIFT);
+ unsigned long min_alignment;
unsigned long flags;
u64 size;
@@ -620,6 +638,8 @@ static int walk_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
for_each_prime_number_from(size, 1, max_pages) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -638,7 +658,7 @@ static int walk_hole(struct i915_address_space *vm,
for (addr = hole_start;
addr + obj->base.size < hole_end;
- addr += obj->base.size) {
+ addr += round_up(obj->base.size, min_alignment)) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
pr_err("%s bind failed at %llx + %llx [hole %llx- %llx] with err=%d\n",
@@ -690,6 +710,7 @@ static int pot_hole(struct i915_address_space *vm,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+ unsigned int min_alignment;
unsigned long flags;
unsigned int pot;
int err = 0;
@@ -698,6 +719,8 @@ static int pot_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
obj = i915_gem_object_create_internal(vm->i915, 2 * I915_GTT_PAGE_SIZE);
if (IS_ERR(obj))
return PTR_ERR(obj);
@@ -710,13 +733,13 @@ static int pot_hole(struct i915_address_space *vm,
/* Insert a pair of pages across every pot boundary within the hole */
for (pot = fls64(hole_end - 1) - 1;
- pot > ilog2(2 * I915_GTT_PAGE_SIZE);
+ pot > ilog2(2 * min_alignment);
pot--) {
u64 step = BIT_ULL(pot);
u64 addr;
- for (addr = round_up(hole_start + I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE;
- addr <= round_down(hole_end - 2*I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE;
+ for (addr = round_up(hole_start + min_alignment, step) - min_alignment;
+ addr <= round_down(hole_end - (2 * min_alignment), step) - min_alignment;
addr += step) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
@@ -761,6 +784,7 @@ static int drunk_hole(struct i915_address_space *vm,
unsigned long end_time)
{
I915_RND_STATE(prng);
+ unsigned int min_alignment;
unsigned int size;
unsigned long flags;
@@ -768,15 +792,18 @@ static int drunk_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
/* Keep creating larger objects until one cannot fit into the hole */
for (size = 12; (hole_end - hole_start) >> size; size++) {
struct drm_i915_gem_object *obj;
unsigned int *order, count, n;
struct i915_vma *vma;
- u64 hole_size;
+ u64 hole_size, aligned_size;
int err = -ENODEV;
- hole_size = (hole_end - hole_start) >> size;
+ aligned_size = max_t(u32, ilog2(min_alignment), size);
+ hole_size = (hole_end - hole_start) >> aligned_size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
hole_size = KMALLOC_MAX_SIZE / sizeof(u32);
count = hole_size >> 1;
@@ -816,7 +843,7 @@ static int drunk_hole(struct i915_address_space *vm,
GEM_BUG_ON(vma->size != BIT_ULL(size));
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
@@ -868,11 +895,14 @@ static int __shrink_hole(struct i915_address_space *vm,
{
struct drm_i915_gem_object *obj;
unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ unsigned int min_alignment;
unsigned int order = 12;
LIST_HEAD(objects);
int err = 0;
u64 addr;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
/* Keep creating larger objects until one cannot fit into the hole */
for (addr = hole_start; addr < hole_end; ) {
struct i915_vma *vma;
@@ -913,7 +943,7 @@ static int __shrink_hole(struct i915_address_space *vm,
}
i915_vma_unpin(vma);
- addr += size;
+ addr += round_up(size, min_alignment);
/*
* Since we are injecting allocation faults at random intervals,
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 2/5] drm/i915: enforce min GTT alignment for discrete cards
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Matthew Auld, Ramalingam C, Robert Beckett,
Thomas Hellström, intel-gfx, dri-devel, linux-kernel
From: Matthew Auld <matthew.auld@intel.com>
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
v3:
* use needs_compact_pt flag to discriminate between
64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment
v8:
* i915_vm_min_alignment protect against array overflow for mock region
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
.../i915/gem/selftests/i915_gem_client_blt.c | 21 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 22 +++++
drivers/gpu/drm/i915/i915_vma.c | 9 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ++++++++++++-------
5 files changed, 119 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(&t->ce->vm->mutex);
memset(&hole, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(&t->ce->vm->mm, &hole,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
- &t->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+ &t->buffers[2], t->hole + t->align,
&t->buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space *vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(&vm->mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+ ARRAY_SIZE(vm->min_alignment));
+
+ if (HAS_64K_PAGES(vm->i915) && NEEDS_COMPACT_PT(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_2M;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] = I915_GTT_PAGE_SIZE_2M;
+ } else if (HAS_64K_PAGES(vm->i915)) {
+ vm->min_alignment[INTEL_MEMORY_LOCAL] = I915_GTT_PAGE_SIZE_64K;
+ vm->min_alignment[INTEL_MEMORY_STOLEN_LOCAL] = I915_GTT_PAGE_SIZE_64K;
+ }
+
vm->mm.head_node.color = I915_COLOR_UNEVICTABLE;
INIT_LIST_HEAD(&vm->bound_list);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 8073438b67c8..6cd518a3277c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -29,6 +29,8 @@
#include "i915_selftest.h"
#include "i915_vma_resource.h"
#include "i915_vma_types.h"
+#include "i915_params.h"
+#include "intel_memory_region.h"
#define I915_GFP_ALLOW_FAIL (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
@@ -223,6 +225,7 @@ struct i915_address_space {
struct device *dma;
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
+ u64 min_alignment[INTEL_MEMORY_STOLEN_LOCAL + 1];
unsigned int bind_async_flags;
@@ -384,6 +387,25 @@ i915_vm_has_scratch_64K(struct i915_address_space *vm)
return vm->scratch_order == get_order(I915_GTT_PAGE_SIZE_64K);
}
+static inline u64 i915_vm_min_alignment(struct i915_address_space *vm,
+ enum intel_memory_type type)
+{
+ /* avoid INTEL_MEMORY_MOCK overflow */
+ if ((int)type >= ARRAY_SIZE(vm->min_alignment))
+ type = INTEL_MEMORY_SYSTEM;
+
+ return vm->min_alignment[type];
+}
+
+static inline u64 i915_vm_obj_min_alignment(struct i915_address_space *vm,
+ struct drm_i915_gem_object *obj)
+{
+ struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+ enum intel_memory_type type = mr ? mr->type : INTEL_MEMORY_SYSTEM;
+
+ return i915_vm_min_alignment(vm, type);
+}
+
static inline bool
i915_vm_has_cache_coloring(struct i915_address_space *vm)
{
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 845cd88f8313..3558b16a929c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -757,6 +757,14 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
end = min_t(u64, end, (1ULL << 32) - I915_GTT_PAGE_SIZE);
GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE));
+ alignment = max(alignment, i915_vm_obj_min_alignment(vma->vm, vma->obj));
+ /*
+ * for compact-pt we round up the reservation to prevent
+ * any smaller pages being used within the same PDE
+ */
+ if (NEEDS_COMPACT_PT(vma->vm->i915))
+ size = round_up(size, alignment);
+
/* If binding the object/GGTT view requires more space than the entire
* aperture has, reject it early before evicting everything in a vain
* attempt to find space.
@@ -769,6 +777,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww,
}
color = 0;
+
if (i915_vm_has_cache_coloring(vma->vm))
color = vma->obj->cache_level;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fba1c8be1649..b80788a2b7f9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -238,6 +238,8 @@ static int lowlevel_hole(struct i915_address_space *vm,
u64 hole_start, u64 hole_end,
unsigned long end_time)
{
+ const unsigned int min_alignment =
+ i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
I915_RND_STATE(seed_prng);
struct i915_vma_resource *mock_vma_res;
unsigned int size;
@@ -251,9 +253,10 @@ static int lowlevel_hole(struct i915_address_space *vm,
I915_RND_SUBSTATE(prng, seed_prng);
struct drm_i915_gem_object *obj;
unsigned int *order, count, n;
- u64 hole_size;
+ u64 hole_size, aligned_size;
- hole_size = (hole_end - hole_start) >> size;
+ aligned_size = max_t(u32, ilog2(min_alignment), size);
+ hole_size = (hole_end - hole_start) >> aligned_size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
hole_size = KMALLOC_MAX_SIZE / sizeof(u32);
count = hole_size >> 1;
@@ -274,8 +277,8 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
GEM_BUG_ON(!order);
- GEM_BUG_ON(count * BIT_ULL(size) > vm->total);
- GEM_BUG_ON(hole_start + count * BIT_ULL(size) > hole_end);
+ GEM_BUG_ON(count * BIT_ULL(aligned_size) > vm->total);
+ GEM_BUG_ON(hole_start + count * BIT_ULL(aligned_size) > hole_end);
/* Ignore allocation failures (i.e. don't report them as
* a test failure) as we are purposefully allocating very
@@ -298,10 +301,10 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
intel_wakeref_t wakeref;
- GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
+ GEM_BUG_ON(addr + BIT_ULL(aligned_size) > vm->total);
if (igt_timeout(end_time,
"%s timed out before %d/%d\n",
@@ -344,7 +347,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
}
mock_vma_res->bi.pages = obj->mm.pages;
- mock_vma_res->node_size = BIT_ULL(size);
+ mock_vma_res->node_size = BIT_ULL(aligned_size);
mock_vma_res->start = addr;
with_intel_runtime_pm(vm->gt->uncore->rpm, wakeref)
@@ -355,7 +358,7 @@ static int lowlevel_hole(struct i915_address_space *vm,
i915_random_reorder(order, count, &prng);
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
intel_wakeref_t wakeref;
GEM_BUG_ON(addr + BIT_ULL(size) > vm->total);
@@ -399,8 +402,10 @@ static int fill_hole(struct i915_address_space *vm,
{
const u64 hole_size = hole_end - hole_start;
struct drm_i915_gem_object *obj;
+ const unsigned int min_alignment =
+ i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
const unsigned long max_pages =
- min_t(u64, ULONG_MAX - 1, hole_size/2 >> PAGE_SHIFT);
+ min_t(u64, ULONG_MAX - 1, (hole_size / 2) >> ilog2(min_alignment));
const unsigned long max_step = max(int_sqrt(max_pages), 2UL);
unsigned long npages, prime, flags;
struct i915_vma *vma;
@@ -441,14 +446,17 @@ static int fill_hole(struct i915_address_space *vm,
offset = p->offset;
list_for_each_entry(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
err = i915_vma_pin(vma, 0, 0, offset | flags);
@@ -470,22 +478,25 @@ static int fill_hole(struct i915_address_space *vm,
i915_vma_unpin(vma);
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
if (!drm_mm_node_allocated(&vma->node) ||
@@ -506,22 +517,25 @@ static int fill_hole(struct i915_address_space *vm,
}
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry_reverse(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
err = i915_vma_pin(vma, 0, 0, offset | flags);
@@ -543,22 +557,25 @@ static int fill_hole(struct i915_address_space *vm,
i915_vma_unpin(vma);
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
offset = p->offset;
list_for_each_entry_reverse(obj, &objects, st_link) {
+ u64 aligned_size = round_up(obj->base.size,
+ min_alignment);
+
vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
continue;
if (p->step < 0) {
- if (offset < hole_start + obj->base.size)
+ if (offset < hole_start + aligned_size)
break;
- offset -= obj->base.size;
+ offset -= aligned_size;
}
if (!drm_mm_node_allocated(&vma->node) ||
@@ -579,9 +596,9 @@ static int fill_hole(struct i915_address_space *vm,
}
if (p->step > 0) {
- if (offset + obj->base.size > hole_end)
+ if (offset + aligned_size > hole_end)
break;
- offset += obj->base.size;
+ offset += aligned_size;
}
}
}
@@ -611,6 +628,7 @@ static int walk_hole(struct i915_address_space *vm,
const u64 hole_size = hole_end - hole_start;
const unsigned long max_pages =
min_t(u64, ULONG_MAX - 1, hole_size >> PAGE_SHIFT);
+ unsigned long min_alignment;
unsigned long flags;
u64 size;
@@ -620,6 +638,8 @@ static int walk_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
for_each_prime_number_from(size, 1, max_pages) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -638,7 +658,7 @@ static int walk_hole(struct i915_address_space *vm,
for (addr = hole_start;
addr + obj->base.size < hole_end;
- addr += obj->base.size) {
+ addr += round_up(obj->base.size, min_alignment)) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
pr_err("%s bind failed at %llx + %llx [hole %llx- %llx] with err=%d\n",
@@ -690,6 +710,7 @@ static int pot_hole(struct i915_address_space *vm,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+ unsigned int min_alignment;
unsigned long flags;
unsigned int pot;
int err = 0;
@@ -698,6 +719,8 @@ static int pot_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
obj = i915_gem_object_create_internal(vm->i915, 2 * I915_GTT_PAGE_SIZE);
if (IS_ERR(obj))
return PTR_ERR(obj);
@@ -710,13 +733,13 @@ static int pot_hole(struct i915_address_space *vm,
/* Insert a pair of pages across every pot boundary within the hole */
for (pot = fls64(hole_end - 1) - 1;
- pot > ilog2(2 * I915_GTT_PAGE_SIZE);
+ pot > ilog2(2 * min_alignment);
pot--) {
u64 step = BIT_ULL(pot);
u64 addr;
- for (addr = round_up(hole_start + I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE;
- addr <= round_down(hole_end - 2*I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE;
+ for (addr = round_up(hole_start + min_alignment, step) - min_alignment;
+ addr <= round_down(hole_end - (2 * min_alignment), step) - min_alignment;
addr += step) {
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
@@ -761,6 +784,7 @@ static int drunk_hole(struct i915_address_space *vm,
unsigned long end_time)
{
I915_RND_STATE(prng);
+ unsigned int min_alignment;
unsigned int size;
unsigned long flags;
@@ -768,15 +792,18 @@ static int drunk_hole(struct i915_address_space *vm,
if (i915_is_ggtt(vm))
flags |= PIN_GLOBAL;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
/* Keep creating larger objects until one cannot fit into the hole */
for (size = 12; (hole_end - hole_start) >> size; size++) {
struct drm_i915_gem_object *obj;
unsigned int *order, count, n;
struct i915_vma *vma;
- u64 hole_size;
+ u64 hole_size, aligned_size;
int err = -ENODEV;
- hole_size = (hole_end - hole_start) >> size;
+ aligned_size = max_t(u32, ilog2(min_alignment), size);
+ hole_size = (hole_end - hole_start) >> aligned_size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
hole_size = KMALLOC_MAX_SIZE / sizeof(u32);
count = hole_size >> 1;
@@ -816,7 +843,7 @@ static int drunk_hole(struct i915_address_space *vm,
GEM_BUG_ON(vma->size != BIT_ULL(size));
for (n = 0; n < count; n++) {
- u64 addr = hole_start + order[n] * BIT_ULL(size);
+ u64 addr = hole_start + order[n] * BIT_ULL(aligned_size);
err = i915_vma_pin(vma, 0, 0, addr | flags);
if (err) {
@@ -868,11 +895,14 @@ static int __shrink_hole(struct i915_address_space *vm,
{
struct drm_i915_gem_object *obj;
unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ unsigned int min_alignment;
unsigned int order = 12;
LIST_HEAD(objects);
int err = 0;
u64 addr;
+ min_alignment = i915_vm_min_alignment(vm, INTEL_MEMORY_SYSTEM);
+
/* Keep creating larger objects until one cannot fit into the hole */
for (addr = hole_start; addr < hole_end; ) {
struct i915_vma *vma;
@@ -913,7 +943,7 @@ static int __shrink_hole(struct i915_address_space *vm,
}
i915_vma_unpin(vma);
- addr += size;
+ addr += round_up(size, min_alignment);
/*
* Since we are injecting allocation faults at random intervals,
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 3/5] drm/i915: support 64K GTT pages for discrete cards
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
(?)
@ 2022-02-08 20:34 ` Robert Beckett
-1 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Robert Beckett, Thomas Hellström, kernel test robot,
intel-gfx, linux-kernel, dri-devel, Stuart Summers, Matthew Auld
From: Matthew Auld <matthew.auld@intel.com>
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++++++++++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +++++++++++++++++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+ * Simple test to catch issues with compact 64K pages -- since the pt is
+ * compacted to 256B that gives us 32 entries per pt, however since the
+ * backing page for the pt is 4K, any extra entries we might incorrectly
+ * write out should be ignored by the HW. If ever hit such a case this
+ * test should catch it since some of our writes would land in scratch.
+ */
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+ * Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+ * insertion.
+ */
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
atomic_read(&pt->used));
GEM_BUG_ON(!count || count >= atomic_read(&pt->used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
- count);
+ num_ptes);
atomic_sub(count, &pt->used);
start += count;
@@ -453,6 +463,95 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
return idx;
}
+static void
+xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res,
+ struct sgt_dma *iter,
+ enum i915_cache_level cache_level,
+ u32 flags)
+{
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
+ unsigned int rem = sg_dma_len(iter->sg);
+ u64 start = vma_res->start;
+
+ GEM_BUG_ON(!i915_vm_is_4lvl(vm));
+
+ do {
+ struct i915_page_directory * const pdp =
+ gen8_pdp_for_page_address(vm, start);
+ struct i915_page_directory * const pd =
+ i915_pd_entry(pdp, __gen8_pte_index(start, 2));
+ struct i915_page_table *pt =
+ i915_pt_entry(pd, __gen8_pte_index(start, 1));
+ gen8_pte_t encode = pte_encode;
+ unsigned int page_size;
+ gen8_pte_t *vaddr;
+ u16 index, max;
+
+ max = I915_PDES;
+
+ if (vma_res->bi.page_sizes.sg & I915_GTT_PAGE_SIZE_2M &&
+ IS_ALIGNED(iter->dma, I915_GTT_PAGE_SIZE_2M) &&
+ rem >= I915_GTT_PAGE_SIZE_2M &&
+ !__gen8_pte_index(start, 0)) {
+ index = __gen8_pte_index(start, 1);
+ encode |= GEN8_PDE_PS_2M;
+ page_size = I915_GTT_PAGE_SIZE_2M;
+
+ vaddr = px_vaddr(pd);
+ } else {
+ if (encode & GEN12_PPGTT_PTE_LM) {
+ GEM_BUG_ON(__gen8_pte_index(start, 0) % 16);
+ GEM_BUG_ON(rem < I915_GTT_PAGE_SIZE_64K);
+ GEM_BUG_ON(!IS_ALIGNED(iter->dma,
+ I915_GTT_PAGE_SIZE_64K));
+
+ index = __gen8_pte_index(start, 0) / 16;
+ page_size = I915_GTT_PAGE_SIZE_64K;
+
+ max /= 16;
+
+ vaddr = px_vaddr(pd);
+ vaddr[__gen8_pte_index(start, 1)] |= GEN12_PDE_64K;
+
+ pt->is_compact = true;
+ } else {
+ GEM_BUG_ON(pt->is_compact);
+ index = __gen8_pte_index(start, 0);
+ page_size = I915_GTT_PAGE_SIZE;
+ }
+
+ vaddr = px_vaddr(pt);
+ }
+
+ do {
+ GEM_BUG_ON(rem < page_size);
+ vaddr[index++] = encode | iter->dma;
+
+ start += page_size;
+ iter->dma += page_size;
+ rem -= page_size;
+ if (iter->dma >= iter->max) {
+ iter->sg = __sg_next(iter->sg);
+ if (!iter->sg)
+ break;
+
+ rem = sg_dma_len(iter->sg);
+ if (!rem)
+ break;
+
+ iter->dma = sg_dma_address(iter->sg);
+ iter->max = iter->dma + rem;
+
+ if (unlikely(!IS_ALIGNED(iter->dma, page_size)))
+ break;
+ }
+ } while (rem >= page_size && index < max);
+
+ vma_res->page_sizes_gtt |= page_size;
+ } while (iter->sg && sg_dma_len(iter->sg));
+}
+
static void gen8_ppgtt_insert_huge(struct i915_address_space *vm,
struct i915_vma_resource *vma_res,
struct sgt_dma *iter,
@@ -586,7 +685,10 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
+ if (HAS_64K_PAGES(vm->i915))
+ xehpsdv_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
+ else
+ gen8_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
} else {
u64 idx = vma_res->start >> GEN8_PTE_SHIFT;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 6cd518a3277c..5e038cef0d9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -92,6 +92,8 @@ typedef u64 gen8_pte_t;
#define GEN12_GGTT_PTE_LM BIT_ULL(1)
+#define GEN12_PDE_64K BIT(6)
+
/*
* Cacheability Control is a 4-bit value. The low three bits are stored in bits
* 3:1 of the PTE, while the fourth bit is stored in bit 11 of the PTE.
@@ -160,6 +162,7 @@ struct i915_page_table {
atomic_t used;
struct i915_page_table *stash;
};
+ bool is_compact;
};
struct i915_page_directory {
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 48e6e2f87700..043652dc6892 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -26,6 +26,7 @@ struct i915_page_table *alloc_pt(struct i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
+ pt->is_compact = false;
atomic_set(&pt->used, 0);
return pt;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [Intel-gfx] [PATCH v8 3/5] drm/i915: support 64K GTT pages for discrete cards
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Thomas Hellström, intel-gfx, linux-kernel, dri-devel, Matthew Auld
From: Matthew Auld <matthew.auld@intel.com>
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++++++++++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +++++++++++++++++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+ * Simple test to catch issues with compact 64K pages -- since the pt is
+ * compacted to 256B that gives us 32 entries per pt, however since the
+ * backing page for the pt is 4K, any extra entries we might incorrectly
+ * write out should be ignored by the HW. If ever hit such a case this
+ * test should catch it since some of our writes would land in scratch.
+ */
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+ * Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+ * insertion.
+ */
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
atomic_read(&pt->used));
GEM_BUG_ON(!count || count >= atomic_read(&pt->used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
- count);
+ num_ptes);
atomic_sub(count, &pt->used);
start += count;
@@ -453,6 +463,95 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
return idx;
}
+static void
+xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res,
+ struct sgt_dma *iter,
+ enum i915_cache_level cache_level,
+ u32 flags)
+{
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
+ unsigned int rem = sg_dma_len(iter->sg);
+ u64 start = vma_res->start;
+
+ GEM_BUG_ON(!i915_vm_is_4lvl(vm));
+
+ do {
+ struct i915_page_directory * const pdp =
+ gen8_pdp_for_page_address(vm, start);
+ struct i915_page_directory * const pd =
+ i915_pd_entry(pdp, __gen8_pte_index(start, 2));
+ struct i915_page_table *pt =
+ i915_pt_entry(pd, __gen8_pte_index(start, 1));
+ gen8_pte_t encode = pte_encode;
+ unsigned int page_size;
+ gen8_pte_t *vaddr;
+ u16 index, max;
+
+ max = I915_PDES;
+
+ if (vma_res->bi.page_sizes.sg & I915_GTT_PAGE_SIZE_2M &&
+ IS_ALIGNED(iter->dma, I915_GTT_PAGE_SIZE_2M) &&
+ rem >= I915_GTT_PAGE_SIZE_2M &&
+ !__gen8_pte_index(start, 0)) {
+ index = __gen8_pte_index(start, 1);
+ encode |= GEN8_PDE_PS_2M;
+ page_size = I915_GTT_PAGE_SIZE_2M;
+
+ vaddr = px_vaddr(pd);
+ } else {
+ if (encode & GEN12_PPGTT_PTE_LM) {
+ GEM_BUG_ON(__gen8_pte_index(start, 0) % 16);
+ GEM_BUG_ON(rem < I915_GTT_PAGE_SIZE_64K);
+ GEM_BUG_ON(!IS_ALIGNED(iter->dma,
+ I915_GTT_PAGE_SIZE_64K));
+
+ index = __gen8_pte_index(start, 0) / 16;
+ page_size = I915_GTT_PAGE_SIZE_64K;
+
+ max /= 16;
+
+ vaddr = px_vaddr(pd);
+ vaddr[__gen8_pte_index(start, 1)] |= GEN12_PDE_64K;
+
+ pt->is_compact = true;
+ } else {
+ GEM_BUG_ON(pt->is_compact);
+ index = __gen8_pte_index(start, 0);
+ page_size = I915_GTT_PAGE_SIZE;
+ }
+
+ vaddr = px_vaddr(pt);
+ }
+
+ do {
+ GEM_BUG_ON(rem < page_size);
+ vaddr[index++] = encode | iter->dma;
+
+ start += page_size;
+ iter->dma += page_size;
+ rem -= page_size;
+ if (iter->dma >= iter->max) {
+ iter->sg = __sg_next(iter->sg);
+ if (!iter->sg)
+ break;
+
+ rem = sg_dma_len(iter->sg);
+ if (!rem)
+ break;
+
+ iter->dma = sg_dma_address(iter->sg);
+ iter->max = iter->dma + rem;
+
+ if (unlikely(!IS_ALIGNED(iter->dma, page_size)))
+ break;
+ }
+ } while (rem >= page_size && index < max);
+
+ vma_res->page_sizes_gtt |= page_size;
+ } while (iter->sg && sg_dma_len(iter->sg));
+}
+
static void gen8_ppgtt_insert_huge(struct i915_address_space *vm,
struct i915_vma_resource *vma_res,
struct sgt_dma *iter,
@@ -586,7 +685,10 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
+ if (HAS_64K_PAGES(vm->i915))
+ xehpsdv_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
+ else
+ gen8_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
} else {
u64 idx = vma_res->start >> GEN8_PTE_SHIFT;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 6cd518a3277c..5e038cef0d9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -92,6 +92,8 @@ typedef u64 gen8_pte_t;
#define GEN12_GGTT_PTE_LM BIT_ULL(1)
+#define GEN12_PDE_64K BIT(6)
+
/*
* Cacheability Control is a 4-bit value. The low three bits are stored in bits
* 3:1 of the PTE, while the fourth bit is stored in bit 11 of the PTE.
@@ -160,6 +162,7 @@ struct i915_page_table {
atomic_t used;
struct i915_page_table *stash;
};
+ bool is_compact;
};
struct i915_page_directory {
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 48e6e2f87700..043652dc6892 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -26,6 +26,7 @@ struct i915_page_table *alloc_pt(struct i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
+ pt->is_compact = false;
atomic_set(&pt->used, 0);
return pt;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 3/5] drm/i915: support 64K GTT pages for discrete cards
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Matthew Auld, kernel test robot, Stuart Summers, Ramalingam C,
Robert Beckett, Thomas Hellström, intel-gfx, dri-devel,
linux-kernel
From: Matthew Auld <matthew.auld@intel.com>
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++++++++++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +++++++++++++++++-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+ * Simple test to catch issues with compact 64K pages -- since the pt is
+ * compacted to 256B that gives us 32 entries per pt, however since the
+ * backing page for the pt is 4K, any extra entries we might incorrectly
+ * write out should be ignored by the HW. If ever hit such a case this
+ * test should catch it since some of our writes would land in scratch.
+ */
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+ * Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+ * insertion.
+ */
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
atomic_read(&pt->used));
GEM_BUG_ON(!count || count >= atomic_read(&pt->used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
- count);
+ num_ptes);
atomic_sub(count, &pt->used);
start += count;
@@ -453,6 +463,95 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
return idx;
}
+static void
+xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
+ struct i915_vma_resource *vma_res,
+ struct sgt_dma *iter,
+ enum i915_cache_level cache_level,
+ u32 flags)
+{
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
+ unsigned int rem = sg_dma_len(iter->sg);
+ u64 start = vma_res->start;
+
+ GEM_BUG_ON(!i915_vm_is_4lvl(vm));
+
+ do {
+ struct i915_page_directory * const pdp =
+ gen8_pdp_for_page_address(vm, start);
+ struct i915_page_directory * const pd =
+ i915_pd_entry(pdp, __gen8_pte_index(start, 2));
+ struct i915_page_table *pt =
+ i915_pt_entry(pd, __gen8_pte_index(start, 1));
+ gen8_pte_t encode = pte_encode;
+ unsigned int page_size;
+ gen8_pte_t *vaddr;
+ u16 index, max;
+
+ max = I915_PDES;
+
+ if (vma_res->bi.page_sizes.sg & I915_GTT_PAGE_SIZE_2M &&
+ IS_ALIGNED(iter->dma, I915_GTT_PAGE_SIZE_2M) &&
+ rem >= I915_GTT_PAGE_SIZE_2M &&
+ !__gen8_pte_index(start, 0)) {
+ index = __gen8_pte_index(start, 1);
+ encode |= GEN8_PDE_PS_2M;
+ page_size = I915_GTT_PAGE_SIZE_2M;
+
+ vaddr = px_vaddr(pd);
+ } else {
+ if (encode & GEN12_PPGTT_PTE_LM) {
+ GEM_BUG_ON(__gen8_pte_index(start, 0) % 16);
+ GEM_BUG_ON(rem < I915_GTT_PAGE_SIZE_64K);
+ GEM_BUG_ON(!IS_ALIGNED(iter->dma,
+ I915_GTT_PAGE_SIZE_64K));
+
+ index = __gen8_pte_index(start, 0) / 16;
+ page_size = I915_GTT_PAGE_SIZE_64K;
+
+ max /= 16;
+
+ vaddr = px_vaddr(pd);
+ vaddr[__gen8_pte_index(start, 1)] |= GEN12_PDE_64K;
+
+ pt->is_compact = true;
+ } else {
+ GEM_BUG_ON(pt->is_compact);
+ index = __gen8_pte_index(start, 0);
+ page_size = I915_GTT_PAGE_SIZE;
+ }
+
+ vaddr = px_vaddr(pt);
+ }
+
+ do {
+ GEM_BUG_ON(rem < page_size);
+ vaddr[index++] = encode | iter->dma;
+
+ start += page_size;
+ iter->dma += page_size;
+ rem -= page_size;
+ if (iter->dma >= iter->max) {
+ iter->sg = __sg_next(iter->sg);
+ if (!iter->sg)
+ break;
+
+ rem = sg_dma_len(iter->sg);
+ if (!rem)
+ break;
+
+ iter->dma = sg_dma_address(iter->sg);
+ iter->max = iter->dma + rem;
+
+ if (unlikely(!IS_ALIGNED(iter->dma, page_size)))
+ break;
+ }
+ } while (rem >= page_size && index < max);
+
+ vma_res->page_sizes_gtt |= page_size;
+ } while (iter->sg && sg_dma_len(iter->sg));
+}
+
static void gen8_ppgtt_insert_huge(struct i915_address_space *vm,
struct i915_vma_resource *vma_res,
struct sgt_dma *iter,
@@ -586,7 +685,10 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
+ if (HAS_64K_PAGES(vm->i915))
+ xehpsdv_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
+ else
+ gen8_ppgtt_insert_huge(vm, vma_res, &iter, cache_level, flags);
} else {
u64 idx = vma_res->start >> GEN8_PTE_SHIFT;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 6cd518a3277c..5e038cef0d9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -92,6 +92,8 @@ typedef u64 gen8_pte_t;
#define GEN12_GGTT_PTE_LM BIT_ULL(1)
+#define GEN12_PDE_64K BIT(6)
+
/*
* Cacheability Control is a 4-bit value. The low three bits are stored in bits
* 3:1 of the PTE, while the fourth bit is stored in bit 11 of the PTE.
@@ -160,6 +162,7 @@ struct i915_page_table {
atomic_t used;
struct i915_page_table *stash;
};
+ bool is_compact;
};
struct i915_page_directory {
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 48e6e2f87700..043652dc6892 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -26,6 +26,7 @@ struct i915_page_table *alloc_pt(struct i915_address_space *vm)
return ERR_PTR(-ENOMEM);
}
+ pt->is_compact = false;
atomic_set(&pt->used, 0);
return pt;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 4/5] drm/i915: add gtt misalignment test
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
(?)
@ 2022-02-08 20:34 ` Robert Beckett
-1 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Robert Beckett, Thomas Hellström, kernel test robot,
intel-gfx, linux-kernel, dri-devel
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot <lkp@intel.com>
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* handle stolen smem region returning -ENODEV due to
uninitialized on some setups
* avoid trying to test bad alignments on single page hole regions
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 126 ++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..4de86e0f33e4 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include <linux/list_sort.h>
#include <linux/prime_numbers.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,118 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+ bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj)) {
+ /* if iGVT-g or DMAR is active, stolen mem will be uninitialized */
+ if (PTR_ERR(obj) == -ENODEV && is_stolen)
+ return 0;
+ return PTR_ERR(obj);
+ }
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(&vma->node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 << (ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* compact-pt should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size != expected_node_size) {
+ err = i915_vma_unbind_unlocked(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind_unlocked(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, (enum intel_memory_type)id);
+ u64 size = min_alignment;
+ u64 addr = round_down(hole_start + (hole_size / 2), min_alignment);
+
+ /* avoid -ENOSPC on very small hole setups */
+ if (hole_size < 3 * min_alignment)
+ continue;
+
+ /* we can't test < 4k alignment due to flags being encoded in lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment / 2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int exercise_ppgtt(struct drm_i915_private *dev_priv,
int (*func)(struct i915_address_space *vm,
u64 hole_start, u64 hole_end,
@@ -1136,6 +1250,11 @@ static int igt_ppgtt_shrink_boom(void *arg)
return exercise_ppgtt(arg, shrink_boom);
}
+static int igt_ppgtt_misaligned_pin(void *arg)
+{
+ return exercise_ppgtt(arg, misaligned_pin);
+}
+
static int sort_holes(void *priv, const struct list_head *A,
const struct list_head *B)
{
@@ -1208,6 +1327,11 @@ static int igt_ggtt_lowlevel(void *arg)
return exercise_ggtt(arg, lowlevel_hole);
}
+static int igt_ggtt_misaligned_pin(void *arg)
+{
+ return exercise_ggtt(arg, misaligned_pin);
+}
+
static int igt_ggtt_page(void *arg)
{
const unsigned int count = PAGE_SIZE/sizeof(u32);
@@ -2180,12 +2304,14 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_ppgtt_fill),
SUBTEST(igt_ppgtt_shrink),
SUBTEST(igt_ppgtt_shrink_boom),
+ SUBTEST(igt_ppgtt_misaligned_pin),
SUBTEST(igt_ggtt_lowlevel),
SUBTEST(igt_ggtt_drunk),
SUBTEST(igt_ggtt_walk),
SUBTEST(igt_ggtt_pot),
SUBTEST(igt_ggtt_fill),
SUBTEST(igt_ggtt_page),
+ SUBTEST(igt_ggtt_misaligned_pin),
SUBTEST(igt_cs_tlb),
};
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [Intel-gfx] [PATCH v8 4/5] drm/i915: add gtt misalignment test
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Thomas Hellström, intel-gfx, linux-kernel, dri-devel
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot <lkp@intel.com>
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* handle stolen smem region returning -ENODEV due to
uninitialized on some setups
* avoid trying to test bad alignments on single page hole regions
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 126 ++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..4de86e0f33e4 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include <linux/list_sort.h>
#include <linux/prime_numbers.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,118 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+ bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj)) {
+ /* if iGVT-g or DMAR is active, stolen mem will be uninitialized */
+ if (PTR_ERR(obj) == -ENODEV && is_stolen)
+ return 0;
+ return PTR_ERR(obj);
+ }
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(&vma->node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 << (ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* compact-pt should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size != expected_node_size) {
+ err = i915_vma_unbind_unlocked(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind_unlocked(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, (enum intel_memory_type)id);
+ u64 size = min_alignment;
+ u64 addr = round_down(hole_start + (hole_size / 2), min_alignment);
+
+ /* avoid -ENOSPC on very small hole setups */
+ if (hole_size < 3 * min_alignment)
+ continue;
+
+ /* we can't test < 4k alignment due to flags being encoded in lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment / 2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int exercise_ppgtt(struct drm_i915_private *dev_priv,
int (*func)(struct i915_address_space *vm,
u64 hole_start, u64 hole_end,
@@ -1136,6 +1250,11 @@ static int igt_ppgtt_shrink_boom(void *arg)
return exercise_ppgtt(arg, shrink_boom);
}
+static int igt_ppgtt_misaligned_pin(void *arg)
+{
+ return exercise_ppgtt(arg, misaligned_pin);
+}
+
static int sort_holes(void *priv, const struct list_head *A,
const struct list_head *B)
{
@@ -1208,6 +1327,11 @@ static int igt_ggtt_lowlevel(void *arg)
return exercise_ggtt(arg, lowlevel_hole);
}
+static int igt_ggtt_misaligned_pin(void *arg)
+{
+ return exercise_ggtt(arg, misaligned_pin);
+}
+
static int igt_ggtt_page(void *arg)
{
const unsigned int count = PAGE_SIZE/sizeof(u32);
@@ -2180,12 +2304,14 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_ppgtt_fill),
SUBTEST(igt_ppgtt_shrink),
SUBTEST(igt_ppgtt_shrink_boom),
+ SUBTEST(igt_ppgtt_misaligned_pin),
SUBTEST(igt_ggtt_lowlevel),
SUBTEST(igt_ggtt_drunk),
SUBTEST(igt_ggtt_walk),
SUBTEST(igt_ggtt_pot),
SUBTEST(igt_ggtt_fill),
SUBTEST(igt_ggtt_page),
+ SUBTEST(igt_ggtt_misaligned_pin),
SUBTEST(igt_cs_tlb),
};
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 4/5] drm/i915: add gtt misalignment test
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Robert Beckett, kernel test robot, Thomas Hellström,
intel-gfx, dri-devel, linux-kernel
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot <lkp@intel.com>
v6:
* use NEEDS_COMPACT_PT instead of hard coding for DG2
v7:
* use i915_vma_unbind_unlocked in misalignment test
v8:
* handle stolen smem region returning -ENODEV due to
uninitialized on some setups
* avoid trying to test bad alignments on single page hole regions
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 126 ++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..4de86e0f33e4 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include <linux/list_sort.h>
#include <linux/prime_numbers.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,118 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+ bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj)) {
+ /* if iGVT-g or DMAR is active, stolen mem will be uninitialized */
+ if (PTR_ERR(obj) == -ENODEV && is_stolen)
+ return 0;
+ return PTR_ERR(obj);
+ }
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(&vma->node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 << (ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (NEEDS_COMPACT_PT(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* compact-pt should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size != expected_node_size) {
+ err = i915_vma_unbind_unlocked(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind_unlocked(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, (enum intel_memory_type)id);
+ u64 size = min_alignment;
+ u64 addr = round_down(hole_start + (hole_size / 2), min_alignment);
+
+ /* avoid -ENOSPC on very small hole setups */
+ if (hole_size < 3 * min_alignment)
+ continue;
+
+ /* we can't test < 4k alignment due to flags being encoded in lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment / 2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int exercise_ppgtt(struct drm_i915_private *dev_priv,
int (*func)(struct i915_address_space *vm,
u64 hole_start, u64 hole_end,
@@ -1136,6 +1250,11 @@ static int igt_ppgtt_shrink_boom(void *arg)
return exercise_ppgtt(arg, shrink_boom);
}
+static int igt_ppgtt_misaligned_pin(void *arg)
+{
+ return exercise_ppgtt(arg, misaligned_pin);
+}
+
static int sort_holes(void *priv, const struct list_head *A,
const struct list_head *B)
{
@@ -1208,6 +1327,11 @@ static int igt_ggtt_lowlevel(void *arg)
return exercise_ggtt(arg, lowlevel_hole);
}
+static int igt_ggtt_misaligned_pin(void *arg)
+{
+ return exercise_ggtt(arg, misaligned_pin);
+}
+
static int igt_ggtt_page(void *arg)
{
const unsigned int count = PAGE_SIZE/sizeof(u32);
@@ -2180,12 +2304,14 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private *i915)
SUBTEST(igt_ppgtt_fill),
SUBTEST(igt_ppgtt_shrink),
SUBTEST(igt_ppgtt_shrink_boom),
+ SUBTEST(igt_ppgtt_misaligned_pin),
SUBTEST(igt_ggtt_lowlevel),
SUBTEST(igt_ggtt_drunk),
SUBTEST(igt_ggtt_walk),
SUBTEST(igt_ggtt_pot),
SUBTEST(igt_ggtt_fill),
SUBTEST(igt_ggtt_page),
+ SUBTEST(igt_ggtt_misaligned_pin),
SUBTEST(igt_cs_tlb),
};
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
(?)
@ 2022-02-08 20:34 ` Robert Beckett
-1 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Robert Beckett, Thomas Hellström, dri-devel, Jordan Justen,
intel-gfx, Kenneth Graunke, Tony Ye, Slawomir Milczarek,
Matthew Auld, mesa-dev, linux-kernel
From: Matthew Auld <matthew.auld@intel.com>
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
cc: Simon Ser <contact@emersion.fr>
cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye <tony.ye@intel.com>
Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
---
include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+ *
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+ *
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+ *
+ * See struct drm_i915_gem_create_ext for the rules when dealing with
+ * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+ * minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
- * Note that for some devices we have might have further minimum
- * page-size restrictions(larger than 4K), like for device local-memory.
- * However in general the final size here should always reflect any
- * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
- * extension to place the object in device local-memory.
+ *
+ * DG2 64K min page size implications:
+ *
+ * On discrete platforms, starting from DG2, we have to contend with GTT
+ * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+ * objects. Specifically the hardware only supports 64K or larger GTT
+ * page sizes for such memory. The kernel will already ensure that all
+ * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+ * sizes underneath.
+ *
+ * Note that the returned size here will always reflect any required
+ * rounding up done by the kernel, i.e 4K will now become 64K on devices
+ * such as DG2.
+ *
+ * Special DG2 GTT address alignment requirement:
+ *
+ * The GTT alignment will also need to be at least 2M for such objects.
+ *
+ * Note that due to how the hardware implements 64K GTT page support, we
+ * have some further complications:
+ *
+ * 1) The entire PDE (which covers a 2MB virtual address range), must
+ * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+ * PDE is forbidden by the hardware.
+ *
+ * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+ * objects.
+ *
+ * To keep things simple for userland, we mandate that any GTT mappings
+ * must be aligned to and rounded up to 2MB. As this only wastes virtual
+ * address space and avoids userland having to copy any needlessly
+ * complicated PDE sharing scheme (coloring) and only affects DG2, this
+ * is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Thomas Hellström, dri-devel, intel-gfx, Kenneth Graunke,
Slawomir Milczarek, Pekka Paalanen, Matthew Auld, Simon Ser,
mesa-dev, linux-kernel
From: Matthew Auld <matthew.auld@intel.com>
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
cc: Simon Ser <contact@emersion.fr>
cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye <tony.ye@intel.com>
Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
---
include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+ *
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+ *
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+ *
+ * See struct drm_i915_gem_create_ext for the rules when dealing with
+ * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+ * minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
- * Note that for some devices we have might have further minimum
- * page-size restrictions(larger than 4K), like for device local-memory.
- * However in general the final size here should always reflect any
- * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
- * extension to place the object in device local-memory.
+ *
+ * DG2 64K min page size implications:
+ *
+ * On discrete platforms, starting from DG2, we have to contend with GTT
+ * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+ * objects. Specifically the hardware only supports 64K or larger GTT
+ * page sizes for such memory. The kernel will already ensure that all
+ * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+ * sizes underneath.
+ *
+ * Note that the returned size here will always reflect any required
+ * rounding up done by the kernel, i.e 4K will now become 64K on devices
+ * such as DG2.
+ *
+ * Special DG2 GTT address alignment requirement:
+ *
+ * The GTT alignment will also need to be at least 2M for such objects.
+ *
+ * Note that due to how the hardware implements 64K GTT page support, we
+ * have some further complications:
+ *
+ * 1) The entire PDE (which covers a 2MB virtual address range), must
+ * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+ * PDE is forbidden by the hardware.
+ *
+ * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+ * objects.
+ *
+ * To keep things simple for userland, we mandate that any GTT mappings
+ * must be aligned to and rounded up to 2MB. As this only wastes virtual
+ * address space and avoids userland having to copy any needlessly
+ * complicated PDE sharing scheme (coloring) and only affects DG2, this
+ * is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-08 20:34 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-08 20:34 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter
Cc: Matthew Auld, Ramalingam C, Robert Beckett, Jordan Justen,
Thomas Hellström, Simon Ser, Pekka Paalanen,
Kenneth Graunke, mesa-dev, Tony Ye, Slawomir Milczarek,
intel-gfx, dri-devel, linux-kernel
From: Matthew Auld <matthew.auld@intel.com>
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
cc: Simon Ser <contact@emersion.fr>
cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye <tony.ye@intel.com>
Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
---
include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+ *
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+ *
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+ *
+ * See struct drm_i915_gem_create_ext for the rules when dealing with
+ * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+ * minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
- * Note that for some devices we have might have further minimum
- * page-size restrictions(larger than 4K), like for device local-memory.
- * However in general the final size here should always reflect any
- * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
- * extension to place the object in device local-memory.
+ *
+ * DG2 64K min page size implications:
+ *
+ * On discrete platforms, starting from DG2, we have to contend with GTT
+ * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+ * objects. Specifically the hardware only supports 64K or larger GTT
+ * page sizes for such memory. The kernel will already ensure that all
+ * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+ * sizes underneath.
+ *
+ * Note that the returned size here will always reflect any required
+ * rounding up done by the kernel, i.e 4K will now become 64K on devices
+ * such as DG2.
+ *
+ * Special DG2 GTT address alignment requirement:
+ *
+ * The GTT alignment will also need to be at least 2M for such objects.
+ *
+ * Note that due to how the hardware implements 64K GTT page support, we
+ * have some further complications:
+ *
+ * 1) The entire PDE (which covers a 2MB virtual address range), must
+ * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+ * PDE is forbidden by the hardware.
+ *
+ * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+ * objects.
+ *
+ * To keep things simple for userland, we mandate that any GTT mappings
+ * must be aligned to and rounded up to 2MB. As this only wastes virtual
+ * address space and avoids userland having to copy any needlessly
+ * complicated PDE sharing scheme (coloring) and only affects DG2, this
+ * is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for discrete card 64K page support (rev6)
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
` (5 preceding siblings ...)
(?)
@ 2022-02-08 22:06 ` Patchwork
-1 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2022-02-08 22:06 UTC (permalink / raw)
To: Robert Beckett; +Cc: intel-gfx
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3661cc75d2f0 drm/i915: add needs_compact_pt flag
d28e89eb3a6f drm/i915: enforce min GTT alignment for discrete cards
-:304: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#304: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:457:
+ if (offset < hole_start + aligned_size)
-:316: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#316: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:481:
+ if (offset + aligned_size > hole_end)
-:334: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#334: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:497:
+ if (offset < hole_start + aligned_size)
-:346: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#346: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:520:
+ if (offset + aligned_size > hole_end)
-:364: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#364: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:536:
+ if (offset < hole_start + aligned_size)
-:376: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#376: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:560:
+ if (offset + aligned_size > hole_end)
-:394: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#394: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:576:
+ if (offset < hole_start + aligned_size)
-:406: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring
#406: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:599:
+ if (offset + aligned_size > hole_end)
total: 0 errors, 8 warnings, 0 checks, 438 lines checked
7c4419b395e6 drm/i915: support 64K GTT pages for discrete cards
821eba08b7a4 drm/i915: add gtt misalignment test
266421b1e797 drm/i915/uapi: document behaviour for DG2 64K support
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for discrete card 64K page support (rev6)
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
` (6 preceding siblings ...)
(?)
@ 2022-02-08 22:07 ` Patchwork
-1 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2022-02-08 22:07 UTC (permalink / raw)
To: Robert Beckett; +Cc: intel-gfx
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for discrete card 64K page support (rev6)
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
` (7 preceding siblings ...)
(?)
@ 2022-02-08 22:39 ` Patchwork
-1 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2022-02-08 22:39 UTC (permalink / raw)
To: Robert Beckett; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 7589 bytes --]
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11205 -> Patchwork_22213
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/index.html
Participating hosts (46 -> 41)
------------------------------
Missing (5): shard-tglu fi-bsw-cyan fi-icl-u2 fi-pnv-d510 bat-jsl-2
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22213:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@workarounds:
- {bat-adlp-6}: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-adlp-6/igt@i915_selftest@live@workarounds.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/bat-adlp-6/igt@i915_selftest@live@workarounds.html
Known issues
------------
Here are the changes found in Patchwork_22213 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#109315]) +17 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-hsw-4770/igt@amdgpu/amd_basic@semaphore.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@gem_lmem_swapping@verify-random.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick: [PASS][6] -> [INCOMPLETE][7] ([i915#2940])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-bsw-nick/igt@i915_selftest@live@execlists.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-bsw-nick/igt@i915_selftest@live@execlists.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_chamelium@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271]) +2 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][10] -> [DMESG-WARN][11] ([i915#4269])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [FAIL][13] ([i915#4547])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-bsw-nick: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#1436] / [i915#3428] / [i915#4312])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-bsw-nick/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [FAIL][15] ([i915#4547]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770: [INCOMPLETE][17] ([i915#4785]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
#### Warnings ####
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][19] -> [DMESG-WARN][20] ([i915#1610])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/fi-apl-guc/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][21] ([i915#4957]) -> [DMESG-FAIL][22] ([i915#4494] / [i915#4957])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/bat-dg1-5/igt@i915_selftest@live@hangcheck.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/bat-dg1-5/igt@i915_selftest@live@hangcheck.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#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* Linux: CI_DRM_11205 -> Patchwork_22213
CI-20190529: 20190529
CI_DRM_11205: 9999c764a7571bebed03bec481d6fffcb23144fe @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22213: 266421b1e797bf464b9796ac6a91b5d1c3af95d5 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
266421b1e797 drm/i915/uapi: document behaviour for DG2 64K support
821eba08b7a4 drm/i915: add gtt misalignment test
7c4419b395e6 drm/i915: support 64K GTT pages for discrete cards
d28e89eb3a6f drm/i915: enforce min GTT alignment for discrete cards
3661cc75d2f0 drm/i915: add needs_compact_pt flag
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/index.html
[-- Attachment #2: Type: text/html, Size: 8981 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for discrete card 64K page support (rev6)
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
` (8 preceding siblings ...)
(?)
@ 2022-02-09 0:33 ` Patchwork
2022-02-15 14:35 ` Robert Beckett
-1 siblings, 1 reply; 37+ messages in thread
From: Patchwork @ 2022-02-09 0:33 UTC (permalink / raw)
To: Robert Beckett; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30260 bytes --]
== Series Details ==
Series: discrete card 64K page support (rev6)
URL : https://patchwork.freedesktop.org/series/99119/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22213_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_22213_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22213_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22213_full:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@mock@vma:
- shard-skl: NOTRUN -> [INCOMPLETE][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@i915_selftest@mock@vma.html
* igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-iclb: [PASS][2] -> [INCOMPLETE][3]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_cursor_legacy@pipe-c-torture-bo.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb6/igt@kms_cursor_legacy@pipe-c-torture-bo.html
* igt@syncobj_timeline@invalid-transfer-non-existent-point:
- shard-skl: NOTRUN -> [DMESG-WARN][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@syncobj_timeline@invalid-transfer-non-existent-point.html
Known issues
------------
Here are the changes found in Patchwork_22213_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#1839])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@feature_discovery@display-4x.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +2 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl7/igt@gem_ctx_isolation@preservation-s3@bcs0.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl6/igt@gem_ctx_isolation@preservation-s3@bcs0.html
* igt@gem_exec_capture@pi@rcs0:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#3371])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_exec_capture@pi@rcs0.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb2/igt@gem_exec_capture@pi@rcs0.html
* igt@gem_exec_capture@pi@vcs0:
- shard-iclb: [PASS][10] -> [INCOMPLETE][11] ([i915#3371])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb1/igt@gem_exec_capture@pi@vcs0.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@gem_exec_capture@pi@vcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: NOTRUN -> [FAIL][12] ([i915#2846])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@gem_exec_fair@basic-deadline.html
- shard-skl: NOTRUN -> [FAIL][13] ([i915#2846])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@gem_exec_fair@basic-deadline.html
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2846])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk1/igt@gem_exec_fair@basic-deadline.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk4/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) +2 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_exec_fair@basic-flow@rcs0.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb7/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2842])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109283])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_exec_params@no-vebox.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@gem_lmem_swapping@heavy-verify-random.html
* igt@gem_lmem_swapping@random-engines:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#4613])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_lmem_swapping@random-engines.html
* igt@gem_lmem_swapping@verify-random:
- shard-apl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@gem_lmem_swapping@verify-random.html
* igt@gem_pxp@create-protected-buffer:
- shard-iclb: NOTRUN -> [SKIP][23] ([i915#4270]) +1 similar issue
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@gem_pxp@create-protected-buffer.html
* igt@gem_pxp@fail-invalid-protected-context:
- shard-tglb: NOTRUN -> [SKIP][24] ([i915#4270])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@gem_pxp@fail-invalid-protected-context.html
* igt@gem_render_copy@yf-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][25] ([i915#768]) +1 similar issue
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_render_copy@yf-tiled-to-vebox-linear.html
* igt@gem_softpin@evict-snoop-interruptible:
- shard-tglb: NOTRUN -> [SKIP][26] ([fdo#109312])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@gem_softpin@evict-snoop-interruptible.html
* igt@gem_userptr_blits@readonly-pwrite-unsync:
- shard-iclb: NOTRUN -> [SKIP][27] ([i915#3297])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_userptr_blits@readonly-pwrite-unsync.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][28] -> [DMESG-WARN][29] ([i915#180]) +2 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-apl8/igt@gem_workarounds@suspend-resume-context.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@gem_workarounds@suspend-resume-context.html
* igt@gen9_exec_parse@batch-zero-length:
- shard-iclb: NOTRUN -> [SKIP][30] ([i915#2856])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gen9_exec_parse@batch-zero-length.html
* igt@gen9_exec_parse@valid-registers:
- shard-tglb: NOTRUN -> [SKIP][31] ([i915#2527] / [i915#2856])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@gen9_exec_parse@valid-registers.html
* igt@i915_pm_rpm@pc8-residency:
- shard-iclb: NOTRUN -> [SKIP][32] ([fdo#109293] / [fdo#109506])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@i915_pm_rpm@pc8-residency.html
* igt@kms_big_fb@linear-32bpp-rotate-180:
- shard-glk: [PASS][33] -> [DMESG-WARN][34] ([i915#118])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk8/igt@kms_big_fb@linear-32bpp-rotate-180.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk3/igt@kms_big_fb@linear-32bpp-rotate-180.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][35] ([fdo#110725] / [fdo#111614]) +1 similar issue
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_big_fb@x-tiled-64bpp-rotate-270.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][36] ([i915#3743])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-kbl: NOTRUN -> [SKIP][37] ([fdo#109271] / [i915#3777]) +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl4/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][38] ([fdo#109271] / [i915#3777])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl4/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-skl: NOTRUN -> [SKIP][39] ([fdo#109271] / [i915#3777]) +3 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
- shard-tglb: NOTRUN -> [SKIP][40] ([fdo#111615])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-kbl: NOTRUN -> [SKIP][41] ([fdo#109271] / [i915#3886]) +5 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl4/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][42] ([i915#3689] / [i915#3886])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][43] ([i915#3689]) +1 similar issue
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
- shard-iclb: NOTRUN -> [SKIP][44] ([fdo#109278] / [i915#3886]) +3 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][45] ([fdo#109271] / [i915#3886]) +4 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl4/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-skl: NOTRUN -> [SKIP][46] ([fdo#109271] / [i915#3886]) +6 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][47] ([fdo#109271]) +205 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium@hdmi-hpd-for-each-pipe:
- shard-apl: NOTRUN -> [SKIP][48] ([fdo#109271] / [fdo#111827]) +2 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@kms_chamelium@hdmi-hpd-for-each-pipe.html
* igt@kms_color@pipe-d-ctm-0-25:
- shard-iclb: NOTRUN -> [SKIP][49] ([fdo#109278] / [i915#1149])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_color@pipe-d-ctm-0-25.html
* igt@kms_color_chamelium@pipe-a-ctm-0-75:
- shard-tglb: NOTRUN -> [SKIP][50] ([fdo#109284] / [fdo#111827]) +4 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_color_chamelium@pipe-a-ctm-0-75.html
* igt@kms_color_chamelium@pipe-c-ctm-0-5:
- shard-iclb: NOTRUN -> [SKIP][51] ([fdo#109284] / [fdo#111827]) +6 similar issues
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_color_chamelium@pipe-c-ctm-0-5.html
* igt@kms_color_chamelium@pipe-c-gamma:
- shard-kbl: NOTRUN -> [SKIP][52] ([fdo#109271] / [fdo#111827]) +6 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@kms_color_chamelium@pipe-c-gamma.html
* igt@kms_color_chamelium@pipe-d-ctm-0-25:
- shard-skl: NOTRUN -> [SKIP][53] ([fdo#109271] / [fdo#111827]) +8 similar issues
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@kms_color_chamelium@pipe-d-ctm-0-25.html
* igt@kms_content_protection@mei_interface:
- shard-tglb: NOTRUN -> [SKIP][54] ([i915#1063])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_content_protection@mei_interface.html
* igt@kms_cursor_crc@pipe-b-cursor-32x10-random:
- shard-kbl: NOTRUN -> [SKIP][55] ([fdo#109271]) +66 similar issues
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@kms_cursor_crc@pipe-b-cursor-32x10-random.html
* igt@kms_cursor_crc@pipe-b-cursor-512x512-rapid-movement:
- shard-tglb: NOTRUN -> [SKIP][56] ([fdo#109279] / [i915#3359]) +1 similar issue
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_cursor_crc@pipe-b-cursor-512x512-rapid-movement.html
* igt@kms_cursor_crc@pipe-c-cursor-32x32-random:
- shard-tglb: NOTRUN -> [SKIP][57] ([i915#3319])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_cursor_crc@pipe-c-cursor-32x32-random.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-iclb: NOTRUN -> [SKIP][58] ([fdo#109274] / [fdo#109278]) +2 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-iclb: NOTRUN -> [FAIL][59] ([i915#2346])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-iclb: [PASS][60] -> [FAIL][61] ([i915#2346])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_dsc@xrgb8888-dsc-compression:
- shard-iclb: NOTRUN -> [SKIP][62] ([i915#3828])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_dsc@xrgb8888-dsc-compression.html
* igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
- shard-tglb: NOTRUN -> [SKIP][63] ([fdo#109274] / [fdo#111825]) +1 similar issue
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html
* igt@kms_flip@2x-flip-vs-rmfb-interruptible:
- shard-iclb: NOTRUN -> [SKIP][64] ([fdo#109274]) +3 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_flip@2x-flip-vs-rmfb-interruptible.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling:
- shard-glk: [PASS][65] -> [FAIL][66] ([i915#4911]) +1 similar issue
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
* igt@kms_force_connector_basic@force-load-detect:
- shard-tglb: NOTRUN -> [SKIP][67] ([fdo#109285])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack-mmap-gtt:
- shard-iclb: NOTRUN -> [SKIP][68] ([fdo#109280]) +17 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu:
- shard-tglb: NOTRUN -> [SKIP][69] ([fdo#109280] / [fdo#111825]) +7 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][70] -> [FAIL][71] ([i915#1188])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl8/igt@kms_hdr@bpc-switch-suspend.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl4/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_hdr@static-toggle:
- shard-tglb: NOTRUN -> [SKIP][72] ([i915#1187])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_hdr@static-toggle.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-kbl: NOTRUN -> [DMESG-WARN][73] ([i915#180])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-kbl: NOTRUN -> [FAIL][74] ([fdo#108145] / [i915#265])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl3/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: NOTRUN -> [FAIL][75] ([fdo#108145] / [i915#265]) +2 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][76] -> [FAIL][77] ([fdo#108145] / [i915#265])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max:
- shard-iclb: NOTRUN -> [SKIP][78] ([fdo#109278]) +20 similar issues
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area:
- shard-iclb: NOTRUN -> [SKIP][79] ([fdo#111068] / [i915#658])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_psr2_sf@plane-move-sf-dmg-area.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-skl: NOTRUN -> [SKIP][80] ([fdo#109271] / [i915#658])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
* igt@kms_psr2_su@page_flip-xrgb8888:
- shard-tglb: NOTRUN -> [SKIP][81] ([i915#1911])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_psr2_su@page_flip-xrgb8888.html
* igt@kms_psr@psr2_primary_blt:
- shard-iclb: [PASS][82] -> [SKIP][83] ([fdo#109441])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_psr@psr2_primary_blt.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_psr@psr2_primary_blt.html
* igt@kms_tv_load_detect@load-detect:
- shard-iclb: NOTRUN -> [SKIP][84] ([fdo#109309])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_tv_load_detect@load-detect.html
* igt@kms_vrr@flip-dpms:
- shard-tglb: NOTRUN -> [SKIP][85] ([fdo#109502])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_vrr@flip-dpms.html
* igt@kms_writeback@writeback-check-output:
- shard-iclb: NOTRUN -> [SKIP][86] ([i915#2437]) +1 similar issue
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@kms_writeback@writeback-check-output.html
* igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame:
- shard-apl: NOTRUN -> [SKIP][87] ([fdo#109271]) +35 similar issues
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame.html
* igt@perf_pmu@event-wait@rcs0:
- shard-tglb: NOTRUN -> [SKIP][88] ([fdo#112283])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@perf_pmu@event-wait@rcs0.html
* igt@prime_nv_api@i915_nv_import_twice_check_flink_name:
- shard-iclb: NOTRUN -> [SKIP][89] ([fdo#109291]) +1 similar issue
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@prime_nv_api@i915_nv_import_twice_check_flink_name.html
* igt@prime_nv_api@nv_i915_import_twice_check_flink_name:
- shard-tglb: NOTRUN -> [SKIP][90] ([fdo#109291])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@prime_nv_api@nv_i915_import_twice_check_flink_name.html
* igt@sysfs_clients@busy:
- shard-iclb: NOTRUN -> [SKIP][91] ([i915#2994])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@sysfs_clients@busy.html
* igt@sysfs_clients@create:
- shard-skl: NOTRUN -> [SKIP][92] ([fdo#109271] / [i915#2994]) +2 similar issues
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@sysfs_clients@create.html
* igt@sysfs_clients@fair-3:
- shard-kbl: NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#2994]) +1 similar issue
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl3/igt@sysfs_clients@fair-3.html
#### Possible fixes ####
* igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [TIMEOUT][94] ([i915#3063]) -> [PASS][95]
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb5/igt@gem_eio@in-flight-contexts-immediate.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb3/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][96] ([i915#2842]) -> [PASS][97] +2 similar issues
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl3/igt@gem_exec_fair@basic-none@vcs0.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl6/igt@gem_exec_fair@basic-none@vcs0.html
* igt@i915_selftest@live@gtt:
- shard-skl: [DMESG-FAIL][98] -> [PASS][99]
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl3/igt@i915_selftest@live@gtt.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@i915_selftest@live@gtt.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [DMESG-WARN][100] ([i915#180]) -> [PASS][101] +1 similar issue
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-apl8/igt@i915_suspend@sysfs-reader.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@i915_suspend@sysfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-tglb: [INCOMPLETE][102] ([i915#2411] / [i915#2828] / [i915#456]) -> [PASS][103]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl: [FAIL][104] ([i915#2346]) -> [PASS][105]
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-skl: [FAIL][106] ([i915#2346] / [i915#533]) -> [PASS][107]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2:
- shard-glk: [FAIL][108] ([i915#79]) -> [PASS][109] +1 similar issue
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk2/igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk7/igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling:
- shard-iclb: [SKIP][110] ([i915#3701]) -> [PASS][111]
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [FAIL][112] ([i915#1188]) -> [PASS][113]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl1/igt@kms_hdr@bpc-switch.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl7/igt@kms_hdr@bpc-switch.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [DMESG-WARN][114] ([i915#180]) -> [PASS][115] +2 similar issues
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [SKIP][116] ([fdo#109441]) -> [PASS][117] +1 similar issue
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
* igt@perf@non-zero-reason:
- shard-glk: [FAIL][118] -> [PASS][119]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk1/igt@perf@non-zero-reason.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk4/igt@perf@non-zero-reason.html
#### Warnings ####
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [SKIP][120] ([i915#4525]) -> [DMESG-WARN][121] ([i915#5076])
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb6/igt@gem_exec_balancer@parallel-keep-in-fence.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb4/igt@gem_exec_balancer@parallel-keep-in-fence.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [DMESG-FAIL][122] -> [SKIP][123] ([i915#4525])
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb4/igt@gem_exec_balancer@parallel-ordering.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_exec_balancer@parallel-ordering.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [DMESG-WARN][124] ([i915#5076]) -> [SKIP][125] ([i915#4525]) +1 similar issue
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@gem_exec_balancer@parallel-out-fence.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_exec_balancer@parallel-out-fence.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][126] ([i915#1804] / [i915#2684]) -> [WARN][127] ([i915#2684])
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb7/igt@i915_pm_rc6_residency@rc6-fence.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb1/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: [WARN][128] ([i915#2684]) -> [WARN][129] ([i915#1804] / [i915#2684])
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb1/igt@i915_pm_rc6_residency@rc6-idle.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@i915_pm_rc6_residency@rc6-idle.html
* igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
- shard-iclb: [SKIP][130] ([fdo#111068] / [i915#658]) -> [SKIP][131] ([i915#2920])
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb3/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
* igt@kms_psr2_su@page_flip-xrgb8888:
- shard-iclb: [SKIP][132] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [FAIL][133] ([i915#4148])
[132]: https://intel-gfx-ci.
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/index.html
[-- Attachment #2: Type: text/html, Size: 33614 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for discrete card 64K page support (rev6)
2022-02-09 0:33 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2022-02-15 14:35 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-15 14:35 UTC (permalink / raw)
To: intel-gfx, C, Ramalingam
On 09/02/2022 00:33, Patchwork wrote:
> *Patch Details*
> *Series:* discrete card 64K page support (rev6)
> *URL:* https://patchwork.freedesktop.org/series/99119/
> <https://patchwork.freedesktop.org/series/99119/>
> *State:* failure
> *Details:*
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/index.html
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/index.html>
>
>
> CI Bug Log - changes from CI_DRM_11205_full -> Patchwork_22213_full
>
>
> Summary
>
> *FAILURE*
>
> Serious unknown changes coming with Patchwork_22213_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_22213_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
> Participating hosts (11 -> 11)
>
> No changes in participating hosts
>
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in
> Patchwork_22213_full:
>
>
> IGT changes
>
>
> Possible regressions
>
> *
>
> igt@i915_selftest@mock@vma:
>
> o shard-skl: NOTRUN -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@i915_selftest@mock@vma.html>
I am unable to repro this locally.
It appears to be just taking longer than usual.
From the log, it appears to actually finish after ~56s
<7> [358.691983] intel_gt_set_wedged called from
intel_gt_set_wedged_on_fini+0x15/0x40 [i915]
Perhaps just an infrastructure issue?
I can't come up with a scenario where this series causes this hang.
> *
>
> igt@kms_cursor_legacy@pipe-c-torture-bo:
>
> o shard-iclb: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_cursor_legacy@pipe-c-torture-bo.html>
> -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb6/igt@kms_cursor_legacy@pipe-c-torture-bo.html>
This one seems to just be taking longer than usual like the one above.
Locally it takes ~22 seconds but succeeds fine.
Again, nothing to do with this patch series.
> *
>
> igt@syncobj_timeline@invalid-transfer-non-existent-point:
>
> o shard-skl: NOTRUN -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@syncobj_timeline@invalid-transfer-non-existent-point.html>
>
This one is due to upstream commit 270b48bb8da7452b4357d8726933beba72652310
It adds a warning for incorrect chained fences, which this test is
deliberately testing.
This is a test issue, nothing to do with this patch series.
>
> Known issues
>
> Here are the changes found in Patchwork_22213_full that come from known
> issues:
>
>
> IGT changes
>
>
> Issues hit
>
> *
>
> igt@feature_discovery@display-4x:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@feature_discovery@display-4x.html>
> ([i915#1839])
> *
>
> igt@gem_ctx_isolation@preservation-s3@bcs0:
>
> o shard-kbl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl7/igt@gem_ctx_isolation@preservation-s3@bcs0.html>
> -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl6/igt@gem_ctx_isolation@preservation-s3@bcs0.html>
> ([i915#180]) +2 similar issues
> *
>
> igt@gem_exec_capture@pi@rcs0:
>
> o shard-tglb: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_exec_capture@pi@rcs0.html>
> -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb2/igt@gem_exec_capture@pi@rcs0.html>
> ([i915#3371])
> *
>
> igt@gem_exec_capture@pi@vcs0:
>
> o shard-iclb: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb1/igt@gem_exec_capture@pi@vcs0.html>
> -> INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@gem_exec_capture@pi@vcs0.html>
> ([i915#3371])
> *
>
> igt@gem_exec_fair@basic-deadline:
>
> o
>
> shard-kbl: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@gem_exec_fair@basic-deadline.html>
> ([i915#2846])
>
> o
>
> shard-skl: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@gem_exec_fair@basic-deadline.html>
> ([i915#2846])
>
> o
>
> shard-glk: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk1/igt@gem_exec_fair@basic-deadline.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk4/igt@gem_exec_fair@basic-deadline.html>
> ([i915#2846])
>
> *
>
> igt@gem_exec_fair@basic-flow@rcs0:
>
> o shard-tglb: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb6/igt@gem_exec_fair@basic-flow@rcs0.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb7/igt@gem_exec_fair@basic-flow@rcs0.html>
> ([i915#2842]) +2 similar issues
> *
>
> igt@gem_exec_fair@basic-none-share@rcs0:
>
> o shard-iclb: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_exec_fair@basic-none-share@rcs0.html>
> ([i915#2842])
> *
>
> igt@gem_exec_params@no-vebox:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_exec_params@no-vebox.html>
> ([fdo#109283])
> *
>
> igt@gem_lmem_swapping@heavy-verify-random:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@gem_lmem_swapping@heavy-verify-random.html>
> ([fdo#109271] / [i915#4613])
> *
>
> igt@gem_lmem_swapping@random-engines:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_lmem_swapping@random-engines.html>
> ([i915#4613])
> *
>
> igt@gem_lmem_swapping@verify-random:
>
> o shard-apl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@gem_lmem_swapping@verify-random.html>
> ([fdo#109271] / [i915#4613])
> *
>
> igt@gem_pxp@create-protected-buffer:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@gem_pxp@create-protected-buffer.html>
> ([i915#4270]) +1 similar issue
> *
>
> igt@gem_pxp@fail-invalid-protected-context:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@gem_pxp@fail-invalid-protected-context.html>
> ([i915#4270])
> *
>
> igt@gem_render_copy@yf-tiled-to-vebox-linear:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_render_copy@yf-tiled-to-vebox-linear.html>
> ([i915#768]) +1 similar issue
> *
>
> igt@gem_softpin@evict-snoop-interruptible:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@gem_softpin@evict-snoop-interruptible.html>
> ([fdo#109312])
> *
>
> igt@gem_userptr_blits@readonly-pwrite-unsync:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_userptr_blits@readonly-pwrite-unsync.html>
> ([i915#3297])
> *
>
> igt@gem_workarounds@suspend-resume-context:
>
> o shard-apl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-apl8/igt@gem_workarounds@suspend-resume-context.html>
> -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@gem_workarounds@suspend-resume-context.html>
> ([i915#180]) +2 similar issues
> *
>
> igt@gen9_exec_parse@batch-zero-length:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gen9_exec_parse@batch-zero-length.html>
> ([i915#2856])
> *
>
> igt@gen9_exec_parse@valid-registers:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@gen9_exec_parse@valid-registers.html>
> ([i915#2527] / [i915#2856])
> *
>
> igt@i915_pm_rpm@pc8-residency:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@i915_pm_rpm@pc8-residency.html>
> ([fdo#109293] / [fdo#109506])
> *
>
> igt@kms_big_fb@linear-32bpp-rotate-180:
>
> o shard-glk: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk8/igt@kms_big_fb@linear-32bpp-rotate-180.html>
> -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk3/igt@kms_big_fb@linear-32bpp-rotate-180.html>
> ([i915#118])
> *
>
> igt@kms_big_fb@x-tiled-64bpp-rotate-270:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_big_fb@x-tiled-64bpp-rotate-270.html>
> ([fdo#110725] / [fdo#111614]) +1 similar issue
> *
>
> igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
>
> o shard-skl: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html>
> ([i915#3743])
> *
>
> igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
>
> o shard-kbl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl4/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html>
> ([fdo#109271] / [i915#3777]) +1 similar issue
> *
>
> igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
>
> o shard-apl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl4/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html>
> ([fdo#109271] / [i915#3777])
> *
>
> igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html>
> ([fdo#109271] / [i915#3777]) +3 similar issues
> *
>
> igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0.html>
> ([fdo#111615])
> *
>
> igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs:
>
> o shard-kbl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl4/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_mc_ccs.html>
> ([fdo#109271] / [i915#3886]) +5 similar issues
> *
>
> igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html>
> ([i915#3689] / [i915#3886])
> *
>
> igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html>
> ([i915#3689]) +1 similar issue
> *
>
> igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html>
> ([fdo#109278] / [i915#3886]) +3 similar issues
> *
>
> igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
>
> o shard-apl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl4/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html>
> ([fdo#109271] / [i915#3886]) +4 similar issues
> *
>
> igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html>
> ([fdo#109271] / [i915#3886]) +6 similar issues
> *
>
> igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html>
> ([fdo#109271]) +205 similar issues
> *
>
> igt@kms_chamelium@hdmi-hpd-for-each-pipe:
>
> o shard-apl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@kms_chamelium@hdmi-hpd-for-each-pipe.html>
> ([fdo#109271] / [fdo#111827]) +2 similar issues
> *
>
> igt@kms_color@pipe-d-ctm-0-25:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_color@pipe-d-ctm-0-25.html>
> ([fdo#109278] / [i915#1149])
> *
>
> igt@kms_color_chamelium@pipe-a-ctm-0-75:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_color_chamelium@pipe-a-ctm-0-75.html>
> ([fdo#109284] / [fdo#111827]) +4 similar issues
> *
>
> igt@kms_color_chamelium@pipe-c-ctm-0-5:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_color_chamelium@pipe-c-ctm-0-5.html>
> ([fdo#109284] / [fdo#111827]) +6 similar issues
> *
>
> igt@kms_color_chamelium@pipe-c-gamma:
>
> o shard-kbl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@kms_color_chamelium@pipe-c-gamma.html>
> ([fdo#109271] / [fdo#111827]) +6 similar issues
> *
>
> igt@kms_color_chamelium@pipe-d-ctm-0-25:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@kms_color_chamelium@pipe-d-ctm-0-25.html>
> ([fdo#109271] / [fdo#111827]) +8 similar issues
> *
>
> igt@kms_content_protection@mei_interface:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_content_protection@mei_interface.html>
> ([i915#1063])
> *
>
> igt@kms_cursor_crc@pipe-b-cursor-32x10-random:
>
> o shard-kbl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@kms_cursor_crc@pipe-b-cursor-32x10-random.html>
> ([fdo#109271]) +66 similar issues
> *
>
> igt@kms_cursor_crc@pipe-b-cursor-512x512-rapid-movement:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_cursor_crc@pipe-b-cursor-512x512-rapid-movement.html>
> ([fdo#109279] / [i915#3359]) +1 similar issue
> *
>
> igt@kms_cursor_crc@pipe-c-cursor-32x32-random:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_cursor_crc@pipe-c-cursor-32x32-random.html>
> ([i915#3319])
> *
>
> igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html>
> ([fdo#109274] / [fdo#109278]) +2 similar issues
> *
>
> igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
>
> o shard-iclb: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html>
> ([i915#2346])
> *
>
> igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
>
> o shard-iclb: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> ([i915#2346])
> *
>
> igt@kms_dsc@xrgb8888-dsc-compression:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_dsc@xrgb8888-dsc-compression.html>
> ([i915#3828])
> *
>
> igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible.html>
> ([fdo#109274] / [fdo#111825]) +1 similar issue
> *
>
> igt@kms_flip@2x-flip-vs-rmfb-interruptible:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_flip@2x-flip-vs-rmfb-interruptible.html>
> ([fdo#109274]) +3 similar issues
> *
>
> igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling:
>
> o shard-glk: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html>
> ([i915#4911]) +1 similar issue
> *
>
> igt@kms_force_connector_basic@force-load-detect:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_force_connector_basic@force-load-detect.html>
> ([fdo#109285])
> *
>
> igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack-mmap-gtt:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-2p-shrfb-fliptrack-mmap-gtt.html>
> ([fdo#109280]) +17 similar issues
> *
>
> igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-cpu.html>
> ([fdo#109280] / [fdo#111825]) +7 similar issues
> *
>
> igt@kms_hdr@bpc-switch-suspend:
>
> o shard-skl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl8/igt@kms_hdr@bpc-switch-suspend.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl4/igt@kms_hdr@bpc-switch-suspend.html>
> ([i915#1188])
> *
>
> igt@kms_hdr@static-toggle:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_hdr@static-toggle.html>
> ([i915#1187])
> *
>
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
>
> o shard-kbl: NOTRUN -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html>
> ([i915#180])
> *
>
> igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
>
> o shard-kbl: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl3/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html>
> ([fdo#108145] / [i915#265])
> *
>
> igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
>
> o shard-skl: NOTRUN -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html>
> ([fdo#108145] / [i915#265]) +2 similar issues
> *
>
> igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
>
> o shard-skl: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html>
> -> FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html>
> ([fdo#108145] / [i915#265])
> *
>
> igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max.html>
> ([fdo#109278]) +20 similar issues
> *
>
> igt@kms_psr2_sf@plane-move-sf-dmg-area:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_psr2_sf@plane-move-sf-dmg-area.html>
> ([fdo#111068] / [i915#658])
> *
>
> igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl1/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html>
> ([fdo#109271] / [i915#658])
> *
>
> igt@kms_psr2_su@page_flip-xrgb8888:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_psr2_su@page_flip-xrgb8888.html>
> ([i915#1911])
> *
>
> igt@kms_psr@psr2_primary_blt:
>
> o shard-iclb: PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_psr@psr2_primary_blt.html>
> -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_psr@psr2_primary_blt.html>
> ([fdo#109441])
> *
>
> igt@kms_tv_load_detect@load-detect:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@kms_tv_load_detect@load-detect.html>
> ([fdo#109309])
> *
>
> igt@kms_vrr@flip-dpms:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_vrr@flip-dpms.html>
> ([fdo#109502])
> *
>
> igt@kms_writeback@writeback-check-output:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@kms_writeback@writeback-check-output.html>
> ([i915#2437]) +1 similar issue
> *
>
> igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame:
>
> o shard-apl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame.html>
> ([fdo#109271]) +35 similar issues
> *
>
> igt@perf_pmu@event-wait@rcs0:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@perf_pmu@event-wait@rcs0.html>
> ([fdo#112283])
> *
>
> igt@prime_nv_api@i915_nv_import_twice_check_flink_name:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@prime_nv_api@i915_nv_import_twice_check_flink_name.html>
> ([fdo#109291]) +1 similar issue
> *
>
> igt@prime_nv_api@nv_i915_import_twice_check_flink_name:
>
> o shard-tglb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@prime_nv_api@nv_i915_import_twice_check_flink_name.html>
> ([fdo#109291])
> *
>
> igt@sysfs_clients@busy:
>
> o shard-iclb: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@sysfs_clients@busy.html>
> ([i915#2994])
> *
>
> igt@sysfs_clients@create:
>
> o shard-skl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@sysfs_clients@create.html>
> ([fdo#109271] / [i915#2994]) +2 similar issues
> *
>
> igt@sysfs_clients@fair-3:
>
> o shard-kbl: NOTRUN -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl3/igt@sysfs_clients@fair-3.html>
> ([fdo#109271] / [i915#2994]) +1 similar issue
>
>
> Possible fixes
>
> *
>
> igt@gem_eio@in-flight-contexts-immediate:
>
> o shard-tglb: TIMEOUT
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb5/igt@gem_eio@in-flight-contexts-immediate.html>
> ([i915#3063]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb3/igt@gem_eio@in-flight-contexts-immediate.html>
> *
>
> igt@gem_exec_fair@basic-none@vcs0:
>
> o shard-kbl: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl3/igt@gem_exec_fair@basic-none@vcs0.html>
> ([i915#2842]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl6/igt@gem_exec_fair@basic-none@vcs0.html>
> +2 similar issues
> *
>
> igt@i915_selftest@live@gtt:
>
> o shard-skl: DMESG-FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl3/igt@i915_selftest@live@gtt.html>
> -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl9/igt@i915_selftest@live@gtt.html>
> *
>
> igt@i915_suspend@sysfs-reader:
>
> o shard-apl: DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-apl8/igt@i915_suspend@sysfs-reader.html>
> ([i915#180]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-apl3/igt@i915_suspend@sysfs-reader.html>
> +1 similar issue
> *
>
> igt@kms_cursor_crc@pipe-a-cursor-suspend:
>
> o shard-tglb: INCOMPLETE
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-tglb2/igt@kms_cursor_crc@pipe-a-cursor-suspend.html>
> ([i915#2411] / [i915#2828] / [i915#456]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-tglb8/igt@kms_cursor_crc@pipe-a-cursor-suspend.html>
> *
>
> igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
>
> o shard-skl: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html>
> ([i915#2346]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl10/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html>
> *
>
> igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
>
> o shard-skl: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> ([i915#2346] / [i915#533]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html>
> *
>
> igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2:
>
> o shard-glk: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk2/igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2.html>
> ([i915#79]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk7/igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a2.html>
> +1 similar issue
> *
>
> igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling:
>
> o shard-iclb: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html>
> ([i915#3701]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html>
> *
>
> igt@kms_hdr@bpc-switch:
>
> o shard-skl: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-skl1/igt@kms_hdr@bpc-switch.html>
> ([i915#1188]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-skl7/igt@kms_hdr@bpc-switch.html>
> *
>
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
>
> o shard-kbl: DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-kbl6/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html>
> ([i915#180]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-kbl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html>
> +2 similar issues
> *
>
> igt@kms_psr@psr2_sprite_plane_move:
>
> o shard-iclb: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html>
> ([fdo#109441]) -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html>
> +1 similar issue
> *
>
> igt@perf@non-zero-reason:
>
> o shard-glk: FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-glk1/igt@perf@non-zero-reason.html>
> -> PASS
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-glk4/igt@perf@non-zero-reason.html>
>
>
> Warnings
>
> *
>
> igt@gem_exec_balancer@parallel-keep-in-fence:
>
> o shard-iclb: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb6/igt@gem_exec_balancer@parallel-keep-in-fence.html>
> ([i915#4525]) -> DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb4/igt@gem_exec_balancer@parallel-keep-in-fence.html>
> ([i915#5076])
> *
>
> igt@gem_exec_balancer@parallel-ordering:
>
> o shard-iclb: DMESG-FAIL
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb4/igt@gem_exec_balancer@parallel-ordering.html>
> -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb7/igt@gem_exec_balancer@parallel-ordering.html>
> ([i915#4525])
> *
>
> igt@gem_exec_balancer@parallel-out-fence:
>
> o shard-iclb: DMESG-WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb2/igt@gem_exec_balancer@parallel-out-fence.html>
> ([i915#5076]) -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb8/igt@gem_exec_balancer@parallel-out-fence.html>
> ([i915#4525]) +1 similar issue
> *
>
> igt@i915_pm_rc6_residency@rc6-fence:
>
> o shard-iclb: WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb7/igt@i915_pm_rc6_residency@rc6-fence.html>
> ([i915#1804] / [i915#2684]) -> WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb1/igt@i915_pm_rc6_residency@rc6-fence.html>
> ([i915#2684])
> *
>
> igt@i915_pm_rc6_residency@rc6-idle:
>
> o shard-iclb: WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb1/igt@i915_pm_rc6_residency@rc6-idle.html>
> ([i915#2684]) -> WARN
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb3/igt@i915_pm_rc6_residency@rc6-idle.html>
> ([i915#1804] / [i915#2684])
> *
>
> igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
>
> o shard-iclb: SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11205/shard-iclb3/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html>
> ([fdo#111068] / [i915#658]) -> SKIP
> <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22213/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html>
> ([i915#2920])
> *
>
> igt@kms_psr2_su@page_flip-xrgb8888:
>
> o shard-iclb: SKIP <https://intel-gfx-ci.> ([fdo#109642] /
> [fdo#111068] / [i915#658]) -> [FAIL][133] ([i915#4148])
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
(?)
@ 2022-02-18 4:57 ` Jordan Justen
-1 siblings, 0 replies; 37+ messages in thread
From: Jordan Justen @ 2022-02-18 4:57 UTC (permalink / raw)
To: Robert Beckett, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter
Cc: Matthew Auld, Ramalingam C, Robert Beckett,
Thomas Hellström, Simon Ser, Pekka Paalanen,
Kenneth Graunke, mesa-dev, Tony Ye, Slawomir Milczarek,
intel-gfx, dri-devel, linux-kernel
Robert Beckett <bob.beckett@collabora.com> writes:
> From: Matthew Auld <matthew.auld@intel.com>
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
> v3: fix typos and less emphasis
> v2: Fixed suggestions on formatting [Daniel]
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> cc: Simon Ser <contact@emersion.fr>
> cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Kenneth Graunke <kenneth@whitecape.org>
> Cc: mesa-dev@lists.freedesktop.org
> Cc: Tony Ye <tony.ye@intel.com>
> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> ---
> include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 5e678917da70..77e5e74c32c1 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> /**
> * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> * the user with the GTT offset at which this object will be pinned.
> + *
> * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> * presumed_offset of the object.
> + *
> * During execbuffer2 the kernel populates it with the value of the
> * current GTT offset of the object, for future presumed_offset writes.
> + *
> + * See struct drm_i915_gem_create_ext for the rules when dealing with
> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> + * minimum page sizes, like DG2.
> */
> __u64 offset;
>
> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> *
> * The (page-aligned) allocated size for the object will be returned.
> *
> - * Note that for some devices we have might have further minimum
> - * page-size restrictions(larger than 4K), like for device local-memory.
> - * However in general the final size here should always reflect any
> - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> - * extension to place the object in device local-memory.
> + *
> + * DG2 64K min page size implications:
> + *
> + * On discrete platforms, starting from DG2, we have to contend with GTT
> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> + * objects. Specifically the hardware only supports 64K or larger GTT
> + * page sizes for such memory. The kernel will already ensure that all
> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> + * sizes underneath.
> + *
> + * Note that the returned size here will always reflect any required
> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> + * such as DG2.
> + *
> + * Special DG2 GTT address alignment requirement:
> + *
> + * The GTT alignment will also need to be at least 2M for such objects.
> + *
> + * Note that due to how the hardware implements 64K GTT page support, we
> + * have some further complications:
> + *
> + * 1) The entire PDE (which covers a 2MB virtual address range), must
> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> + * PDE is forbidden by the hardware.
> + *
> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> + * objects.
> + *
> + * To keep things simple for userland, we mandate that any GTT mappings
> + * must be aligned to and rounded up to 2MB.
Could I get a clarification about this "rounded up" part.
Currently Mesa is aligning the start of each and every buffer VMA to be
2MiB aligned. But, we are *not* taking any steps to "round up" the size
of buffers to 2MiB alignment.
Bob's Mesa MR from a while ago,
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
was trying to add this "round up" size for buffers. We didn't accept
this MR because we thought if we have ensured that no other buffer will
use the same 2MiB VMA range, then it should not be required.
If what we are doing is ok, then maybe this "round up" language should
be dropped? Or, perhaps the "round up" mentioned here isn't implying we
must align the size of buffers that we create, and I'm misinterpreting
this.
-Jordan
> As this only wastes virtual
> + * address space and avoids userland having to copy any needlessly
> + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> + * is deemed to be a good compromise.
> */
> __u64 size;
> /**
> --
> 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 4:57 ` Jordan Justen
0 siblings, 0 replies; 37+ messages in thread
From: Jordan Justen @ 2022-02-18 4:57 UTC (permalink / raw)
To: Robert Beckett, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter
Cc: Robert Beckett, Thomas Hellström, dri-devel, intel-gfx,
Kenneth Graunke, Tony Ye, Slawomir Milczarek, Matthew Auld,
mesa-dev, linux-kernel
Robert Beckett <bob.beckett@collabora.com> writes:
> From: Matthew Auld <matthew.auld@intel.com>
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
> v3: fix typos and less emphasis
> v2: Fixed suggestions on formatting [Daniel]
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> cc: Simon Ser <contact@emersion.fr>
> cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Kenneth Graunke <kenneth@whitecape.org>
> Cc: mesa-dev@lists.freedesktop.org
> Cc: Tony Ye <tony.ye@intel.com>
> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> ---
> include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 5e678917da70..77e5e74c32c1 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> /**
> * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> * the user with the GTT offset at which this object will be pinned.
> + *
> * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> * presumed_offset of the object.
> + *
> * During execbuffer2 the kernel populates it with the value of the
> * current GTT offset of the object, for future presumed_offset writes.
> + *
> + * See struct drm_i915_gem_create_ext for the rules when dealing with
> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> + * minimum page sizes, like DG2.
> */
> __u64 offset;
>
> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> *
> * The (page-aligned) allocated size for the object will be returned.
> *
> - * Note that for some devices we have might have further minimum
> - * page-size restrictions(larger than 4K), like for device local-memory.
> - * However in general the final size here should always reflect any
> - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> - * extension to place the object in device local-memory.
> + *
> + * DG2 64K min page size implications:
> + *
> + * On discrete platforms, starting from DG2, we have to contend with GTT
> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> + * objects. Specifically the hardware only supports 64K or larger GTT
> + * page sizes for such memory. The kernel will already ensure that all
> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> + * sizes underneath.
> + *
> + * Note that the returned size here will always reflect any required
> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> + * such as DG2.
> + *
> + * Special DG2 GTT address alignment requirement:
> + *
> + * The GTT alignment will also need to be at least 2M for such objects.
> + *
> + * Note that due to how the hardware implements 64K GTT page support, we
> + * have some further complications:
> + *
> + * 1) The entire PDE (which covers a 2MB virtual address range), must
> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> + * PDE is forbidden by the hardware.
> + *
> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> + * objects.
> + *
> + * To keep things simple for userland, we mandate that any GTT mappings
> + * must be aligned to and rounded up to 2MB.
Could I get a clarification about this "rounded up" part.
Currently Mesa is aligning the start of each and every buffer VMA to be
2MiB aligned. But, we are *not* taking any steps to "round up" the size
of buffers to 2MiB alignment.
Bob's Mesa MR from a while ago,
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
was trying to add this "round up" size for buffers. We didn't accept
this MR because we thought if we have ensured that no other buffer will
use the same 2MiB VMA range, then it should not be required.
If what we are doing is ok, then maybe this "round up" language should
be dropped? Or, perhaps the "round up" mentioned here isn't implying we
must align the size of buffers that we create, and I'm misinterpreting
this.
-Jordan
> As this only wastes virtual
> + * address space and avoids userland having to copy any needlessly
> + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> + * is deemed to be a good compromise.
> */
> __u64 size;
> /**
> --
> 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 4:57 ` Jordan Justen
0 siblings, 0 replies; 37+ messages in thread
From: Jordan Justen @ 2022-02-18 4:57 UTC (permalink / raw)
To: Robert Beckett, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter
Cc: Thomas Hellström, dri-devel, intel-gfx, Kenneth Graunke,
Slawomir Milczarek, Pekka Paalanen, Matthew Auld, Simon Ser,
mesa-dev, linux-kernel
Robert Beckett <bob.beckett@collabora.com> writes:
> From: Matthew Auld <matthew.auld@intel.com>
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
> v3: fix typos and less emphasis
> v2: Fixed suggestions on formatting [Daniel]
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> cc: Simon Ser <contact@emersion.fr>
> cc: Pekka Paalanen <ppaalanen@gmail.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Kenneth Graunke <kenneth@whitecape.org>
> Cc: mesa-dev@lists.freedesktop.org
> Cc: Tony Ye <tony.ye@intel.com>
> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> ---
> include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 5e678917da70..77e5e74c32c1 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> /**
> * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> * the user with the GTT offset at which this object will be pinned.
> + *
> * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> * presumed_offset of the object.
> + *
> * During execbuffer2 the kernel populates it with the value of the
> * current GTT offset of the object, for future presumed_offset writes.
> + *
> + * See struct drm_i915_gem_create_ext for the rules when dealing with
> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> + * minimum page sizes, like DG2.
> */
> __u64 offset;
>
> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> *
> * The (page-aligned) allocated size for the object will be returned.
> *
> - * Note that for some devices we have might have further minimum
> - * page-size restrictions(larger than 4K), like for device local-memory.
> - * However in general the final size here should always reflect any
> - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> - * extension to place the object in device local-memory.
> + *
> + * DG2 64K min page size implications:
> + *
> + * On discrete platforms, starting from DG2, we have to contend with GTT
> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> + * objects. Specifically the hardware only supports 64K or larger GTT
> + * page sizes for such memory. The kernel will already ensure that all
> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> + * sizes underneath.
> + *
> + * Note that the returned size here will always reflect any required
> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> + * such as DG2.
> + *
> + * Special DG2 GTT address alignment requirement:
> + *
> + * The GTT alignment will also need to be at least 2M for such objects.
> + *
> + * Note that due to how the hardware implements 64K GTT page support, we
> + * have some further complications:
> + *
> + * 1) The entire PDE (which covers a 2MB virtual address range), must
> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> + * PDE is forbidden by the hardware.
> + *
> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> + * objects.
> + *
> + * To keep things simple for userland, we mandate that any GTT mappings
> + * must be aligned to and rounded up to 2MB.
Could I get a clarification about this "rounded up" part.
Currently Mesa is aligning the start of each and every buffer VMA to be
2MiB aligned. But, we are *not* taking any steps to "round up" the size
of buffers to 2MiB alignment.
Bob's Mesa MR from a while ago,
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
was trying to add this "round up" size for buffers. We didn't accept
this MR because we thought if we have ensured that no other buffer will
use the same 2MiB VMA range, then it should not be required.
If what we are doing is ok, then maybe this "round up" language should
be dropped? Or, perhaps the "round up" mentioned here isn't implying we
must align the size of buffers that we create, and I'm misinterpreting
this.
-Jordan
> As this only wastes virtual
> + * address space and avoids userland having to copy any needlessly
> + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> + * is deemed to be a good compromise.
> */
> __u64 size;
> /**
> --
> 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
2022-02-18 4:57 ` Jordan Justen
(?)
@ 2022-02-18 13:47 ` Ramalingam C
-1 siblings, 0 replies; 37+ messages in thread
From: Ramalingam C @ 2022-02-18 13:47 UTC (permalink / raw)
To: Jordan Justen
Cc: Robert Beckett, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter, Matthew Auld,
Thomas Hellström, Simon Ser, Pekka Paalanen,
Kenneth Graunke, mesa-dev, Tony Ye, Slawomir Milczarek,
intel-gfx, dri-devel, linux-kernel
On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> Robert Beckett <bob.beckett@collabora.com> writes:
>
> > From: Matthew Auld <matthew.auld@intel.com>
> >
> > On discrete platforms like DG2, we need to support a minimum page size
> > of 64K when dealing with device local-memory. This is quite tricky for
> > various reasons, so try to document the new implicit uapi for this.
> >
> > v3: fix typos and less emphasis
> > v2: Fixed suggestions on formatting [Daniel]
> >
> > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > cc: Simon Ser <contact@emersion.fr>
> > cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Cc: Kenneth Graunke <kenneth@whitecape.org>
> > Cc: mesa-dev@lists.freedesktop.org
> > Cc: Tony Ye <tony.ye@intel.com>
> > Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> > ---
> > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> > 1 file changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 5e678917da70..77e5e74c32c1 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > /**
> > * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> > * the user with the GTT offset at which this object will be pinned.
> > + *
> > * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> > * presumed_offset of the object.
> > + *
> > * During execbuffer2 the kernel populates it with the value of the
> > * current GTT offset of the object, for future presumed_offset writes.
> > + *
> > + * See struct drm_i915_gem_create_ext for the rules when dealing with
> > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > + * minimum page sizes, like DG2.
> > */
> > __u64 offset;
> >
> > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > *
> > * The (page-aligned) allocated size for the object will be returned.
> > *
> > - * Note that for some devices we have might have further minimum
> > - * page-size restrictions(larger than 4K), like for device local-memory.
> > - * However in general the final size here should always reflect any
> > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > - * extension to place the object in device local-memory.
> > + *
> > + * DG2 64K min page size implications:
> > + *
> > + * On discrete platforms, starting from DG2, we have to contend with GTT
> > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > + * objects. Specifically the hardware only supports 64K or larger GTT
> > + * page sizes for such memory. The kernel will already ensure that all
> > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > + * sizes underneath.
> > + *
> > + * Note that the returned size here will always reflect any required
> > + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> > + * such as DG2.
> > + *
> > + * Special DG2 GTT address alignment requirement:
> > + *
> > + * The GTT alignment will also need to be at least 2M for such objects.
> > + *
> > + * Note that due to how the hardware implements 64K GTT page support, we
> > + * have some further complications:
> > + *
> > + * 1) The entire PDE (which covers a 2MB virtual address range), must
> > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > + * PDE is forbidden by the hardware.
> > + *
> > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > + * objects.
> > + *
> > + * To keep things simple for userland, we mandate that any GTT mappings
> > + * must be aligned to and rounded up to 2MB.
>
> Could I get a clarification about this "rounded up" part.
>
> Currently Mesa is aligning the start of each and every buffer VMA to be
> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> of buffers to 2MiB alignment.
>
> Bob's Mesa MR from a while ago,
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
>
> was trying to add this "round up" size for buffers. We didn't accept
> this MR because we thought if we have ensured that no other buffer will
> use the same 2MiB VMA range, then it should not be required.
>
> If what we are doing is ok, then maybe this "round up" language should
> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> must align the size of buffers that we create, and I'm misinterpreting
> this.
Jordan,
as per my understanding this size rounding up to 2MB is for the VMA mapping,
not for the buffer size.
Even if we drop this rounding up of vma size to 2MB but align the VMA
start to 2MB address then also this should be fine. Becasue the remaining of the
last PDE(2MB) will never be used for any other GTT mapping as the
starting addr wont align to 2MB.
Bob, Is the above understanding is right? if so could we drop the
requirement of mapping the vma size to 2MB?
Ram
>
> -Jordan
>
> > As this only wastes virtual
> > + * address space and avoids userland having to copy any needlessly
> > + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> > + * is deemed to be a good compromise.
> > */
> > __u64 size;
> > /**
> > --
> > 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 13:47 ` Ramalingam C
0 siblings, 0 replies; 37+ messages in thread
From: Ramalingam C @ 2022-02-18 13:47 UTC (permalink / raw)
To: Jordan Justen
Cc: Robert Beckett, Tvrtko Ursulin, dri-devel, Thomas Hellström,
David Airlie, intel-gfx, Tony Ye, Kenneth Graunke,
Slawomir Milczarek, Matthew Auld, Rodrigo Vivi, mesa-dev,
linux-kernel
On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> Robert Beckett <bob.beckett@collabora.com> writes:
>
> > From: Matthew Auld <matthew.auld@intel.com>
> >
> > On discrete platforms like DG2, we need to support a minimum page size
> > of 64K when dealing with device local-memory. This is quite tricky for
> > various reasons, so try to document the new implicit uapi for this.
> >
> > v3: fix typos and less emphasis
> > v2: Fixed suggestions on formatting [Daniel]
> >
> > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > cc: Simon Ser <contact@emersion.fr>
> > cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Cc: Kenneth Graunke <kenneth@whitecape.org>
> > Cc: mesa-dev@lists.freedesktop.org
> > Cc: Tony Ye <tony.ye@intel.com>
> > Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> > ---
> > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> > 1 file changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 5e678917da70..77e5e74c32c1 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > /**
> > * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> > * the user with the GTT offset at which this object will be pinned.
> > + *
> > * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> > * presumed_offset of the object.
> > + *
> > * During execbuffer2 the kernel populates it with the value of the
> > * current GTT offset of the object, for future presumed_offset writes.
> > + *
> > + * See struct drm_i915_gem_create_ext for the rules when dealing with
> > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > + * minimum page sizes, like DG2.
> > */
> > __u64 offset;
> >
> > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > *
> > * The (page-aligned) allocated size for the object will be returned.
> > *
> > - * Note that for some devices we have might have further minimum
> > - * page-size restrictions(larger than 4K), like for device local-memory.
> > - * However in general the final size here should always reflect any
> > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > - * extension to place the object in device local-memory.
> > + *
> > + * DG2 64K min page size implications:
> > + *
> > + * On discrete platforms, starting from DG2, we have to contend with GTT
> > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > + * objects. Specifically the hardware only supports 64K or larger GTT
> > + * page sizes for such memory. The kernel will already ensure that all
> > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > + * sizes underneath.
> > + *
> > + * Note that the returned size here will always reflect any required
> > + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> > + * such as DG2.
> > + *
> > + * Special DG2 GTT address alignment requirement:
> > + *
> > + * The GTT alignment will also need to be at least 2M for such objects.
> > + *
> > + * Note that due to how the hardware implements 64K GTT page support, we
> > + * have some further complications:
> > + *
> > + * 1) The entire PDE (which covers a 2MB virtual address range), must
> > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > + * PDE is forbidden by the hardware.
> > + *
> > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > + * objects.
> > + *
> > + * To keep things simple for userland, we mandate that any GTT mappings
> > + * must be aligned to and rounded up to 2MB.
>
> Could I get a clarification about this "rounded up" part.
>
> Currently Mesa is aligning the start of each and every buffer VMA to be
> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> of buffers to 2MiB alignment.
>
> Bob's Mesa MR from a while ago,
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
>
> was trying to add this "round up" size for buffers. We didn't accept
> this MR because we thought if we have ensured that no other buffer will
> use the same 2MiB VMA range, then it should not be required.
>
> If what we are doing is ok, then maybe this "round up" language should
> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> must align the size of buffers that we create, and I'm misinterpreting
> this.
Jordan,
as per my understanding this size rounding up to 2MB is for the VMA mapping,
not for the buffer size.
Even if we drop this rounding up of vma size to 2MB but align the VMA
start to 2MB address then also this should be fine. Becasue the remaining of the
last PDE(2MB) will never be used for any other GTT mapping as the
starting addr wont align to 2MB.
Bob, Is the above understanding is right? if so could we drop the
requirement of mapping the vma size to 2MB?
Ram
>
> -Jordan
>
> > As this only wastes virtual
> > + * address space and avoids userland having to copy any needlessly
> > + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> > + * is deemed to be a good compromise.
> > */
> > __u64 size;
> > /**
> > --
> > 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 13:47 ` Ramalingam C
0 siblings, 0 replies; 37+ messages in thread
From: Ramalingam C @ 2022-02-18 13:47 UTC (permalink / raw)
To: Jordan Justen
Cc: dri-devel, Thomas Hellström, David Airlie, Simon Ser,
intel-gfx, Kenneth Graunke, Slawomir Milczarek, Pekka Paalanen,
Matthew Auld, Rodrigo Vivi, mesa-dev, linux-kernel
On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> Robert Beckett <bob.beckett@collabora.com> writes:
>
> > From: Matthew Auld <matthew.auld@intel.com>
> >
> > On discrete platforms like DG2, we need to support a minimum page size
> > of 64K when dealing with device local-memory. This is quite tricky for
> > various reasons, so try to document the new implicit uapi for this.
> >
> > v3: fix typos and less emphasis
> > v2: Fixed suggestions on formatting [Daniel]
> >
> > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > cc: Simon Ser <contact@emersion.fr>
> > cc: Pekka Paalanen <ppaalanen@gmail.com>
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Cc: Kenneth Graunke <kenneth@whitecape.org>
> > Cc: mesa-dev@lists.freedesktop.org
> > Cc: Tony Ye <tony.ye@intel.com>
> > Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> > ---
> > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> > 1 file changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 5e678917da70..77e5e74c32c1 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > /**
> > * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> > * the user with the GTT offset at which this object will be pinned.
> > + *
> > * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> > * presumed_offset of the object.
> > + *
> > * During execbuffer2 the kernel populates it with the value of the
> > * current GTT offset of the object, for future presumed_offset writes.
> > + *
> > + * See struct drm_i915_gem_create_ext for the rules when dealing with
> > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > + * minimum page sizes, like DG2.
> > */
> > __u64 offset;
> >
> > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > *
> > * The (page-aligned) allocated size for the object will be returned.
> > *
> > - * Note that for some devices we have might have further minimum
> > - * page-size restrictions(larger than 4K), like for device local-memory.
> > - * However in general the final size here should always reflect any
> > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > - * extension to place the object in device local-memory.
> > + *
> > + * DG2 64K min page size implications:
> > + *
> > + * On discrete platforms, starting from DG2, we have to contend with GTT
> > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > + * objects. Specifically the hardware only supports 64K or larger GTT
> > + * page sizes for such memory. The kernel will already ensure that all
> > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > + * sizes underneath.
> > + *
> > + * Note that the returned size here will always reflect any required
> > + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> > + * such as DG2.
> > + *
> > + * Special DG2 GTT address alignment requirement:
> > + *
> > + * The GTT alignment will also need to be at least 2M for such objects.
> > + *
> > + * Note that due to how the hardware implements 64K GTT page support, we
> > + * have some further complications:
> > + *
> > + * 1) The entire PDE (which covers a 2MB virtual address range), must
> > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > + * PDE is forbidden by the hardware.
> > + *
> > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > + * objects.
> > + *
> > + * To keep things simple for userland, we mandate that any GTT mappings
> > + * must be aligned to and rounded up to 2MB.
>
> Could I get a clarification about this "rounded up" part.
>
> Currently Mesa is aligning the start of each and every buffer VMA to be
> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> of buffers to 2MiB alignment.
>
> Bob's Mesa MR from a while ago,
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
>
> was trying to add this "round up" size for buffers. We didn't accept
> this MR because we thought if we have ensured that no other buffer will
> use the same 2MiB VMA range, then it should not be required.
>
> If what we are doing is ok, then maybe this "round up" language should
> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> must align the size of buffers that we create, and I'm misinterpreting
> this.
Jordan,
as per my understanding this size rounding up to 2MB is for the VMA mapping,
not for the buffer size.
Even if we drop this rounding up of vma size to 2MB but align the VMA
start to 2MB address then also this should be fine. Becasue the remaining of the
last PDE(2MB) will never be used for any other GTT mapping as the
starting addr wont align to 2MB.
Bob, Is the above understanding is right? if so could we drop the
requirement of mapping the vma size to 2MB?
Ram
>
> -Jordan
>
> > As this only wastes virtual
> > + * address space and avoids userland having to copy any needlessly
> > + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> > + * is deemed to be a good compromise.
> > */
> > __u64 size;
> > /**
> > --
> > 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
2022-02-18 13:47 ` Ramalingam C
(?)
@ 2022-02-18 18:06 ` Robert Beckett
-1 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-18 18:06 UTC (permalink / raw)
To: Ramalingam C, Jordan Justen
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter, Matthew Auld, Thomas Hellström,
Simon Ser, Pekka Paalanen, Kenneth Graunke, mesa-dev, Tony Ye,
Slawomir Milczarek, intel-gfx, dri-devel, linux-kernel
On 18/02/2022 13:47, Ramalingam C wrote:
> On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
>> Robert Beckett <bob.beckett@collabora.com> writes:
>>
>>> From: Matthew Auld <matthew.auld@intel.com>
>>>
>>> On discrete platforms like DG2, we need to support a minimum page size
>>> of 64K when dealing with device local-memory. This is quite tricky for
>>> various reasons, so try to document the new implicit uapi for this.
>>>
>>> v3: fix typos and less emphasis
>>> v2: Fixed suggestions on formatting [Daniel]
>>>
>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>>> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
>>> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
>>> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
>>> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> cc: Simon Ser <contact@emersion.fr>
>>> cc: Pekka Paalanen <ppaalanen@gmail.com>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Cc: Kenneth Graunke <kenneth@whitecape.org>
>>> Cc: mesa-dev@lists.freedesktop.org
>>> Cc: Tony Ye <tony.ye@intel.com>
>>> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
>>> ---
>>> include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
>>> 1 file changed, 39 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>>> index 5e678917da70..77e5e74c32c1 100644
>>> --- a/include/uapi/drm/i915_drm.h
>>> +++ b/include/uapi/drm/i915_drm.h
>>> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
>>> /**
>>> * When the EXEC_OBJECT_PINNED flag is specified this is populated by
>>> * the user with the GTT offset at which this object will be pinned.
>>> + *
>>> * When the I915_EXEC_NO_RELOC flag is specified this must contain the
>>> * presumed_offset of the object.
>>> + *
>>> * During execbuffer2 the kernel populates it with the value of the
>>> * current GTT offset of the object, for future presumed_offset writes.
>>> + *
>>> + * See struct drm_i915_gem_create_ext for the rules when dealing with
>>> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
>>> + * minimum page sizes, like DG2.
>>> */
>>> __u64 offset;
>>>
>>> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
>>> *
>>> * The (page-aligned) allocated size for the object will be returned.
>>> *
>>> - * Note that for some devices we have might have further minimum
>>> - * page-size restrictions(larger than 4K), like for device local-memory.
>>> - * However in general the final size here should always reflect any
>>> - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
>>> - * extension to place the object in device local-memory.
>>> + *
>>> + * DG2 64K min page size implications:
>>> + *
>>> + * On discrete platforms, starting from DG2, we have to contend with GTT
>>> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
>>> + * objects. Specifically the hardware only supports 64K or larger GTT
>>> + * page sizes for such memory. The kernel will already ensure that all
>>> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
>>> + * sizes underneath.
>>> + *
>>> + * Note that the returned size here will always reflect any required
>>> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
>>> + * such as DG2.
>>> + *
>>> + * Special DG2 GTT address alignment requirement:
>>> + *
>>> + * The GTT alignment will also need to be at least 2M for such objects.
>>> + *
>>> + * Note that due to how the hardware implements 64K GTT page support, we
>>> + * have some further complications:
>>> + *
>>> + * 1) The entire PDE (which covers a 2MB virtual address range), must
>>> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
>>> + * PDE is forbidden by the hardware.
>>> + *
>>> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
>>> + * objects.
>>> + *
>>> + * To keep things simple for userland, we mandate that any GTT mappings
>>> + * must be aligned to and rounded up to 2MB.
>>
>> Could I get a clarification about this "rounded up" part.
>>
>> Currently Mesa is aligning the start of each and every buffer VMA to be
>> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
>> of buffers to 2MiB alignment.
>>
>> Bob's Mesa MR from a while ago,
>>
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
>>
>> was trying to add this "round up" size for buffers. We didn't accept
>> this MR because we thought if we have ensured that no other buffer will
>> use the same 2MiB VMA range, then it should not be required.
>>
>> If what we are doing is ok, then maybe this "round up" language should
>> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
>> must align the size of buffers that we create, and I'm misinterpreting
>> this.
> Jordan,
>
> as per my understanding this size rounding up to 2MB is for the VMA mapping,
> not for the buffer size.
correct, only the vma is rounded up
>
> Even if we drop this rounding up of vma size to 2MB but align the VMA
> start to 2MB address then also this should be fine. Becasue the remaining of the
> last PDE(2MB) will never be used for any other GTT mapping as the
> starting addr wont align to 2MB.
The kernel has to handle 4K pages also, which could in theory attempt to
be placed in any remaining space within a 2MB region, which is not
supported. For this reason, the kernel rounds up the vma to next 2MB to
ensure no 4K pages can treat the remaining space as a candidate for
placement.
For mesa, this is not required as they only ever use 2MB alignment for
all buffers, hence the denial of the mesa mr.
Internally, the kernel will still round up the vma reservations to
prevent any kernel 4K buffers being situated in remaining space.
If desired, we can make the wording clearer, maybe something like:
"To keep things simple for userland, we mandate that any GTT mappings
must be aligned to 2MB. The kernel will internally pad them out to the
next 2MB boundary"
>
> Bob, Is the above understanding is right? if so could we drop the
> requirement of mapping the vma size to 2MB?
>
> Ram
>>
>> -Jordan
>>
>>> As this only wastes virtual
>>> + * address space and avoids userland having to copy any needlessly
>>> + * complicated PDE sharing scheme (coloring) and only affects DG2, this
>>> + * is deemed to be a good compromise.
>>> */
>>> __u64 size;
>>> /**
>>> --
>>> 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 18:06 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-18 18:06 UTC (permalink / raw)
To: Ramalingam C, Jordan Justen
Cc: Tony Ye, Tvrtko Ursulin, dri-devel, Thomas Hellström,
David Airlie, intel-gfx, Kenneth Graunke, Slawomir Milczarek,
Matthew Auld, Rodrigo Vivi, mesa-dev, linux-kernel
On 18/02/2022 13:47, Ramalingam C wrote:
> On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
>> Robert Beckett <bob.beckett@collabora.com> writes:
>>
>>> From: Matthew Auld <matthew.auld@intel.com>
>>>
>>> On discrete platforms like DG2, we need to support a minimum page size
>>> of 64K when dealing with device local-memory. This is quite tricky for
>>> various reasons, so try to document the new implicit uapi for this.
>>>
>>> v3: fix typos and less emphasis
>>> v2: Fixed suggestions on formatting [Daniel]
>>>
>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>>> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
>>> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
>>> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
>>> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> cc: Simon Ser <contact@emersion.fr>
>>> cc: Pekka Paalanen <ppaalanen@gmail.com>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Cc: Kenneth Graunke <kenneth@whitecape.org>
>>> Cc: mesa-dev@lists.freedesktop.org
>>> Cc: Tony Ye <tony.ye@intel.com>
>>> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
>>> ---
>>> include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
>>> 1 file changed, 39 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>>> index 5e678917da70..77e5e74c32c1 100644
>>> --- a/include/uapi/drm/i915_drm.h
>>> +++ b/include/uapi/drm/i915_drm.h
>>> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
>>> /**
>>> * When the EXEC_OBJECT_PINNED flag is specified this is populated by
>>> * the user with the GTT offset at which this object will be pinned.
>>> + *
>>> * When the I915_EXEC_NO_RELOC flag is specified this must contain the
>>> * presumed_offset of the object.
>>> + *
>>> * During execbuffer2 the kernel populates it with the value of the
>>> * current GTT offset of the object, for future presumed_offset writes.
>>> + *
>>> + * See struct drm_i915_gem_create_ext for the rules when dealing with
>>> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
>>> + * minimum page sizes, like DG2.
>>> */
>>> __u64 offset;
>>>
>>> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
>>> *
>>> * The (page-aligned) allocated size for the object will be returned.
>>> *
>>> - * Note that for some devices we have might have further minimum
>>> - * page-size restrictions(larger than 4K), like for device local-memory.
>>> - * However in general the final size here should always reflect any
>>> - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
>>> - * extension to place the object in device local-memory.
>>> + *
>>> + * DG2 64K min page size implications:
>>> + *
>>> + * On discrete platforms, starting from DG2, we have to contend with GTT
>>> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
>>> + * objects. Specifically the hardware only supports 64K or larger GTT
>>> + * page sizes for such memory. The kernel will already ensure that all
>>> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
>>> + * sizes underneath.
>>> + *
>>> + * Note that the returned size here will always reflect any required
>>> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
>>> + * such as DG2.
>>> + *
>>> + * Special DG2 GTT address alignment requirement:
>>> + *
>>> + * The GTT alignment will also need to be at least 2M for such objects.
>>> + *
>>> + * Note that due to how the hardware implements 64K GTT page support, we
>>> + * have some further complications:
>>> + *
>>> + * 1) The entire PDE (which covers a 2MB virtual address range), must
>>> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
>>> + * PDE is forbidden by the hardware.
>>> + *
>>> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
>>> + * objects.
>>> + *
>>> + * To keep things simple for userland, we mandate that any GTT mappings
>>> + * must be aligned to and rounded up to 2MB.
>>
>> Could I get a clarification about this "rounded up" part.
>>
>> Currently Mesa is aligning the start of each and every buffer VMA to be
>> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
>> of buffers to 2MiB alignment.
>>
>> Bob's Mesa MR from a while ago,
>>
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
>>
>> was trying to add this "round up" size for buffers. We didn't accept
>> this MR because we thought if we have ensured that no other buffer will
>> use the same 2MiB VMA range, then it should not be required.
>>
>> If what we are doing is ok, then maybe this "round up" language should
>> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
>> must align the size of buffers that we create, and I'm misinterpreting
>> this.
> Jordan,
>
> as per my understanding this size rounding up to 2MB is for the VMA mapping,
> not for the buffer size.
correct, only the vma is rounded up
>
> Even if we drop this rounding up of vma size to 2MB but align the VMA
> start to 2MB address then also this should be fine. Becasue the remaining of the
> last PDE(2MB) will never be used for any other GTT mapping as the
> starting addr wont align to 2MB.
The kernel has to handle 4K pages also, which could in theory attempt to
be placed in any remaining space within a 2MB region, which is not
supported. For this reason, the kernel rounds up the vma to next 2MB to
ensure no 4K pages can treat the remaining space as a candidate for
placement.
For mesa, this is not required as they only ever use 2MB alignment for
all buffers, hence the denial of the mesa mr.
Internally, the kernel will still round up the vma reservations to
prevent any kernel 4K buffers being situated in remaining space.
If desired, we can make the wording clearer, maybe something like:
"To keep things simple for userland, we mandate that any GTT mappings
must be aligned to 2MB. The kernel will internally pad them out to the
next 2MB boundary"
>
> Bob, Is the above understanding is right? if so could we drop the
> requirement of mapping the vma size to 2MB?
>
> Ram
>>
>> -Jordan
>>
>>> As this only wastes virtual
>>> + * address space and avoids userland having to copy any needlessly
>>> + * complicated PDE sharing scheme (coloring) and only affects DG2, this
>>> + * is deemed to be a good compromise.
>>> */
>>> __u64 size;
>>> /**
>>> --
>>> 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 18:06 ` Robert Beckett
0 siblings, 0 replies; 37+ messages in thread
From: Robert Beckett @ 2022-02-18 18:06 UTC (permalink / raw)
To: Ramalingam C, Jordan Justen
Cc: dri-devel, Thomas Hellström, David Airlie, Simon Ser,
intel-gfx, Kenneth Graunke, Slawomir Milczarek, Pekka Paalanen,
Matthew Auld, Rodrigo Vivi, mesa-dev, linux-kernel
On 18/02/2022 13:47, Ramalingam C wrote:
> On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
>> Robert Beckett <bob.beckett@collabora.com> writes:
>>
>>> From: Matthew Auld <matthew.auld@intel.com>
>>>
>>> On discrete platforms like DG2, we need to support a minimum page size
>>> of 64K when dealing with device local-memory. This is quite tricky for
>>> various reasons, so try to document the new implicit uapi for this.
>>>
>>> v3: fix typos and less emphasis
>>> v2: Fixed suggestions on formatting [Daniel]
>>>
>>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>>> Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
>>> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
>>> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
>>> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> cc: Simon Ser <contact@emersion.fr>
>>> cc: Pekka Paalanen <ppaalanen@gmail.com>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Cc: Kenneth Graunke <kenneth@whitecape.org>
>>> Cc: mesa-dev@lists.freedesktop.org
>>> Cc: Tony Ye <tony.ye@intel.com>
>>> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
>>> ---
>>> include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
>>> 1 file changed, 39 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>>> index 5e678917da70..77e5e74c32c1 100644
>>> --- a/include/uapi/drm/i915_drm.h
>>> +++ b/include/uapi/drm/i915_drm.h
>>> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
>>> /**
>>> * When the EXEC_OBJECT_PINNED flag is specified this is populated by
>>> * the user with the GTT offset at which this object will be pinned.
>>> + *
>>> * When the I915_EXEC_NO_RELOC flag is specified this must contain the
>>> * presumed_offset of the object.
>>> + *
>>> * During execbuffer2 the kernel populates it with the value of the
>>> * current GTT offset of the object, for future presumed_offset writes.
>>> + *
>>> + * See struct drm_i915_gem_create_ext for the rules when dealing with
>>> + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
>>> + * minimum page sizes, like DG2.
>>> */
>>> __u64 offset;
>>>
>>> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
>>> *
>>> * The (page-aligned) allocated size for the object will be returned.
>>> *
>>> - * Note that for some devices we have might have further minimum
>>> - * page-size restrictions(larger than 4K), like for device local-memory.
>>> - * However in general the final size here should always reflect any
>>> - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
>>> - * extension to place the object in device local-memory.
>>> + *
>>> + * DG2 64K min page size implications:
>>> + *
>>> + * On discrete platforms, starting from DG2, we have to contend with GTT
>>> + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
>>> + * objects. Specifically the hardware only supports 64K or larger GTT
>>> + * page sizes for such memory. The kernel will already ensure that all
>>> + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
>>> + * sizes underneath.
>>> + *
>>> + * Note that the returned size here will always reflect any required
>>> + * rounding up done by the kernel, i.e 4K will now become 64K on devices
>>> + * such as DG2.
>>> + *
>>> + * Special DG2 GTT address alignment requirement:
>>> + *
>>> + * The GTT alignment will also need to be at least 2M for such objects.
>>> + *
>>> + * Note that due to how the hardware implements 64K GTT page support, we
>>> + * have some further complications:
>>> + *
>>> + * 1) The entire PDE (which covers a 2MB virtual address range), must
>>> + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
>>> + * PDE is forbidden by the hardware.
>>> + *
>>> + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
>>> + * objects.
>>> + *
>>> + * To keep things simple for userland, we mandate that any GTT mappings
>>> + * must be aligned to and rounded up to 2MB.
>>
>> Could I get a clarification about this "rounded up" part.
>>
>> Currently Mesa is aligning the start of each and every buffer VMA to be
>> 2MiB aligned. But, we are *not* taking any steps to "round up" the size
>> of buffers to 2MiB alignment.
>>
>> Bob's Mesa MR from a while ago,
>>
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
>>
>> was trying to add this "round up" size for buffers. We didn't accept
>> this MR because we thought if we have ensured that no other buffer will
>> use the same 2MiB VMA range, then it should not be required.
>>
>> If what we are doing is ok, then maybe this "round up" language should
>> be dropped? Or, perhaps the "round up" mentioned here isn't implying we
>> must align the size of buffers that we create, and I'm misinterpreting
>> this.
> Jordan,
>
> as per my understanding this size rounding up to 2MB is for the VMA mapping,
> not for the buffer size.
correct, only the vma is rounded up
>
> Even if we drop this rounding up of vma size to 2MB but align the VMA
> start to 2MB address then also this should be fine. Becasue the remaining of the
> last PDE(2MB) will never be used for any other GTT mapping as the
> starting addr wont align to 2MB.
The kernel has to handle 4K pages also, which could in theory attempt to
be placed in any remaining space within a 2MB region, which is not
supported. For this reason, the kernel rounds up the vma to next 2MB to
ensure no 4K pages can treat the remaining space as a candidate for
placement.
For mesa, this is not required as they only ever use 2MB alignment for
all buffers, hence the denial of the mesa mr.
Internally, the kernel will still round up the vma reservations to
prevent any kernel 4K buffers being situated in remaining space.
If desired, we can make the wording clearer, maybe something like:
"To keep things simple for userland, we mandate that any GTT mappings
must be aligned to 2MB. The kernel will internally pad them out to the
next 2MB boundary"
>
> Bob, Is the above understanding is right? if so could we drop the
> requirement of mapping the vma size to 2MB?
>
> Ram
>>
>> -Jordan
>>
>>> As this only wastes virtual
>>> + * address space and avoids userland having to copy any needlessly
>>> + * complicated PDE sharing scheme (coloring) and only affects DG2, this
>>> + * is deemed to be a good compromise.
>>> */
>>> __u64 size;
>>> /**
>>> --
>>> 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
2022-02-18 18:06 ` Robert Beckett
(?)
@ 2022-02-18 18:55 ` Ramalingam C
-1 siblings, 0 replies; 37+ messages in thread
From: Ramalingam C @ 2022-02-18 18:55 UTC (permalink / raw)
To: Robert Beckett
Cc: Jordan Justen, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter, Matthew Auld,
Thomas Hellström, Simon Ser, Pekka Paalanen,
Kenneth Graunke, mesa-dev, Tony Ye, Slawomir Milczarek,
intel-gfx, dri-devel, linux-kernel
On 2022-02-18 at 18:06:00 +0000, Robert Beckett wrote:
>
>
> On 18/02/2022 13:47, Ramalingam C wrote:
> > On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> > > Robert Beckett <bob.beckett@collabora.com> writes:
> > >
> > > > From: Matthew Auld <matthew.auld@intel.com>
> > > >
> > > > On discrete platforms like DG2, we need to support a minimum page size
> > > > of 64K when dealing with device local-memory. This is quite tricky for
> > > > various reasons, so try to document the new implicit uapi for this.
> > > >
> > > > v3: fix typos and less emphasis
> > > > v2: Fixed suggestions on formatting [Daniel]
> > > >
> > > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > > > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > > > Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > > cc: Simon Ser <contact@emersion.fr>
> > > > cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > > > Cc: Kenneth Graunke <kenneth@whitecape.org>
> > > > Cc: mesa-dev@lists.freedesktop.org
> > > > Cc: Tony Ye <tony.ye@intel.com>
> > > > Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> > > > ---
> > > > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> > > > 1 file changed, 39 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 5e678917da70..77e5e74c32c1 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > > > /**
> > > > * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> > > > * the user with the GTT offset at which this object will be pinned.
> > > > + *
> > > > * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> > > > * presumed_offset of the object.
> > > > + *
> > > > * During execbuffer2 the kernel populates it with the value of the
> > > > * current GTT offset of the object, for future presumed_offset writes.
> > > > + *
> > > > + * See struct drm_i915_gem_create_ext for the rules when dealing with
> > > > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > > > + * minimum page sizes, like DG2.
> > > > */
> > > > __u64 offset;
> > > > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > > > *
> > > > * The (page-aligned) allocated size for the object will be returned.
> > > > *
> > > > - * Note that for some devices we have might have further minimum
> > > > - * page-size restrictions(larger than 4K), like for device local-memory.
> > > > - * However in general the final size here should always reflect any
> > > > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > > > - * extension to place the object in device local-memory.
> > > > + *
> > > > + * DG2 64K min page size implications:
> > > > + *
> > > > + * On discrete platforms, starting from DG2, we have to contend with GTT
> > > > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > > > + * objects. Specifically the hardware only supports 64K or larger GTT
> > > > + * page sizes for such memory. The kernel will already ensure that all
> > > > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > > > + * sizes underneath.
> > > > + *
> > > > + * Note that the returned size here will always reflect any required
> > > > + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> > > > + * such as DG2.
> > > > + *
> > > > + * Special DG2 GTT address alignment requirement:
> > > > + *
> > > > + * The GTT alignment will also need to be at least 2M for such objects.
> > > > + *
> > > > + * Note that due to how the hardware implements 64K GTT page support, we
> > > > + * have some further complications:
> > > > + *
> > > > + * 1) The entire PDE (which covers a 2MB virtual address range), must
> > > > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > > > + * PDE is forbidden by the hardware.
> > > > + *
> > > > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > > > + * objects.
> > > > + *
> > > > + * To keep things simple for userland, we mandate that any GTT mappings
> > > > + * must be aligned to and rounded up to 2MB.
> > >
> > > Could I get a clarification about this "rounded up" part.
> > >
> > > Currently Mesa is aligning the start of each and every buffer VMA to be
> > > 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> > > of buffers to 2MiB alignment.
> > >
> > > Bob's Mesa MR from a while ago,
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
> > >
> > > was trying to add this "round up" size for buffers. We didn't accept
> > > this MR because we thought if we have ensured that no other buffer will
> > > use the same 2MiB VMA range, then it should not be required.
> > >
> > > If what we are doing is ok, then maybe this "round up" language should
> > > be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> > > must align the size of buffers that we create, and I'm misinterpreting
> > > this.
> > Jordan,
> >
> > as per my understanding this size rounding up to 2MB is for the VMA mapping,
> > not for the buffer size.
> correct, only the vma is rounded up
>
> >
> > Even if we drop this rounding up of vma size to 2MB but align the VMA
> > start to 2MB address then also this should be fine. Becasue the remaining of the
> > last PDE(2MB) will never be used for any other GTT mapping as the
> > starting addr wont align to 2MB.
> The kernel has to handle 4K pages also, which could in theory attempt to be
> placed in any remaining space within a 2MB region, which is not supported.
> For this reason, the kernel rounds up the vma to next 2MB to ensure no 4K
> pages can treat the remaining space as a candidate for placement.
>
> For mesa, this is not required as they only ever use 2MB alignment for all
> buffers, hence the denial of the mesa mr.
>
> Internally, the kernel will still round up the vma reservations to prevent
> any kernel 4K buffers being situated in remaining space.
>
> If desired, we can make the wording clearer, maybe something like:
>
> "To keep things simple for userland, we mandate that any GTT mappings
> must be aligned to 2MB. The kernel will internally pad them out to the next
> 2MB boundary"
Added the extra information in next version @ https://patchwork.freedesktop.org/patch/475166/?series=100419&rev=1
Jordan, hope this explanation clears your doubt.
Ram.
>
>
> >
> > Bob, Is the above understanding is right? if so could we drop the
> > requirement of mapping the vma size to 2MB?
> >
> > Ram
> > >
> > > -Jordan
> > >
> > > > As this only wastes virtual
> > > > + * address space and avoids userland having to copy any needlessly
> > > > + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> > > > + * is deemed to be a good compromise.
> > > > */
> > > > __u64 size;
> > > > /**
> > > > --
> > > > 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 18:55 ` Ramalingam C
0 siblings, 0 replies; 37+ messages in thread
From: Ramalingam C @ 2022-02-18 18:55 UTC (permalink / raw)
To: Robert Beckett
Cc: Tony Ye, Tvrtko Ursulin, dri-devel, Thomas Hellström,
David Airlie, Jordan Justen, intel-gfx, Kenneth Graunke,
Slawomir Milczarek, Matthew Auld, Rodrigo Vivi, mesa-dev,
linux-kernel
On 2022-02-18 at 18:06:00 +0000, Robert Beckett wrote:
>
>
> On 18/02/2022 13:47, Ramalingam C wrote:
> > On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> > > Robert Beckett <bob.beckett@collabora.com> writes:
> > >
> > > > From: Matthew Auld <matthew.auld@intel.com>
> > > >
> > > > On discrete platforms like DG2, we need to support a minimum page size
> > > > of 64K when dealing with device local-memory. This is quite tricky for
> > > > various reasons, so try to document the new implicit uapi for this.
> > > >
> > > > v3: fix typos and less emphasis
> > > > v2: Fixed suggestions on formatting [Daniel]
> > > >
> > > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > > > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > > > Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > > cc: Simon Ser <contact@emersion.fr>
> > > > cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > > > Cc: Kenneth Graunke <kenneth@whitecape.org>
> > > > Cc: mesa-dev@lists.freedesktop.org
> > > > Cc: Tony Ye <tony.ye@intel.com>
> > > > Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> > > > ---
> > > > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> > > > 1 file changed, 39 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 5e678917da70..77e5e74c32c1 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > > > /**
> > > > * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> > > > * the user with the GTT offset at which this object will be pinned.
> > > > + *
> > > > * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> > > > * presumed_offset of the object.
> > > > + *
> > > > * During execbuffer2 the kernel populates it with the value of the
> > > > * current GTT offset of the object, for future presumed_offset writes.
> > > > + *
> > > > + * See struct drm_i915_gem_create_ext for the rules when dealing with
> > > > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > > > + * minimum page sizes, like DG2.
> > > > */
> > > > __u64 offset;
> > > > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > > > *
> > > > * The (page-aligned) allocated size for the object will be returned.
> > > > *
> > > > - * Note that for some devices we have might have further minimum
> > > > - * page-size restrictions(larger than 4K), like for device local-memory.
> > > > - * However in general the final size here should always reflect any
> > > > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > > > - * extension to place the object in device local-memory.
> > > > + *
> > > > + * DG2 64K min page size implications:
> > > > + *
> > > > + * On discrete platforms, starting from DG2, we have to contend with GTT
> > > > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > > > + * objects. Specifically the hardware only supports 64K or larger GTT
> > > > + * page sizes for such memory. The kernel will already ensure that all
> > > > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > > > + * sizes underneath.
> > > > + *
> > > > + * Note that the returned size here will always reflect any required
> > > > + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> > > > + * such as DG2.
> > > > + *
> > > > + * Special DG2 GTT address alignment requirement:
> > > > + *
> > > > + * The GTT alignment will also need to be at least 2M for such objects.
> > > > + *
> > > > + * Note that due to how the hardware implements 64K GTT page support, we
> > > > + * have some further complications:
> > > > + *
> > > > + * 1) The entire PDE (which covers a 2MB virtual address range), must
> > > > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > > > + * PDE is forbidden by the hardware.
> > > > + *
> > > > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > > > + * objects.
> > > > + *
> > > > + * To keep things simple for userland, we mandate that any GTT mappings
> > > > + * must be aligned to and rounded up to 2MB.
> > >
> > > Could I get a clarification about this "rounded up" part.
> > >
> > > Currently Mesa is aligning the start of each and every buffer VMA to be
> > > 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> > > of buffers to 2MiB alignment.
> > >
> > > Bob's Mesa MR from a while ago,
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
> > >
> > > was trying to add this "round up" size for buffers. We didn't accept
> > > this MR because we thought if we have ensured that no other buffer will
> > > use the same 2MiB VMA range, then it should not be required.
> > >
> > > If what we are doing is ok, then maybe this "round up" language should
> > > be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> > > must align the size of buffers that we create, and I'm misinterpreting
> > > this.
> > Jordan,
> >
> > as per my understanding this size rounding up to 2MB is for the VMA mapping,
> > not for the buffer size.
> correct, only the vma is rounded up
>
> >
> > Even if we drop this rounding up of vma size to 2MB but align the VMA
> > start to 2MB address then also this should be fine. Becasue the remaining of the
> > last PDE(2MB) will never be used for any other GTT mapping as the
> > starting addr wont align to 2MB.
> The kernel has to handle 4K pages also, which could in theory attempt to be
> placed in any remaining space within a 2MB region, which is not supported.
> For this reason, the kernel rounds up the vma to next 2MB to ensure no 4K
> pages can treat the remaining space as a candidate for placement.
>
> For mesa, this is not required as they only ever use 2MB alignment for all
> buffers, hence the denial of the mesa mr.
>
> Internally, the kernel will still round up the vma reservations to prevent
> any kernel 4K buffers being situated in remaining space.
>
> If desired, we can make the wording clearer, maybe something like:
>
> "To keep things simple for userland, we mandate that any GTT mappings
> must be aligned to 2MB. The kernel will internally pad them out to the next
> 2MB boundary"
Added the extra information in next version @ https://patchwork.freedesktop.org/patch/475166/?series=100419&rev=1
Jordan, hope this explanation clears your doubt.
Ram.
>
>
> >
> > Bob, Is the above understanding is right? if so could we drop the
> > requirement of mapping the vma size to 2MB?
> >
> > Ram
> > >
> > > -Jordan
> > >
> > > > As this only wastes virtual
> > > > + * address space and avoids userland having to copy any needlessly
> > > > + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> > > > + * is deemed to be a good compromise.
> > > > */
> > > > __u64 size;
> > > > /**
> > > > --
> > > > 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 18:55 ` Ramalingam C
0 siblings, 0 replies; 37+ messages in thread
From: Ramalingam C @ 2022-02-18 18:55 UTC (permalink / raw)
To: Robert Beckett
Cc: Simon Ser, dri-devel, Thomas Hellström, David Airlie,
intel-gfx, Kenneth Graunke, Slawomir Milczarek, Pekka Paalanen,
Matthew Auld, Rodrigo Vivi, mesa-dev, linux-kernel
On 2022-02-18 at 18:06:00 +0000, Robert Beckett wrote:
>
>
> On 18/02/2022 13:47, Ramalingam C wrote:
> > On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> > > Robert Beckett <bob.beckett@collabora.com> writes:
> > >
> > > > From: Matthew Auld <matthew.auld@intel.com>
> > > >
> > > > On discrete platforms like DG2, we need to support a minimum page size
> > > > of 64K when dealing with device local-memory. This is quite tricky for
> > > > various reasons, so try to document the new implicit uapi for this.
> > > >
> > > > v3: fix typos and less emphasis
> > > > v2: Fixed suggestions on formatting [Daniel]
> > > >
> > > > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > > > Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > > > Acked-by: Jordan Justen <jordan.l.justen@intel.com>
> > > > Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
> > > > Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > > cc: Simon Ser <contact@emersion.fr>
> > > > cc: Pekka Paalanen <ppaalanen@gmail.com>
> > > > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > > > Cc: Kenneth Graunke <kenneth@whitecape.org>
> > > > Cc: mesa-dev@lists.freedesktop.org
> > > > Cc: Tony Ye <tony.ye@intel.com>
> > > > Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>
> > > > ---
> > > > include/uapi/drm/i915_drm.h | 44 ++++++++++++++++++++++++++++++++-----
> > > > 1 file changed, 39 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 5e678917da70..77e5e74c32c1 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
> > > > /**
> > > > * When the EXEC_OBJECT_PINNED flag is specified this is populated by
> > > > * the user with the GTT offset at which this object will be pinned.
> > > > + *
> > > > * When the I915_EXEC_NO_RELOC flag is specified this must contain the
> > > > * presumed_offset of the object.
> > > > + *
> > > > * During execbuffer2 the kernel populates it with the value of the
> > > > * current GTT offset of the object, for future presumed_offset writes.
> > > > + *
> > > > + * See struct drm_i915_gem_create_ext for the rules when dealing with
> > > > + * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> > > > + * minimum page sizes, like DG2.
> > > > */
> > > > __u64 offset;
> > > > @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
> > > > *
> > > > * The (page-aligned) allocated size for the object will be returned.
> > > > *
> > > > - * Note that for some devices we have might have further minimum
> > > > - * page-size restrictions(larger than 4K), like for device local-memory.
> > > > - * However in general the final size here should always reflect any
> > > > - * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > > > - * extension to place the object in device local-memory.
> > > > + *
> > > > + * DG2 64K min page size implications:
> > > > + *
> > > > + * On discrete platforms, starting from DG2, we have to contend with GTT
> > > > + * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> > > > + * objects. Specifically the hardware only supports 64K or larger GTT
> > > > + * page sizes for such memory. The kernel will already ensure that all
> > > > + * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> > > > + * sizes underneath.
> > > > + *
> > > > + * Note that the returned size here will always reflect any required
> > > > + * rounding up done by the kernel, i.e 4K will now become 64K on devices
> > > > + * such as DG2.
> > > > + *
> > > > + * Special DG2 GTT address alignment requirement:
> > > > + *
> > > > + * The GTT alignment will also need to be at least 2M for such objects.
> > > > + *
> > > > + * Note that due to how the hardware implements 64K GTT page support, we
> > > > + * have some further complications:
> > > > + *
> > > > + * 1) The entire PDE (which covers a 2MB virtual address range), must
> > > > + * contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> > > > + * PDE is forbidden by the hardware.
> > > > + *
> > > > + * 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> > > > + * objects.
> > > > + *
> > > > + * To keep things simple for userland, we mandate that any GTT mappings
> > > > + * must be aligned to and rounded up to 2MB.
> > >
> > > Could I get a clarification about this "rounded up" part.
> > >
> > > Currently Mesa is aligning the start of each and every buffer VMA to be
> > > 2MiB aligned. But, we are *not* taking any steps to "round up" the size
> > > of buffers to 2MiB alignment.
> > >
> > > Bob's Mesa MR from a while ago,
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599
> > >
> > > was trying to add this "round up" size for buffers. We didn't accept
> > > this MR because we thought if we have ensured that no other buffer will
> > > use the same 2MiB VMA range, then it should not be required.
> > >
> > > If what we are doing is ok, then maybe this "round up" language should
> > > be dropped? Or, perhaps the "round up" mentioned here isn't implying we
> > > must align the size of buffers that we create, and I'm misinterpreting
> > > this.
> > Jordan,
> >
> > as per my understanding this size rounding up to 2MB is for the VMA mapping,
> > not for the buffer size.
> correct, only the vma is rounded up
>
> >
> > Even if we drop this rounding up of vma size to 2MB but align the VMA
> > start to 2MB address then also this should be fine. Becasue the remaining of the
> > last PDE(2MB) will never be used for any other GTT mapping as the
> > starting addr wont align to 2MB.
> The kernel has to handle 4K pages also, which could in theory attempt to be
> placed in any remaining space within a 2MB region, which is not supported.
> For this reason, the kernel rounds up the vma to next 2MB to ensure no 4K
> pages can treat the remaining space as a candidate for placement.
>
> For mesa, this is not required as they only ever use 2MB alignment for all
> buffers, hence the denial of the mesa mr.
>
> Internally, the kernel will still round up the vma reservations to prevent
> any kernel 4K buffers being situated in remaining space.
>
> If desired, we can make the wording clearer, maybe something like:
>
> "To keep things simple for userland, we mandate that any GTT mappings
> must be aligned to 2MB. The kernel will internally pad them out to the next
> 2MB boundary"
Added the extra information in next version @ https://patchwork.freedesktop.org/patch/475166/?series=100419&rev=1
Jordan, hope this explanation clears your doubt.
Ram.
>
>
> >
> > Bob, Is the above understanding is right? if so could we drop the
> > requirement of mapping the vma size to 2MB?
> >
> > Ram
> > >
> > > -Jordan
> > >
> > > > As this only wastes virtual
> > > > + * address space and avoids userland having to copy any needlessly
> > > > + * complicated PDE sharing scheme (coloring) and only affects DG2, this
> > > > + * is deemed to be a good compromise.
> > > > */
> > > > __u64 size;
> > > > /**
> > > > --
> > > > 2.25.1
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
2022-02-18 18:55 ` Ramalingam C
(?)
@ 2022-02-18 19:42 ` Jordan Justen
-1 siblings, 0 replies; 37+ messages in thread
From: Jordan Justen @ 2022-02-18 19:42 UTC (permalink / raw)
To: Ramalingam C, Robert Beckett
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
David Airlie, Daniel Vetter, Matthew Auld, Thomas Hellström,
Simon Ser, Pekka Paalanen, Kenneth Graunke, mesa-dev, Tony Ye,
Slawomir Milczarek, intel-gfx, dri-devel, linux-kernel
Ramalingam C <ramalingam.c@intel.com> writes:
> On 2022-02-18 at 18:06:00 +0000, Robert Beckett wrote:
>>
>> If desired, we can make the wording clearer, maybe something like:
>>
>> "To keep things simple for userland, we mandate that any GTT mappings
>> must be aligned to 2MB. The kernel will internally pad them out to the next
>> 2MB boundary"
>
> Added the extra information in next version @
> https://patchwork.freedesktop.org/patch/475166/?series=100419&rev=1
>
> Jordan, hope this explanation clears your doubt.
Ok. It sounds like what we are doing in Mesa matches what is required by
hardware and the kernel. Thanks.
-Jordan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 19:42 ` Jordan Justen
0 siblings, 0 replies; 37+ messages in thread
From: Jordan Justen @ 2022-02-18 19:42 UTC (permalink / raw)
To: Ramalingam C, Robert Beckett
Cc: Tony Ye, Tvrtko Ursulin, dri-devel, Thomas Hellström,
David Airlie, intel-gfx, Kenneth Graunke, Slawomir Milczarek,
Matthew Auld, Rodrigo Vivi, mesa-dev, linux-kernel
Ramalingam C <ramalingam.c@intel.com> writes:
> On 2022-02-18 at 18:06:00 +0000, Robert Beckett wrote:
>>
>> If desired, we can make the wording clearer, maybe something like:
>>
>> "To keep things simple for userland, we mandate that any GTT mappings
>> must be aligned to 2MB. The kernel will internally pad them out to the next
>> 2MB boundary"
>
> Added the extra information in next version @
> https://patchwork.freedesktop.org/patch/475166/?series=100419&rev=1
>
> Jordan, hope this explanation clears your doubt.
Ok. It sounds like what we are doing in Mesa matches what is required by
hardware and the kernel. Thanks.
-Jordan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
@ 2022-02-18 19:42 ` Jordan Justen
0 siblings, 0 replies; 37+ messages in thread
From: Jordan Justen @ 2022-02-18 19:42 UTC (permalink / raw)
To: Ramalingam C, Robert Beckett
Cc: dri-devel, Thomas Hellström, David Airlie, Simon Ser,
intel-gfx, Kenneth Graunke, Slawomir Milczarek, Pekka Paalanen,
Matthew Auld, Rodrigo Vivi, mesa-dev, linux-kernel
Ramalingam C <ramalingam.c@intel.com> writes:
> On 2022-02-18 at 18:06:00 +0000, Robert Beckett wrote:
>>
>> If desired, we can make the wording clearer, maybe something like:
>>
>> "To keep things simple for userland, we mandate that any GTT mappings
>> must be aligned to 2MB. The kernel will internally pad them out to the next
>> 2MB boundary"
>
> Added the extra information in next version @
> https://patchwork.freedesktop.org/patch/475166/?series=100419&rev=1
>
> Jordan, hope this explanation clears your doubt.
Ok. It sounds like what we are doing in Mesa matches what is required by
hardware and the kernel. Thanks.
-Jordan
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2022-02-18 19:43 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-08 20:34 [PATCH v8 0/5] discrete card 64K page support Robert Beckett
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
2022-02-08 20:34 ` [PATCH v8 1/5] drm/i915: add needs_compact_pt flag Robert Beckett
2022-02-08 20:34 ` Robert Beckett
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
2022-02-08 20:34 ` [PATCH v8 2/5] drm/i915: enforce min GTT alignment for discrete cards Robert Beckett
2022-02-08 20:34 ` Robert Beckett
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
2022-02-08 20:34 ` [PATCH v8 3/5] drm/i915: support 64K GTT pages " Robert Beckett
2022-02-08 20:34 ` Robert Beckett
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
2022-02-08 20:34 ` [PATCH v8 4/5] drm/i915: add gtt misalignment test Robert Beckett
2022-02-08 20:34 ` Robert Beckett
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
2022-02-08 20:34 ` [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support Robert Beckett
2022-02-08 20:34 ` Robert Beckett
2022-02-08 20:34 ` [Intel-gfx] " Robert Beckett
2022-02-18 4:57 ` Jordan Justen
2022-02-18 4:57 ` [Intel-gfx] " Jordan Justen
2022-02-18 4:57 ` Jordan Justen
2022-02-18 13:47 ` Ramalingam C
2022-02-18 13:47 ` [Intel-gfx] " Ramalingam C
2022-02-18 13:47 ` Ramalingam C
2022-02-18 18:06 ` Robert Beckett
2022-02-18 18:06 ` [Intel-gfx] " Robert Beckett
2022-02-18 18:06 ` Robert Beckett
2022-02-18 18:55 ` Ramalingam C
2022-02-18 18:55 ` [Intel-gfx] " Ramalingam C
2022-02-18 18:55 ` Ramalingam C
2022-02-18 19:42 ` Jordan Justen
2022-02-18 19:42 ` [Intel-gfx] " Jordan Justen
2022-02-18 19:42 ` Jordan Justen
2022-02-08 22:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for discrete card 64K page support (rev6) Patchwork
2022-02-08 22:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-08 22:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-09 0:33 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-02-15 14:35 ` Robert Beckett
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.