[PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Janusz Krzysztofik]

Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT.  Unfortunately, that filtering
is unconditional, no matter if running on old shared GTT or not.  When
running on PPGTT, that may result in errors other than those intended
to be skipped over being silently ignored.

Skip over unavailable addresses only when not running on PPGTT.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/i915/gem_exec_reloc.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..8f88826e 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -539,12 +539,13 @@ static void basic_range(int fd, unsigned flags)
 		obj[n].offset = (1ull << (i + 12)) - 4096;
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
-		gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
-		execbuf.buffers_ptr = to_user_pointer(&obj[n]);
-		execbuf.buffer_count = 1;
-		if (__gem_execbuf(fd, &execbuf))
-			continue;
-
+		if (!gem_uses_ppgtt(fd)) {
+			gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
+			execbuf.buffers_ptr = to_user_pointer(&obj[n]);
+			execbuf.buffer_count = 1;
+			if (__gem_execbuf(fd, &execbuf))
+				continue;
+		}
 		igt_debug("obj[%d] handle=%d, address=%llx\n",
 			  n, obj[n].handle, (long long)obj[n].offset);
 
@@ -559,12 +560,13 @@ static void basic_range(int fd, unsigned flags)
 		obj[n].offset = 1ull << (i + 12);
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
-		gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
-		execbuf.buffers_ptr = to_user_pointer(&obj[n]);
-		execbuf.buffer_count = 1;
-		if (__gem_execbuf(fd, &execbuf))
-			continue;
-
+		if (!gem_uses_ppgtt(fd)) {
+			gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
+			execbuf.buffers_ptr = to_user_pointer(&obj[n]);
+			execbuf.buffer_count = 1;
+			if (__gem_execbuf(fd, &execbuf))
+				continue;
+		}
 		igt_debug("obj[%d] handle=%d, address=%llx\n",
 			  n, obj[n].handle, (long long)obj[n].offset);
 
-- 
2.21.0

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

[Intel-gfx] [PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Janusz Krzysztofik]

Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT.  Unfortunately, that filtering
is unconditional, no matter if running on old shared GTT or not.  When
running on PPGTT, that may result in errors other than those intended
to be skipped over being silently ignored.

Skip over unavailable addresses only when not running on PPGTT.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/i915/gem_exec_reloc.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..8f88826e 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -539,12 +539,13 @@ static void basic_range(int fd, unsigned flags)
 		obj[n].offset = (1ull << (i + 12)) - 4096;
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
-		gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
-		execbuf.buffers_ptr = to_user_pointer(&obj[n]);
-		execbuf.buffer_count = 1;
-		if (__gem_execbuf(fd, &execbuf))
-			continue;
-
+		if (!gem_uses_ppgtt(fd)) {
+			gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
+			execbuf.buffers_ptr = to_user_pointer(&obj[n]);
+			execbuf.buffer_count = 1;
+			if (__gem_execbuf(fd, &execbuf))
+				continue;
+		}
 		igt_debug("obj[%d] handle=%d, address=%llx\n",
 			  n, obj[n].handle, (long long)obj[n].offset);
 
@@ -559,12 +560,13 @@ static void basic_range(int fd, unsigned flags)
 		obj[n].offset = 1ull << (i + 12);
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
-		gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
-		execbuf.buffers_ptr = to_user_pointer(&obj[n]);
-		execbuf.buffer_count = 1;
-		if (__gem_execbuf(fd, &execbuf))
-			continue;
-
+		if (!gem_uses_ppgtt(fd)) {
+			gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
+			execbuf.buffers_ptr = to_user_pointer(&obj[n]);
+			execbuf.buffer_count = 1;
+			if (__gem_execbuf(fd, &execbuf))
+				continue;
+		}
 		igt_debug("obj[%d] handle=%d, address=%llx\n",
 			  n, obj[n].handle, (long long)obj[n].offset);
 
-- 
2.21.0

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

[PATCH i-g-t 2/2] tests/gem_exec_reloc: Calculate softpin offsets from batch size

[Janusz Krzysztofik]

From: Janusz Krzysztofik <janusz.krzysztofik@intel.com>

The basic-range subtest assumes 4kB minimum batch size.  On future
backends with possibly bigger minimum batch sizes this subtest will
fail as buffer objects may overlap.  To avoid object overlapping,
offsets need to be calculated with actual minimum batch size in mind.

Replace hardcoded constants corresponding to the assumed 4kB minimum
batch size with values calculated from a variable supposed to represent
actual batch size.  For now, the variable is still initialized with the
4kB value, suitable for backends currently supported by IGT.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@intel.com>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
---
 tests/i915/gem_exec_reloc.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 8f88826e..8d2f10ac 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -518,16 +518,21 @@ static void basic_range(int fd, unsigned flags)
 	struct drm_i915_gem_execbuffer2 execbuf;
 	uint64_t address_mask = has_64b_reloc(fd) ? ~(uint64_t)0 : ~(uint32_t)0;
 	uint64_t gtt_size = gem_aperture_size(fd);
+	/* FIXME: switch to a suitable library function when available */
+	uint64_t batch_size = 4096;
 	const uint32_t bbe = MI_BATCH_BUFFER_END;
 	igt_spin_t *spin = NULL;
-	int count, n;
+	int batch_order, count, n;
 
 	igt_require(gem_has_softpin(fd));
 
-	for (count = 12; gtt_size >> (count + 1); count++)
+	for (batch_order = 0; batch_size >> (batch_order + 1); batch_order++)
 		;
 
-	count -= 12;
+	for (count = batch_order; gtt_size >> (count + 1); count++)
+		;
+
+	count -= batch_order;
 
 	memset(obj, 0, sizeof(obj));
 	memset(reloc, 0, sizeof(reloc));
@@ -535,8 +540,8 @@ static void basic_range(int fd, unsigned flags)
 
 	n = 0;
 	for (int i = 0; i <= count; i++) {
-		obj[n].handle = gem_create(fd, 4096);
-		obj[n].offset = (1ull << (i + 12)) - 4096;
+		obj[n].handle = gem_create(fd, batch_size);
+		obj[n].offset = (1ull << (i + batch_order)) - batch_size;
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 		if (!gem_uses_ppgtt(fd)) {
@@ -556,8 +561,8 @@ static void basic_range(int fd, unsigned flags)
 		n++;
 	}
 	for (int i = 1; i < count; i++) {
-		obj[n].handle = gem_create(fd, 4096);
-		obj[n].offset = 1ull << (i + 12);
+		obj[n].handle = gem_create(fd, batch_size);
+		obj[n].offset = 1ull << (i + batch_order);
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 		if (!gem_uses_ppgtt(fd)) {
@@ -578,7 +583,7 @@ static void basic_range(int fd, unsigned flags)
 	}
 	igt_require(n);
 
-	obj[n].handle = gem_create(fd, 4096);
+	obj[n].handle = gem_create(fd, batch_size);
 	obj[n].relocs_ptr = to_user_pointer(reloc);
 	obj[n].relocation_count = n;
 	gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
-- 
2.21.0

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

[Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_reloc: Calculate softpin offsets from batch size

[Janusz Krzysztofik]

From: Janusz Krzysztofik <janusz.krzysztofik@intel.com>

The basic-range subtest assumes 4kB minimum batch size.  On future
backends with possibly bigger minimum batch sizes this subtest will
fail as buffer objects may overlap.  To avoid object overlapping,
offsets need to be calculated with actual minimum batch size in mind.

Replace hardcoded constants corresponding to the assumed 4kB minimum
batch size with values calculated from a variable supposed to represent
actual batch size.  For now, the variable is still initialized with the
4kB value, suitable for backends currently supported by IGT.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@intel.com>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
---
 tests/i915/gem_exec_reloc.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 8f88826e..8d2f10ac 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -518,16 +518,21 @@ static void basic_range(int fd, unsigned flags)
 	struct drm_i915_gem_execbuffer2 execbuf;
 	uint64_t address_mask = has_64b_reloc(fd) ? ~(uint64_t)0 : ~(uint32_t)0;
 	uint64_t gtt_size = gem_aperture_size(fd);
+	/* FIXME: switch to a suitable library function when available */
+	uint64_t batch_size = 4096;
 	const uint32_t bbe = MI_BATCH_BUFFER_END;
 	igt_spin_t *spin = NULL;
-	int count, n;
+	int batch_order, count, n;
 
 	igt_require(gem_has_softpin(fd));
 
-	for (count = 12; gtt_size >> (count + 1); count++)
+	for (batch_order = 0; batch_size >> (batch_order + 1); batch_order++)
 		;
 
-	count -= 12;
+	for (count = batch_order; gtt_size >> (count + 1); count++)
+		;
+
+	count -= batch_order;
 
 	memset(obj, 0, sizeof(obj));
 	memset(reloc, 0, sizeof(reloc));
@@ -535,8 +540,8 @@ static void basic_range(int fd, unsigned flags)
 
 	n = 0;
 	for (int i = 0; i <= count; i++) {
-		obj[n].handle = gem_create(fd, 4096);
-		obj[n].offset = (1ull << (i + 12)) - 4096;
+		obj[n].handle = gem_create(fd, batch_size);
+		obj[n].offset = (1ull << (i + batch_order)) - batch_size;
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 		if (!gem_uses_ppgtt(fd)) {
@@ -556,8 +561,8 @@ static void basic_range(int fd, unsigned flags)
 		n++;
 	}
 	for (int i = 1; i < count; i++) {
-		obj[n].handle = gem_create(fd, 4096);
-		obj[n].offset = 1ull << (i + 12);
+		obj[n].handle = gem_create(fd, batch_size);
+		obj[n].offset = 1ull << (i + batch_order);
 		obj[n].offset = gen8_canonical_address(obj[n].offset);
 		obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
 		if (!gem_uses_ppgtt(fd)) {
@@ -578,7 +583,7 @@ static void basic_range(int fd, unsigned flags)
 	}
 	igt_require(n);
 
-	obj[n].handle = gem_create(fd, 4096);
+	obj[n].handle = gem_create(fd, batch_size);
 	obj[n].relocs_ptr = to_user_pointer(reloc);
 	obj[n].relocation_count = n;
 	gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
-- 
2.21.0

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

Re: [PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Chris Wilson]

Quoting Janusz Krzysztofik (2019-10-23 10:07:51)
> Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> addresses for !ppgtt") introduced filtering of addresses possibly
> occupied by other users of shared GTT.  Unfortunately, that filtering
> is unconditional, no matter if running on old shared GTT or not.  When
> running on PPGTT, that may result in errors other than those intended
> to be skipped over being silently ignored.

You forgot the aliasing-ppgtt which has exactly the same issues with
reserved locations (since it is a mirror of the GGTT).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Chris Wilson]

Quoting Janusz Krzysztofik (2019-10-23 10:07:51)
> Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> addresses for !ppgtt") introduced filtering of addresses possibly
> occupied by other users of shared GTT.  Unfortunately, that filtering
> is unconditional, no matter if running on old shared GTT or not.  When
> running on PPGTT, that may result in errors other than those intended
> to be skipped over being silently ignored.

You forgot the aliasing-ppgtt which has exactly the same issues with
reserved locations (since it is a mirror of the GGTT).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Chris Wilson]

Quoting Janusz Krzysztofik (2019-10-23 10:07:51)
> Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> addresses for !ppgtt") introduced filtering of addresses possibly
> occupied by other users of shared GTT.  Unfortunately, that filtering
> is unconditional, no matter if running on old shared GTT or not.  When
> running on PPGTT, that may result in errors other than those intended
> to be skipped over being silently ignored.

You forgot the aliasing-ppgtt which has exactly the same issues with
reserved locations (since it is a mirror of the GGTT).
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t 2/2] tests/gem_exec_reloc: Calculate softpin offsets from batch size

[Chris Wilson]

Quoting Janusz Krzysztofik (2019-10-23 10:07:52)
> From: Janusz Krzysztofik <janusz.krzysztofik@intel.com>
> 
> The basic-range subtest assumes 4kB minimum batch size.  On future
> backends with possibly bigger minimum batch sizes this subtest will
> fail as buffer objects may overlap.  To avoid object overlapping,
> offsets need to be calculated with actual minimum batch size in mind.
> 
> Replace hardcoded constants corresponding to the assumed 4kB minimum
> batch size with values calculated from a variable supposed to represent
> actual batch size.  For now, the variable is still initialized with the
> 4kB value, suitable for backends currently supported by IGT.

You could do this entirely within the reloc API, no? By probing whether
a 4KiB offset is legal?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_reloc: Calculate softpin offsets from batch size

[Chris Wilson]

Quoting Janusz Krzysztofik (2019-10-23 10:07:52)
> From: Janusz Krzysztofik <janusz.krzysztofik@intel.com>
> 
> The basic-range subtest assumes 4kB minimum batch size.  On future
> backends with possibly bigger minimum batch sizes this subtest will
> fail as buffer objects may overlap.  To avoid object overlapping,
> offsets need to be calculated with actual minimum batch size in mind.
> 
> Replace hardcoded constants corresponding to the assumed 4kB minimum
> batch size with values calculated from a variable supposed to represent
> actual batch size.  For now, the variable is still initialized with the
> 4kB value, suitable for backends currently supported by IGT.

You could do this entirely within the reloc API, no? By probing whether
a 4KiB offset is legal?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 2/2] tests/gem_exec_reloc: Calculate softpin offsets from batch size

[Janusz Krzysztofik]

Hi Chris,

On Wednesday, October 23, 2019 11:13:02 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-23 10:07:52)
> > From: Janusz Krzysztofik <janusz.krzysztofik@intel.com>
> > 
> > The basic-range subtest assumes 4kB minimum batch size.  On future
> > backends with possibly bigger minimum batch sizes this subtest will
> > fail as buffer objects may overlap.  To avoid object overlapping,
> > offsets need to be calculated with actual minimum batch size in mind.
> > 
> > Replace hardcoded constants corresponding to the assumed 4kB minimum
> > batch size with values calculated from a variable supposed to represent
> > actual batch size.  For now, the variable is still initialized with the
> > 4kB value, suitable for backends currently supported by IGT.
> 
> You could do this entirely within the reloc API, no? By probing whether
> a 4KiB offset is legal?

Thanks for the hint, I'll try to take this path.
Janusz

> -Chris
> 




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

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_reloc: Calculate softpin offsets from batch size

[Janusz Krzysztofik]

Hi Chris,

On Wednesday, October 23, 2019 11:13:02 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-23 10:07:52)
> > From: Janusz Krzysztofik <janusz.krzysztofik@intel.com>
> > 
> > The basic-range subtest assumes 4kB minimum batch size.  On future
> > backends with possibly bigger minimum batch sizes this subtest will
> > fail as buffer objects may overlap.  To avoid object overlapping,
> > offsets need to be calculated with actual minimum batch size in mind.
> > 
> > Replace hardcoded constants corresponding to the assumed 4kB minimum
> > batch size with values calculated from a variable supposed to represent
> > actual batch size.  For now, the variable is still initialized with the
> > 4kB value, suitable for backends currently supported by IGT.
> 
> You could do this entirely within the reloc API, no? By probing whether
> a 4KiB offset is legal?

Thanks for the hint, I'll try to take this path.
Janusz

> -Chris
> 




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

Re: [PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Janusz Krzysztofik]

Hi Chris,

On Wednesday, October 23, 2019 11:11:35 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-23 10:07:51)
> > Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> > addresses for !ppgtt") introduced filtering of addresses possibly
> > occupied by other users of shared GTT.  Unfortunately, that filtering
> > is unconditional, no matter if running on old shared GTT or not.  When
> > running on PPGTT, that may result in errors other than those intended
> > to be skipped over being silently ignored.
> 
> You forgot the aliasing-ppgtt which has exactly the same issues with
> reserved locations (since it is a mirror of the GGTT).

OK, let me check if the aliasing-ppgtt case can be addressed.

Thanks,
Janusz

> -Chris
> 




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

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Janusz Krzysztofik]

Hi Chris,

On Wednesday, October 23, 2019 11:11:35 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-23 10:07:51)
> > Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> > addresses for !ppgtt") introduced filtering of addresses possibly
> > occupied by other users of shared GTT.  Unfortunately, that filtering
> > is unconditional, no matter if running on old shared GTT or not.  When
> > running on PPGTT, that may result in errors other than those intended
> > to be skipped over being silently ignored.
> 
> You forgot the aliasing-ppgtt which has exactly the same issues with
> reserved locations (since it is a mirror of the GGTT).

OK, let me check if the aliasing-ppgtt case can be addressed.

Thanks,
Janusz

> -Chris
> 




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

[igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT

[Patchwork]

== Series Details ==

Series: series starting with [i-g-t,1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT
URL   : https://patchwork.freedesktop.org/series/68447/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7157 -> IGTPW_3597
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Possible fixes ####

  * igt@i915_selftest@live_execlists:
    - fi-icl-u2:          [DMESG-FAIL][1] ([fdo#112046]) -> [PASS][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7157/fi-icl-u2/igt@i915_selftest@live_execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3597/fi-icl-u2/igt@i915_selftest@live_execlists.html

  * {igt@i915_selftest@live_gt_heartbeat}:
    - fi-cfl-8109u:       [DMESG-FAIL][3] ([fdo#112096]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7157/fi-cfl-8109u/igt@i915_selftest@live_gt_heartbeat.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3597/fi-cfl-8109u/igt@i915_selftest@live_gt_heartbeat.html

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

  [fdo#112046]: https://bugs.freedesktop.org/show_bug.cgi?id=112046
  [fdo#112096]: https://bugs.freedesktop.org/show_bug.cgi?id=112096


Participating hosts (36 -> 36)
------------------------------

  Additional (7): fi-kbl-soraka fi-byt-j1900 fi-snb-2520m fi-kbl-7500u fi-pnv-d510 fi-bsw-kefka fi-icl-guc 
  Missing    (7): fi-bxt-dsi fi-bsw-cyan fi-byt-clapper fi-icl-u3 fi-icl-y fi-icl-dsi fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5235 -> IGTPW_3597

  CI-20190529: 20190529
  CI_DRM_7157: a95fb31a3271f72325447d5027597b4562e31f50 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3597: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3597/index.html
  IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3597/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev