From: David Weinehall <david.weinehall@linux.intel.com>
To: Derek Morton <derek.j.morton@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t] lib/igt_core.c: Expand --run-subtest functionality.
Date: Thu, 4 Feb 2016 13:41:49 +0200 [thread overview]
Message-ID: <20160204114149.GR3193@boom> (raw)
In-Reply-To: <1453889156-24489-1-git-send-email-derek.j.morton@intel.com>
I really like the thought of having this functionality in i-g-t,
especially if combined with my patches that allows for categorising
subtests (I'll submit a new version of those patches soon, since they
never got merged last time around). I'll refrain from bikeshedding on
the syntax.
In the longer run I think a rewrite of the subtest logic to allow not
only specifying what tests to run and/or exclude, but also to specify
what *order* to run the tests in (if reordering is possible) and to
randomise the order would be useful.
Since some testcases contain so many subtests that having those
testcases be a part of the CI/Piglit testruns isn't possible,
we need some way to have those tests run anyway.
My current train of thought is to either traverse through the tests
(1..20, 21..40, 41..60, etc.; which would require piglit to keep state,
which it currently doesn't) or to randomise a set of subtests that would
take something like 30s.
This might mean that things could slip under the radar for a long time,
but compared to today's situation where these tests aren't run at all
it'd still be an improvement.
Just my 2¢.
Kind regards, David Weinehall
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2016-02-04 11:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 10:05 [PATCH i-g-t] lib/igt_core.c: Expand --run-subtest functionality Derek Morton
2016-01-27 12:32 ` Ville Syrjälä
2016-01-27 13:30 ` Morton, Derek J
2016-01-27 14:30 ` Ville Syrjälä
2016-01-27 15:02 ` Morton, Derek J
2016-01-27 15:36 ` Ville Syrjälä
2016-01-28 8:35 ` Dave Gordon
2016-01-28 10:47 ` Morton, Derek J
2016-01-27 13:39 ` Daniel Vetter
2016-01-27 14:01 ` Morton, Derek J
2016-01-27 15:42 ` Daniel Vetter
2016-01-27 16:45 ` Morton, Derek J
2016-01-27 17:58 ` Daniel Vetter
2016-02-04 11:41 ` David Weinehall [this message]
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=20160204114149.GR3193@boom \
--to=david.weinehall@linux.intel.com \
--cc=derek.j.morton@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 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.