From: "Kempczynski, Zbigniew" <zbigniew.kempczynski@intel.com>
To: "Vasilev, Oleg" <oleg.vasilev@intel.com>,
"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Cc: "Latvala, Petri" <petri.latvala@intel.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>
Subject: Re: [igt-dev] [EARLY RFC 1/1] Introduce new method of device selection
Date: Tue, 2 Jul 2019 07:38:10 +0000 [thread overview]
Message-ID: <aa67b24e7e8287ee230cbe3544b8d9079f134260.camel@intel.com> (raw)
In-Reply-To: <d22e4f02cb7876ccf6d6a5501ca2a07d45411bd1.camel@intel.com>
On Mon, 2019-07-01 at 21:57 +0100, Vasilev, Oleg wrote:
> Hi,
>
> First of all, thanks for working on this. This will definitely be
> useful.
>
> On Mon, 2019-07-01 at 15:03 +0200, Zbigniew Kempczyński wrote:
> > Change adds device selection based on implemented filters. Currently
> > drm, dev and pci filters were added to address different device
> > selection possibilities.
> >
> > drm filter allows selection /dev/dri/cardN node by using filter
> > drm:card=N
> > where N is number of card.
> >
> > dev filter allows selection of N-th device in all gpus avilable
> > (PCI devices at the moment). Regardless of driver load time
> > and /dev/dri/cardN this filter will select same device until
> > new card will be added. Filter syntax is as follows:
> > dev:card=N
>
> I am not sure I understand the purpose of this method. The first is
> mostly for debugging. The third one is used to specify the exact
> device. Why do we need this?
Let we have two cards, first on pci slot 0000:00:01.0, second
on 0000:00:02.0. Driver module load time makes influence which device
will have /dev/dri/card0 and which /dev/dri/card1.
Filter 'drm:card=0' always will return you /dev/dri/card0.
Filter 'dev:card=0' will return you /dev/dri/card0 or /dev/dri/card1
because it will find first card on PCI bus.
> > pci filter gives vendor / device / card number selection. Only
> > cards which match this filter will be returned. Filter syntax:
> > pci:vendor=xxxx,device=yyyy,card=N
> > where xxxx, yyyy are hex numbers which identify vendor and device,
> > card selects N-th matching card.
> > New device selection uses --device filter or IGT_DEVICE environent
> > variable.
>
> I think, we are still missing a method for specifying the device in a
> human-readable format. Is there any reliable way of projecting strings
> like "intel", "amd", "vkms", etc to an actual device, or we still need
> to maintain this mapping inside IGT runner?
Adding '8086' -> 'intel' mapping and so on is easy. Small problem occurs
for handling device, especially that set is larger and how to select that
(string matching, what to do if device is not on the list?). I'd crazy idea
to convert pci.ids to table but this is overkill IMHO for this case. And in
this case we need to put data to library in compiled form because I guess we
don't want to depend on pciutils package (or whichever contains pci.ids).
> Also, should IGT_FORCE_DRIVER be kept? Seems like IGT_FORCE_DRIVER and
> IGT_DEVICE serve quite a similar purpose.
IGT_FORCE_DRIVER ensures that this driver module is used for device
opened with DRIVER_ANY. I didn't wanted to change this behavior for legacy
usage. That's why I proposed new IGT_DEVICE to leave old device selection
intact.
> >
> > Tool 'lsgpu' which uses device scanning feature was added.
> >
> > Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> > Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Petri Latvala <petri.latvala@intel.com>
>
> BTW, about multiple devices tests and drm_open_driver(DRIVER_INTEL).
> One approach could be this:
>
> 1. We add another instance of this --device property, called for
> example --device2, which would correspond to an auxiliary device. This
> approach allows us to have the same generic device selection mechanism
> in all places. Also, if we ever have the test involving 3 devices, this
> can scale :)
> 2. With new selection mechanism active
> fd = drm_open_driver(DRIVER_SOMETHING)
> is an alias for
> fd = drm_open_driver(DRIVER_ANY)
> igt_require_something(fd)
> Oleg
If we need to handle more than one device it is possible to reimplement
parsing of --device filter to something like this:
--device pci:vendor=1234,card=0;pci:vendor=2345,card=2;...
Splitting against ';' would extract separate device filters giving array
as an output. Then access to device using array index would give you
expected card.
Zbigniew
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-07-02 7:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 13:03 [igt-dev] [EARLY RFC 0/1] New device selection Zbigniew Kempczyński
2019-07-01 13:03 ` [igt-dev] [EARLY RFC 1/1] Introduce new method of " Zbigniew Kempczyński
2019-07-01 20:57 ` Vasilev, Oleg
2019-07-02 7:38 ` Kempczynski, Zbigniew [this message]
2019-07-03 8:45 ` Vasilev, Oleg
2019-07-03 10:10 ` Kempczynski, Zbigniew
2019-07-03 7:56 ` Arkadiusz Hiler
2019-07-01 14:37 ` [igt-dev] ✗ GitLab.Pipeline: failure for New " Patchwork
2019-07-02 6:49 ` Arkadiusz Hiler
2019-07-01 14:37 ` [igt-dev] ✓ Fi.CI.BAT: success " 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=aa67b24e7e8287ee230cbe3544b8d9079f134260.camel@intel.com \
--to=zbigniew.kempczynski@intel.com \
--cc=daniel@ffwll.ch \
--cc=igt-dev@lists.freedesktop.org \
--cc=oleg.vasilev@intel.com \
--cc=petri.latvala@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