Quoting Tvrtko Ursulin (2019-07-26 10:51:01) > > On 26/07/2019 10:33, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-07-26 10:22:08) > >> > >> On 23/07/2019 19:38, Chris Wilson wrote: > >> I read it, relatively rushed, since pressure keeps getting applied! :/ > >> > >> There are some good parts and implementation looks okay, but I am not > >> sure we need a tree. Nodes are bigger than pointers, management code is > >> bigger, lookup is slower.. is it a win all things considered? > > > > A big win imo. Consider that this interface is purely debug, the primary > > interface runtime will be via gt->engines, the nodes are much smaller > > than the sparse array. > > I guess it depends. One rb_node is three pointers and can only be used > from a single tree. Nor does the patch replaces all sparse arrays. There would be reasonable objection if I removed all the arrays in one go :-p > > I am adamant that we are not adding more sparse arrays. A 2D lookup > > table since that matches the HW, but even then we may just end up with > > LUT (1 extra pointer load to replace the sparse array with a compact?) > > I feel it's too early for this specific patch. It's too early? The whole point is to enable gt-centrification for the later patches and lift gt initialisation out of GEM. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
