On Wed, Apr 29, 2015 at 04:05:40PM +0100, Tvrtko Ursulin wrote: > > On 04/27/2015 01:41 PM, Chris Wilson wrote: > >With the removal of the pin_ioctl, we need only consider > >obj->pin_display when looking at available aperture space. > > > >Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >--- > > drivers/gpu/drm/i915/i915_gem.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > >index afdb604e4005..ec9e36e9ec78 100644 > >--- a/drivers/gpu/drm/i915/i915_gem.c > >+++ b/drivers/gpu/drm/i915/i915_gem.c > >@@ -157,7 +157,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data, > > pinned = 0; > > mutex_lock(&dev->struct_mutex); > > list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) > >- if (i915_gem_obj_is_pinned(obj)) > >+ if (obj->pin_display) > > pinned += i915_gem_obj_ggtt_size(obj); > > mutex_unlock(&dev->struct_mutex); > > The only thing I can think of are transients from execbuf, > pre-ppgtt, but I suppose we don't care about that a lot? Or I > misunderstand how something works? They are only pinned whilst we process reservations for the batch. The only things that are permenantly pinned are the display objects, which hardware is pointed at. Hmm, I guess they are actually a few others we do care about such as overlay regs and legacy ringbuffer objs, default contects and status pages and the like. On the other hand perma-pinning into the GGTT is now quite rare, so perhaps it is time to start tracking it again. I guess I am going to have to revisit this patch (my goal is try and clarify what i915_gem_obj_is_pinned() means by eliminating it ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
