[igt-dev] [Intel-gfx] [PATCH igt 1/2] Iterate over physical engines

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-21 16:25:34)
> 
> On 21/02/2018 14:45, Chris Wilson wrote:
> > We current have a single for_each_engine() iterator which we use to
> > generate both a set of uABI engines and a set of physical engines.
> > Determining what uABI ring-id corresponds to an actual HW engine is
> > tricky, so pull that out to a library function and introduce
> > for_each_physical_engine() for cases where we want to issue requests
> > once on each HW ring (avoiding aliasing issues).
> 
> As you know I tried to make for_each_engine actually behave like this 
> (iterate physical engines). I still think it would be better / more 
> intuitive, and leave the uABI for a specially named iterator instead. 
> However, I am willing to accept this compromise in order to start moving 
> towards the long overdue cleanup in this respect.

Right, next step would be s/for_each_engine/for_each_uabi_ring/ to catch
the remaining cases, although most now in this case iterate over the
engine static array and igt_require(gem_has_ring()), so that the test
list is stable across machines.

[snip]

> Hm, what I did with intel_execution_engines2 to fake class/instance. 
> Have to think if that could somehow be merged into one. Or perhaps the 
> approach adopted and then when available just switch the implementation 
> to real class/instance.

Yeah, I think of this as an intermediate stepping stone so will be
refined as we refine the uABI. In the meantime, if there are trivial
refactors, no problem, but I wouldn't spend too much effort forcing it
as I think we will end up replacing it.
-Chris