• Chris Wilson's avatar
    drm/i915/gem: Async GPU relocations only · 9e0f9464
    Chris Wilson authored
    Reduce the 3 relocation paths down to the single path that accommodates
    all. The primary motivation for this is to guard the relocations with a
    natural fence (derived from the i915_request used to write the
    relocation from the GPU).
    
    The tradeoff in using async gpu relocations is that it increases latency
    over using direct CPU relocations, for the cases where the target is
    idle and accessible by the CPU. The benefit is greatly reduced lock
    contention and improved concurrency by pipelining.
    
    Note that forcing the async gpu relocations does reveal a few issues
    they have. Firstly, is that they are visible as writes to gem_busy,
    causing to mark some buffers are being to written to by the GPU even
    though userspace only reads. Secondly is that, in combination with the
    cmdparser, they can cause priority inversions. This should be the case
    where the work is being put into a common workqueue losing our priority
    information and so being executed in FIFO from the worker, denying us
    the opportunity to reorder the requests afterwards.
    Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200604211457.19696-1-chris@chris-wilson.co.uk
    9e0f9464
i915_gem_execbuffer.c 73.7 KB