From: Daniel Vetter <daniel@ffwll.ch>
To: "Kempczynski, Zbigniew" <zbigniew.kempczynski@intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [igt-dev] [RFC] IGT device scanning and selection
Date: Wed, 5 Jun 2019 14:31:09 +0200 [thread overview]
Message-ID: <20190605123109.GR21222@phenom.ffwll.local> (raw)
In-Reply-To: <6bb5d8cf375fc1ce0f8afdddddbde87866c11b9e.camel@intel.com>
On Tue, Jun 04, 2019 at 08:47:12AM +0000, Kempczynski, Zbigniew wrote:
> On Tue, 2019-06-04 at 11:36 +0300, Arkadiusz Hiler wrote:
> >
> > Hey,
> >
> > Seems like a well-written verbalization of some of the ideas that were
> > floating around since XDC. Thanks!
> >
> >
> > Couple of points that were not captured here:
> >
> > 1. We should have an option to set device via .igtrc and IGT_DEVICE env
> > variable too. ENV variable would take precedence over .igtrc, and
> > --device switch would take precedence over both of the other methods.
> >
> > That would help a lot with both automatization and having some defaults
> > for local development.
>
> Acked. I'll follow this override path.
>
> >
> >
> > 2. What to do with drm_open_driver(DRIVER_INTEL) et al?
> >
> > Simplest solution would be to just skip if we are --device-ing a card
> > that does not meet those "constraints", but we may want to rework those
> > a bit?
> >
>
> IMHO --device specification should override this vendor requirement
> constraint. Using globals is not pretty solution but allows easily
> adds new device selection without rewritting all tests.
We still need to follow DRIVER_INTEL/DRIVER_AMD constraints. You can't run
an i915 gem tests on amdgpu or the other way round. So allowing these
options to overwrite these test constraints sounds like a bad idea to me.
Also, we can't blindly skip either, because some tests want to have an
intel and an amdgpu (e.g. kbl-g), and then tests dma-buf sharing between
the two.
So this all gets a bit tricky, and it's the reason why have the current
somewhat silly device selection logic. I think the only option for these
is that they would indicate the preferred device, but we'll pick another
one if that is present and fullfills the criteria. At least as an initial
step.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-06-05 12:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 8:09 [igt-dev] [RFC] IGT device scanning and selection Kempczynski, Zbigniew
2019-06-04 8:29 ` Ser, Simon
2019-06-04 9:10 ` Michał Winiarski
2019-06-04 8:36 ` Arkadiusz Hiler
2019-06-04 8:47 ` Kempczynski, Zbigniew
2019-06-05 12:31 ` Daniel Vetter [this message]
2019-06-05 12:35 ` Daniel Vetter
2019-06-06 9:35 ` Kempczynski, Zbigniew
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=20190605123109.GR21222@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=igt-dev@lists.freedesktop.org \
--cc=zbigniew.kempczynski@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox