From: Ashutosh Dixit <ashutosh.dixit@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>,
Jose Souza <jose.souza@intel.com>,
Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
Jonathan Cavitt <jonathan.cavitt@intel.com>
Subject: [PATCH v2 0/7] drm/xe/oa: xe_syncs for OA
Date: Mon, 19 Aug 2024 17:58:01 -0700 [thread overview]
Message-ID: <20240820005808.1412649-1-ashutosh.dixit@intel.com> (raw)
OA stream configuration submits batches which can be queued behind other
(say workload) batches. Also, in some cases, additional delay is needed for
an OA configuration to take effect, even after programming batches have
completed executing on HW.
Mesa has use cases where a single workload is replayed repeatedly on the
GPU, each time with a different OA configuration (or metric set), in order
to capture different aspects of workload performance. This requires that OA
configuration takes effect at precisely the correct input batch and also
userspace is correctly informed when a new configuration has been activated
(at batch granularity).
In the previous implementation this is implemented by introducing a delay
in the stream open and reconfiguration ioctl's. This works, except that we
introdce a bubble in the userspace pipeline (the pipeline stalls during the
delays in calls into these ioctl's). Mesa prefers that such pipeline stalls
don't happen.
In this series this problem is solved using xe_sync arrays, similar to
xe_exec and vm_bind. Here OA re-configuration can be made to wait till
input fences signal and OA will signal output fences after a new
configuration has been activated. This can of course be done without
stalling the userspace pipeline.
v2: Address review comments from Matt Brost, Jonathan Cavitt and Jose Souza
Test-with: 20240820003104.1407398-1-ashutosh.dixit@intel.com
Ashutosh Dixit (7):
drm/xe/oa: Separate batch submission from waiting for completion
drm/xe/oa/uapi: Define and parse OA sync properties
drm/xe/oa: Add input fence dependencies
drm/xe/oa: Signal output fences
drm/xe/oa: Move functions up so they can be reused for config ioctl
drm/xe/oa: Add syncs support to OA config ioctl
drm/xe/oa: Allow only certain property changes from config
drivers/gpu/drm/xe/xe_oa.c | 650 +++++++++++++++++++++----------
drivers/gpu/drm/xe/xe_oa_types.h | 12 +
drivers/gpu/drm/xe/xe_query.c | 2 +-
include/uapi/drm/xe_drm.h | 17 +
4 files changed, 478 insertions(+), 203 deletions(-)
--
2.41.0
next reply other threads:[~2024-08-20 0:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 0:58 Ashutosh Dixit [this message]
2024-08-20 0:58 ` [PATCH 1/7] drm/xe/oa: Separate batch submission from waiting for completion Ashutosh Dixit
2024-08-20 0:58 ` [PATCH 2/7] drm/xe/oa/uapi: Define and parse OA sync properties Ashutosh Dixit
2024-08-20 0:58 ` [PATCH 3/7] drm/xe/oa: Add input fence dependencies Ashutosh Dixit
2024-08-20 0:58 ` [PATCH 4/7] drm/xe/oa: Signal output fences Ashutosh Dixit
2024-08-20 19:23 ` Matthew Brost
2024-08-21 15:20 ` Dixit, Ashutosh
2024-08-21 16:02 ` Matthew Brost
2024-08-20 0:58 ` [PATCH 5/7] drm/xe/oa: Move functions up so they can be reused for config ioctl Ashutosh Dixit
2024-08-20 0:58 ` [PATCH 6/7] drm/xe/oa: Add syncs support to OA " Ashutosh Dixit
2024-08-20 0:58 ` [PATCH 7/7] drm/xe/oa: Allow only certain property changes from config Ashutosh Dixit
2024-08-20 14:15 ` Cavitt, Jonathan
2024-08-21 15:19 ` Dixit, Ashutosh
2024-08-20 1:03 ` ✓ CI.Patch_applied: success for drm/xe/oa: xe_syncs for OA (rev2) Patchwork
2024-08-20 1:04 ` ✓ CI.checkpatch: " Patchwork
2024-08-20 1:05 ` ✓ CI.KUnit: " Patchwork
2024-08-20 1:17 ` ✓ CI.Build: " Patchwork
2024-08-20 1:19 ` ✓ CI.Hooks: " Patchwork
2024-08-20 1:20 ` ✓ CI.checksparse: " Patchwork
2024-08-20 1:40 ` ✓ CI.BAT: " Patchwork
2024-08-20 9:37 ` ✗ 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=20240820005808.1412649-1-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=jose.souza@intel.com \
--cc=lionel.g.landwerlin@intel.com \
--cc=matthew.brost@intel.com \
--cc=umesh.nerlige.ramappa@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