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];
> > };
next prev parent 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