Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/8] lib: Introduce drmtest_skip_on_simulation()
Date: Thu, 18 Jul 2013 23:54:22 +0200	[thread overview]
Message-ID: <20130718215422.GV4550@phenom.ffwll.local> (raw)
In-Reply-To: <20130718165500.GK7379@strange.amr.corp.intel.com>

On Thu, Jul 18, 2013 at 05:55:00PM +0100, Damien Lespiau wrote:
> On Thu, Jul 18, 2013 at 09:31:15AM -0700, Ben Widawsky wrote:
> > On Thu, Jul 18, 2013 at 09:18:34AM -0700, Jesse Barnes wrote:
> > > On Thu, 18 Jul 2013 16:19:07 +0100
> > > Damien Lespiau <damien.lespiau@intel.com> wrote:
> > > 
> > > > This will allow us to explicitely blacklist tests we don't want to run
> > > > on simulation.
> > 
> > I agree with Jesse on this. Mostly what I've wanted is an "opt-in"
> > approach as opposed to an "opt-out" one. Such a thing is better
> > controlled via a Makefile target, or separate script.
> 
> Well, for this one I'd like a slightly different approach. Actually have
> a drmtest structure with metadata about the test. Something like:
> 
> #define DECLARE_SUBTEST(n, func, d)    \
>        {                               \
>                .name = n,              \
>                .run = func,            \
>                .data = d,              \
>        }
> 
> enum drmtest_category {
>        TEST_DISPLAY    = (1 << 0),
>        TEST_GT         = (1 << 1),
>        TEST_CONTEXT     = (1 << 2),
>        TEST_GEM        = (1 << 3),
>        TEST_TORTURE    = (1 << 31),
> };
> 
> 
> struct drm_subtest {
>        const char *name;
>        int (*run)(struct drm_test *test);
>        void *data;
> };
> 
> struct drm_test {
>        const char *name;
>        int fd;
>        enum drmtest_category categories;
>        int subtests_nr;
>        struct drm_subtest *subtests;
> };
> 
> and in the test:
> 
> struct drm_subtest subtests[] = {
>        DECLARE_SUBTEST("bad-close", test_bad_close, &test_data),
>        DECLARE_SUBTEST("create-close", test_create_close, &test_data),
>        DECLARE_SUBTEST("create-fd-close", test_create_fd_close, &test_data),
> };
> 
> struct drm_test test = {
>        .name = "gem-basic",
>        .subtests = subtests,
>        .subtests_nr = ARRAY_SIZE(subtests),
> };
> 
> (better macros possible)
> 
> and:
>        drmtest_init(&test, argc, argv);
>        drmtest_run(&test);
> 
> That'll allow you to do things like "please run all the context tests" for
> instance.
> 
> But well, still quite far away, and it maybe quite hard/time consuming to
> convert some tests to that.

More metaprogramming for subtest would certainly be nice, currently we use
a lot of add-hoc macro infrastructure. For a group of tests that just
share a bunch of helper functions but not the overall logic like kms_flip
approach used in prime quite a bit. Maybe we need a few different variants
to declare subtests ...

Not sure how useful the grouping of tests is, since the big usecase for
igt is to check for unrelated breakage imo. In any way we have lots of
room for improvement ;-) I've added a few points to our internal wiki for
infrastructure ideas around igt.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  parent reply	other threads:[~2013-07-18 21:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18 15:19 Provide a simulation friendly test environment v4 Damien Lespiau
2013-07-18 15:19 ` [PATCH 1/8] lib: Rename IGT_QUICK to INTEL_SIMULATION Damien Lespiau
2013-07-18 15:19 ` [PATCH 2/8] lib: Introduce drmtest_skip_on_simulation() Damien Lespiau
2013-07-18 16:18   ` Jesse Barnes
2013-07-18 16:31     ` Ben Widawsky
2013-07-18 16:55       ` Damien Lespiau
2013-07-18 16:57         ` Jesse Barnes
2013-07-18 21:54         ` Daniel Vetter [this message]
2013-07-18 16:42     ` Daniel Vetter
2013-07-18 15:19 ` [PATCH 3/8] lib: Remove old dead code intel_batchbuffer_emit_mi_flush() Damien Lespiau
2013-07-18 15:19 ` [PATCH 4/8] tests: Black list tests we don't want to run on simulation Damien Lespiau
2013-07-18 15:19 ` [PATCH 5/8] tests: Instrument tests run in simulation to run quickly Damien Lespiau
2013-07-18 15:19 ` [PATCH 6/8] tests: Instrument gem_lut_handle for simulation Damien Lespiau
2013-07-18 15:19 ` [PATCH 7/8] tests: Instrument gem_seqno_wrap to run in simulation Damien Lespiau
2013-07-18 15:19 ` [PATCH 8/8] tests: Add some tiled tests to the runs on simulation Damien Lespiau
2013-07-18 15:50 ` Provide a simulation friendly test environment v4 Daniel Vetter
2013-07-19 11:21   ` Damien Lespiau

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=20130718215422.GV4550@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --cc=damien.lespiau@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