Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH v3 2/3] drm/xe: Expose display alignment requirement
Date: Mon, 22 Jul 2024 14:17:07 -0400	[thread overview]
Message-ID: <Zp6iI6lwWpOQo1d_@intel.com> (raw)
In-Reply-To: <20240712090013.ex2peruaomb6q5e5@zkempczy-mobl2>

On Fri, Jul 12, 2024 at 11:00:13AM +0200, Zbigniew Kempczyński wrote:
> On Thu, Jul 11, 2024 at 05:44:24PM -0400, Rodrigo Vivi wrote:
> > 
> > On Thu, Jul 11, 2024 at 11:09:24AM +0200, Zbigniew Kempczyński wrote:
> > 
> > Please use prefix 'drm/xe/uapi:' on the commit subject for anything
> > touching uapi.
> > 
> > And also documentation please.
> 
> Ok, I'm going to retag this to drm/xe/uapi.

Thanks. And sorry for taking so long to answer here.

> 
> Hmm, I've added this similar to MIN_ALIGNMENT (see on the bottom of the
> patch). Do you want to elaborate this more? I thought xe_drm.h is
> appropriate place to document this flag.

Yeap, I believe it would be good to elaborate it more. Specially because
the impact on the media side for instance.

> 
> > 
> > But more then that, we need to engage first with userspace and get
> > them to implement this.
> 
> I'm aware that BMG display complicated things a bit. As it supports
> 4K on vram I think switching vram_flags to XE_VRAM_FLAGS_NEED64K will
> work, but we loose 4K granularity on vram so imo there's a waste
> of memory for smaller allocations.
> 
> > 
> > > Scanout buffer on Battlemage requires allocation in 64K contigues
> > > pages to support Tile4 + compression what differs from normal bo
> > > requirements. Expose display alignment configuration to userspace
> > > to ensure it will properly align requested memory.
> > 
> > We should probably consider something that aligns better with
> > the default alignment that comes from the min_page_size
> > from struct drm_xe_mem_region.
> 
> At the moment I see following options:
> 
> 1. change xe_graphics_desc bmg to:
>    .vram_flags = XE_VRAM_FLAGS_NEED64K
>    at cost of loosing 4K granularity on vram

yeap, this is bad... basically expanding the media limitation to every umd :/

> 
> 2. add new flag as I proposed; we may burn out one reserved u64 (u32)
>    and expose min_display_page_size. But I'm not sure should we follow
>    this way as display is not taken from system memory but vram
>    (this field will be inappropriate set for system memory).
> 
> 3. add new flag as I proposed, and expose this in via config query
>    (current proposal).
> 
> 4. any other ideas?

no other idea to be honest. Let's ask UMD folks' opinions on this as well.

> 
> > 
> > BTW: This will be a big impact in Media because right now they are
> > having to use SCANOUT flag for every buffer since they have no
> > ways to know upfront what buffers they will send to display.
> 
> If media will use buffer which is Tile4 + compressed I think they
> will have no choice and they will need to allocate buffers in 64K contigues
> chunks somehow.

indeed. but let's get their ack here at least.

> 
> At the moment I've mitigated this issue seen in kms_ccs for bmg
> in series: https://patchwork.freedesktop.org/series/135994/
> but this is not temporary and not fully correct solution until kernel
> will switch to 64K physical alignment for scanout buffers.
> 
> --
> Zbigniew
> 
> > 
> > > 
> > > Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_query.c | 4 +++-
> > >  include/uapi/drm/xe_drm.h     | 3 +++
> > >  2 files changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_query.c b/drivers/gpu/drm/xe/xe_query.c
> > > index 4e01df6b1b7a..c32894f3eea1 100644
> > > --- a/drivers/gpu/drm/xe/xe_query.c
> > > +++ b/drivers/gpu/drm/xe/xe_query.c
> > > @@ -313,7 +313,7 @@ static int query_mem_regions(struct xe_device *xe,
> > >  
> > >  static int query_config(struct xe_device *xe, struct drm_xe_device_query *query)
> > >  {
> > > -	const u32 num_params = DRM_XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY + 1;
> > > +	const u32 num_params = DRM_XE_QUERY_CONFIG_DISPLAY_ALIGNMENT + 1;
> > >  	size_t size =
> > >  		sizeof(struct drm_xe_query_config) + num_params * sizeof(u64);
> > >  	struct drm_xe_query_config __user *query_ptr =
> > > @@ -342,6 +342,8 @@ static int query_config(struct xe_device *xe, struct drm_xe_device_query *query)
> > >  	config->info[DRM_XE_QUERY_CONFIG_VA_BITS] = xe->info.va_bits;
> > >  	config->info[DRM_XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY] =
> > >  		xe_exec_queue_device_get_max_priority(xe);
> > > +	config->info[DRM_XE_QUERY_CONFIG_DISPLAY_ALIGNMENT] =
> > > +		xe->info.vram_flags & XE_VRAM_FLAGS_DISPLAY_NEED64K ? SZ_64K : SZ_4K;
> > >  
> > >  	if (copy_to_user(query_ptr, config, size)) {
> > >  		kfree(config);
> > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > > index 19619d4952a8..c7a930dbf58c 100644
> > > --- a/include/uapi/drm/xe_drm.h
> > > +++ b/include/uapi/drm/xe_drm.h
> > > @@ -398,6 +398,8 @@ struct drm_xe_query_mem_regions {
> > >   *  - %DRM_XE_QUERY_CONFIG_VA_BITS - Maximum bits of a virtual address
> > >   *  - %DRM_XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY - Value of the highest
> > >   *    available exec queue priority
> > > + *  - %DRM_XE_QUERY_CONFIG_DISPLAY_ALIGNMENT - Alignment of contigous physical
> > > + *    memory allocation required by the display, typically SZ_4K or SZ_64K
> > >   */
> > >  struct drm_xe_query_config {
> > >  	/** @num_params: number of parameters returned in info */
> > > @@ -412,6 +414,7 @@ struct drm_xe_query_config {
> > >  #define DRM_XE_QUERY_CONFIG_MIN_ALIGNMENT		2
> > >  #define DRM_XE_QUERY_CONFIG_VA_BITS			3
> > >  #define DRM_XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY	4
> > > +#define DRM_XE_QUERY_CONFIG_DISPLAY_ALIGNMENT		5
> > >  	/** @info: array of elements containing the config info */
> > >  	__u64 info[];
> > >  };
> > > -- 
> > > 2.34.1
> > > 

  parent reply	other threads:[~2024-07-22 18:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-11  9:09 [PATCH v3 0/3] Restrict BMG to use 64K pages for scanout buffers Zbigniew Kempczyński
2024-07-11  9:09 ` [PATCH v3 1/3] drm/xe: Separate 64K physical allocation for display Zbigniew Kempczyński
2024-07-11  9:09 ` [PATCH v3 2/3] drm/xe: Expose display alignment requirement Zbigniew Kempczyński
2024-07-11 21:44   ` Rodrigo Vivi
2024-07-12  9:00     ` Zbigniew Kempczyński
2024-07-12  9:23       ` Zbigniew Kempczyński
2024-07-22 18:17       ` Rodrigo Vivi [this message]
2024-07-11  9:09 ` [PATCH v3 3/3] drm/xe: Use 64K pages for scanout buffers for Battlemage Zbigniew Kempczyński
2024-07-11  9:18 ` ✓ CI.Patch_applied: success for Restrict BMG to use 64K pages for scanout buffers (rev2) Patchwork
2024-07-11  9:19 ` ✓ CI.checkpatch: " Patchwork
2024-07-11  9:20 ` ✓ CI.KUnit: " Patchwork
2024-07-11  9:32 ` ✓ CI.Build: " Patchwork
2024-07-11  9:34 ` ✓ CI.Hooks: " Patchwork
2024-07-11  9:35 ` ✓ CI.checksparse: " Patchwork
2024-07-11 10:00 ` ✓ CI.BAT: " Patchwork
2024-07-11 11:09 ` ✗ 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=Zp6iI6lwWpOQo1d_@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=zbigniew.kempczynski@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