[igt-dev] [RFC] IGT device scanning and selection

Daniel Vetter daniel at ffwll.ch
Wed Jun 5 12:31:09 UTC 2019


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


More information about the igt-dev mailing list