On 03/07/2020 10:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-03 09:59:01)
On 02/07/2020 09:32, Chris Wilson wrote:
Remove the stub i915_vma_pin() used for incrementally pining objects for
execbuf (under the severe restriction that they must not wait on a
resource as we may have already pinned it) and replace it with a
i915_vma_pin_inplace() that is only allowed to reclaim the currently
bound location for the vma (and will never wait for a pinned resource).
Hm I thought the point of the previous patch ("drm/i915/gem: Break apart
the early i915_vma_pin from execbuf object lookup") was to move the
pinning into a phase under the ww lock, where it will be allowed. I
misunderstood something?
Still different locks, and the vm->mutex is still being used for managing
the iova assignments.
Right, think I get it. For the record I've asked for a cover letter with
a high level design description. Emphasis on flow of stages through
execbuf by the end of the series and separation of lookup and
reservation, and/or vm->mutex (ppgtt space) and obj->wwlock (backing store).
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
