On Thu, 4 Jun 2020 at 11:38, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
>
> Reduce the 3 relocation patches 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 <ch...@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.a...@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
