From: Thomas Zimmermann <tzimmermann@suse.de>
To: daniel@ffwll.ch, noralf@tronnes.org, airlied@linux.ie,
rong.a.chen@intel.com, feng.tang@intel.com, ying.huang@intel.com,
sean@poorly.run, maxime.ripard@bootlin.com,
maarten.lankhorst@linux.intel.com, dave@stgolabs.net,
kraxel@redhat.com
Cc: Thomas Zimmermann <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org
Subject: [PATCH v4 4/4] drm/vram: Implement lazy unmapping for GEM VRAM buffers
Date: Fri, 6 Sep 2019 14:20:56 +0200 [thread overview]
Message-ID: <20190906122056.32018-5-tzimmermann@suse.de> (raw)
In-Reply-To: <20190906122056.32018-1-tzimmermann@suse.de>
Frequent mapping and unmapping a buffer object adds overhead for
modifying the page table and creates debug output. Unmapping a buffer
is only required when the memory manager evicts the buffer from its
current location.
v4:
* WARN_ON if buffer is still mapped during BO cleanup
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_gem_vram_helper.c | 49 ++++++++++++++++++++++-----
include/drm/drm_gem_vram_helper.h | 4 +++
2 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 1e17f11cc7b9..0990f0e03213 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -28,6 +28,7 @@ static void drm_gem_vram_cleanup(struct drm_gem_vram_object *gbo)
*/
WARN_ON(gbo->kmap_use_count);
+ WARN_ON(gbo->kmap.virtual);
drm_gem_object_release(&gbo->bo.base);
}
@@ -356,18 +357,17 @@ EXPORT_SYMBOL(drm_gem_vram_kmap);
static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo)
{
- struct ttm_bo_kmap_obj *kmap = &gbo->kmap;
-
if (WARN_ON_ONCE(!gbo->kmap_use_count))
return;
if (--gbo->kmap_use_count > 0)
return;
- if (!kmap->virtual)
- return;
-
- ttm_bo_kunmap(kmap);
- kmap->virtual = NULL;
+ /*
+ * Permanently mapping and unmapping buffers adds overhead from
+ * updating the page tables and creates debugging output. Therefore,
+ * we delay the actual unmap operation until the BO gets evicted
+ * from memory. See drm_gem_vram_bo_driver_move_notify().
+ */
}
/**
@@ -497,6 +497,38 @@ int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
+/**
+ * drm_gem_vram_bo_driver_move_notify() -
+ * Implements &struct ttm_bo_driver.move_notify
+ * @bo: TTM buffer object. Refers to &struct drm_gem_vram_object.bo
+ * @evict: True, if the BO is being evicted from graphics memory;
+ * false otherwise.
+ * @new_mem: New memory region, or NULL on destruction
+ */
+void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
+ bool evict,
+ struct ttm_mem_reg *new_mem)
+{
+ struct drm_gem_vram_object *gbo;
+ struct ttm_bo_kmap_obj *kmap;
+
+ /* TTM may pass BOs that are not GEM VRAM BOs. */
+ if (!drm_is_gem_vram(bo))
+ return;
+
+ gbo = drm_gem_vram_of_bo(bo);
+ kmap = &gbo->kmap;
+
+ if (WARN_ON_ONCE(gbo->kmap_use_count))
+ return;
+
+ if (!kmap->virtual)
+ return;
+ ttm_bo_kunmap(kmap);
+ kmap->virtual = NULL;
+}
+EXPORT_SYMBOL(drm_gem_vram_bo_driver_move_notify);
+
/*
* drm_gem_vram_mm_funcs - Functions for &struct drm_vram_mm
*
@@ -506,7 +538,8 @@ EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
*/
const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs = {
.evict_flags = drm_gem_vram_bo_driver_evict_flags,
- .verify_access = drm_gem_vram_bo_driver_verify_access
+ .verify_access = drm_gem_vram_bo_driver_verify_access,
+ .move_notify = drm_gem_vram_bo_driver_move_notify,
};
EXPORT_SYMBOL(drm_gem_vram_mm_funcs);
diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h
index 4f0e207ee097..b47c46516466 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -112,6 +112,10 @@ int drm_gem_vram_fill_create_dumb(struct drm_file *file,
void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
struct ttm_placement *pl);
+void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
+ bool evict,
+ struct ttm_mem_reg *new_mem);
+
int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
struct file *filp);
--
2.23.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-09-06 12:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 12:20 [PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers Thomas Zimmermann
2019-09-06 12:20 ` [PATCH v4 1/4] drm/vram: Add kmap ref-counting to GEM VRAM objects Thomas Zimmermann
2019-09-06 12:20 ` [PATCH v4 2/4] drm/vram: Acquire lock only once per call to vmap()/vunmap() Thomas Zimmermann
2019-09-06 12:20 ` [PATCH v4 3/4] drm/vram: Add infrastructure for move_notify() Thomas Zimmermann
2019-09-06 12:20 ` Thomas Zimmermann [this message]
2019-09-06 18:33 ` [PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers Daniel Vetter
2019-09-06 18:39 ` Davidlohr Bueso
2019-09-09 9:47 ` Gerd Hoffmann
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=20190906122056.32018-5-tzimmermann@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dave@stgolabs.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=feng.tang@intel.com \
--cc=kraxel@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime.ripard@bootlin.com \
--cc=noralf@tronnes.org \
--cc=rong.a.chen@intel.com \
--cc=sean@poorly.run \
--cc=ying.huang@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.