drm/i915/gem: Async GPU relocations only
authorChris Wilson <chris@chris-wilson.co.uk>
Thu, 4 Jun 2020 21:14:57 +0000 (22:14 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Fri, 5 Jun 2020 08:45:44 +0000 (09:45 +0100)
commit9e0f9464e2ab36b864359a59b0e9058fdef0ce47
tree09a512e836c6179e8a5a99ddddcd5150418ab375
parent2d3879950f8ac1eb5638958a01ff0abeba5427d9
drm/i915/gem: Async GPU relocations only

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: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200604211457.19696-1-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c