From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: John Harrison <john.c.harrison@intel.com>,
<Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Move lrc desc setup to where it is needed
Date: Wed, 23 Feb 2022 18:03:24 -0800 [thread overview]
Message-ID: <0cd43952-3a0d-60ec-5702-fb0e395025fa@intel.com> (raw)
In-Reply-To: <0b971744-b456-9a92-818f-1f038669da7f@intel.com>
On 2/23/2022 12:23 PM, John Harrison wrote:
> On 2/22/2022 17:12, Ceraolo Spurio, Daniele wrote:
>> On 2/17/2022 3:52 PM, John.C.Harrison@Intel.com wrote:
>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>
>>> The LRC descriptor was being initialised early on in the context
>>> registration sequence. It could then be determined that the actual
>>> registration needs to be delayed and the descriptor would be wiped
>>> out. This is inefficient, so move the setup to later in the process
>>> after the point of no return.
>>>
>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>> ---
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++++++++--
>>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> index 0ab2d1a24bf6..aa74ec74194a 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> @@ -2153,6 +2153,8 @@ static int
>>> __guc_action_register_context(struct intel_guc *guc,
>>> 0, loop);
>>> }
>>> +static void prepare_context_registration_info(struct
>>> intel_context *ce);
>>> +
>>> static int register_context(struct intel_context *ce, bool loop)
>>> {
>>> struct intel_guc *guc = ce_to_guc(ce);
>>> @@ -2163,6 +2165,8 @@ static int register_context(struct
>>> intel_context *ce, bool loop)
>>> GEM_BUG_ON(intel_context_is_child(ce));
>>> trace_intel_context_register(ce);
>>> + prepare_context_registration_info(ce);
>>> +
>>> if (intel_context_is_parent(ce))
>>> ret = __guc_action_register_multi_lrc(guc, ce, ce->guc_id.id,
>>> offset, loop);
>>> @@ -2246,7 +2250,6 @@ static void
>>> prepare_context_registration_info(struct intel_context *ce)
>>> struct intel_context *child;
>>> GEM_BUG_ON(!engine->mask);
>>> - GEM_BUG_ON(!sched_state_is_init(ce));
>>> /*
>>> * Ensure LRC + CT vmas are is same region as write barrier is
>>> done
>>> @@ -2314,9 +2317,13 @@ static int try_context_registration(struct
>>> intel_context *ce, bool loop)
>>> bool context_registered;
>>> int ret = 0;
>>> + GEM_BUG_ON(!sched_state_is_init(ce));
>>> +
>>> context_registered = ctx_id_mapped(guc, desc_idx);
>>> - prepare_context_registration_info(ce);
>>> + if (context_registered)
>>> + clr_ctx_id_mapping(guc, desc_idx);
>>> + set_ctx_id_mapping(guc, desc_idx, ce);
>>
>> I think we can do the clr unconditionally. Also, should we drop the
>> clr/set pair in prepare_context_registration_info? it shouldn't be
>> needed, unless I'm missing a path where we don;t pass through here.
>>
>> Daniele
> I don't believe so.
>
> The point is that the context id might have changed (it got stolen,
> re-used, etc. - all the state machine code below can cause aborts and
> retries and such like if something is pending and the register needs
> to be delayed). So we need to clear out the old mapping and add a new
> one to be safe. Also, I'm not sure if it is safe to do a xa_store to
> an already used entry as an update or if you are supposed to clear it
> first? But that's what the code did before and I'm trying to not
> change any actual behaviour here.
I was comparing with previous behavior. before this patch, we only do
the setting of the ctx_id here (inside
prepare_context_registration_info) and you're not changing any of the
abort/retry behavior, so if it was enough before it should be enough now.
Regarding the xa ops, we did an unconditional clear before, so it should
be ok to just do the same and have the clear and set back to back
without checking if the context ID was already in use or not.
Daniele
>
> John.
>
>>
>>> /*
>>> * The context_lookup xarray is used to determine if the hardware
>>
>
next prev parent reply other threads:[~2022-02-24 2:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 23:51 [Intel-gfx] [PATCH 0/8] Prep work for next GuC release John.C.Harrison
2022-02-17 23:52 ` [Intel-gfx] [PATCH 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration John.C.Harrison
2022-02-18 21:13 ` Ceraolo Spurio, Daniele
2022-02-17 23:52 ` [Intel-gfx] [PATCH 2/8] drm/i915/guc: Add an explicit 'submission_initialized' flag John.C.Harrison
2022-02-18 21:18 ` Ceraolo Spurio, Daniele
2022-02-17 23:52 ` [Intel-gfx] [PATCH 3/8] drm/i915/guc: Better name for context id limit John.C.Harrison
2022-02-23 1:00 ` Ceraolo Spurio, Daniele
2022-02-17 23:52 ` [Intel-gfx] [PATCH 4/8] drm/i915/guc: Split guc_lrc_desc_pin apart John.C.Harrison
2022-02-23 1:04 ` Ceraolo Spurio, Daniele
2022-02-17 23:52 ` [Intel-gfx] [PATCH 5/8] drm/i915/guc: Move lrc desc setup to where it is needed John.C.Harrison
2022-02-23 1:12 ` Ceraolo Spurio, Daniele
2022-02-23 20:23 ` John Harrison
2022-02-24 2:03 ` Ceraolo Spurio, Daniele [this message]
2022-02-24 21:13 ` John Harrison
2022-02-17 23:52 ` [Intel-gfx] [PATCH 6/8] drm/i915/guc: Rename desc_idx to ctx_id John.C.Harrison
2022-02-23 1:14 ` Ceraolo Spurio, Daniele
2022-02-17 23:52 ` [Intel-gfx] [PATCH 7/8] drm/i915/guc: Drop obsolete H2G definitions John.C.Harrison
2022-02-23 1:19 ` Ceraolo Spurio, Daniele
2022-02-17 23:52 ` [Intel-gfx] [PATCH 8/8] drm/i915/guc: Fix potential invalid pointer dereferences when decoding G2Hs John.C.Harrison
2022-02-23 1:28 ` Ceraolo Spurio, Daniele
2022-02-18 5:29 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Prep work for next GuC release (rev2) Patchwork
2022-02-18 5:56 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-18 16:58 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-02-08 2:20 [Intel-gfx] [PATCH 0/8] Prep work for next GuC release John.C.Harrison
2022-02-08 2:20 ` [Intel-gfx] [PATCH 5/8] drm/i915/guc: Move lrc desc setup to where it is needed John.C.Harrison
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=0cd43952-3a0d-60ec-5702-fb0e395025fa@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=DRI-Devel@Lists.FreeDesktop.Org \
--cc=Intel-GFX@Lists.FreeDesktop.Org \
--cc=john.c.harrison@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