From: Daniel Vetter <daniel@ffwll.ch>
To: tom.orourke@intel.com
Cc: intel-gfx@lists.freedesktop.org,
radoslaw.szwichtenberg@intel.com, paulo.r.zanoni@intel.com,
Tom O'Rourke <Tom.O'Rourke@intel.com>
Subject: Re: [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change
Date: Thu, 28 Apr 2016 10:41:21 +0200 [thread overview]
Message-ID: <20160428084121.GU2558@phenom.ffwll.local> (raw)
In-Reply-To: <20160428083827.GT2558@phenom.ffwll.local>
On Thu, Apr 28, 2016 at 10:38:27AM +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2016 at 06:10:59PM -0700, tom.orourke@intel.com wrote:
> > From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> >
> > This patch will inform GuC SLPC about changes in the refresh rate
> > due to Seamless DRRS. Refresh rate changes due to Static DRRS will
> > be notified via commit path.
> >
> > v2: Rebased on previous changed patch and printed error message if
> > H2G action fails.
> > v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with
> > intel_slpc_active. return void instead of ignored error code.
> >
> > Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> > Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
>
> So all this display notification stuff looks real fancy, but we have it
> already in the kernel. We notice when we're late in a frame, and then
> aggressively ramp up.
>
> I want to see an implementation that reuses that infrastructure and just
> tells guc to hurry up, and then benchmark against this one (wrt overall
> frame latency distribution in spikey workloads). All this complexity and
> an entire 2nd codepath needs to be justified in a unified driver, and I
> see exactly none of that going on.
+ power consumption benchmarks ofc, since current code also aggressively
downclocks again when the burst is over. My concern here is that
fundamentally guc just doesn't know enough to make a good decision here,
or at least it can react only much later. Whereas the kernel actually
knows what atomic display update it has pending, and what exactly it needs
to boost to get that to the screen asap.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-28 8:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 1:10 [PATCH v4 00/21] Add support for GuC-based SLPC tom.orourke
2016-04-28 1:10 ` [PATCH 01/21] drm/i915/slpc: Expose guc functions for use with SLPC tom.orourke
2016-04-28 7:00 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 02/21] drm/i915/slpc: Add has_slpc capability flag tom.orourke
2016-04-28 1:10 ` [PATCH 03/21] drm/i915/slpc: Add slpc_version_check tom.orourke
2016-04-28 6:46 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 04/21] drm/i915/slpc: Add enable_slpc module parameter tom.orourke
2016-04-28 7:02 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 05/21] drm/i915/slpc: Use intel_slpc_* functions if supported tom.orourke
2016-04-28 1:10 ` [PATCH 06/21] drm/i915/slpc: Enable SLPC in guc " tom.orourke
2016-04-28 1:10 ` [PATCH 07/21] drm/i915/slpc: If using SLPC, do not set frequency tom.orourke
2016-04-28 6:34 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 08/21] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data tom.orourke
2016-04-28 7:15 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 09/21] drm/i915/slpc: Setup rps frequency values during SLPC init tom.orourke
2016-04-28 6:41 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 10/21] drm/i915/slpc: Update current requested frequency tom.orourke
2016-04-28 6:25 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 11/21] drm/i915/slpc: Send reset event tom.orourke
2016-04-28 1:10 ` [PATCH 12/21] drm/i915/slpc: Send shutdown event tom.orourke
2016-04-28 7:07 ` Chris Wilson
2016-04-28 1:10 ` [PATCH 13/21] drm/i915/slpc: Add Display mode event related data structures tom.orourke
2016-04-28 1:10 ` [PATCH 14/21] drm/i915/slpc: Notification of Display mode change tom.orourke
2016-04-28 1:10 ` [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change tom.orourke
2016-04-28 8:38 ` Daniel Vetter
2016-04-28 8:41 ` Daniel Vetter [this message]
2016-04-29 9:09 ` Ville Syrjälä
2016-04-28 1:11 ` [PATCH 16/21] drm/i915/slpc: Add slpc_status enum values tom.orourke
2016-04-28 1:11 ` [PATCH 17/21] drm/i915/slpc: Add parameter unset/set/get functions tom.orourke
2016-04-28 1:11 ` [PATCH 18/21] drm/i915/slpc: Add slpc support for max/min freq tom.orourke
2016-04-28 1:11 ` [PATCH 19/21] drm/i915/slpc: Add enable/disable debugfs for slpc tom.orourke
2016-04-28 7:28 ` Chris Wilson
2016-04-28 1:11 ` [PATCH 20/21] drm/i915/slpc: Add i915_slpc_info to debugfs tom.orourke
2016-04-28 1:11 ` [PATCH 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active tom.orourke
2016-04-28 6:56 ` Chris Wilson
2016-04-28 7:57 ` Imre Deak
2016-04-28 8:00 ` Chris Wilson
2016-04-29 9:34 ` Imre Deak
2016-04-28 7:16 ` ✓ Fi.CI.BAT: success for Add support for GuC-based SLPC (rev4) Patchwork
2016-04-28 23:01 ` [PATCH v4 00/21] Add support for GuC-based SLPC O'Rourke, Tom
2016-04-29 8:47 ` 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=20160428084121.GU2558@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Tom.O'Rourke@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=radoslaw.szwichtenberg@intel.com \
--cc=tom.orourke@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