From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Francois Dugast <francois.dugast@intel.com>
Cc: intel-xe@lists.freedesktop.org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-xe] [PATCH v3 03/16] drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof
Date: Thu, 30 Nov 2023 12:32:33 -0800 [thread overview]
Message-ID: <874jh3yobi.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20231130183955.7-4-francois.dugast@intel.com>
On Thu, 30 Nov 2023 10:39:42 -0800, Francois Dugast wrote:
>
> From: José Roberto de Souza <jose.souza@intel.com>
>
> We have at least 2 future features(OA and future media engines
> capabilities) that will require Xe to provide more information about
> engines to UMDs.
>
> But this information should not just be added to
> drm_xe_engine_class_instance for a couple of reasons:
> - drm_xe_engine_class_instance is used as input to other structs/uAPIs
> and those uAPIs don't care about any of these future new engine fields
> - those new fields are useless information after initialization for
> some UMDs, so it should not need to carry that around
>
> So here my proposal is to make DRM_XE_DEVICE_QUERY_ENGINES return an
> array of drm_xe_query_engine_info that contain
> drm_xe_engine_class_instance and 3 u64s to be used for future features.
>
> Reference OA:
> https://patchwork.freedesktop.org/patch/558362/?series=121084&rev=6
Incidentally we're proposing to remove OA info from
drm_xe_engine_class_instance. The direction now is to collect all OA info
into a separate struct which looks something like this at present, see
drm_xe_engine_class_instance at the bottom:
struct drm_xe_query_oa_units {
/** @extensions: Pointer to the first extension struct, if any */
__u64 extensions;
/** @num_oa_units: number of OA units returned in oau[] */
__u32 num_oa_units;
/** @pad: MBZ */
__u32 pad;
/** @reserved: MBZ */
__u64 reserved[4];
/** @oa_units: OA units returned for this device */
struct drm_xe_oa_unit {
/** @oa_unit_id: OA unit ID */
__u16 oa_unit_id;
/** @oa_unit_type: OA unit type of @drm_xe_oa_unit_type */
__u16 oa_unit_type;
/** @gt_id: GT ID for this OA unit */
__u16 gt_id;
/** @open_stream: True if a stream is open on the OA unit */
__u16 open_stream;
/** @internal_events: True if internal events are available */
__u16 internal_events;
/** @pad: MBZ */
__u16 pad;
/** @capabilities: OA capabilities bit-mask */
__u64 capabilities;
/** @oa_timestamp_freq: OA timestamp freq */
__u64 oa_timestamp_freq;
/** @oa_buf_size: OA buffer size */
__u64 oa_buf_size;
/** @reserved: MBZ */
__u64 reserved[4];
/** @num_engines: number of engines in @eci array */
__u64 num_engines;
/** @eci: engines attached to this OA unit */
struct drm_xe_engine_class_instance eci[];
} oa_units[];
};
next prev parent reply other threads:[~2023-11-30 20:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 18:39 [Intel-xe] [PATCH v3 00/16] uAPI Alignment - Cleanup and future proof Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 01/16] drm/xe: Extend drm_xe_vm_bind_op Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 02/16] drm/xe/uapi: Separate bo_create placement from flags Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 03/16] drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof Francois Dugast
2023-11-30 20:32 ` Dixit, Ashutosh [this message]
2023-11-30 20:36 ` Souza, Jose
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 04/16] drm/xe/uapi: Reject bo creation of unaligned size Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 05/16] drm/xe/uapi: Align on a common way to return arrays (memory regions) Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 06/16] drm/xe/uapi: Align on a common way to return arrays (gt) Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 07/16] drm/xe/uapi: Align on a common way to return arrays (engines) Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 08/16] drm/xe/uapi: Split xe_sync types from flags Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 09/16] drm/xe/uapi: Kill tile_mask Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 10/16] drm/xe/uapi: Crystal Reference Clock updates Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 11/16] drm/xe/uapi: Add Tile ID information to the GT info query Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 12/16] drm/xe/uapi: Fix various struct padding for 64b alignment Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 13/16] drm/xe/uapi: Move xe_exec after xe_exec_queue Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 14/16] drm/xe/uapi: Use LR abbrev for long-running vms Francois Dugast
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 15/16] drm/xe: Remove unused extension definition Francois Dugast
2023-12-02 1:10 ` Dixit, Ashutosh
2023-11-30 18:39 ` [Intel-xe] [PATCH v3 16/16] drm/xe/uapi: Kill exec_queue_set_property Francois Dugast
2023-11-30 20:59 ` [Intel-xe] [PATCH v3 00/16] uAPI Alignment - Cleanup and future proof Souza, Jose
2023-11-30 23:27 ` [Intel-xe] ✓ CI.Patch_applied: success for uAPI Alignment - Cleanup and future proof (rev6) Patchwork
2023-11-30 23:27 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-11-30 23:29 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-11-30 23:36 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-30 23:36 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-11-30 23:38 ` [Intel-xe] ✓ CI.checksparse: success " Patchwork
2023-12-01 0:12 ` [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=874jh3yobi.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@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