Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	 Jose Souza <jose.souza@intel.com>,
	Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Subject: Re: [PATCH 5/8] drm/xe/oa: Signal output fences
Date: Thu, 08 Aug 2024 21:15:05 -0700	[thread overview]
Message-ID: <87mslmcoxi.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <ZrVSgjTbzPameTeb@DUT025-TGLU.fm.intel.com>

On Thu, 08 Aug 2024 16:19:30 -0700, Matthew Brost wrote:
>

Hi Matt,

> On Thu, Aug 08, 2024 at 10:41:36AM -0700, Ashutosh Dixit wrote:
> > Complete 'struct xe_oa_fence' to include the dma_fence used to signal
> > output fences in the xe_sync array. The fences are signalled
> > asynchronously. When there are no output fences to signal, the OA
> > configuration wait is synchronously re-introduced into the ioctl.
> >
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > ---
> >  drivers/gpu/drm/xe/xe_oa.c | 46 +++++++++++++++++++++++++++++++++++---
> >  1 file changed, 43 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c
> > index 416e031ac454b..bc421cd0af6ba 100644
> > --- a/drivers/gpu/drm/xe/xe_oa.c
> > +++ b/drivers/gpu/drm/xe/xe_oa.c
> > @@ -96,6 +96,10 @@ struct xe_oa_config_bo {
> >  };
> >
> >  struct xe_oa_fence {
>
> I don't think you need this at all.
>
> The fence from the job can directly be installed via
> xe_sync_entry_signal between xe_sched_job_arm and
> xe_sched_job_push.

I think I understand what you are saying here, that
job->drm.s_fence->finished can be used to signal the output fences. But the
complication in OA is that an additional delay is needed after the register
programming batch has executed (see below where I point this out) before we
signal the output fences. So the sequence is:

* Submit a register programming batch
* Wait till this completes (signaled by the finished fence)
* Wait for an additional delay
* Now signal output fences after this delay (signal ofence->base)

So 'struct xe_oa_fence' is needed because of this additional
delay. Otherwise I agree, we could just have used the finished fence.

> Then before xe_sync_entry_cleanup check for !num_signal and directly
> wait on the job's fence.

Here also, we never want to wait in the direct ioctl call, we always want
to do the wait in the work item (so it has to be an asychronous wait).

>
> Matt
>
> > +	/* @base: dma fence base */
> > +	struct dma_fence base;
> > +	/* @lock: lock for the fence */
> > +	spinlock_t lock;
> >	/* @xe: pointer to xe device */
> >	struct xe_device *xe;
> >	/* @work: work to signal that OA configuration is applied */
> > @@ -953,9 +957,26 @@ static void xe_oa_fence_work_fn(struct work_struct *w)
> >	/* Additional empirical delay needed for NOA programming after registers are written */
> >	usleep_range(us, 2 * us);

This is the additional delay after which we signal output fences.

Please let me know if you agree with this or if there's another way to do
this.

Thanks.
--
Ashutosh



> >
> > -	kfree(ofence);
> > +	/* Now signal fence to indicate new OA configuration is active */
> > +	dma_fence_signal(&ofence->base);
> > +	dma_fence_put(&ofence->base);
> >  }
> >
> > +static const char *xe_oa_get_driver_name(struct dma_fence *fence)
> > +{
> > +	return "xe_oa";
> > +}
> > +
> > +static const char *xe_oa_get_timeline_name(struct dma_fence *fence)
> > +{
> > +	return "unbound";
> > +}
> > +
> > +static const struct dma_fence_ops xe_oa_fence_ops = {
> > +	.get_driver_name = xe_oa_get_driver_name,
> > +	.get_timeline_name = xe_oa_get_timeline_name,
> > +};
> > +
> >  static struct xe_oa_fence *xe_oa_fence_init(struct xe_device *xe, struct dma_fence *config_fence)
> >  {
> >	struct xe_oa_fence *ofence;
> > @@ -967,6 +988,8 @@ static struct xe_oa_fence *xe_oa_fence_init(struct xe_device *xe, struct dma_fen
> >	ofence->xe = xe;
> >	INIT_WORK(&ofence->work, xe_oa_fence_work_fn);
> >	ofence->config_fence = config_fence;
> > +	spin_lock_init(&ofence->lock);
> > +	dma_fence_init(&ofence->base, &xe_oa_fence_ops, &ofence->lock, 0, 0);
> >
> >	return ofence;
> >  }
> > @@ -975,8 +998,8 @@ static int xe_oa_emit_oa_config(struct xe_oa_stream *stream, struct xe_oa_config
> >  {
> >	struct xe_oa_config_bo *oa_bo;
> >	struct xe_oa_fence *ofence;
> > +	int i, err, num_signal = 0;
> >	struct dma_fence *fence;
> > -	int err;
> >
> >	/* Emit OA configuration batch */
> >	oa_bo = xe_oa_alloc_config_buffer(stream, config);
> > @@ -989,13 +1012,30 @@ static int xe_oa_emit_oa_config(struct xe_oa_stream *stream, struct xe_oa_config
> >	if (err)
> >		goto exit;
> >
> > +	/* Initialize and set fence to signal */
> >	ofence = xe_oa_fence_init(stream->oa->xe, fence);
> >	if (IS_ERR(ofence)) {
> >		err = PTR_ERR(ofence);
> >		goto put_fence;
> >	}
> >
> > -	xe_oa_fence_work_fn(&ofence->work);
> > +	for (i = 0; i < stream->num_syncs; i++)
> > +		xe_sync_entry_signal(&stream->syncs[i], &ofence->base);
> > +
> > +	/* Schedule work to signal the fence */
> > +	queue_work(system_unbound_wq, &ofence->work);
> > +
> > +	/* If nothing needs to be signaled we wait synchronously */
> > +	for (i = 0; i < stream->num_syncs; i++)
> > +		if (stream->syncs[i].flags & DRM_XE_SYNC_FLAG_SIGNAL)
> > +			num_signal++;
> > +	if (!num_signal)
> > +		flush_work(&ofence->work);
> > +
> > +	/* Done with syncs */
> > +	for (i = 0; i < stream->num_syncs; i++)
> > +		xe_sync_entry_cleanup(&stream->syncs[i]);
> > +	kfree(stream->syncs);
> >
> >	return 0;
> >  put_fence:
> > --
> > 2.41.0
> >

  reply	other threads:[~2024-08-09  4:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-08 17:41 [PATCH 0/8] drm/xe/oa: xe_syncs for OA Ashutosh Dixit
2024-08-08 17:41 ` [PATCH 1/8] drm/xe/oa: Separate batch submission from waiting for completion Ashutosh Dixit
2024-08-08 20:18   ` Cavitt, Jonathan
2024-08-20  1:01     ` Dixit, Ashutosh
2024-08-08 23:04   ` Matthew Brost
2024-08-20  1:00     ` Dixit, Ashutosh
2024-08-08 17:41 ` [PATCH 2/8] drm/xe/oa: Introduce 'struct xe_oa_fence' Ashutosh Dixit
2024-08-08 20:58   ` Cavitt, Jonathan
2024-08-20  1:03     ` Dixit, Ashutosh
2024-08-08 23:29   ` Matthew Brost
2024-08-08 17:41 ` [PATCH 3/8] drm/xe/oa/uapi: Define and parse OA sync properties Ashutosh Dixit
2024-08-08 21:05   ` Cavitt, Jonathan
2024-08-08 23:13   ` Matthew Brost
2024-08-20  1:04     ` Dixit, Ashutosh
2024-08-08 17:41 ` [PATCH 4/8] drm/xe/oa: Add input fence dependencies Ashutosh Dixit
2024-08-08 21:09   ` Cavitt, Jonathan
2024-08-20  1:05     ` Dixit, Ashutosh
2024-08-08 23:25   ` Matthew Brost
2024-08-20  1:06     ` Dixit, Ashutosh
2024-08-08 17:41 ` [PATCH 5/8] drm/xe/oa: Signal output fences Ashutosh Dixit
2024-08-08 21:16   ` Cavitt, Jonathan
2024-08-20  1:30     ` Dixit, Ashutosh
2024-08-08 23:19   ` Matthew Brost
2024-08-09  4:15     ` Dixit, Ashutosh [this message]
2024-08-09  4:50       ` Matthew Brost
2024-08-13 21:35         ` Dixit, Ashutosh
2024-08-20  1:30         ` Dixit, Ashutosh
2024-08-08 17:41 ` [PATCH 6/8] drm/xe/oa: Move functions up so they can be reused for config ioctl Ashutosh Dixit
2024-08-08 21:18   ` Cavitt, Jonathan
2024-08-08 17:41 ` [PATCH 7/8] drm/xe/oa: Add syncs support to OA " Ashutosh Dixit
2024-08-08 21:39   ` Cavitt, Jonathan
2024-08-20  1:40     ` Dixit, Ashutosh
2024-08-08 17:41 ` [PATCH 8/8] drm/xe/oa: Allow only certain property changes from " Ashutosh Dixit
2024-08-08 22:15   ` Cavitt, Jonathan
2024-08-20  1:45     ` Dixit, Ashutosh
2024-08-08 19:04 ` ✓ CI.Patch_applied: success for drm/xe/oa: xe_syncs for OA Patchwork
2024-08-08 19:04 ` ✓ CI.checkpatch: " Patchwork
2024-08-08 19:05 ` ✓ CI.KUnit: " Patchwork
2024-08-08 19:17 ` ✓ CI.Build: " Patchwork
2024-08-08 19:19 ` ✓ CI.Hooks: " Patchwork
2024-08-08 19:21 ` ✓ CI.checksparse: " Patchwork
2024-08-08 19:51 ` ✓ CI.BAT: " Patchwork
2024-08-08 22:26 ` ✗ 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=87mslmcoxi.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --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