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
next prev parent reply other threads:[~2016-02-18 21:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 18:31 [PATCH v2 0/2] Add i915_gem_object_vmap yu.dai
2016-02-18 18:31 ` [PATCH v2 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space yu.dai
2016-02-18 21:05 ` Chris Wilson
2016-02-18 21:30 ` Yu Dai [this message]
2016-02-19 11:07 ` Tvrtko Ursulin
2016-02-29 12:03 ` Tvrtko Ursulin
2016-02-18 18:31 ` [PATCH v2 2/2] drm/i915/guc: Simplify code by keeping vmap of guc_client object yu.dai
2016-02-19 11:10 ` Tvrtko Ursulin
2016-02-19 8:06 ` ✗ Fi.CI.BAT: failure for Add i915_gem_object_vmap (rev2) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C637EA.1060502@intel.com \
--to=yu.dai@intel.com \
--cc=chris.harris@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=david.s.gordon@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).