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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
