Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Welty, Brian" <brian.welty@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v2 02/14] drm/xe/uapi: Separate bo_create placement from flags
Date: Wed, 29 Nov 2023 15:41:32 -0500	[thread overview]
Message-ID: <ZWeh_OpTGsNaWRAu@intel.com> (raw)
In-Reply-To: <f8d95d48-74f9-44f4-8eac-ff4d925f51fe@intel.com>

On Wed, Nov 29, 2023 at 11:36:03AM -0800, Welty, Brian wrote:
> 
> 
> On 11/22/2023 6:38 AM, Francois Dugast wrote:
> > From: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > Although the flags are about the creation, the memory placement
> > of the BO deserves a proper dedicated field in the uapi.
> > 
> > Besides getting more clear, it also allows to remove the
> > 'magic' shifts from the flags that was a concern during the
> > uapi reviews.
> > 
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> > Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >   drivers/gpu/drm/xe/xe_bo.c | 15 +++++++--------
> >   include/uapi/drm/xe_drm.h  | 12 ++++++------
> >   2 files changed, 13 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> > index 4305f5cbc2ab..bbce4cd80f7e 100644
> > --- a/drivers/gpu/drm/xe/xe_bo.c
> > +++ b/drivers/gpu/drm/xe/xe_bo.c
> > @@ -1799,19 +1799,18 @@ int xe_gem_create_ioctl(struct drm_device *dev, void *data,
> >   	u32 handle;
> >   	int err;
> > -	if (XE_IOCTL_DBG(xe, args->extensions) || XE_IOCTL_DBG(xe, args->pad) ||
> > +	if (XE_IOCTL_DBG(xe, args->extensions) ||
> >   	    XE_IOCTL_DBG(xe, args->reserved[0] || args->reserved[1]))
> >   		return -EINVAL;
> > +	/* at least one valid memory placement must be specified */
> > +	if (XE_IOCTL_DBG(xe, !(args->placement & xe->info.mem_region_mask)))
> > +		return -EINVAL;
> 
> I think you are missing to test that args->placement is *only* a mask of
> regions.   Looks like you allow other bits to be included and those will
> get slammed into bo_flags below.

now that they are split I don't believe that they would get slammed below,
but anyway, good catch, you are absolutely right that we should check
for the real valid bits in a better way, like the one you proposed below.

> 
> Probably:
> 
>   if (XE_IOCTL_DBG(xe, (args->placement & ~xe->info.mem_region_mask) ||
> !args->placement))
>      return -EINVAL;

Thank you!

> 
> 
> -Brian
> 
> 
> > +
> >   	if (XE_IOCTL_DBG(xe, args->flags &
> >   			 ~(DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING |
> >   			   DRM_XE_GEM_CREATE_FLAG_SCANOUT |
> > -			   DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM |
> > -			   xe->info.mem_region_mask)))
> > -		return -EINVAL;
> > -
> > -	/* at least one memory type must be specified */
> > -	if (XE_IOCTL_DBG(xe, !(args->flags & xe->info.mem_region_mask)))
> > +			   DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM)))
> >   		return -EINVAL;
> >   	if (XE_IOCTL_DBG(xe, args->handle))
> > @@ -1832,7 +1831,7 @@ int xe_gem_create_ioctl(struct drm_device *dev, void *data,
> >   	if (args->flags & DRM_XE_GEM_CREATE_FLAG_SCANOUT)
> >   		bo_flags |= XE_BO_SCANOUT_BIT;
> > -	bo_flags |= args->flags << (ffs(XE_BO_CREATE_SYSTEM_BIT) - 1);
> > +	bo_flags |= args->placement << (ffs(XE_BO_CREATE_SYSTEM_BIT) - 1);
> >   	if (args->flags & DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM) {
> >   		if (XE_IOCTL_DBG(xe, !(bo_flags & XE_BO_CREATE_VRAM_MASK)))
> > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > index b0d13bc6d9cf..1bdd20d3c4a8 100644
> > --- a/include/uapi/drm/xe_drm.h
> > +++ b/include/uapi/drm/xe_drm.h
> > @@ -500,8 +500,11 @@ struct drm_xe_gem_create {
> >   	 */
> >   	__u64 size;
> > -#define DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING		(0x1 << 24)
> > -#define DRM_XE_GEM_CREATE_FLAG_SCANOUT			(0x1 << 25)
> > +	/** @placement: A mask of memory instances of where BO can be placed. */
> > +	__u32 placement;
> > +
> > +#define DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING		(1 << 0)
> > +#define DRM_XE_GEM_CREATE_FLAG_SCANOUT			(1 << 1)
> >   /*
> >    * When using VRAM as a possible placement, ensure that the corresponding VRAM
> >    * allocation will always use the CPU accessible part of VRAM. This is important
> > @@ -517,7 +520,7 @@ struct drm_xe_gem_create {
> >    * display surfaces, therefore the kernel requires setting this flag for such
> >    * objects, otherwise an error is thrown on small-bar systems.
> >    */
> > -#define DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM	(0x1 << 26)
> > +#define DRM_XE_GEM_CREATE_FLAG_NEEDS_VISIBLE_VRAM	(1 << 2)
> >   	/**
> >   	 * @flags: Flags, currently a mask of memory instances of where BO can
> >   	 * be placed
> > @@ -541,9 +544,6 @@ struct drm_xe_gem_create {
> >   	 */
> >   	__u32 handle;
> > -	/** @pad: MBZ */
> > -	__u32 pad;
> > -
> >   	/** @reserved: Reserved */
> >   	__u64 reserved[2];
> >   };

  reply	other threads:[~2023-11-29 20:41 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 14:38 [Intel-xe] [PATCH v2 00/14] uAPI Alignment - Cleanup and future proof Francois Dugast
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 01/14] drm/xe: Extend drm_xe_vm_bind_op Francois Dugast
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 02/14] drm/xe/uapi: Separate bo_create placement from flags Francois Dugast
2023-11-29 19:36   ` Welty, Brian
2023-11-29 20:41     ` Rodrigo Vivi [this message]
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 03/14] drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof Francois Dugast
2023-11-28 21:17   ` Matthew Brost
2023-11-29 16:54     ` Rodrigo Vivi
2023-11-29 12:35       ` Matthew Brost
2023-11-29 20:04         ` Souza, Jose
2023-11-29 22:52           ` Rodrigo Vivi
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 04/14] drm/xe/uapi: Reject bo creation of unaligned size Francois Dugast
2023-11-24 18:15   ` Souza, Jose
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 05/14] drm/xe/uapi: Align on a common way to return arrays (memory regions) Francois Dugast
2023-11-24 18:19   ` Souza, Jose
2023-11-28 20:51     ` Rodrigo Vivi
2023-11-29 12:33       ` Francois Dugast
2023-11-30 20:53   ` Dixit, Ashutosh
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 06/14] drm/xe/uapi: Align on a common way to return arrays (gt) Francois Dugast
2023-11-28 20:51   ` Rodrigo Vivi
2023-11-29 18:30   ` Matt Roper
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 07/14] drm/xe/uapi: Align on a common way to return arrays (engines) Francois Dugast
2023-11-28 20:56   ` Rodrigo Vivi
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 08/14] drm/xe/uapi: Split xe_sync types from flags Francois Dugast
2023-11-28 21:19   ` Matthew Brost
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 09/14] drm/xe/uapi: Kill tile_mask Francois Dugast
2023-11-29  9:07   ` Matthew Brost
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 10/14] drm/xe/uapi: Crystal Reference Clock updates Francois Dugast
2023-11-24 18:38   ` Souza, Jose
2023-11-29 14:08     ` Francois Dugast
2023-11-29 18:33       ` Souza, Jose
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 11/14] drm/xe/uapi: Remove bogus engine list from the wait_user_fence IOCTL Francois Dugast
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 12/14] drm/xe/uapi: Add Tile ID information to the GT info query Francois Dugast
2023-11-24 18:45   ` Souza, Jose
2023-11-27 14:08     ` Francois Dugast
2023-11-27 14:20       ` Souza, Jose
2023-11-29 18:33         ` Souza, Jose
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 13/14] drm/xe/uapi: Fix various struct padding for 64b alignment Francois Dugast
2023-11-29 17:02   ` Souza, Jose
2023-11-29 17:39     ` Francois Dugast
2023-11-22 14:38 ` [Intel-xe] [PATCH v2 14/14] drm/xe/uapi: Move xe_exec after xe_exec_queue Francois Dugast
2023-11-29 18:34   ` Souza, Jose
2023-11-23 14:14 ` [Intel-xe] ✓ CI.Patch_applied: success for uAPI Alignment - Cleanup and future proof (rev5) Patchwork
2023-11-23 14:14 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-11-23 14:15 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-11-23 14:23 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-23 14:23 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-11-23 14:24 ` [Intel-xe] ✓ CI.checksparse: success " Patchwork
2023-11-23 15:01 ` [Intel-xe] ✗ CI.BAT: 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=ZWeh_OpTGsNaWRAu@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=brian.welty@intel.com \
    --cc=francois.dugast@intel.com \
    --cc=intel-xe@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