Re: [PATCH v2 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space

From: Yu Dai <yu.dai@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org, tvrtko.ursulin@intel.com,
	daniel.vetter@ffwll.ch, david.s.gordon@intel.com,
	chris.harris@intel.com
Subject: Re: [PATCH v2 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
Date: Thu, 18 Feb 2016 13:30:18 -0800	[thread overview]
Message-ID: <56C637EA.1060502@intel.com> (raw)
In-Reply-To: <20160218210514.GA28380@nuc-i3427.alporthouse.com>

On 02/18/2016 01:05 PM, Chris Wilson wrote:
> On Thu, Feb 18, 2016 at 10:31:37AM -0800, yu.dai@intel.com wrote:
> > From: Alex Dai <yu.dai@intel.com>
> >
> > There are several places inside driver where a GEM object is mapped to
> > kernel virtual space. The mapping is either done for the whole object
> > or certain page range of it.
> >
> > This patch introduces a function i915_gem_object_vmap to do such job.
> >
> > v2: Use obj->pages->nents for iteration within i915_gem_object_vmap;
> >     break when it finishes all desired pages. The caller need to pass
> >     in actual page number. (Tvrtko Ursulin)
>
> Who owns the pages? vmap doesn't increase the page refcount nor
> mapcount, so it is the callers responsibility to keep the pages alive
> for the duration of the vmapping.
>
> I suggested i915_gem_object_pin_vmap/unpin_vmap for that reason and that
> also provides the foundation for undoing one of the more substantial
> performance regressions from vmap_batch().
>
>

OK, found it at 050/190 of your patch series. That is a huge list of 
patches. :-) The code I put here does not change (at least tries to 
keep) the current code logic or driver behavior. I am not opposed to 
using i915_gem_object_pin_vmap/unpin_vmap at all. I will now just keep 
eyes on that patch.

Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx