[Intel-gfx] [PATCH 3/3] drm/i915/gem: Extract transient execbuf flags from i915_vma

[Daniel Vetter]

On Fri, Nov 8, 2019 at 11:05 AM Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Quoting Daniel Vetter (2019-11-08 09:53:51)
> > On Wed, Nov 6, 2019 at 4:48 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > For our convenience, and to avoid frequent allocations, we placed some
> > > lists we use for execbuf inside the common i915_vma struct. As we look
> > > to parallelise execbuf, such fields guarded by the struct_mutex BKL must
> > > be pulled under local control. Instead of using the i915_vma as our
> > > primary means of tracking the user's list of objects and their virtual
> > > mappings, we use a local eb_vma with the same lists as before (just now
> > > local not global).
> > >
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >
> > (--supress-cc ? Added Maarten for real, didn't seem to be on cc in my
> > inbox at least)
> >
> > Why do we need this?
>
> Because the execbuf state is not covered by the object locks. We put
> them inside the vma for the express purpose of avoiding an allocation; an
> allocation we ended up doing anyway, which we can now use for the sole
> purpose of tracking the execbuf.
>
> This is _execbuf_ state that we rammed into the i915_vma.

Ok, that makes sense. The locking story imo doesn't make so much sense
to me really, since no matter where we allocate this we'll pretty much
have to hold the corresponding obj dma_resv, at least for slow-paths
with relocs (which are the ones where we need this stuff). I guess one
downside of this is that the temp allocation is now quite a bit
bigger. Isn't that hurting?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch