All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Kenneth Graunke <kenneth@whitecape.org>
Subject: Re: [Mesa-dev] [PATCH] i965: Embrace "unlimited" GTT mmap support
Date: Thu, 25 Aug 2016 09:06:13 +0200	[thread overview]
Message-ID: <20160825070613.GM10980@phenom.ffwll.local> (raw)
In-Reply-To: <20160824194244.27583-2-chris@chris-wilson.co.uk>

On Wed, Aug 24, 2016 at 08:42:44PM +0100, Chris Wilson wrote:
> From about kernel 4.9, GTT mmaps are virtually unlimited. A new
> parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
> feature so query it and use it to avoid limiting tiled allocations to
> only fit within the mappable aperture.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> ---
>  src/mesa/drivers/dri/i965/brw_context.c  | 17 ++---------------
>  src/mesa/drivers/dri/i965/brw_context.h  |  2 +-
>  src/mesa/drivers/dri/i965/intel_screen.c | 32 ++++++++++++++++++++++++++++++++
>  src/mesa/drivers/dri/i965/intel_screen.h |  2 ++
>  4 files changed, 37 insertions(+), 16 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
> index b0f9063..79dba1e 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -1033,21 +1033,6 @@ brwCreateContext(gl_api api,
>     brw->urb.max_ds_entries = devinfo->urb.max_ds_entries;
>     brw->urb.max_gs_entries = devinfo->urb.max_gs_entries;
>  
> -   /* Estimate the size of the mappable aperture into the GTT.  There's an
> -    * ioctl to get the whole GTT size, but not one to get the mappable subset.
> -    * It turns out it's basically always 256MB, though some ancient hardware
> -    * was smaller.
> -    */
> -   uint32_t gtt_size = 256 * 1024 * 1024;
> -
> -   /* We don't want to map two objects such that a memcpy between them would
> -    * just fault one mapping in and then the other over and over forever.  So
> -    * we would need to divide the GTT size by 2.  Additionally, some GTT is
> -    * taken up by things like the framebuffer and the ringbuffer and such, so
> -    * be more conservative.
> -    */
> -   brw->max_gtt_map_object_size = gtt_size / 4;
> -
>     if (brw->gen == 6)
>        brw->urb.gs_present = false;
>  
> @@ -1058,6 +1043,8 @@ brwCreateContext(gl_api api,
>  
>     brw->predicate.state = BRW_PREDICATE_STATE_RENDER;
>  
> +   brw->max_gtt_map_object_size = screen->max_gtt_map_object_size;
> +
>     brw->use_resource_streamer = screen->has_resource_streamer &&
>        (env_var_as_boolean("INTEL_USE_HW_BT", false) ||
>         env_var_as_boolean("INTEL_USE_GATHER", false));
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h
> index f2dd164..523f36c 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -861,7 +861,7 @@ struct brw_context
>      */
>     bool perf_debug;
>  
> -   uint32_t max_gtt_map_object_size;
> +   uint64_t max_gtt_map_object_size;
>  
>     int gen;
>     int gt;
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c
> index 98f1c76..62eacba 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1006,6 +1006,17 @@ intel_get_boolean(struct intel_screen *screen, int param)
>     return (intel_get_param(screen, param, &value) == 0) && value;
>  }
>  
> +static int
> +intel_get_integer(struct intel_screen *screen, int param)
> +{
> +   int value = -1;
> +
> +   if (intel_get_param(screen, param, &value) == 0)
> +	   return value;
> +
> +   return -1;
> +}
> +
>  static void
>  intelDestroyScreen(__DRIscreen * sPriv)
>  {
> @@ -1576,6 +1587,27 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
>     if (INTEL_DEBUG & DEBUG_AUB)
>        drm_intel_bufmgr_gem_set_aub_dump(intelScreen->bufmgr, true);
>  
> +#define I915_PARAM_MMAP_GTT_VERSION 40 /* XXX delete me with new libdrm */
> +   if (intel_get_integer(intelScreen, I915_PARAM_MMAP_GTT_VERSION) >= 1) {
> +      /* Theorectically unlimited! */
> +      intelScreen->max_gtt_map_object_size = UINT64_MAX;
> +   } else {
> +      /* Estimate the size of the mappable aperture into the GTT.  There's an
> +       * ioctl to get the whole GTT size, but not one to get the mappable subset.
> +       * It turns out it's basically always 256MB, though some ancient hardware
> +       * was smaller.
> +       */
> +      uint32_t gtt_size = 256 * 1024 * 1024;
> +
> +      /* We don't want to map two objects such that a memcpy between them would
> +       * just fault one mapping in and then the other over and over forever.  So
> +       * we would need to divide the GTT size by 2.  Additionally, some GTT is
> +       * taken up by things like the framebuffer and the ringbuffer and such, so
> +       * be more conservative.
> +       */
> +      intelScreen->max_gtt_map_object_size = gtt_size / 4;
> +   }
> +
>     intelScreen->hw_has_swizzling = intel_detect_swizzling(intelScreen);
>     intelScreen->hw_has_timestamp = intel_detect_timestamp(intelScreen);
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.h b/src/mesa/drivers/dri/i965/intel_screen.h
> index 35cd5df..fa806a3 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.h
> +++ b/src/mesa/drivers/dri/i965/intel_screen.h
> @@ -44,6 +44,8 @@ struct intel_screen
>  
>     __DRIscreen *driScrnPriv;
>  
> +   uint64_t max_gtt_map_object_size;
> +
>     bool no_hw;
>     bool hw_has_swizzling;
>     bool has_fence_fd;
> -- 
> 2.9.3
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

  reply	other threads:[~2016-08-25  7:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24 19:42 [PATCH] drm/i915: Add I915_PARAM_MMAP_GTT_VERSION to advertise unlimited mmaps Chris Wilson
2016-08-24 19:42 ` [PATCH] i965: Embrace "unlimited" GTT mmap support Chris Wilson
2016-08-25  7:06   ` Daniel Vetter [this message]
2016-08-25  7:26   ` Kenneth Graunke
2016-08-25 20:43   ` Ian Romanick
2016-08-25 21:58     ` Chris Wilson
2016-08-25  7:02 ` [PATCH] drm/i915: Add I915_PARAM_MMAP_GTT_VERSION to advertise unlimited mmaps Daniel Vetter
2016-08-25  8:00 ` Joonas Lahtinen
2016-08-25  8:27   ` [Intel-gfx] " Chris Wilson
2016-08-25 12:15     ` Joonas Lahtinen
2016-08-25 18:05       ` [PATCH v2] " 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=20160825070613.GM10980@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kenneth@whitecape.org \
    --cc=mesa-dev@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 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.