[Intel-gfx] [PATCH 34/34] drm/i915: Create VMAs (part 3)

Daniel Vetter daniel at ffwll.ch
Mon May 27 10:59:46 CEST 2013


On Mon, May 27, 2013 at 9:31 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Sat, May 25, 2013 at 12:27:08PM -0700, Ben Widawsky wrote:
>> Plumb the functions we care about with VM arguments.
>>
>> With the exception of the hack in i915_ppgtt_bind to only ever be able
>> to do aliasing PPGTT, this most everything we want.
>
> Purge is wrong -- it needs to select a victim obj and unbind it from all
> vma at once, then repeat for a new victim.
>
> obj->pin_count is per-vma. Most of the pinning is only relevant for the
> ggtt (pinned for registers), with other vma only using it for
> reserve/eviction. But we can remove things from the ppgtt if they are
> only pinned due to scanout, for example.

I haven't yet read through the full pile, but I think we can avoid a
vma->pin_count for now. It'll be a bit inefficient since it'll block
eviction unnecessarily in a few cases but:
- I think for execbuf we should switch over to reserve/unreserve and
untie it from our pinning (together with finer-grained locking to
avoid OOM issues for real).
- per-vma pinning for your softpin ioctl is a bit a different beast
than the ggtt pinning since the later forbids eviction completely. The
former otoh allows eviction, we may just not free the drm_mm node
allocation to make sure we'll put it back into the right place.

So I think untangling obj->pin_count is a bit more more but also not
really required to get real ppgtt off the ground.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list