From: Vanshidhar Konda <vanshidhar.r.konda@intel.com>
To: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, igt-dev@lists.freedesktop.org
Subject: Re: [RFC PATCH i-g-t v4 1/4] tests/gem_exec_reloc: Don't filter out invalid addresses
Date: Thu, 31 Oct 2019 09:59:50 -0700 [thread overview]
Message-ID: <20191031165950.jytjykldypucxksd@vrkonda-desk.ra.intel.com> (raw)
In-Reply-To: <20191031152857.17143-2-janusz.krzysztofik@linux.intel.com>
May be this patch can just be merged with the other patch in this series
that changes gem_exec_reloc.
Vanshi
On Thu, Oct 31, 2019 at 04:28:54PM +0100, Janusz Krzysztofik wrote:
>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
>doesn't distinguish between actually occupied addresses and otherwise
>invalid softpin offsets. As soon as incorrect GTT alignment is assumed
>when running on future backends with possibly larger minimum page
>sizes, a half of calculated offsets to be tested will be incorrectly
>detected as occupied by other users and silently skipped instead of
>reported as a problem. That will significantly distort the intended
>test pattern.
>
>Filter out failing addresses only if not reported as invalid.
>
>v2: Skip unavailable addresses only when not running on full PPGTT.
>v3: Replace the not on full PPGTT requirement for skipping with error
> code checking.
>
>Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>Cc: Chris Wilson <chris@chris-wilson.co.uk>
>---
> tests/i915/gem_exec_reloc.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>index 5f59fe99..423fed8b 100644
>--- a/tests/i915/gem_exec_reloc.c
>+++ b/tests/i915/gem_exec_reloc.c
>@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> uint64_t gtt_size = gem_aperture_size(fd);
> const uint32_t bbe = MI_BATCH_BUFFER_END;
> igt_spin_t *spin = NULL;
>- int count, n;
>+ int count, n, err;
>
> igt_require(gem_has_softpin(fd));
>
>@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> 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))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> continue;
>+ }
>
> igt_debug("obj[%d] handle=%d, address=%llx\n",
> n, obj[n].handle, (long long)obj[n].offset);
>@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> 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))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Vanshidhar Konda <vanshidhar.r.konda@intel.com>
To: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, igt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC PATCH i-g-t v4 1/4] tests/gem_exec_reloc: Don't filter out invalid addresses
Date: Thu, 31 Oct 2019 09:59:50 -0700 [thread overview]
Message-ID: <20191031165950.jytjykldypucxksd@vrkonda-desk.ra.intel.com> (raw)
Message-ID: <20191031165950.-Er0MBzmv6VhcgJtN-u2b8B_15Kbq2_yc1W_qd86R4E@z> (raw)
In-Reply-To: <20191031152857.17143-2-janusz.krzysztofik@linux.intel.com>
May be this patch can just be merged with the other patch in this series
that changes gem_exec_reloc.
Vanshi
On Thu, Oct 31, 2019 at 04:28:54PM +0100, Janusz Krzysztofik wrote:
>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
>doesn't distinguish between actually occupied addresses and otherwise
>invalid softpin offsets. As soon as incorrect GTT alignment is assumed
>when running on future backends with possibly larger minimum page
>sizes, a half of calculated offsets to be tested will be incorrectly
>detected as occupied by other users and silently skipped instead of
>reported as a problem. That will significantly distort the intended
>test pattern.
>
>Filter out failing addresses only if not reported as invalid.
>
>v2: Skip unavailable addresses only when not running on full PPGTT.
>v3: Replace the not on full PPGTT requirement for skipping with error
> code checking.
>
>Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>Cc: Chris Wilson <chris@chris-wilson.co.uk>
>---
> tests/i915/gem_exec_reloc.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>index 5f59fe99..423fed8b 100644
>--- a/tests/i915/gem_exec_reloc.c
>+++ b/tests/i915/gem_exec_reloc.c
>@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> uint64_t gtt_size = gem_aperture_size(fd);
> const uint32_t bbe = MI_BATCH_BUFFER_END;
> igt_spin_t *spin = NULL;
>- int count, n;
>+ int count, n, err;
>
> igt_require(gem_has_softpin(fd));
>
>@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> 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))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> continue;
>+ }
>
> igt_debug("obj[%d] handle=%d, address=%llx\n",
> n, obj[n].handle, (long long)obj[n].offset);
>@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> 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))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> 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
next prev parent reply other threads:[~2019-10-31 16:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-31 15:28 [RFC PATCH i-g-t v4 0/4] Calculate softpin offsets from minimum GTT alignment Janusz Krzysztofik
2019-10-31 15:28 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-31 15:28 ` [RFC PATCH i-g-t v4 1/4] tests/gem_exec_reloc: Don't filter out invalid addresses Janusz Krzysztofik
2019-10-31 15:28 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-31 16:59 ` Vanshidhar Konda [this message]
2019-10-31 16:59 ` Vanshidhar Konda
2019-11-04 9:16 ` Janusz Krzysztofik
2019-11-04 9:16 ` [Intel-gfx] " Janusz Krzysztofik
2019-11-01 10:02 ` Chris Wilson
2019-11-01 10:02 ` [igt-dev] " Chris Wilson
2019-11-01 10:02 ` [Intel-gfx] " Chris Wilson
2019-11-04 9:13 ` Janusz Krzysztofik
2019-11-04 9:13 ` [Intel-gfx] " Janusz Krzysztofik
2019-11-04 9:17 ` Chris Wilson
2019-11-04 9:17 ` [igt-dev] " Chris Wilson
2019-11-04 9:17 ` [Intel-gfx] " Chris Wilson
2019-10-31 15:28 ` [RFC PATCH i-g-t v4 2/4] lib: Add minimum GTT alignment helper Janusz Krzysztofik
2019-10-31 15:28 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-31 16:58 ` Vanshidhar Konda
2019-10-31 16:58 ` [Intel-gfx] " Vanshidhar Konda
2019-11-04 14:40 ` Janusz Krzysztofik
2019-11-04 14:40 ` [Intel-gfx] " Janusz Krzysztofik
2019-11-01 10:08 ` Chris Wilson
2019-11-01 10:08 ` [igt-dev] " Chris Wilson
2019-11-01 10:08 ` [Intel-gfx] " Chris Wilson
2019-11-04 9:23 ` Janusz Krzysztofik
2019-11-04 9:23 ` [Intel-gfx] " Janusz Krzysztofik
2019-11-04 9:28 ` Chris Wilson
2019-11-04 9:28 ` [Intel-gfx] " Chris Wilson
2019-11-04 10:26 ` Janusz Krzysztofik
2019-11-04 10:26 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-31 15:28 ` [RFC PATCH i-g-t v4 3/4] tests/gem_exec_reloc: Calculate offsets from minimum GTT alignment Janusz Krzysztofik
2019-10-31 15:28 ` [Intel-gfx] " Janusz Krzysztofik
2019-11-01 10:11 ` Chris Wilson
2019-11-01 10:11 ` [igt-dev] " Chris Wilson
2019-11-01 10:11 ` [Intel-gfx] " Chris Wilson
2019-10-31 15:28 ` [RFC PATCH i-g-t v4 4/4] tests/gem_ctx_shared: Align objects using " Janusz Krzysztofik
2019-10-31 15:28 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-31 17:00 ` Vanshidhar Konda
2019-10-31 17:00 ` [Intel-gfx] " Vanshidhar Konda
2019-11-01 9:42 ` Chris Wilson
2019-11-01 9:42 ` [Intel-gfx] " Chris Wilson
2019-11-01 10:11 ` Chris Wilson
2019-11-01 10:11 ` [igt-dev] " Chris Wilson
2019-11-01 10:11 ` [Intel-gfx] " Chris Wilson
2019-11-04 9:39 ` Janusz Krzysztofik
2019-11-04 9:39 ` [Intel-gfx] " Janusz Krzysztofik
2019-11-04 9:47 ` Chris Wilson
2019-11-04 9:47 ` [igt-dev] " Chris Wilson
2019-11-04 9:47 ` [Intel-gfx] " Chris Wilson
2019-10-31 16:47 ` [igt-dev] ✓ Fi.CI.BAT: success for Calculate softpin offsets from " Patchwork
2019-11-01 19:09 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191031165950.jytjykldypucxksd@vrkonda-desk.ra.intel.com \
--to=vanshidhar.r.konda@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=janusz.krzysztofik@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.