On Fri, Dec 16, 2016 at 04:14:30PM +0200, Joonas Lahtinen wrote: > On pe, 2016-12-16 at 07:47 +0000, Chris Wilson wrote: > > Using mm->color_adjust makes the eviction scanner much tricker since we > > don't know the actual neighbours of the target hole until after it is > > created (after scanning is complete). To work out whether we need to > > evict the neighbours because they impact upon the hole, we have to then > > check the hole afterwards - requiring an extra step in the user of the > > eviction scanner when they apply color_adjust. > > > > v2: Massage kerneldoc. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > It's not optimal as a separate function, but good for now. Yes, it's nasty that it requires a separate step by the caller to catch for residual overlap. The problem is that we do require the mm.color_adjust to be performed to tell if the user thinks there will be overlap - and that requires the final state of the hole and its neighbours. Alternatives I considered were just a color_expand parameter and always evicting the neighbouring nodes (but that is not great for us as most of our nodes have one colour). Or I considered searching the node list to find the overlaps and flag them (presuming eviction happened as we intended). They all seemed to be worse than just asking the user to check after eviction if they are using color_adjust. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
