From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Cc: akash.goel@intel.com
Subject: Re: [PATCH 12/12] drm/i915: Extend GET_APERTURE ioctl to report size of the stolen region
Date: Thu, 21 Apr 2016 15:17:06 +0100 [thread overview]
Message-ID: <5718E0E2.2060001@linux.intel.com> (raw)
In-Reply-To: <1461151059-16361-13-git-send-email-ankitprasad.r.sharma@intel.com>
On 20/04/16 12:17, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> This patch extends the GET_APERTURE ioctl to add support
> for getting total size and available size of the stolen region
> as well as single largest block available in the stolen region.
> Also adds debugfs support to retieve the size information of the
> stolen area.
>
> v2: respinned over Rodrigo's patch which extends the GET_APERTURE
> too. Used drm_mm to get the size information of the stolen region
> (Chris)
> Added debugfs support for testing (Ankit)
>
> v3: Rebased to the latest drm-intel-nightly (Ankit)
>
> v4: Addressed comments, moved non-limits to debugfs.c (Chris/Tvrtko)
>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +++++++++-
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/i915_gem.c | 2 ++
> drivers/gpu/drm/i915/i915_gem_stolen.c | 41 ++++++++++++++++++++++++++++++++++
> include/uapi/drm/i915_drm.h | 6 +++++
> 5 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index d8d7994..55d110e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -580,7 +580,7 @@ static int i915_gem_aperture_info(struct seq_file *m, void *data)
> struct list_head map_list;
> const uint64_t map_limit = ggtt->mappable_end;
> uint64_t map_space, map_largest, fence_space, fence_largest;
> - uint64_t last, size;
> + uint64_t last, size, stolen_free, stolen_largest;
> int ret;
>
> INIT_LIST_HEAD(&map_list);
> @@ -593,6 +593,10 @@ static int i915_gem_aperture_info(struct seq_file *m, void *data)
> return ret;
>
> mutex_lock(&dev->struct_mutex);
> +
> + i915_gem_stolen_size_info(dev_priv, &stolen_free,
> + &stolen_largest);
> +
> list_for_each_entry(vma, &ggtt->base.active_list, vm_link)
> if (vma->pin_count &&
> (vma->node.start + vma->node.size) <= map_limit)
> @@ -652,6 +656,12 @@ skip_first:
> fence_space);
> seq_printf(m, "Single largest fence available: %llu bytes\n",
> fence_largest);
> + seq_printf(m, "Total size of the stolen region: %llu bytes\n",
> + arg.stolen_total_size);
> + seq_printf(m, "Available size of the stolen region: %llu bytes\n",
> + stolen_free);
> + seq_printf(m, "Single largest area in the stolen region: %llu bytes\n",
> + stolen_largest);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 37f9de8..d5c6b23 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3424,6 +3424,9 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
> u32 gtt_offset,
> u32 size);
> int __must_check i915_gem_stolen_freeze(struct drm_i915_private *i915);
> +void i915_gem_stolen_size_info(struct drm_i915_private *dev_priv,
> + uint64_t *stolen_free,
> + uint64_t *stolen_largest);
>
> /* i915_gem_shrinker.c */
> unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a1be35f..e0f2259 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -166,6 +166,8 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
> args->aper_size = ggtt->base.total;
> args->aper_available_size = args->aper_size - pinned;
> args->map_total_size = ggtt->mappable_end;;
> + args->stolen_total_size =
> + dev_priv->mm.volatile_stolen ? 0 : ggtt->stolen_usable_size;
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index ef28af6..f2621c5 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -912,3 +912,44 @@ int i915_gem_stolen_freeze(struct drm_i915_private *i915)
>
> return ret;
> }
> +
> +
> +void i915_gem_stolen_size_info(struct drm_i915_private *dev_priv,
> + uint64_t *stolen_free,
> + uint64_t *stolen_largest)
> +{
> + struct drm_mm *mm = &dev_priv->mm.stolen;
> + struct drm_mm_node *head_node = &mm->head_node;
> + struct drm_mm_node *entry;
> + uint64_t hole_size, hole_start, hole_end, largest_hole = 0;
> + uint64_t total_free = 0;
> +
> + if (dev_priv->mm.volatile_stolen) {
> + *stolen_free = 0;
> + *stolen_largest = 0;
> + return;
> + }
> +
> + if (head_node->hole_follows) {
> + hole_start = drm_mm_hole_node_start(head_node);
> + hole_end = drm_mm_hole_node_end(head_node);
> + hole_size = hole_end - hole_start;
> + total_free += hole_size;
> + if (largest_hole < hole_size)
> + largest_hole = hole_size;
> + }
> +
Why does this block need to be separately handled and the loop below
would not cover it? On first iteration entry will be the head node below
as well, no?
> + drm_mm_for_each_node(entry, mm) {
> + if (entry->hole_follows) {
> + hole_start = drm_mm_hole_node_start(entry);
> + hole_end = drm_mm_hole_node_end(entry);
> + hole_size = hole_end - hole_start;
> + total_free += hole_size;
> + if (largest_hole < hole_size)
> + largest_hole = hole_size;
> + }
> + }
> +
> + *stolen_free = total_free;
> + *stolen_largest = largest_hole;
> +}
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 8f38407..424e57e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1012,6 +1012,12 @@ struct drm_i915_gem_get_aperture {
> * Total space in the mappable region of the aperture, in bytes
> */
> __u64 map_total_size;
> +
> + /**
> + * Total space in the stolen region, in bytes
> + */
> + __u64 stolen_total_size;
> +
How will the userspace detect existence of the new ioctl fields? Is it
intended that they try to call it with a buffer of certain size and act
on the failure when that fails? Is that good enough or we need something
better like get_param or something?
Regards,
Tvrtko
> };
>
> struct drm_i915_get_pipe_from_crtc_id {
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-21 14:19 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 11:17 [PATCH v19 00/12] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
2016-04-20 11:17 ` [PATCH 01/12] drm/i915: Add support for mapping an object page by page ankitprasad.r.sharma
2016-04-20 12:04 ` Chris Wilson
2016-05-24 8:17 ` Ankitprasad Sharma
2016-04-20 11:17 ` [PATCH 02/12] drm/i915: Introduce i915_gem_object_get_dma_address() ankitprasad.r.sharma
2016-04-20 12:08 ` Chris Wilson
2016-04-20 11:17 ` [PATCH 03/12] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
2016-04-20 13:01 ` kbuild test robot
2016-04-20 11:17 ` [PATCH 04/12] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
2016-04-20 11:17 ` [PATCH 05/12] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
2016-04-20 11:17 ` [PATCH 06/12] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
2016-04-20 11:17 ` [PATCH 07/12] drm/i915: Add support for stealing purgable stolen pages ankitprasad.r.sharma
2016-04-20 11:17 ` [PATCH 08/12] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
2016-04-20 12:19 ` Chris Wilson
2016-04-20 11:17 ` [PATCH 09/12] drm/i915: Migrate stolen objects before hibernation ankitprasad.r.sharma
2016-04-20 11:17 ` [PATCH 10/12] drm/i915: Disable use of stolen area by User when Intel RST is present ankitprasad.r.sharma
2016-04-20 23:15 ` Lukas Wunner
2016-04-20 11:17 ` [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space ankitprasad.r.sharma
2016-04-20 13:02 ` [PATCH] drm/i915: fix semicolon.cocci warnings kbuild test robot
2016-04-20 13:02 ` [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space kbuild test robot
2016-04-21 14:04 ` Tvrtko Ursulin
2016-04-21 14:46 ` Chris Wilson
2016-04-21 14:59 ` Tvrtko Ursulin
2016-04-25 10:35 ` Ankitprasad Sharma
2016-04-25 14:51 ` Tvrtko Ursulin
2016-04-26 9:44 ` Chris Wilson
2016-04-28 9:30 ` Tvrtko Ursulin
2016-04-28 10:24 ` Chris Wilson
2016-04-29 10:06 ` Tvrtko Ursulin
2016-04-29 10:18 ` Chris Wilson
2016-04-29 10:26 ` Tvrtko Ursulin
2016-04-29 10:39 ` Chris Wilson
2016-04-29 10:56 ` Tvrtko Ursulin
2016-04-29 11:03 ` Chris Wilson
2016-04-20 11:17 ` [PATCH 12/12] drm/i915: Extend GET_APERTURE ioctl to report size of the stolen region ankitprasad.r.sharma
2016-04-21 14:17 ` Tvrtko Ursulin [this message]
2016-04-21 14:41 ` Chris Wilson
2016-04-21 14:52 ` Tvrtko Ursulin
2016-04-20 16:28 ` ✗ Fi.CI.BAT: failure for Support for creating/using Stolen memory backed objects (rev13) Patchwork
2016-04-28 10:20 ` Tvrtko Ursulin
2016-04-24 14:58 ` ✓ Fi.CI.BAT: success " Patchwork
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=5718E0E2.2060001@linux.intel.com \
--to=tvrtko.ursulin@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 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).