intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: "Piórkowski, Piotr" <piotr.piorkowski@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v1 2/4] drm/xe: Introduce new BO flag XE_BO_FLAG_FORCE_USER_VRAM
Date: Wed, 13 Aug 2025 17:38:57 +0100	[thread overview]
Message-ID: <18c05072-3d03-475e-a376-7f08251bff3d@intel.com> (raw)
In-Reply-To: <20250718081752.630122-3-piotr.piorkowski@intel.com>

On 18/07/2025 09:17, Piórkowski, Piotr wrote:
> From: Piotr Piórkowski <piotr.piorkowski@intel.com>
> 
> When using a separate VRAM region for kernel allocations,
> some kernel structures, such as context userspace data,
> should not reside in the VRAM region dedicated to the kernel.
> To support this, we need a mechanism to explicitly force such
> allocations.

Maybe add a bit more commentary here for the why? IIRC we don't want 
anything long term allocatable via an ioctl filling up the kernel VRAM 
region, since it's not really evictable plus there might not be a 
fallback if we run out.

> Let's add a new BO flag that forces BO allocation in
> the general-purpose VRAM region accessible to userspace.
> 
> Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
>   drivers/gpu/drm/xe/xe_bo.c | 5 +++--
>   drivers/gpu/drm/xe/xe_bo.h | 1 +
>   2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 12e899726534..997ebb6fdfaa 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -224,7 +224,7 @@ static u32 bo_vram_flags_to_vram_placement(struct xe_device *xe, u32 bo_flags, u
>   
>   	xe_assert(xe, tile_id < xe->info.tile_count);
>   
> -	if (type == ttm_bo_type_kernel)
> +	if (type == ttm_bo_type_kernel && !(bo_flags & XE_BO_FLAG_FORCE_USER_VRAM))
>   		return xe->tiles[tile_id].mem.kernel_vram->placement;
>   	else
>   		return xe->tiles[tile_id].mem.vram->placement;
> @@ -2035,7 +2035,8 @@ __xe_bo_create_locked(struct xe_device *xe,
>   	 * that we are using unified VRAM and we need fix VRAM BO flags.
>   	 */
>   	if (tile && type == ttm_bo_type_kernel && xe_tile_has_separate_kernel_vram(tile) &&
> -	    (flags & XE_BO_FLAG_VRAM_MASK) && tile->mem.vram->id != tile->mem.kernel_vram->id) {
> +	    (flags & XE_BO_FLAG_VRAM_MASK) && tile->mem.vram->id != tile->mem.kernel_vram->id &&
> +	    !(flags & XE_BO_FLAG_FORCE_USER_VRAM)) {
>   		flags &= ~XE_BO_FLAG_VRAM_MASK;
>   		flags |= (XE_BO_FLAG_VRAM0 << tile->mem.kernel_vram->id);
>   	}
> diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h
> index dde8e0274ff2..46c36f656ad7 100644
> --- a/drivers/gpu/drm/xe/xe_bo.h
> +++ b/drivers/gpu/drm/xe/xe_bo.h
> @@ -48,6 +48,7 @@
>   #define XE_BO_FLAG_GGTT2		BIT(22)
>   #define XE_BO_FLAG_GGTT3		BIT(23)
>   #define XE_BO_FLAG_CPU_ADDR_MIRROR	BIT(24)
> +#define XE_BO_FLAG_FORCE_USER_VRAM	BIT(25)
>   
>   /* this one is trigger internally only */
>   #define XE_BO_FLAG_INTERNAL_TEST	BIT(30)


  reply	other threads:[~2025-08-13 16:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-18  8:17 [PATCH v1 0/4] Preliminary support for separate VRAM region for kernel allocations on tiles Piórkowski, Piotr
2025-07-18  8:17 ` [PATCH v1 1/4] drm/xe: Add initial support for separate kernel VRAM region on the tile Piórkowski, Piotr
2025-08-13 16:53   ` Matthew Auld
2025-07-18  8:17 ` [PATCH v1 2/4] drm/xe: Introduce new BO flag XE_BO_FLAG_FORCE_USER_VRAM Piórkowski, Piotr
2025-08-13 16:38   ` Matthew Auld [this message]
2025-07-18  8:17 ` [PATCH v1 3/4] drm/xe: Force user context allocations in user VRAM Piórkowski, Piotr
2025-08-13 16:42   ` Matthew Auld
2025-07-18  8:17 ` [PATCH v1 4/4] drm/xe/pf: Force use user VRAM for LMEM provisioning Piórkowski, Piotr
2025-07-18  8:24 ` ✓ CI.KUnit: success for Preliminary support for separate VRAM region for kernel allocations on tiles Patchwork
2025-07-18  9:00 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-21  8:15 ` ✗ Xe.CI.Full: failure " 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=18c05072-3d03-475e-a376-7f08251bff3d@intel.com \
    --to=matthew.auld@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=piotr.piorkowski@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;
as well as URLs for NNTP newsgroup(s).