Quoting Matthew Auld (2020-07-06 19:15:27)
> On Mon, 6 Jul 2020 at 07:19, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > We need to make the DMA allocations used for page directories to be
> > performed up front so that we can include those allocations in our
> > memory reservation pass. The downside is that we have to assume the
> > worst case, even before we know the final layout, and always allocate
> > enough page directories for this object, even when there will be overlap.
> >
> > It should be noted that the lifetime for the page directories DMA is
> > more or less decoupled from individual fences as they will be shared
> > across objects across timelines.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>
> <snip>
>
> > @@ -874,11 +873,21 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
> > return err;
> >
> > if (flags & vma->vm->bind_async_flags) {
> > + u64 max_size;
> > +
> > work = i915_vma_work();
> > if (!work) {
> > err = -ENOMEM;
> > goto err_pages;
> > }
> > +
> > + work->vm = i915_vm_get(vma->vm);
> > +
> > + /* Allocate enough page directories to cover worst case */
> > + max_size = max(size, vma->size);
> > + if (flags & PIN_MAPPABLE)
> > + max_size = max_t(u64, max_size, vma->fence_size);
> > + i915_vm_alloc_pt_stash(vma->vm, &work->stash, max_size);
>
> Why do we need to take into account size when allocating the page
> directories, and not just vma->size/fence_size, since the difference
> is only really padding? It could be gigantic thanks to pad_to_size.
We need to cover the PT entries we actually insert, which is indeed
vma->size. So yes, this is overkill, I was trying to match the size of
the node we create, but as you say we don't populate all of that node
and leave the unused portion/tail pointing to scratch.
That gets rid of some clumsy code!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
