All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org,
	akash.goel@intel.com
Subject: Re: [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast
Date: Sat, 7 Nov 2015 10:13:13 +0000	[thread overview]
Message-ID: <20151107101313.GH18324@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <563B69E6.9030605@linux.intel.com>

On Thu, Nov 05, 2015 at 02:38:30PM +0000, Tvrtko Ursulin wrote:
> 
> On 05/11/15 12:58, Chris Wilson wrote:
> >On Thu, Nov 05, 2015 at 12:53:20PM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 05/11/15 12:42, Chris Wilson wrote:
> >>>On Thu, Nov 05, 2015 at 12:37:46PM +0000, Tvrtko Ursulin wrote:
> >>>>
> >>>>On 05/11/15 11:45, ankitprasad.r.sharma@intel.com wrote:
> >>>>>From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> >>>>>
> >>>>>In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> >>>>>we try a nonblocking pin for the whole object (since that is fastest if
> >>>>>reused), then failing that we try to grab one page in the mappable
> >>>>>aperture. It also allows us to handle objects larger than the mappable
> >>>>>aperture (e.g. if we need to pwrite with vGPU restricting the aperture
> >>>>>to a measely 8MiB or something like that).
> >>>>
> >>>>Aperture in aperture, reminds me of those "Yo dawg I've heard you
> >>>>like X so I've put X in your X so you can Y while you Y" jokes. :D
> >>>>
> >>>>Would using the partial view code be interesting for this? Might be
> >>>>faster due to larger chunks possible, or slower due more expensive
> >>>>set up time, I don't know.
> >>>
> >>>It's the wrong abstraction.
> >>
> >>Looks the same to me, only difference is the size.
> >
> >There are many places that insert-page is used where we cannot do a
> >partial-pin.
> >
> >>Why not just to the page aperture then for simplicity? If there is
> >>any performance gain from trying the full VMA first then why there
> >>wouldn't be some to try with the partial VMA?
> >
> >obj->base.size >> PAGE_SHIFT x partial pages is not even funny.
> 
> Well I did not suggest that but larger chunks so I will repeat my question.
> 
> If going page by page is fine for performance then why have the two
> code paths at all? One which tries top pin the whole object first,
> and second which goes page by page if that fails. Why not just do it
> page by page and avoid having two copy loops etc?

If we already have the vma or can allocate it with impacting upon the
system, using it is best (since we expect to reuse it again). If we
cannot allocate it, our natural iterator size is 4096 bytes and is also
our best chance at allocating that in the aperture.

Partial vma are a high overhead and more importantly a massive impedance
mismatch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-11-07 10:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05 11:45 [PATCH 0/3] Support for mapping an object page by page ankitprasad.r.sharma
2015-11-05 11:45 ` [PATCH 1/3] drm/i915: Add support " ankitprasad.r.sharma
2015-11-05 11:45 ` [PATCH 2/3] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
2015-11-05 11:45 ` [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
2015-11-05 12:34   ` Chris Wilson
2015-11-06  6:15     ` Ankitprasad Sharma
2015-11-05 12:37   ` Tvrtko Ursulin
2015-11-05 12:42     ` Chris Wilson
2015-11-05 12:53       ` Tvrtko Ursulin
2015-11-05 12:58         ` Chris Wilson
2015-11-05 14:38           ` Tvrtko Ursulin
2015-11-07 10:13             ` Chris Wilson [this message]
2015-11-18  9:59   ` Daniel Vetter
2015-11-20  9:37     ` Ankitprasad Sharma
2015-11-20 10:06       ` Chris Wilson
2015-11-24 12:22         ` Daniel Vetter
2015-12-14  8:19           ` Ankitprasad Sharma
2015-11-07  8:02 [PATCH v2 0/3] Support for mapping an object page by page ankitprasad.r.sharma
2015-11-07  8:02 ` [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
2015-11-07 10:07   ` Chris Wilson
2015-11-09 10:56 [PATCH v3 0/3] Support for mapping an object page by page ankitprasad.r.sharma
2015-11-09 10:56 ` [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
2015-11-09 12:20   ` kbuild test robot
2015-11-10  7:55   ` Mika Kuoppala
2015-11-10  8:05     ` Ankitprasad Sharma
2015-11-10  8:44     ` Chris Wilson
2015-11-10 11:51       ` Chris Wilson

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=20151107101313.GH18324@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=akash.goel@intel.com \
    --cc=ankitprasad.r.sharma@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.