From: Philipp Stanner <phasta@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Matthew Brost" <matthew.brost@intel.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/sched: Clarify docu concerning drm_sched_job_arm()
Date: Thu, 13 Mar 2025 11:26:30 +0100 [thread overview]
Message-ID: <db82a8a37e548f7c893c999bb476551c6793b411.camel@mailbox.org> (raw)
In-Reply-To: <d02a205a-c7e7-45a5-bcba-b5a5a6bebf4e@amd.com>
On Thu, 2025-03-13 at 11:07 +0100, Christian König wrote:
> Am 13.03.25 um 10:30 schrieb Philipp Stanner:
> > The documentation for drm_sched_job_arm() and especially
> > drm_sched_job_cleanup() does not make it very clear why
> > drm_sched_job_arm() is a point of no return, which it indeed is.
> >
> > Make the nature of drm_sched_job_arm() in the docu as clear as
> > possible.
> >
> > Suggested-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Philipp Stanner <phasta@kernel.org>
>
> Reviewed-by: Christian König <christian.koenig@amd.com>
Thx
>
> I'm currently looking into how to fix the amdgpu CS path for gang
> submission regarding this.
>
> Any objections that I add a preload function to allocate the memory
> for the XA outside of the critical section?
I can't fully follow, you mean when creating the dependencies xarray?
I think in a perfect world we wouldn't have any more functions that
only have 1 user to work around driver-internal problems. That said, I
realize that the world isn't perfect. Would still be cool if every
function we add would be useful to >1 driver.
I think it's probably best if you just propose sth in form of a patch
and we discuss it there
Grüße
P.
>
> Regards,
> Christian.
>
> > ---
> > drivers/gpu/drm/scheduler/sched_main.c | 24 ++++++++++++++++++----
> > --
> > 1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 4d4219fbe49d..829579c41c6b 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -828,11 +828,15 @@ EXPORT_SYMBOL(drm_sched_job_init);
> > *
> > * This arms a scheduler job for execution. Specifically it
> > initializes the
> > * &drm_sched_job.s_fence of @job, so that it can be attached to
> > struct dma_resv
> > - * or other places that need to track the completion of this job.
> > + * or other places that need to track the completion of this job.
> > It also
> > + * initializes sequence numbers, which are fundamental for fence
> > ordering.
> > *
> > * Refer to drm_sched_entity_push_job() documentation for locking
> > * considerations.
> > *
> > + * Once this function was called, you *must* submit @job with
> > + * drm_sched_entity_push_job().
> > + *
> > * This can only be called if drm_sched_job_init() succeeded.
> > */
> > void drm_sched_job_arm(struct drm_sched_job *job)
> > @@ -1017,9 +1021,12 @@ EXPORT_SYMBOL(drm_sched_job_has_dependency);
> > * Drivers should call this from their error unwind code if @job
> > is aborted
> > * before drm_sched_job_arm() is called.
> > *
> > - * After that point of no return @job is committed to be executed
> > by the
> > - * scheduler, and this function should be called from the
> > - * &drm_sched_backend_ops.free_job callback.
> > + * drm_sched_job_arm() is a point of no return since it
> > initializes the fences
> > + * and their sequence number etc. Once that function has been
> > called, you *must*
> > + * submit it with drm_sched_entity_push_job() and cannot simply
> > abort it by
> > + * calling drm_sched_job_cleanup().
> > + *
> > + * This function should be called in the
> > &drm_sched_backend_ops.free_job callback.
> > */
> > void drm_sched_job_cleanup(struct drm_sched_job *job)
> > {
> > @@ -1027,10 +1034,15 @@ void drm_sched_job_cleanup(struct
> > drm_sched_job *job)
> > unsigned long index;
> >
> > if (kref_read(&job->s_fence->finished.refcount)) {
> > - /* drm_sched_job_arm() has been called */
> > + /* The job has been processed by the scheduler,
> > i.e.,
> > + * drm_sched_job_arm() and
> > drm_sched_entity_push_job() have
> > + * been called.
> > + */
> > dma_fence_put(&job->s_fence->finished);
> > } else {
> > - /* aborted job before committing to run it */
> > + /* The job was aborted before it has been
> > committed to be run;
> > + * notably, drm_sched_job_arm() has not been
> > called.
> > + */
> > drm_sched_fence_free(job->s_fence);
> > }
> >
>
next prev parent reply other threads:[~2025-03-13 10:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 9:30 Philipp Stanner
2025-03-13 10:07 ` Christian König
2025-03-13 10:26 ` Philipp Stanner [this message]
2025-03-13 10:32 ` Christian König
2025-03-14 9:54 ` Philipp Stanner
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=db82a8a37e548f7c893c999bb476551c6793b411.camel@mailbox.org \
--to=phasta@mailbox.org \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=phasta@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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
all inboxes | Powered by JetHome®