Quoting Thomas Hellström (Intel) (2020-06-23 10:33:20)
> Hi, Chris!
>
> On 6/22/20 11:59 AM, Chris Wilson wrote:
> > In order to actually handle eviction and what not, we need to process
> > all the objects together under a common lock, reservation_ww_class. As
> > such, do a memory reservation pass after looking up the object/vma,
> > which then feeds into the rest of execbuf [relocation, cmdparsing,
> > flushing and ofc execution].
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 91 ++++++++++++++-----
> > 1 file changed, 70 insertions(+), 21 deletions(-)
> >
> Which tree is this against? The series doesn't apply cleanly against
> drm-tip?
It's continuing on from the scheduler patches, the bug fixes and the
iris-deferred-fence work. I thought throwing all of those old patches
into the pile would have been distracting.
> ...
>
> > +static int eb_reserve_mm(struct i915_execbuffer *eb)
> > +{
> > + const u64 idx = eb->context->timeline->fence_context;
> > + struct ww_acquire_ctx acquire;
> > + struct eb_vma *ev;
> > + int err;
> > +
> > + eb->mm_fence = __dma_fence_create_proxy(0, 0);
> > + if (!eb->mm_fence)
> > + return -ENOMEM;
>
> Where are the proxy fence functions defined?
In dma-fence-proxy.c ;)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
