Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 5/5] drm/i915/guc: enable only the user interrupt when using GuC submission
Date: Tue, 5 Jan 2021 18:39:36 -0800	[thread overview]
Message-ID: <a27e4059-622a-e61c-bf97-0e24cdef6ca8@intel.com> (raw)
In-Reply-To: <160989210594.14894.9421268000220341017@build.alporthouse.com>



On 1/5/2021 4:15 PM, Chris Wilson wrote:
> Quoting Daniele Ceraolo Spurio (2021-01-05 23:56:52)
>>
>> On 1/5/2021 3:38 PM, Chris Wilson wrote:
>>> Quoting Daniele Ceraolo Spurio (2021-01-05 23:19:47)
>>>> In GuC submission mode the CS is owned by the GuC FW, so all CS status
>>>> interrupts are handled by it. We only need the user interrupt as that
>>>> signals request completion.
>>>>
>>>> Since we're now starting the engines directly in GuC submission mode
>>>> when selected, we can stop switching back and forth between the
>>>> execlists and the GuC programming and select directly the correct
>>>> interrupt mask.
>>>>
>>>> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>> Cc: Matthew Brost <matthew.brost@intel.com>
>>>> Cc: John Harrison <john.c.harrison@intel.com>
>>>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gt/intel_gt_irq.c        | 18 ++++++-----
>>>>    .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 31 -------------------
>>>>    2 files changed, 11 insertions(+), 38 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
>>>> index 9830342aa6f4..7b2b8cb2d2be 100644
>>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
>>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
>>>> @@ -237,14 +237,18 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
>>>>    
>>>>    void gen11_gt_irq_postinstall(struct intel_gt *gt)
>>>>    {
>>>> -       const u32 irqs =
>>>> -               GT_CS_MASTER_ERROR_INTERRUPT |
>>>> -               GT_RENDER_USER_INTERRUPT |
>>>> -               GT_CONTEXT_SWITCH_INTERRUPT |
>>>> -               GT_WAIT_SEMAPHORE_INTERRUPT;
>>>>           struct intel_uncore *uncore = gt->uncore;
>>>> -       const u32 dmask = irqs << 16 | irqs;
>>>> -       const u32 smask = irqs << 16;
>>>> +       u32 irqs = GT_RENDER_USER_INTERRUPT;
>>>> +       u32 dmask;
>>>> +       u32 smask;
>>>> +
>>>> +       if (!intel_uc_wants_guc_submission(&gt->uc))
>>>> +               irqs |= GT_CS_MASTER_ERROR_INTERRUPT |
>>>> +                       GT_CONTEXT_SWITCH_INTERRUPT |
>>>> +                       GT_WAIT_SEMAPHORE_INTERRUPT;
>>> Hmm, we should stop performing this by default then, and make the
>>> execlists setup request the interrupt vector it desires.
>>>
>>> That's certainly a bit more fiddly to untangle the packed iir across
>>> multiple gen. :|
>> I had considered that, but this is a gt-level setup while the execlists
>> submission code is currently all engine-based, so I couldn't find a good
>> place to move this to and I didn't want to add a new function just for
>> it. Any preference?
> I think we should definitely strive to avoid having too many backend-
> conditional paths in the common routines, and we can certainly adjust
> the interrupts as we enable each engine (it certainly would help when
> debugging by removing engines by removing spurious iir).
>
> I guess we may end up with something like
> gen8_gt_unmask_engine_irq(struct intel_gt *gt,
> 			  struct intel_engine_cs *engine,
> 			  u16 iir)
> {
> 	if (INTEL_GEN(gt->i915) >= 11)
> 		__gen11...
> 	else
> 		__gen8...
> }
> [Not sure if gen8_gt or intel_gt; I chose gen8_gt for the iir definition]
>
> Then that would fit reasonably into logical_ring_default_irqs().
> Hindsight says that if we had done that earlier, we could have avoided
> maintaining the same engine-iir in two different sites. So maybe worth
> a bit of effort.
> -Chris

Looks reasonable, I'll give it a try.

Daniele

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-01-06  2:39 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 23:19 [Intel-gfx] [PATCH 0/5] Split GuC submission from execlists submission Daniele Ceraolo Spurio
2021-01-05 23:19 ` [Intel-gfx] [PATCH 1/5] drm/i915/guc: Delete GuC code unused in future patches Daniele Ceraolo Spurio
2021-01-06  0:55   ` Chris Wilson
2021-01-06  2:28     ` Daniele Ceraolo Spurio
2021-01-06  3:11       ` Chris Wilson
2021-01-05 23:19 ` [Intel-gfx] [PATCH 2/5] drm/i915/guc: do not dump execlists state with GuC submission Daniele Ceraolo Spurio
2021-01-06  0:58   ` Chris Wilson
2021-01-06  2:32     ` Daniele Ceraolo Spurio
2021-01-06  2:55       ` Chris Wilson
2021-01-06 17:21         ` Daniele Ceraolo Spurio
2021-01-06 19:43           ` Chris Wilson
2021-01-13  1:03             ` Daniele Ceraolo Spurio
2021-01-05 23:19 ` [Intel-gfx] [PATCH 3/5] drm/i915/guc: init engine directly in GuC submission mode Daniele Ceraolo Spurio
2021-01-05 23:33   ` Chris Wilson
2021-01-05 23:51     ` Daniele Ceraolo Spurio
2021-01-06  0:02       ` Chris Wilson
2021-01-06  3:14         ` Chris Wilson
2021-01-05 23:19 ` [Intel-gfx] [PATCH 4/5] drm/i915/guc: stop calling execlists_set_default_submission Daniele Ceraolo Spurio
2021-01-06  1:02   ` Chris Wilson
2021-01-06  2:38     ` Daniele Ceraolo Spurio
2021-01-06  3:09       ` Chris Wilson
2021-01-06 17:22         ` Daniele Ceraolo Spurio
2021-01-05 23:19 ` [Intel-gfx] [PATCH 5/5] drm/i915/guc: enable only the user interrupt when using GuC submission Daniele Ceraolo Spurio
2021-01-05 23:38   ` Chris Wilson
2021-01-05 23:56     ` Daniele Ceraolo Spurio
2021-01-06  0:15       ` Chris Wilson
2021-01-06  2:39         ` Daniele Ceraolo Spurio [this message]
2021-01-06  1:05   ` Chris Wilson
2021-01-06  0:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Split GuC submission from execlists submission Patchwork
2021-01-06  0:29 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-01-06  0:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-01-06  3:42 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=a27e4059-622a-e61c-bf97-0e24cdef6ca8@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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