From: "Piórkowski, Piotr" <piotr.piorkowski@intel.com>
To: <intel-xe@lists.freedesktop.org>
Cc: "Piotr Piórkowski" <piotr.piorkowski@intel.com>,
"Matthew Brost" <matthew.brost@intel.com>
Subject: [PATCH v1 1/7] drm/xe: Define partitioned VRAM manager types
Date: Fri, 2 Oct 2026 12:40:12 +0200 [thread overview]
Message-ID: <20261002104018.3648425-2-piotr.piorkowski@intel.com> (raw)
In-Reply-To: <20261002104018.3648425-1-piotr.piorkowski@intel.com>
From: Piotr Piórkowski <piotr.piorkowski@intel.com>
A VRAM region may need to be split into hard partitions, e.g. to keep
kernel allocations in a dedicated low range of VRAM. Expressing such a
split purely as a placement range would turn every VRAM allocation into
a %GPU_BUDDY_RANGE_ALLOCATION, which constrains the buddy algorithm for
what is really a hard, statically known split.
Describe the types needed to manage each partition with a buddy
allocator of its own instead. struct xe_ttm_vram_mgr_part ties a buddy
allocator to the VRAM pool it backs, the manager holds up to
XE_TTM_VRAM_MGR_MAX_PARTS of them, and resources and offlined pages
record the partition their blocks were allocated from, as buddy offsets
become partition relative.
Each partition also tracks the CPU visible memory allocated from it, so
that usage can be reported per pool purpose, and the alignment a
partition base must honour is defined next to the partition itself.
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Assisted-by: Claude Opus 5.5
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h b/drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h
index efcf3e1d4e80c..6af179b2b95b5 100644
--- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h
+++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr_types.h
@@ -7,8 +7,46 @@
#define _XE_TTM_VRAM_MGR_TYPES_H_
#include <linux/gpu_buddy.h>
+#include <linux/sizes.h>
#include <drm/ttm/ttm_device.h>
+struct xe_vram_pool;
+
+/**
+ * struct xe_ttm_vram_mgr_part - Partition of a VRAM region
+ *
+ * A VRAM region may be split into disjoint partitions, each managed by its
+ * own buddy allocator. An allocation belongs to exactly one partition and
+ * cannot span partition boundaries. This lets the manager allocate directly
+ * from the requested partition without resorting to
+ * %GPU_BUDDY_RANGE_ALLOCATION, which constrains the buddy allocation
+ * algorithm.
+ */
+struct xe_ttm_vram_mgr_part {
+ /**
+ * @pool: VRAM pool backed by this partition
+ *
+ * Once the manager is initialized, pool->part points back here.
+ */
+ struct xe_vram_pool *pool;
+ /** @mm: DRM buddy allocator which manages this partition */
+ struct gpu_buddy mm;
+ /** @used_visible: CPU visible bytes allocated from this partition */
+ u64 used_visible;
+};
+
+/** XE_TTM_VRAM_MGR_MAX_PARTS - Max partitions of a single VRAM region */
+#define XE_TTM_VRAM_MGR_MAX_PARTS 2
+
+/**
+ * XE_TTM_VRAM_MGR_PART_ALIGN - Required alignment of a partition base
+ *
+ * Buddy offsets are partition relative, so a partition base has to be
+ * aligned to the largest VRAM page size in regular use, otherwise an aligned
+ * buddy allocation is not aligned in the region.
+ */
+#define XE_TTM_VRAM_MGR_PART_ALIGN SZ_2M
+
/**
* struct xe_ttm_vram_mgr - Xe TTM VRAM manager
*
@@ -19,6 +57,10 @@ struct xe_ttm_vram_mgr {
struct ttm_resource_manager manager;
/** @mm: DRM buddy allocator which manages the VRAM */
struct gpu_buddy mm;
+ /** @parts: Partitions this VRAM region is split into */
+ struct xe_ttm_vram_mgr_part parts[XE_TTM_VRAM_MGR_MAX_PARTS];
+ /** @num_parts: Number of initialized entries in @parts */
+ unsigned int num_parts;
/** @offlined_pages: List of offlined pages */
struct list_head offlined_pages;
/** @n_offlined_pages: Number of offlined pages */
@@ -49,6 +91,8 @@ struct xe_ttm_vram_mgr_resource {
struct ttm_resource base;
/** @blocks: list of DRM buddy blocks */
struct list_head blocks;
+ /** @part: Partition owning @blocks, set on successful allocation */
+ struct xe_ttm_vram_mgr_part *part;
/** @used_visible_size: How many CPU visible bytes this resource is using */
u64 used_visible_size;
/** @flags: flags associated with the resource */
@@ -75,6 +119,8 @@ struct xe_ttm_vram_offline_resource {
struct list_head queued_link;
/** @blocks: Buddy blocks reserved for this page */
struct list_head blocks;
+ /** @part: Partition owning @blocks, set on successful reservation */
+ struct xe_ttm_vram_mgr_part *part;
/** @used_visible_size: CPU-visible bytes consumed */
u64 used_visible_size;
/** @addr: Faulty DPA reported by HW */
--
2.34.1
next prev parent reply other threads:[~2026-10-02 10:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 10:40 [PATCH v1 0/7] Introduce purpose-specific VRAM pools Piórkowski, Piotr
2026-10-02 10:40 ` Piórkowski, Piotr [this message]
2026-10-02 10:40 ` [PATCH v1 2/7] drm/xe: Define VRAM regions and pools Piórkowski, Piotr
2026-10-02 10:40 ` [PATCH v1 3/7] drm/xe/vram: Make VRAM pools the allocation handle Piórkowski, Piotr
2026-10-02 10:53 ` sashiko-bot
2026-10-02 10:40 ` [PATCH v1 4/7] drm/xe/ttm: Back each VRAM pool with its own buddy allocator Piórkowski, Piotr
2026-10-02 10:40 ` [PATCH v1 5/7] drm/xe/vram: Allow splitting a region into pools Piórkowski, Piotr
2026-10-02 10:40 ` [PATCH v1 6/7] drm/xe/kunit: Test partitioned VRAM manager Piórkowski, Piotr
2026-10-02 10:40 ` [PATCH v1 7/7] drm/xe/kunit: Test VRAM pool allocation Piórkowski, Piotr
2026-10-02 10:47 ` ✗ CI.checkpatch: warning for Introduce purpose-specific VRAM pools Patchwork
2026-10-02 10:49 ` ✓ CI.KUnit: 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=20261002104018.3648425-2-piotr.piorkowski@intel.com \
--to=piotr.piorkowski@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox