[Intel-gfx] [PATCH igt] igt/gem_exec_schedule: Ignore set-priority failures on old kernels

[Chris Wilson]

Quoting Michał Winiarski (2017-09-26 15:11:15)
> On Mon, Sep 25, 2017 at 09:21:15PM +0100, Chris Wilson wrote:
> > When plugging the device, we need to submit batches at highest priority
> > so that they cannot be gazumped by the queued requests. On older kernels
> > that do not support the user changing context priority, all contexts
> > therefore have max priority and we can ignore the error.
> 
> All context have equal priority, we can ignore the error, it's not MAX.
> 
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  tests/gem_exec_schedule.c | 39 +++++++++++++++++++--------------------
> >  1 file changed, 19 insertions(+), 20 deletions(-)
> > 
> > diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> > index e9b928f1..0b1925f1 100644
> > --- a/tests/gem_exec_schedule.c
> > +++ b/tests/gem_exec_schedule.c
> > @@ -152,33 +152,32 @@ static void unplug(struct cork *c)
> >       close(c->device);
> >  }
> >  
> > +static uint32_t create_highest_priority(int fd)
> > +{
> > +     uint32_t ctx = gem_context_create(fd);
> > +
> > +     /* If no priority support, all contexts have equal and max priority */
> 
> Same here. It's DEFAULT (0), not MAX. We still do PI for display AFAICS.

Ssh. From the user perspective, one priority rules them all, I was
trying to emphasize that we could not submit a higher priority context
ourselves that would escape the plug. Hence the language focusing around
this being the maximum priority that we would see.

> That's just to handle fifo test even if we don't have userspace control, right?

Right. Just the test that doesn't depend upon context priorities as it
is checking that equal priority requests submitted in order are executed
in order. Hmm, could do with that being fifo at different priorities
just in case we happen to treat default as a special case.
-Chris