On Fri, Nov 8, 2019 at 11:05 AM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > Quoting Daniel Vetter (2019-11-08 09:53:51) > > On Wed, Nov 6, 2019 at 4:48 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > > > (--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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
