All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Lionel Landwerlin" <lionel.g.landwerlin@intel.com>,
	"Kenneth Graunke" <kenneth@whitecape.org>,
	"Jon Bloomfield" <jon.bloomfield@intel.com>,
	dri-devel@lists.freedesktop.org,
	"Jordan Justen" <jordan.l.justen@intel.com>,
	"Akeem G Abodunrin" <akeem.g.abodunrin@intel.com>
Subject: [PATCH 02/10] drm/i915/uapi: add probed_cpu_visible_size
Date: Wed, 25 May 2022 19:43:29 +0100	[thread overview]
Message-ID: <20220525184337.491763-3-matthew.auld@intel.com> (raw)
In-Reply-To: <20220525184337.491763-1-matthew.auld@intel.com>

Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so it's just case of plumbing that through to the region query.

Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
---
 drivers/gpu/drm/i915/i915_query.c |  6 +++
 include/uapi/drm/i915_drm.h       | 74 +++++++++++++++++--------------
 2 files changed, 47 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
index 7584cec53d5d..9aa0b28aa6ee 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -496,6 +496,12 @@ static int query_memregion_info(struct drm_i915_private *i915,
 		info.region.memory_class = mr->type;
 		info.region.memory_instance = mr->instance;
 		info.probed_size = mr->total;
+
+		if (mr->type == INTEL_MEMORY_LOCAL)
+			info.probed_cpu_visible_size = mr->io_size;
+		else
+			info.probed_cpu_visible_size = mr->total;
+
 		info.unallocated_size = mr->avail;
 
 		if (__copy_to_user(info_ptr, &info, sizeof(info)))
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index de49b68b4fc8..9df419a45244 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3207,36 +3207,6 @@ struct drm_i915_gem_memory_class_instance {
  * struct drm_i915_memory_region_info - Describes one region as known to the
  * driver.
  *
- * Note that we reserve some stuff here for potential future work. As an example
- * we might want expose the capabilities for a given region, which could include
- * things like if the region is CPU mappable/accessible, what are the supported
- * mapping types etc.
- *
- * Note that to extend struct drm_i915_memory_region_info and struct
- * drm_i915_query_memory_regions in the future the plan is to do the following:
- *
- * .. code-block:: C
- *
- *	struct drm_i915_memory_region_info {
- *		struct drm_i915_gem_memory_class_instance region;
- *		union {
- *			__u32 rsvd0;
- *			__u32 new_thing1;
- *		};
- *		...
- *		union {
- *			__u64 rsvd1[8];
- *			struct {
- *				__u64 new_thing2;
- *				__u64 new_thing3;
- *				...
- *			};
- *		};
- *	};
- *
- * With this things should remain source compatible between versions for
- * userspace, even as we add new fields.
- *
  * Note this is using both struct drm_i915_query_item and struct drm_i915_query.
  * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS
  * at &drm_i915_query_item.query_id.
@@ -3248,14 +3218,52 @@ struct drm_i915_memory_region_info {
 	/** @rsvd0: MBZ */
 	__u32 rsvd0;
 
-	/** @probed_size: Memory probed by the driver (-1 = unknown) */
+	/**
+	 * @probed_size: Memory probed by the driver (-1 = unknown)
+	 *
+	 * Note that it should not be possible to ever encounter a zero value
+	 * here, also note that no current region type will ever return -1 here.
+	 * Although for future region types, this might be a possibility. The
+	 * same applies to the other size fields.
+	 */
 	__u64 probed_size;
 
 	/** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
 	__u64 unallocated_size;
 
-	/** @rsvd1: MBZ */
-	__u64 rsvd1[8];
+	union {
+		/** @rsvd1: MBZ */
+		__u64 rsvd1[8];
+		struct {
+			/**
+			 * @probed_cpu_visible_size: Memory probed by the driver
+			 * that is CPU accessible. (-1 = unknown).
+			 *
+			 * This will be always be <= @probed_size, and the
+			 * remainder (if there is any) will not be CPU
+			 * accessible.
+			 *
+			 * On systems without small BAR, the @probed_size will
+			 * always equal the @probed_cpu_visible_size, since all
+			 * of it will be CPU accessible.
+			 *
+			 * Note this is only tracked for
+			 * I915_MEMORY_CLASS_DEVICE regions (for other types the
+			 * value here will always equal the @probed_size).
+			 *
+			 * Note that if the value returned here is zero, then
+			 * this must be an old kernel which lacks the relevant
+			 * small-bar uAPI support (including
+			 * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+			 * such systems we should never actually end up with a
+			 * small BAR configuration, assuming we are able to load
+			 * the kernel module. Hence it should be safe to treat
+			 * this the same as when @probed_cpu_visible_size ==
+			 * @probed_size.
+			 */
+			__u64 probed_cpu_visible_size;
+		};
+	};
 };
 
 /**
-- 
2.34.3


WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Kenneth Graunke" <kenneth@whitecape.org>,
	dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 02/10] drm/i915/uapi: add probed_cpu_visible_size
Date: Wed, 25 May 2022 19:43:29 +0100	[thread overview]
Message-ID: <20220525184337.491763-3-matthew.auld@intel.com> (raw)
In-Reply-To: <20220525184337.491763-1-matthew.auld@intel.com>

Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so it's just case of plumbing that through to the region query.

Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
---
 drivers/gpu/drm/i915/i915_query.c |  6 +++
 include/uapi/drm/i915_drm.h       | 74 +++++++++++++++++--------------
 2 files changed, 47 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
index 7584cec53d5d..9aa0b28aa6ee 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -496,6 +496,12 @@ static int query_memregion_info(struct drm_i915_private *i915,
 		info.region.memory_class = mr->type;
 		info.region.memory_instance = mr->instance;
 		info.probed_size = mr->total;
+
+		if (mr->type == INTEL_MEMORY_LOCAL)
+			info.probed_cpu_visible_size = mr->io_size;
+		else
+			info.probed_cpu_visible_size = mr->total;
+
 		info.unallocated_size = mr->avail;
 
 		if (__copy_to_user(info_ptr, &info, sizeof(info)))
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index de49b68b4fc8..9df419a45244 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3207,36 +3207,6 @@ struct drm_i915_gem_memory_class_instance {
  * struct drm_i915_memory_region_info - Describes one region as known to the
  * driver.
  *
- * Note that we reserve some stuff here for potential future work. As an example
- * we might want expose the capabilities for a given region, which could include
- * things like if the region is CPU mappable/accessible, what are the supported
- * mapping types etc.
- *
- * Note that to extend struct drm_i915_memory_region_info and struct
- * drm_i915_query_memory_regions in the future the plan is to do the following:
- *
- * .. code-block:: C
- *
- *	struct drm_i915_memory_region_info {
- *		struct drm_i915_gem_memory_class_instance region;
- *		union {
- *			__u32 rsvd0;
- *			__u32 new_thing1;
- *		};
- *		...
- *		union {
- *			__u64 rsvd1[8];
- *			struct {
- *				__u64 new_thing2;
- *				__u64 new_thing3;
- *				...
- *			};
- *		};
- *	};
- *
- * With this things should remain source compatible between versions for
- * userspace, even as we add new fields.
- *
  * Note this is using both struct drm_i915_query_item and struct drm_i915_query.
  * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS
  * at &drm_i915_query_item.query_id.
@@ -3248,14 +3218,52 @@ struct drm_i915_memory_region_info {
 	/** @rsvd0: MBZ */
 	__u32 rsvd0;
 
-	/** @probed_size: Memory probed by the driver (-1 = unknown) */
+	/**
+	 * @probed_size: Memory probed by the driver (-1 = unknown)
+	 *
+	 * Note that it should not be possible to ever encounter a zero value
+	 * here, also note that no current region type will ever return -1 here.
+	 * Although for future region types, this might be a possibility. The
+	 * same applies to the other size fields.
+	 */
 	__u64 probed_size;
 
 	/** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
 	__u64 unallocated_size;
 
-	/** @rsvd1: MBZ */
-	__u64 rsvd1[8];
+	union {
+		/** @rsvd1: MBZ */
+		__u64 rsvd1[8];
+		struct {
+			/**
+			 * @probed_cpu_visible_size: Memory probed by the driver
+			 * that is CPU accessible. (-1 = unknown).
+			 *
+			 * This will be always be <= @probed_size, and the
+			 * remainder (if there is any) will not be CPU
+			 * accessible.
+			 *
+			 * On systems without small BAR, the @probed_size will
+			 * always equal the @probed_cpu_visible_size, since all
+			 * of it will be CPU accessible.
+			 *
+			 * Note this is only tracked for
+			 * I915_MEMORY_CLASS_DEVICE regions (for other types the
+			 * value here will always equal the @probed_size).
+			 *
+			 * Note that if the value returned here is zero, then
+			 * this must be an old kernel which lacks the relevant
+			 * small-bar uAPI support (including
+			 * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+			 * such systems we should never actually end up with a
+			 * small BAR configuration, assuming we are able to load
+			 * the kernel module. Hence it should be safe to treat
+			 * this the same as when @probed_cpu_visible_size ==
+			 * @probed_size.
+			 */
+			__u64 probed_cpu_visible_size;
+		};
+	};
 };
 
 /**
-- 
2.34.3


  parent reply	other threads:[~2022-05-25 18:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25 18:43 [PATCH 00/10] small BAR uapi bits Matthew Auld
2022-05-25 18:43 ` [Intel-gfx] " Matthew Auld
2022-05-25 18:43 ` [PATCH 01/10] drm/doc: add rfc section for small BAR uapi Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-06-16 11:18   ` Thomas Hellström (Intel)
2022-05-25 18:43 ` Matthew Auld [this message]
2022-05-25 18:43   ` [Intel-gfx] [PATCH 02/10] drm/i915/uapi: add probed_cpu_visible_size Matthew Auld
2022-06-01 12:36   ` Das, Nirmoy
2022-06-01 12:36     ` [Intel-gfx] " Das, Nirmoy
2022-06-16 11:22   ` Thomas Hellström (Intel)
2022-05-25 18:43 ` [PATCH 03/10] drm/i915/uapi: expose the avail tracking Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-05-26  2:44   ` kernel test robot
2022-05-26  7:58   ` Tvrtko Ursulin
2022-05-26  7:58     ` [Intel-gfx] " Tvrtko Ursulin
2022-05-26  8:10     ` Matthew Auld
2022-05-26  8:10       ` [Intel-gfx] " Matthew Auld
2022-05-26  8:33       ` Tvrtko Ursulin
2022-05-26  8:33         ` [Intel-gfx] " Tvrtko Ursulin
2022-05-30 17:05         ` Matthew Auld
2022-05-30 17:05           ` [Intel-gfx] " Matthew Auld
2022-05-25 18:43 ` [PATCH 04/10] drm/i915: remove intel_memory_region avail Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-06-17 12:16   ` Thomas Hellström
2022-05-25 18:43 ` [PATCH 05/10] drm/i915/uapi: apply ALLOC_GPU_ONLY by default Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-05-25 18:43 ` [PATCH 06/10] drm/i915/uapi: add NEEDS_CPU_ACCESS hint Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-06-01 12:30   ` Das, Nirmoy
2022-06-17 14:30   ` Thomas Hellström (Intel)
2022-05-25 18:43 ` [PATCH 07/10] drm/i915/error: skip non-mappable pages Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-06-01 12:30   ` Das, Nirmoy
2022-06-17 14:26   ` Thomas Hellström (Intel)
2022-05-25 18:43 ` [PATCH 08/10] drm/i915/uapi: disable capturing objects on recoverable contexts Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-05-26  0:08   ` kernel test robot
2022-05-26  0:08     ` kernel test robot
2022-06-17 12:28   ` Thomas Hellström (Intel)
2022-05-25 18:43 ` [PATCH 09/10] drm/i915: turn on small BAR support Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-06-17 12:33   ` Thomas Hellström
2022-06-21  8:38     ` Matthew Auld
2022-06-21  9:05       ` Das, Nirmoy
2022-06-21  9:34         ` Thomas Hellström
2022-05-25 18:43 ` [PATCH 10/10] HAX: force small BAR on dg2 Matthew Auld
2022-05-25 18:43   ` [Intel-gfx] " Matthew Auld
2022-05-25 19:25 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for small BAR uapi bits Patchwork
2022-05-25 19:25 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-05-25 20:16 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-26 10:58 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=20220525184337.491763-3-matthew.auld@intel.com \
    --to=matthew.auld@intel.com \
    --cc=akeem.g.abodunrin@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jon.bloomfield@intel.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kenneth@whitecape.org \
    --cc=lionel.g.landwerlin@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tvrtko.ursulin@linux.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.