From: "Siluvery, Arun" <arun.siluvery@linux.intel.com>
To: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Cc: akash.goel@intel.com
Subject: Re: [PATCH 1/3] drm/i915: Support for pre-populating the object with system pages
Date: Tue, 25 Aug 2015 11:51:49 +0100 [thread overview]
Message-ID: <55DC48C5.5090307@linux.intel.com> (raw)
In-Reply-To: <1440417496-3175-2-git-send-email-ankitprasad.r.sharma@intel.com>
On 24/08/2015 12:58, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> This patch provides support for the User to populate the object
> with system pages at its creation time. Since this can be safely
> performed without holding the 'struct_mutex', it would help to reduce
> the time 'struct_mutex' is kept locked especially during the exec-buffer
> path, where it is generally held for the longest time.
>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> ---
> drivers/gpu/drm/i915/i915_dma.c | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 51 +++++++++++++++++++++++++++++++----------
> include/uapi/drm/i915_drm.h | 11 ++++-----
> 3 files changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 8319e07..955aa16 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -171,7 +171,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
> value = HAS_RESOURCE_STREAMER(dev);
> break;
> case I915_PARAM_CREATE_VERSION:
> - value = 2;
> + value = 3;
> break;
> default:
> DRM_DEBUG("Unknown parameter %d\n", param->param);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c44bd05..3904feb 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -46,6 +46,7 @@ static void
> i915_gem_object_retire__write(struct drm_i915_gem_object *obj);
> static void
> i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring);
> +static int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
>
> static bool cpu_cache_is_coherent(struct drm_device *dev,
> enum i915_cache_level level)
> @@ -414,6 +415,18 @@ i915_gem_create(struct drm_file *file,
> if (obj == NULL)
> return -ENOMEM;
>
> + if (flags & I915_CREATE_POPULATE) {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + ret = __i915_gem_object_get_pages(obj);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&dev->struct_mutex);
> + list_add_tail(&obj->global_list, &dev_priv->mm.unbound_list);
> + mutex_unlock(&dev->struct_mutex);
> + }
> +
> ret = drm_gem_handle_create(file, &obj->base, &handle);
If I915_CREATE_POPULATE is set, don't we have to release the pages when
this call fails?
regards
Arun
> /* drop reference from allocate - handle holds it now */
> drm_gem_object_unreference_unlocked(&obj->base);
> @@ -2328,6 +2341,31 @@ err_pages:
> return ret;
> }
>
> +static int
> +__i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> +{
> + const struct drm_i915_gem_object_ops *ops = obj->ops;
> + int ret;
> +
> + WARN_ON(obj->pages);
> +
> + if (obj->madv != I915_MADV_WILLNEED) {
> + DRM_DEBUG("Attempting to obtain a purgeable object\n");
> + return -EFAULT;
> + }
> +
> + BUG_ON(obj->pages_pin_count);
> +
> + ret = ops->get_pages(obj);
> + if (ret)
> + return ret;
> +
> + obj->get_page.sg = obj->pages->sgl;
> + obj->get_page.last = 0;
> +
> + return 0;
> +}
> +
> /* Ensure that the associated pages are gathered from the backing storage
> * and pinned into our object. i915_gem_object_get_pages() may be called
> * multiple times before they are released by a single call to
> @@ -2339,28 +2377,17 @@ int
> i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> - const struct drm_i915_gem_object_ops *ops = obj->ops;
> int ret;
>
> if (obj->pages)
> return 0;
>
> - if (obj->madv != I915_MADV_WILLNEED) {
> - DRM_DEBUG("Attempting to obtain a purgeable object\n");
> - return -EFAULT;
> - }
> -
> - BUG_ON(obj->pages_pin_count);
> -
> - ret = ops->get_pages(obj);
> + ret = __i915_gem_object_get_pages(obj);
> if (ret)
> return ret;
>
> list_add_tail(&obj->global_list, &dev_priv->mm.unbound_list);
>
> - obj->get_page.sg = obj->pages->sgl;
> - obj->get_page.last = 0;
> -
> return 0;
> }
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index f71f75c..26ea715 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -457,20 +457,19 @@ struct drm_i915_gem_create {
> __u32 handle;
> __u32 pad;
> /**
> - * Requested flags (currently used for placement
> - * (which memory domain))
> + * Requested flags
> *
> * You can request that the object be created from special memory
> * rather than regular system pages using this parameter. Such
> * irregular objects may have certain restrictions (such as CPU
> * access to a stolen object is verboten).
> - *
> - * This can be used in the future for other purposes too
> - * e.g. specifying tiling/caching/madvise
> + * Also using this parameter object can be pre-populated with system
> + * pages.
> */
> __u32 flags;
> #define I915_CREATE_PLACEMENT_STOLEN (1<<0) /* Cannot use CPU mmaps */
> -#define __I915_CREATE_UNKNOWN_FLAGS -(I915_CREATE_PLACEMENT_STOLEN << 1)
> +#define I915_CREATE_POPULATE (1<<1) /* Pre-populate object pages */
> +#define __I915_CREATE_UNKNOWN_FLAGS -(I915_CREATE_POPULATE << 1)
> };
>
> struct drm_i915_gem_pread {
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-08-25 10:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 11:58 [PATCH 0/3] Reduce the time for which 'struct_mutex' is held ankitprasad.r.sharma
2015-08-24 11:58 ` [PATCH 1/3] drm/i915: Support for pre-populating the object with system pages ankitprasad.r.sharma
2015-08-24 12:35 ` Chris Wilson
2015-08-27 5:48 ` Ankitprasad Sharma
2015-08-27 7:45 ` Chris Wilson
2015-08-25 10:51 ` Siluvery, Arun [this message]
2015-08-27 6:34 ` Ankitprasad Sharma
2015-08-27 7:43 ` Chris Wilson
2015-08-24 11:58 ` [PATCH 2/3] drm/i915: Support for the clflush of pre-populated pages ankitprasad.r.sharma
2015-08-24 12:43 ` Chris Wilson
2015-08-24 11:58 ` [PATCH 3/3] drm/i915: Only move to the CPU write domain if keeping the GTT pages ankitprasad.r.sharma
2015-08-24 12:46 ` Chris Wilson
2015-08-26 9:25 ` [PATCH 0/3] Reduce the time for which 'struct_mutex' is held Daniel Vetter
2015-08-27 10:48 ` Ankitprasad Sharma
-- strict thread matches above, loose matches on Subject: below --
2015-08-27 11:04 [PATCH v2 " ankitprasad.r.sharma
2015-08-27 11:04 ` [PATCH 1/3] drm/i915: Support for pre-populating the object with system pages ankitprasad.r.sharma
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=55DC48C5.5090307@linux.intel.com \
--to=arun.siluvery@linux.intel.com \
--cc=akash.goel@intel.com \
--cc=ankitprasad.r.sharma@intel.com \
--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 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.