From: Jason Ekstrand <jason@jlekstrand.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 10/27] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT
Date: Fri, 14 May 2021 13:19:14 -0500 [thread overview]
Message-ID: <CAOFGe97rHt90pqDnR+QdGsNTeeRJfKDftQKdpAf=hdTtQLj8kw@mail.gmail.com> (raw)
In-Reply-To: <YJEMJ0TF6vLmPo5d@phenom.ffwll.local>
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > Even though FENCE_SUBMIT is only documented to wait until the request in
> > the in-fence starts instead of waiting until it completes, it has a bit
> > more magic than that. If FENCE_SUBMIT is used to submit something to a
> > balanced engine, we would wait to assign engines until the primary
> > request was ready to start and then attempt to assign it to a different
> > engine than the primary. There is an IGT test which exercises this by
> > submitting a primary batch to a specific VCS and then using FENCE_SUBMIT
> > to submit a secondary which can run on any VCS and have i915 figure out
> > which VCS to run it on such that they can run in parallel.
> >
> > However, this functionality has never been used in the real world. The
> > media driver (the only user of FENCE_SUBMIT) always picks exactly two
> > physical engines to bond and never asks us to pick which to use.
>
> Maybe reference the specific igt you're break (and removing in the igt
> series to match this) here. Just for the record and all that.
Done.
> -Daniel
>
> >
> > Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 -------
> > .../drm/i915/gt/intel_execlists_submission.c | 17 -----------------
> > 3 files changed, 1 insertion(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index d640bba6ad9ab..efb2fa3522a42 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -3474,7 +3474,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > if (args->flags & I915_EXEC_FENCE_SUBMIT)
> > err = i915_request_await_execution(eb.request,
> > in_fence,
> > - eb.engine->bond_execute);
> > + NULL);
> > else
> > err = i915_request_await_dma_fence(eb.request,
> > in_fence);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 883bafc449024..68cfe5080325c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -446,13 +446,6 @@ struct intel_engine_cs {
> > */
> > void (*submit_request)(struct i915_request *rq);
> >
> > - /*
> > - * Called on signaling of a SUBMIT_FENCE, passing along the signaling
> > - * request down to the bonded pairs.
> > - */
> > - void (*bond_execute)(struct i915_request *rq,
> > - struct dma_fence *signal);
> > -
> > /*
> > * Call when the priority on a request has changed and it and its
> > * dependencies may need rescheduling. Note the request itself may
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 14378b28169b7..635d6d2494d26 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3547,22 +3547,6 @@ static void virtual_submit_request(struct i915_request *rq)
> > spin_unlock_irqrestore(&ve->base.active.lock, flags);
> > }
> >
> > -static void
> > -virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
> > -{
> > - intel_engine_mask_t allowed, exec;
> > -
> > - allowed = ~to_request(signal)->engine->mask;
> > -
> > - /* Restrict the bonded request to run on only the available engines */
> > - exec = READ_ONCE(rq->execution_mask);
> > - while (!try_cmpxchg(&rq->execution_mask, &exec, exec & allowed))
> > - ;
> > -
> > - /* Prevent the master from being re-run on the bonded engines */
> > - to_request(signal)->execution_mask &= ~allowed;
> > -}
> > -
> > struct intel_context *
> > intel_execlists_create_virtual(struct intel_engine_cs **siblings,
> > unsigned int count)
> > @@ -3616,7 +3600,6 @@ intel_execlists_create_virtual(struct intel_engine_cs **siblings,
> >
> > ve->base.schedule = i915_schedule;
> > ve->base.submit_request = virtual_submit_request;
> > - ve->base.bond_execute = virtual_bond_execute;
> >
> > INIT_LIST_HEAD(virtual_queue(ve));
> > ve->base.execlists.queue_priority_hint = INT_MIN;
> > --
> > 2.31.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
next prev parent reply other threads:[~2021-05-14 18:19 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-03 15:57 [PATCH 00/27] drm/i915/gem: ioctl clean-ups (v5) Jason Ekstrand
2021-05-03 15:57 ` [PATCH 01/27] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Jason Ekstrand
2021-05-03 15:57 ` [PATCH 02/27] drm/i915: Stop storing the ring size in the ring pointer Jason Ekstrand
2021-05-04 8:47 ` Daniel Vetter
2021-05-14 18:06 ` Jason Ekstrand
2021-05-03 15:57 ` [PATCH 03/27] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Jason Ekstrand
2021-05-04 8:48 ` [Intel-gfx] " Daniel Vetter
2021-05-03 15:57 ` [PATCH 04/27] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2) Jason Ekstrand
2021-05-03 15:57 ` [PATCH 05/27] drm/i915/gem: Return void from context_apply_all Jason Ekstrand
2021-05-03 15:57 ` [PATCH 06/27] drm/i915: Drop the CONTEXT_CLONE API Jason Ekstrand
2021-05-04 8:50 ` [Intel-gfx] " Daniel Vetter
2021-05-14 18:07 ` Jason Ekstrand
2021-05-03 15:57 ` [PATCH 07/27] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4) Jason Ekstrand
2021-05-03 15:57 ` [PATCH 08/27] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES Jason Ekstrand
2021-05-03 15:57 ` [PATCH 09/27] drm/i915/gem: Disallow bonding of virtual engines (v3) Jason Ekstrand
2021-05-03 15:57 ` [PATCH 10/27] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT Jason Ekstrand
2021-05-04 8:56 ` Daniel Vetter
2021-05-14 18:19 ` Jason Ekstrand [this message]
2021-05-03 15:57 ` [PATCH 11/27] drm/i915/request: Remove the hook from await_execution Jason Ekstrand
2021-05-04 8:55 ` Daniel Vetter
2021-05-03 15:57 ` [PATCH 12/27] drm/i915/gem: Disallow creating contexts with too many engines Jason Ekstrand
2021-05-05 9:56 ` [Intel-gfx] " Tvrtko Ursulin
2021-05-03 15:57 ` [PATCH 13/27] drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2) Jason Ekstrand
2021-05-03 15:57 ` [PATCH 14/27] drm/i915/gem: Add a separate validate_priority helper Jason Ekstrand
2021-05-03 15:57 ` [PATCH 15/27] drm/i915: Add gem/i915_gem_context.h to the docs Jason Ekstrand
2021-05-04 9:11 ` Daniel Vetter
2021-05-03 15:57 ` [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct Jason Ekstrand
2021-05-04 16:13 ` Daniel Vetter
2021-06-02 21:53 ` Jason Ekstrand
2021-06-03 7:07 ` Daniel Vetter
2021-05-05 10:09 ` [Intel-gfx] " Tvrtko Ursulin
2021-05-03 15:57 ` [PATCH 17/27] drm/i915/gem: Rework error handling in default_engines Jason Ekstrand
2021-05-04 16:17 ` [Intel-gfx] " Daniel Vetter
2021-05-14 18:21 ` Jason Ekstrand
2021-05-03 15:57 ` [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem Jason Ekstrand
2021-05-04 19:00 ` [Intel-gfx] " Daniel Vetter
2021-05-05 9:28 ` Tvrtko Ursulin
2021-05-05 9:47 ` Daniel Vetter
2021-05-05 9:52 ` Tvrtko Ursulin
2021-05-03 15:57 ` [PATCH 19/27] drm/i915/gem: Use the proto-context to handle create parameters Jason Ekstrand
2021-05-04 20:33 ` Daniel Vetter
2021-05-14 19:13 ` Jason Ekstrand
2021-05-17 13:40 ` Daniel Vetter
2021-05-17 17:04 ` Jason Ekstrand
2021-05-17 18:44 ` Daniel Vetter
2021-05-18 10:51 ` Jani Nikula
2021-05-03 15:57 ` [PATCH 20/27] drm/i915/gem: Return an error ptr from context_lookup Jason Ekstrand
2021-05-03 15:57 ` [PATCH 21/27] drm/i915/gt: Drop i915_address_space::file (v2) Jason Ekstrand
2021-05-03 15:57 ` [PATCH 22/27] drm/i915/gem: Delay context creation Jason Ekstrand
2021-05-03 19:38 ` [Intel-gfx] " kernel test robot
2021-05-04 20:53 ` Daniel Vetter
2021-05-04 20:53 ` Daniel Vetter
2021-05-03 15:57 ` [PATCH 23/27] drm/i915/gem: Don't allow changing the VM on running contexts Jason Ekstrand
2021-05-03 18:52 ` [Intel-gfx] " kernel test robot
2021-05-04 21:00 ` Daniel Vetter
2021-05-04 21:17 ` Daniel Vetter
2021-05-03 15:57 ` [PATCH 24/27] drm/i915/gem: Don't allow changing the engine set " Jason Ekstrand
2021-05-05 9:49 ` [Intel-gfx] " Daniel Vetter
2021-05-03 15:57 ` [PATCH 25/27] drm/i915/selftests: Take a VM in kernel_context() Jason Ekstrand
2021-05-05 9:50 ` Daniel Vetter
2021-05-03 15:57 ` [PATCH 26/27] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec Jason Ekstrand
2021-05-05 9:53 ` [Intel-gfx] " Daniel Vetter
2021-05-03 15:57 ` [PATCH 27/27] drm/i915/gem: Roll all of context creation together Jason Ekstrand
2021-05-05 10:05 ` [Intel-gfx] " Daniel Vetter
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='CAOFGe97rHt90pqDnR+QdGsNTeeRJfKDftQKdpAf=hdTtQLj8kw@mail.gmail.com' \
--to=jason@jlekstrand.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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;
as well as URLs for NNTP newsgroup(s).