public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tursulin@ursulin.net>
Subject: Re: [PATCH 4/7] drm/i915/perf: lock powergating configuration to default when active
Date: Thu, 6 Sep 2018 10:41:07 +0100	[thread overview]
Message-ID: <a55a11c8-72f4-bdd3-ce07-28fcc0cace97@linux.intel.com> (raw)
In-Reply-To: <153616091254.28292.6696793233220895060@skylake-alporthouse-com>


On 05/09/2018 16:21, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-09-05 15:22:19)
>> -static u32 make_rpcs(struct drm_i915_private *dev_priv,
>> -                    struct intel_sseu *ctx_sseu)
>> +u32 gen8_make_rpcs(struct drm_i915_private *dev_priv,
>> +                  struct intel_sseu *req_sseu)
> 
> Should we retrospectively make this const?

Can do, but generally I try to avoid it kernel code since most of the 
time it is way more pain than benefit.

> (And anychance for a s/dev_priv/i915?)

Will check if it is doable without much noise at any of the stages.

>>   {
>>          const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu;
>>          bool subslice_pg = sseu->has_subslice_pg;
>> -       u8 slices = hweight8(ctx_sseu->slice_mask);
>> -       u8 subslices = hweight8(ctx_sseu->subslice_mask);
>> +       struct intel_sseu ctx_sseu;
>> +       u8 slices, subslices;
>>          u32 rpcs = 0;
>>   
>> +       /*
>> +        * 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).
>> +        */
>> +       if (unlikely(dev_priv->perf.oa.exclusive_stream))
>> +               ctx_sseu = intel_device_default_sseu(dev_priv);
>> +       else
>> +               ctx_sseu = *req_sseu;
> 
> :(
> 
> I'm not sure if I can suggest anything better, but this does feel like a
> layering violation.
> 
> It makes sense which makes it only feel worse.

It used to be a helper which applied the adjustment but I wasn't happy 
with how callers then had to know to call the helper and decided 
handling it at the core is better in more than one way.

I think bottom line is there is fundamental interaction between the two 
so some layering violation has to happen.

Regards,

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

  reply	other threads:[~2018-09-06  9:41 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 14:22 [PATCH v11 0/7] Per context dynamic (sub)slice power-gating Tvrtko Ursulin
2018-09-05 14:22 ` [PATCH 1/7] drm/i915/execlists: Move RPCS setup to context pin Tvrtko Ursulin
2018-09-05 15:14   ` Chris Wilson
2018-09-05 14:22 ` [PATCH 2/7] drm/i915: Program RPCS for Broadwell Tvrtko Ursulin
2018-09-05 14:22 ` [PATCH 3/7] drm/i915: Record the sseu configuration per-context & engine Tvrtko Ursulin
2018-09-05 15:18   ` Chris Wilson
2018-09-06  9:36     ` Tvrtko Ursulin
2018-09-05 14:22 ` [PATCH 4/7] drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin
2018-09-05 15:21   ` Chris Wilson
2018-09-06  9:41     ` Tvrtko Ursulin [this message]
2018-09-06  9:57   ` Lionel Landwerlin
2018-09-06 10:10     ` Chris Wilson
2018-09-06 10:18       ` Lionel Landwerlin
2018-09-06 10:22         ` Chris Wilson
2018-09-06 10:36           ` Lionel Landwerlin
2018-09-07  8:26             ` Tvrtko Ursulin
2018-09-07  8:59               ` Chris Wilson
2018-09-07  9:23               ` Lionel Landwerlin
2018-09-07  9:39                 ` Tvrtko Ursulin
2018-09-07  9:55                   ` Lionel Landwerlin
2018-09-10 13:44                     ` Tvrtko Ursulin
2018-09-11 20:11                       ` Lionel Landwerlin
2018-09-12  8:03                         ` Tvrtko Ursulin
2018-09-05 14:22 ` [PATCH 5/7] drm/i915: Add timeline barrier support Tvrtko Ursulin
2018-09-05 15:23   ` Chris Wilson
2018-09-05 14:22 ` [PATCH 6/7] drm/i915: Expose RPCS (SSEU) configuration to userspace Tvrtko Ursulin
2018-09-05 15:29   ` Chris Wilson
2018-09-06  9:50     ` Tvrtko Ursulin
2018-09-06  9:54       ` Chris Wilson
2018-09-06  9:58       ` Lionel Landwerlin
2018-09-05 14:22 ` [PATCH 7/7] drm/i915/icl: Support co-existance between per-context SSEU and OA Tvrtko Ursulin
2018-09-05 14:46 ` ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev2) Patchwork
2018-09-05 14:49 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-09-05 15:05 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-05 19:55 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-09-06 19:33 ` [PATCH v11 0/7] Per context dynamic (sub)slice power-gating Chris Wilson
2018-09-06 19:52   ` Chris Wilson

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=a55a11c8-72f4-bdd3-ce07-28fcc0cace97@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=tursulin@ursulin.net \
    /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