All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Ankit Navik <ankit.p.navik@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 0/4] Dynamic EU configuration of Slice/Subslice/EU.
Date: Tue, 11 Dec 2018 11:48:53 +0000	[thread overview]
Message-ID: <59018093-6b03-b2d8-f0a6-891d5f43301a@linux.intel.com> (raw)
In-Reply-To: <1544523261-26905-1-git-send-email-ankit.p.navik@intel.com>


On 11/12/2018 10:14, Ankit Navik wrote:
> drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel
> 
> Current GPU configuration code for i915 does not allow us to change
> EU/Slice/Sub-slice configuration dynamically. Its done only once while context
> is created.
> 
> While particular graphics application is running, if we examine the command
> requests from user space, we observe that command density is not consistent.
> It means there is scope to change the graphics configuration dynamically even
> while context is running actively. This patch series proposes the solution to
> find the active pending load for all active context at given time and based on
> that, dynamically perform graphics configuration for each context.
> 
> We use a hr (high resolution) timer with i915 driver in kernel to get a
> callback every few milliseconds (this timer value can be configured through
> debugfs, default is '0' indicating timer is in disabled state i.e. original
> system without any intervention).In the timer callback, we examine pending
> commands for a context in the queue, essentially, we intercept them before
> they are executed by GPU and we update context with required number of EUs.
> 
> Two questions, how did we arrive at right timer value? and what's the right
> number of EUs? For the prior one, empirical data to achieve best performance
> in least power was considered. For the later one, we roughly categorized number
> of EUs logically based on platform. Now we compare number of pending commands
> with a particular threshold and then set number of EUs accordingly with update
> context. That threshold is also based on experiments & findings. If GPU is able
> to catch up with CPU, typically there are no pending commands, the EU config
> would remain unchanged there. In case there are more pending commands we
> reprogram context with higher number of EUs. Please note, here we are changing
> EUs even while context is running by examining pending commands every 'x'
> milliseconds.
> 
> With this solution in place, on KBL-GT3 + Android we saw following pnp
> benefits, power numbers mentioned here are system power.
> 
> App /KPI               | % Power |
>                         | Benefit |
>                         |  (mW)   |
> ---------------------------------|
> 3D Mark (Ice storm)    | 2.30%   |
> TRex On screen         | 2.49%   |
> TRex Off screen        | 1.32%   |
> ManhattanOn screen     | 3.11%   |
> Manhattan Off screen   | 0.89%   |
> AnTuTu  6.1.4          | 3.42%   |
> SynMark2               | 1.70%   |

Is this the aggregated SynMark2 result, like all sub-tests averaged or 
something?

I suggest you do want to list much more detail here, all individual 
sub-tests, different platforms, etc. The change you are proposing is 
quite big and the amount of research that you must demonstrate for 
people to take this seriously has to be equally exhaustive.

Regards,

Tvrtko

> 
> Note - For KBL (GEN9) we cannot control at sub-slice level, it was always  a
> constraint.
> We always controlled number of EUs rather than sub-slices/slices.
> We have also observed GPU core residencies improves by 1.03%.
> 
> Praveen Diwakar (4):
>    drm/i915: Get active pending request for given context
>    drm/i915: Update render power clock state configuration for given
>      context
>    drm/i915: set optimum eu/slice/sub-slice configuration based on load
>      type
>    drm/i915: Predictive governor to control eu/slice/subslice
> 
>   drivers/gpu/drm/i915/i915_debugfs.c      | 90 +++++++++++++++++++++++++++++++-
>   drivers/gpu/drm/i915/i915_drv.c          |  4 ++
>   drivers/gpu/drm/i915/i915_drv.h          |  9 ++++
>   drivers/gpu/drm/i915/i915_gem_context.c  | 23 ++++++++
>   drivers/gpu/drm/i915/i915_gem_context.h  | 39 ++++++++++++++
>   drivers/gpu/drm/i915/i915_request.c      |  2 +
>   drivers/gpu/drm/i915/intel_device_info.c | 47 ++++++++++++++++-
>   drivers/gpu/drm/i915/intel_lrc.c         | 16 +++++-
>   8 files changed, 226 insertions(+), 4 deletions(-)
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-12-11 11:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 10:14 [PATCH v3 0/4] Dynamic EU configuration of Slice/Subslice/EU Ankit Navik
2018-12-11 10:14 ` [PATCH v3 1/4] drm/i915: Get active pending request for given context Ankit Navik
2018-12-11 11:58   ` Tvrtko Ursulin
2018-12-11 10:14 ` [PATCH v3 2/4] drm/i915: Update render power clock state configuration " Ankit Navik
2018-12-11 12:36   ` Tvrtko Ursulin
2019-03-14  8:55     ` Ankit Navik
2018-12-11 10:14 ` [PATCH v3 3/4] drm/i915: set optimum eu/slice/sub-slice configuration based on load type Ankit Navik
2018-12-11 12:47   ` Tvrtko Ursulin
2018-12-12  7:36     ` Navik, Ankit P
2018-12-11 10:14 ` [PATCH v3 4/4] drm/i915: Predictive governor to control eu/slice/subslice Ankit Navik
2018-12-11 13:00   ` Tvrtko Ursulin
2018-12-11 11:12 ` ✗ Fi.CI.BAT: failure for Dynamic EU configuration of Slice/Subslice/EU Patchwork
2018-12-11 13:02   ` Tvrtko Ursulin
2018-12-11 11:48 ` Tvrtko Ursulin [this message]
2018-12-12  7:43   ` [PATCH v3 0/4] " Navik, Ankit P
2018-12-14 10:27 ` Joonas Lahtinen
2018-12-14 12:09   ` Navik, Ankit P
  -- strict thread matches above, loose matches on Subject: below --
2018-12-11  9:51 Ankit Navik

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=59018093-6b03-b2d8-f0a6-891d5f43301a@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=ankit.p.navik@intel.com \
    --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 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.