On Wed, Aug 17, 2016 at 03:36:51PM +0100, Tvrtko Ursulin wrote: > > On 17/08/16 11:05, Chris Wilson wrote: > >On Wed, Aug 17, 2016 at 10:57:34AM +0100, Tvrtko Ursulin wrote: > >> > >>On 17/08/16 10:41, Chris Wilson wrote: > >>>On Wed, Aug 17, 2016 at 10:34:18AM +0100, Tvrtko Ursulin wrote: > >>>>Or add an initialized engine array to dev_priv, in addition to the > >>>>existing map for best of both worlds. > >>> > >>>We have the ring_mask which already tells us that mapping, so I think > >>>the second array is overkill. > >> > >>Yes, I said "in addition to the existing map". In addition we could > >>have an array of only initialized engines to avoid any skipping at > >>runtime. Since iterators end with intel_engine_initialized anyway. > > > >And I'm saying we already have that information in ring_mask. > > The ffs smarts you've been developing? I am not sure devising very > smart macros and expanding all that code to all the call sites is > that great. It is effectively just re-implementing arrays at runtime > using CPU instructions. > > What would be the big deal of just building the array when engines > are initialized for simplicity? Just the allure of getting away with > no iterator variable? It's just the redundant information. We definitely want the (sparse) id->engine lookup table just for convenience in execbuf and friends. Given that, having a second array is overkill. A list may be a reasonable compromise, and I guess pushing for using an ffs iterator where it matters (where we know we have a sparse set). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
