dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Liviu Dudau <liviu.dudau@arm.com>
Cc: "Steven Price" <steven.price@arm.com>,
	"Adrián Larumbe" <adrian.larumbe@collabora.com>,
	dri-devel@lists.freedesktop.org, kernel@collabora.com
Subject: Re: [PATCH 2/2] drm/panthor: Fix sync-only jobs
Date: Sat, 29 Jun 2024 10:52:56 +0200	[thread overview]
Message-ID: <20240629105256.55b9c4c4@collabora.com> (raw)
In-Reply-To: <Zn8sgSQUoQgdxHZ7@e110455-lin.cambridge.arm.com>

On Fri, 28 Jun 2024 22:34:57 +0100
Liviu Dudau <liviu.dudau@arm.com> wrote:

> On Fri, Jun 28, 2024 at 04:55:36PM +0200, Boris Brezillon wrote:
> > A sync-only job is meant to provide a synchronization point on a
> > queue, so we can't return a NULL fence there, we have to add a signal
> > operation to the command stream which executes after all other
> > previously submitted jobs are done.
> > 
> > Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>  
> 
> Took me a bit longer to read, lets blame Friday.
> 
> > ---
> >  drivers/gpu/drm/panthor/panthor_sched.c | 41 ++++++++++++++++++++-----
> >  include/uapi/drm/panthor_drm.h          |  5 +++
> >  2 files changed, 38 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> > index 79ffcbc41d78..951ff7e63ea8 100644
> > --- a/drivers/gpu/drm/panthor/panthor_sched.c
> > +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> > @@ -458,6 +458,16 @@ struct panthor_queue {
> >  		/** @seqno: Sequence number of the last initialized fence. */
> >  		atomic64_t seqno;
> >  
> > +		/**
> > +		 * @last_fence: Fence of the last submitted job.
> > +		 *
> > +		 * We return this fence when we get an empty command stream.
> > +		 * This way, we are guaranteed that all earlier jobs have completed
> > +		 * when drm_sched_job::s_fence::finished without having to feed
> > +		 * the CS ring buffer with a dummy job that only signals the fence.
> > +		 */
> > +		struct dma_fence *last_fence;
> > +
> >  		/**
> >  		 * @in_flight_jobs: List containing all in-flight jobs.
> >  		 *
> > @@ -829,6 +839,9 @@ static void group_free_queue(struct panthor_group *group, struct panthor_queue *
> >  	panthor_kernel_bo_destroy(queue->ringbuf);
> >  	panthor_kernel_bo_destroy(queue->iface.mem);
> >  
> > +	/* Release the last_fence we were holding, if any. */
> > +	dma_fence_put(queue->fence_ctx.last_fence);
> > +
> >  	kfree(queue);
> >  }
> >  
> > @@ -2865,11 +2878,14 @@ queue_run_job(struct drm_sched_job *sched_job)
> >  	static_assert(sizeof(call_instrs) % 64 == 0,
> >  		      "call_instrs is not aligned on a cacheline");
> >  
> > -	/* Stream size is zero, nothing to do => return a NULL fence and let
> > -	 * drm_sched signal the parent.
> > +	/* Stream size is zero, nothing to do except making sure all previously
> > +	 * submitted jobs are done before we signal the
> > +	 * drm_sched_job::s_fence::finished fence.
> >  	 */
> > -	if (!job->call_info.size)
> > -		return NULL;
> > +	if (!job->call_info.size) {
> > +		job->done_fence = dma_fence_get(queue->fence_ctx.last_fence);
> > +		return job->done_fence;  
> 
> What happens if the last job's done_fence was cancelled or timed out? Is the
> sync job's done_fence going to be signalled with the same error?

It's the same object, so yes, the job will also be considered faulty
(the error propagated to the job::s_fence::finished fence). I guess
synchronization jobs are not supposed to fail/timeout in theory, because
they don't do anything, but I don't think that's an issue in
practice, because dma_fence errors are never propagated to user-space
(only the queue status is).

> 
> Now that we're returning a fence here, should the job be also added into the
> in_flight_jobs?

Yeah, that's done on purpose, such that we don't end up signalling the
same dma_fence object twice (which is forbidden). This makes me realize
I should probably drop the 'is_cs_empty()' check in
group_sync_upd_work(), since we're not supposed to have a job with an
empty CS in the in_flight_jobs list.

diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
index 951ff7e63ea8..8bf01b7b1596 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -2797,9 +2797,6 @@ static void group_sync_upd_work(struct work_struct *work)
 
                spin_lock(&queue->fence_ctx.lock);
                list_for_each_entry_safe(job, job_tmp, &queue->fence_ctx.in_flight_jobs, node) {
-                       if (!job->call_info.size)
-                               continue;
-
                        if (syncobj->seqno < job->done_fence->seqno)
                                break;


> 
> If you're happy with depending on the previous job's done_fence and not
> track the sync job in in_flight_jobs, then you can have my
> 
> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> 
> Best regards,
> Liviu
> 
> > +	}
> >  
> >  	ret = pm_runtime_resume_and_get(ptdev->base.dev);
> >  	if (drm_WARN_ON(&ptdev->base, ret))
> > @@ -2928,6 +2944,10 @@ queue_run_job(struct drm_sched_job *sched_job)
> >  		}
> >  	}
> >  
> > +	/* Update the last fence. */
> > +	dma_fence_put(queue->fence_ctx.last_fence);
> > +	queue->fence_ctx.last_fence = dma_fence_get(job->done_fence);
> > +
> >  	done_fence = dma_fence_get(job->done_fence);
> >  
> >  out_unlock:
> > @@ -3378,10 +3398,15 @@ panthor_job_create(struct panthor_file *pfile,
> >  		goto err_put_job;
> >  	}
> >  
> > -	job->done_fence = kzalloc(sizeof(*job->done_fence), GFP_KERNEL);
> > -	if (!job->done_fence) {
> > -		ret = -ENOMEM;
> > -		goto err_put_job;
> > +	/* Empty command streams don't need a fence, they'll pick the one from
> > +	 * the previously submitted job.
> > +	 */
> > +	if (job->call_info.size) {
> > +		job->done_fence = kzalloc(sizeof(*job->done_fence), GFP_KERNEL);
> > +		if (!job->done_fence) {
> > +			ret = -ENOMEM;
> > +			goto err_put_job;
> > +		}
> >  	}
> >  
> >  	ret = drm_sched_job_init(&job->base,
> > diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> > index aaed8e12ad0b..926b1deb1116 100644
> > --- a/include/uapi/drm/panthor_drm.h
> > +++ b/include/uapi/drm/panthor_drm.h
> > @@ -802,6 +802,9 @@ struct drm_panthor_queue_submit {
> >  	 * Must be 64-bit/8-byte aligned (the size of a CS instruction)
> >  	 *
> >  	 * Can be zero if stream_addr is zero too.
> > +	 *
> > +	 * When the stream size is zero, the queue submit serves as a
> > +	 * synchronization point.
> >  	 */
> >  	__u32 stream_size;
> >  
> > @@ -822,6 +825,8 @@ struct drm_panthor_queue_submit {
> >  	 * ensure the GPU doesn't get garbage when reading the indirect command
> >  	 * stream buffers. If you want the cache flush to happen
> >  	 * unconditionally, pass a zero here.
> > +	 *
> > +	 * Ignored when stream_size is zero.
> >  	 */
> >  	__u32 latest_flush;
> >  
> > -- 
> > 2.45.0
> >   
> 


  reply	other threads:[~2024-06-29 13:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 14:55 [PATCH 0/2] drm/panthor: Fix support for sync-only jobs Boris Brezillon
2024-06-28 14:55 ` [PATCH 1/2] drm/panthor: Don't check the array stride on empty uobj arrays Boris Brezillon
2024-06-28 19:19   ` Liviu Dudau
2024-07-01  9:03   ` Steven Price
2024-06-28 14:55 ` [PATCH 2/2] drm/panthor: Fix sync-only jobs Boris Brezillon
2024-06-28 21:34   ` Liviu Dudau
2024-06-29  8:52     ` Boris Brezillon [this message]
2024-06-29 12:10       ` Liviu Dudau
2024-07-01  6:59         ` Boris Brezillon
2024-07-01  9:03   ` Steven Price
2024-07-01 11:02   ` kernel test robot
2024-07-02 15:13   ` Boris Brezillon

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=20240629105256.55b9c4c4@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=adrian.larumbe@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=liviu.dudau@arm.com \
    --cc=steven.price@arm.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