Re: [PATCH 14/22] drm/i915/gem: Async GPU relocations only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 4 Jun 2020 at 11:38, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 <chris@xxxxxxxxxxxxxxxxxx>
Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux