From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: [PATCH v7 0/7] Reorganise calls to vmap() GEM objects
Date: Tue, 1 Mar 2016 16:33:52 +0000 [thread overview]
Message-ID: <1456850039-25856-1-git-send-email-david.s.gordon@intel.com> (raw)
Alex Dai and Chris Wilson have both recently posted patches to
rationalise the use of vmap() for mapping GEM objects into kernel
virtual space. However, they addressed different areas, with Alex's
patch being derived from the copy_batch() code, whereas Chris' patch
refactored the dma-buf and ringbuffer code.
So this patchset unifies the two, copying Chris' interfaces which
unite pin-and-vmap for convenient lifecycle management, but using
Alex's code underneath to permit partial mappings. And finally
there's a little optimisation I've added for "small" objects e.g.
ringbuffers and contexts, which are expected to be the objects most
commonly handled by this code.
v5:
Added another of Chris' patches, introducing drm_malloc_gfp().
Split Chris' original patch into three, of which two are actually
minor unrelated improvements, and only one is actually addresses
the vmap() reorganisation [Tvrtko Ursulin]
Decided not to hold onto vmappings after the pin count goes to
zero. This may reduce the benefit of Chris' scheme somewhat, but
does avoid any increased risk of exhausting kernel vmap space on
32-bit kernels [Tvrtko Ursulin]. Potentially, the vunmap() could
be moved back to the put_pages() stage (thus extending the cache
lifetime) if a suitable notifier were written, but that's not
included here.
v6:
Addressed a few review comments by Tvrtko & Chris; the main
functional change is that i915_gem_object_vmap_range() now takes
a range in bytes rather than pages, so we use sg_nents_for_len()
to validate it against the actual scatterlist.
v7:
Reverted to passing range specification in pages not bytes, and
allow npages==0 as a shorthand for "up to the end of the object".
Reordered patch sequence, with the most local changes first and
the optional ones at the end.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Alex Dai (1):
drm/i915: introduce and use i915_gem_object_vmap_range()
Chris Wilson (3):
drm/i915: deduplicate intel_pin_and_map_ringbuffer_obj() error
handling
drm/i915: move locking in i915_gem_unmap_dma_buf()
drm,i915: introduce drm_malloc_gfp()
Dave Gordon (3):
drm/i915: optimise i915_gem_object_vmap_range() for small objects
drm/i915: refactor duplicate object vmap functions (the final rework?)
drm: add parameter-order checking to drm memory allocators
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
drivers/gpu/drm/i915/i915_cmd_parser.c | 34 ++-------
drivers/gpu/drm/i915/i915_drv.h | 26 +++++--
drivers/gpu/drm/i915/i915_gem.c | 103 +++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 53 ++------------
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 15 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 52 +++++---------
include/drm/drm_mem_util.h | 44 +++++++++++-
10 files changed, 206 insertions(+), 140 deletions(-)
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2016-03-01 16:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 16:33 Dave Gordon [this message]
2016-03-01 16:33 ` [PATCH v7 1/7] drm/i915: deduplicate intel_pin_and_map_ringbuffer_obj() error handling Dave Gordon
2016-03-01 16:33 ` [PATCH v7 2/7] drm/i915: move locking in i915_gem_unmap_dma_buf() Dave Gordon
2016-03-01 16:33 ` [PATCH v7 3/7] drm,i915: introduce drm_malloc_gfp() Dave Gordon
2016-03-01 16:33 ` [PATCH v7 4/7] drm/i915: introduce and use i915_gem_object_vmap_range() Dave Gordon
2016-03-01 17:39 ` Tvrtko Ursulin
2016-03-01 16:33 ` [PATCH v7 5/7] drm/i915: optimise i915_gem_object_vmap_range() for small objects Dave Gordon
2016-03-01 16:33 ` [PATCH v7 6/7] drm/i915: refactor duplicate object vmap functions (the final rework?) Dave Gordon
2016-03-02 12:08 ` Chris Wilson
2016-03-02 15:40 ` Dave Gordon
2016-03-08 9:43 ` Tvrtko Ursulin
2016-03-22 15:25 ` Dave Gordon
2016-03-23 12:23 ` Tvrtko Ursulin
2016-03-01 16:33 ` [PATCH v7 7/7] drm: add parameter-order checking to drm memory allocators Dave Gordon
2016-03-02 15:00 ` Tvrtko Ursulin
2016-03-02 6:54 ` ✗ Fi.CI.BAT: warning for Reorganise calls to vmap() GEM objects (rev5) Patchwork
2016-03-02 12:38 ` Dave Gordon
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=1456850039-25856-1-git-send-email-david.s.gordon@intel.com \
--to=david.s.gordon@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/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).