• Chris Wilson's avatar
    drm/i915: Eliminate lots of iterations over the execobjects array · 2889caa9
    Chris Wilson authored
    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: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    2889caa9
i915_vma.c 19.1 KB