Re: [Intel-gfx] [PATCH i-g-t] Revert "tests/i915: Use engine query interface for gem_ctx_isolation/persistence"

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Andi Shyti (2019-12-07 17:42:39)
> Hi Chris,
> 
> On Sat, Dec 07, 2019 at 01:08:35AM +0000, Chris Wilson wrote:
> > This reverts commit 343aae776a58a67fa153825385e6fe90e3185c5b.
> > 
> > __for_each_physical_engine() reprograms the context, invalidating the
> > use of e->flags to select engines, necessitating e->index instead.
> > Withot also fixing up the engine selection, the result is that random
> > engines were being used to read registers from the intended engine.
> > This does not end well.
> 
> So, the problem here is that with __for_each_physical_engine() we
> "reprogram the context" which means that there is a re-mapping of
> engines in it. Have I understood correctly?
> 
> Doesn't that happen only in the case when the context has no
> engines in it?

iirc, it does something like init_engine_map and sets a consistent
engine layout on the context -- but switches execbuf over to index mode.
 
> > @@ -877,7 +876,8 @@ igt_main
> >               igt_skip_on(gen > LAST_KNOWN_GEN);
> >       }
> >  
> > -     __for_each_physical_engine(fd, e) {
> > +     for (const struct intel_execution_engine2 *e = intel_execution_engines2;
> > +          e->name; e++) {
> 
> __for_each_static_engine() ?

I'm just doing a simple revert so we can try again :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx