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
