public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH v2 7/7] drm/i915/selftests: add sanity selftest for huge-GTT-pages
Date: Mon, 21 Oct 2019 20:27:47 +0100	[thread overview]
Message-ID: <20191021192747.24804-7-matthew.auld@intel.com> (raw)
In-Reply-To: <20191021192747.24804-1-matthew.auld@intel.com>

Now that for all the relevant backends we do randomised testing, we need
to make sure we still sanity check the obvious cases that might blow up,
such that introducing a temporary regression is less likely.  Also
rather than do this for every backend, just limit to our two memory
types: system and local.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   | 103 ++++++++++++++++++
 1 file changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 1d7c2a50d636..fee8a6c338b8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1505,6 +1505,108 @@ static int igt_ppgtt_lmem_huge(void *arg)
 	return err;
 }
 
+static struct drm_i915_gem_object *
+igt_create_local(struct drm_i915_private *i915, u32 size)
+{
+	return i915_gem_object_create_lmem(i915, size, I915_ALLOC_CONTIGUOUS);
+}
+
+static struct drm_i915_gem_object *
+igt_create_system(struct drm_i915_private *i915, u32 size)
+{
+	return huge_pages_object(i915, size, size);
+}
+
+typedef struct drm_i915_gem_object *
+(*igt_create_fn)(struct drm_i915_private *i915, u32 size);
+
+static int igt_ppgtt_sanity_check(void *arg)
+{
+	struct i915_gem_context *ctx = arg;
+	struct drm_i915_private *i915 = ctx->i915;
+	unsigned int supported = INTEL_INFO(i915)->page_sizes;
+	struct {
+		u32 size;
+		u32 pages;
+	} combos[] = {
+		{ SZ_64K, 	  SZ_64K,          },
+		{ SZ_2M,          SZ_2M,           },
+		{ SZ_2M,          SZ_64K,          },
+		{ SZ_2M + SZ_4K,  SZ_64K | SZ_4K,  },
+		{ SZ_2M + SZ_4K,  SZ_2M  | SZ_4K,  },
+		{ SZ_2M + SZ_64K, SZ_2M  | SZ_64K, },
+	};
+	igt_create_fn fns[] = {
+		igt_create_local,
+		igt_create_system,
+	};
+	int i, j;
+	int err;
+
+	if (supported == I915_GTT_PAGE_SIZE_4K)
+		return 0;
+
+	/*
+	 * Sanity check that the HW behaves with a limited set of combinations.
+	 * We already have a bunch of randomised testing, which should give us
+	 * a decent amount of variation between runs, however we should keep
+	 * this to limit the chances of introducing a temporary regression, by
+	 * testing the most obvious cases that might make something blow up.
+	 */
+
+	for (i = 0; i < ARRAY_SIZE(fns); ++i) {
+		for (j = 0; j < ARRAY_SIZE(combos); ++j) {
+			struct drm_i915_gem_object *obj;
+			u32 size = combos[j].size;
+			u32 pages = combos[j].pages;
+
+			obj = fns[i](i915, size);
+			if (IS_ERR(obj)) {
+				err = PTR_ERR(obj);
+				if (err == -ENODEV) {
+					pr_info("Device lacks local memory, skipping\n");
+					err = 0;
+					break;
+				}
+
+				return err;
+			}
+
+			err = i915_gem_object_pin_pages(obj);
+			if (err) {
+				i915_gem_object_put(obj);
+				goto out;
+			}
+
+			GEM_BUG_ON(pages > obj->base.size);
+			pages = pages & supported;
+
+			if (pages)
+				obj->mm.page_sizes.sg = pages;
+
+			err = igt_write_huge(ctx, obj);
+
+			i915_gem_object_unpin_pages(obj);
+			__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+			i915_gem_object_put(obj);
+
+			if (err) {
+				pr_err("%s write-huge failed with size=%u pages=%u i=%d, j=%d\n",
+				       __func__, size, pages, i, j);
+				goto out;
+			}
+		}
+
+		cond_resched();
+	}
+
+out:
+	if (err == -ENOMEM)
+		err = 0;
+
+	return err;
+}
+
 static int igt_ppgtt_pin_update(void *arg)
 {
 	struct i915_gem_context *ctx = arg;
@@ -1867,6 +1969,7 @@ int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
 		SUBTEST(igt_ppgtt_gemfs_huge),
 		SUBTEST(igt_ppgtt_internal_huge),
 		SUBTEST(igt_ppgtt_lmem_huge),
+		SUBTEST(igt_ppgtt_sanity_check),
 	};
 	struct drm_file *file;
 	struct i915_gem_context *ctx;
-- 
2.20.1

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

  parent reply	other threads:[~2019-10-21 19:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21 19:27 [PATCH v2 1/7] drm/i915: support creating LMEM objects Matthew Auld
2019-10-21 19:27 ` [PATCH v2 2/7] drm/i915: setup io-mapping for LMEM Matthew Auld
2019-10-21 19:27 ` [PATCH v2 3/7] drm/i915/lmem: support kernel mapping Matthew Auld
2019-10-21 19:37   ` Chris Wilson
2019-10-21 19:39     ` Chris Wilson
2019-10-21 19:27 ` [PATCH v2 4/7] drm/i915/selftests: add write-dword test for LMEM Matthew Auld
2019-10-21 19:27 ` [PATCH v2 5/7] drm/i915/selftests: extend coverage to include LMEM huge-pages Matthew Auld
2019-10-21 19:27 ` [PATCH v2 6/7] drm/i915/selftests: prefer random sizes for the huge-GTT-page smoke tests Matthew Auld
2019-10-21 19:27 ` Matthew Auld [this message]
2019-10-21 20:28   ` [PATCH v2 7/7] drm/i915/selftests: add sanity selftest for huge-GTT-pages Chris Wilson
2019-10-21 20:24 ` [PATCH v2 1/7] drm/i915: support creating LMEM objects Chris Wilson

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=20191021192747.24804-7-matthew.auld@intel.com \
    --to=matthew.auld@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox