All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: feng.tang@intel.com, dave@stgolabs.net, rong.a.chen@intel.com,
	airlied@linux.ie, dri-devel@lists.freedesktop.org,
	maxime.ripard@bootlin.com, kraxel@redhat.com,
	ying.huang@intel.com, sean@poorly.run
Subject: Re: [PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers
Date: Fri, 6 Sep 2019 20:33:01 +0200	[thread overview]
Message-ID: <20190906183301.GG3958@phenom.ffwll.local> (raw)
In-Reply-To: <20190906122056.32018-1-tzimmermann@suse.de>

On Fri, Sep 06, 2019 at 02:20:52PM +0200, Thomas Zimmermann wrote:
> Generic fbdev emulation maps and unmaps the console BO for updating it's
> content from the shadow buffer. If this involves an actual mapping
> operation (instead of reusing an existing mapping), lots of debug messages
> may be printed, such as
> 
>   x86/PAT: Overlap at 0xd0000000-0xd1000000
>   x86/PAT: reserve_memtype added [mem 0xd0000000-0xd02fffff], track write-combining, req write-combining, ret write-combining
>   x86/PAT: free_memtype request [mem 0xd0000000-0xd02fffff]
> 
> as reported at [1]. Drivers using VRAM helpers may also see reduced
> performance as the mapping operations can create overhead.
> 
> In v3 and later of the patch set, this problem is being solved by lazily
> unmapping the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap()
> only changes a reference counter. VRAM helpers later perform the unmapping
> operation when TTM evicts the buffer object from its current location. If
> the buffer is never evicted, the existing mapping is reused by later calls
> to drm_gem_vram_kmap().
> 
> v4:
> 	* lock kmap with ttm_bo_reserve()
> 	* acquire lock only once for vmap()
> 	* warn about stale mappings during buffer cleanup
> v3:
>       	* implement lazy unmapping
> v2:
> 	* fixed comment typos
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html

On the series: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-Daniel

> 
> Thomas Zimmermann (4):
>   drm/vram: Add kmap ref-counting to GEM VRAM objects
>   drm/vram: Acquire lock only once per call to vmap()/vunmap()
>   drm/vram: Add infrastructure for move_notify()
>   drm/vram: Implement lazy unmapping for GEM VRAM buffers
> 
>  drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++++++++++++++++++--------
>  drivers/gpu/drm/drm_vram_mm_helper.c  |  12 ++
>  include/drm/drm_gem_vram_helper.h     |  18 ++
>  include/drm/drm_vram_mm_helper.h      |   4 +
>  4 files changed, 198 insertions(+), 65 deletions(-)
> 
> --
> 2.23.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-09-06 18:33 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 ` [PATCH v4 4/4] drm/vram: Implement lazy unmapping for GEM VRAM buffers Thomas Zimmermann
2019-09-06 18:33 ` Daniel Vetter [this message]
2019-09-06 18:39 ` [PATCH v4 0/4] " 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=20190906183301.GG3958@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=dave@stgolabs.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=feng.tang@intel.com \
    --cc=kraxel@redhat.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=rong.a.chen@intel.com \
    --cc=sean@poorly.run \
    --cc=tzimmermann@suse.de \
    --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.