On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote: > The major scaling bottleneck in execbuffer is the processing of the > execobjects. Creating an auxiliary list is inefficient when compared to > using the execobject array we already have allocated. > > Reservation is then split into phases. As we lookup up the VMA, we > try and bind it back into active location. Only if that fails, do we add > it to the unbound list for phase 2. In phase 2, we try and add all those > objects that could not fit into their previous location, with fallback > to retrying all objects and evicting the VM in case of severe > fragmentation. (This is the same as before, except that phase 1 is now > done inline with looking up the VMA to avoid an iteration over the > execobject array. In the ideal case, we eliminate the separate reservation > phase). During the reservation phase, we only evict from the VM between > passes (rather than currently as we try to fit every new VMA). In > testing with Unreal Engine's Atlantis demo which stresses the eviction > logic on gen7 class hardware, this speed up the framerate by a factor of > 2. > > The second loop amalgamation is between move_to_gpu and move_to_active. > As we always submit the request, even if incomplete, we can use the > current request to track active VMA as we perform the flushes and > synchronisation required. > > The next big advancement is to avoid copying back to the user any > execobjects and relocations that are not changed. > > v2: Add a Theory of Operation spiel. > v3: Fall back to slow relocations in preparation for flushing userptrs. > v4: Document struct members, factor out eb_validate_vma(), add a few > more comments to explain some magic and hide other magic behind macros. > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Changelog checks out. Assuming you peeked at the generated html docs: Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
