[Intel-gfx] [PATCH 08/24] drm/i915: Use per object locking in execbuf, v12.

Thomas Hellström (Intel) thomas_os at shipmail.org
Wed Aug 12 20:59:37 UTC 2020


On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
> Now that we changed execbuf submission slightly to allow us to do all
> pinning in one place, we can now simply add ww versions on top of
> struct_mutex. All we have to do is a separate path for -EDEADLK
> handling, which needs to unpin all gem bo's before dropping the lock,
> then starting over.
>
> This finally allows us to do parallel submission, but because not
> all of the pinning code uses the ww ctx yet, we cannot completely
> drop struct_mutex yet.
>
> Changes since v1:
> - Keep struct_mutex for now. :(
> Changes since v2:
> - Make sure we always lock the ww context in slowpath.
> Changes since v3:
> - Don't call __eb_unreserve_vma in eb_move_to_gpu now; this can be
>    done on normal unlock path.
> - Unconditionally release vmas and context.
> Changes since v4:
> - Rebased on top of struct_mutex reduction.
> Changes since v5:
> - Remove training wheels.
> Changes since v6:
> - Fix accidentally broken -ENOSPC handling.
> Changes since v7:
> - Handle gt buffer pool better.
> Changes since v8:
> - Properly clear variables, to make -EDEADLK handling not BUG.
> Change since v9:
> - Fix unpinning fence on pnv and below.
> Changes since v10:
> - Make relocation gpu chaining working again.
> Changes since v11:
> - Remove relocation chaining, pain to make it work.
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>

Reviewed-by: Thomas Hellström <thomas.hellstrom at intel.com>




More information about the Intel-gfx mailing list