From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
Date: Mon, 1 Oct 2018 15:18:53 +0100 [thread overview]
Message-ID: <395ddfac-3c5e-0559-d552-91cf36cd1d1f@intel.com> (raw)
In-Reply-To: <1050cfbb-a98d-3977-4eb6-8680b980a2d4@linux.intel.com>
On 01/10/2018 13:42, Tvrtko Ursulin wrote:
>
> On 01/10/2018 12:06, Lionel Landwerlin wrote:
>> On 01/10/2018 12:20, Tvrtko Ursulin wrote:
>>>
>>> On 01/10/2018 10:50, Lionel Landwerlin wrote:
>>>> On 17/09/2018 13:30, Tvrtko Ursulin wrote:
>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>
>>>>> When OA is active we want to lock the powergating configuration,
>>>>> but on
>>>>> Icelake, users like the media stack will have issues if we lock to
>>>>> the
>>>>> full device configuration.
>>>>>
>>>>> Instead lock to a subset of (sub)slices which are currently a known
>>>>> working configuration for all users.
>>>>>
>>>>> v2:
>>>>> * Fix commit message spelling.
>>>>>
>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/intel_lrc.c | 25 ++++++++++++++++++++-----
>>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>>>>> b/drivers/gpu/drm/i915/intel_lrc.c
>>>>> index b5603e977a3f..cded1f1d9ec2 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>>>>> @@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private
>>>>> *i915, struct intel_sseu *req_sseu)
>>>>> /*
>>>>> * If i915/perf is active, we want a stable powergating
>>>>> configuration
>>>>> - * on the system. The most natural configuration to take in
>>>>> that case
>>>>> - * is the default (i.e maximum the hardware can do).
>>>>> + * on the system.
>>>>> + *
>>>>> + * We could choose full enablement, but on ICL we know there
>>>>> are use
>>>>> + * cases which disable slices for functional, apart for
>>>>> performance
>>>>> + * reasons. So in this case we select a known stable subset.
>>>>> */
>>>>> - if (unlikely(i915->perf.oa.exclusive_stream))
>>>>> - ctx_sseu = intel_device_default_sseu(i915);
>>>>> - else
>>>>> + if (!i915->perf.oa.exclusive_stream) {
>>>>> ctx_sseu = *req_sseu;
>>>>> + } else {
>>>>> + ctx_sseu = intel_device_default_sseu(i915);
>>>>> +
>>>>> + if (IS_GEN11(i915)) {
>>>>> + /*
>>>>> + * We only need subslice count so it doesn't matter
>>>>> + * which ones we select - just turn of low bits in the
>>>>
>>>> s/turn of/turn off/
>>>
>>> Yep, thanks.
>>>
>>>>
>>>>> + * amount of half of all available subslices per slice.
>>>>> + */
>>>>> + ctx_sseu.subslice_mask =
>>>>> + ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
>>>>
>>>>
>>>> I would go with :
>>>>
>>>>
>>>> ctx_sseu.subslice_mask = ctx_sseu.subslice_mask & 0xf;
>>>>
>>>>
>>>> Documentation says that the first 4 subslices are the "big" ones
>>>> (gathered from the fusing register fields which go from
>>>> slice0-subslice[0-3] then slice1-subslice[0-3], etc...), so this
>>>> should be equally media/3d capable.
>>>
>>> Doesn't work I think - one 1x6x8 part I've seen has a subslice mask
>>> of 0b11111100 and there we want to have three subslices enabled.
>>>
>>> Regards,
>>>
>>> Tvrtko
>>
>>
>> Thanks, then the fusing fields don't match for a big/small sets of
>> subslices.
>>
>> I guess the fusing might be in this pattern (Small/Big) : SBSBSBSB
>>
>> I was hoping we could know so that we program the powergating at the
>> most capable configuration.
>
> It will be the most capable configuration. Did you forget the RPCS
> register in ICL works with counts and not masks? According the that
> Bspec table we cannot select anything but the most capable configuration.
>
> Regards,
>
> Tvrtko
>
Sorry, I must have forgotten. I was trying to read the docs again
looking for something that said the fusing always happened in pairs.
I'm confident we need to limit the subslices when OA is on and if you
know where the details are written down (maybe add the bspec number?),
this is :
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-10-01 14:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-17 11:30 [PATCH v13 0/6] Per context dynamic (sub)slice power-gating Tvrtko Ursulin
2018-09-17 11:30 ` [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin Tvrtko Ursulin
2018-09-17 11:43 ` Chris Wilson
2018-09-17 11:30 ` [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine Tvrtko Ursulin
2018-09-17 11:30 ` [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin
2018-09-17 11:50 ` Chris Wilson
2018-09-17 11:30 ` [PATCH 4/6] drm/i915: Add timeline barrier support Tvrtko Ursulin
2018-09-17 11:30 ` [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace Tvrtko Ursulin
2018-09-17 11:48 ` Chris Wilson
2018-09-18 13:43 ` [PATCH v18 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) Tvrtko Ursulin
2018-09-17 11:30 ` [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA Tvrtko Ursulin
2018-10-01 8:49 ` Tvrtko Ursulin
2018-10-01 9:50 ` Lionel Landwerlin
2018-10-01 10:20 ` Tvrtko Ursulin
2018-10-01 11:06 ` Lionel Landwerlin
2018-10-01 11:42 ` Tvrtko Ursulin
2018-10-01 14:18 ` Lionel Landwerlin [this message]
2018-10-01 15:05 ` Tvrtko Ursulin
2018-10-01 15:26 ` [PATCH v3] " Tvrtko Ursulin
2018-09-17 11:44 ` ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev4) Patchwork
2018-09-17 11:46 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-09-17 12:02 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-17 13:04 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-09-18 14:06 ` ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev5) Patchwork
2018-09-18 14:09 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-09-18 14:25 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-18 16:05 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-10-01 16:35 ` ✗ Fi.CI.BAT: failure for Per context dynamic (sub)slice power-gating (rev6) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2018-11-13 14:35 [PATCH 0/6] Per context dynamic (sub)slice power-gating Tvrtko Ursulin
2018-11-13 14:35 ` [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA Tvrtko Ursulin
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=395ddfac-3c5e-0559-d552-91cf36cd1d1f@intel.com \
--to=lionel.g.landwerlin@intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=tursulin@ursulin.net \
--cc=tvrtko.ursulin@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.