From: Martin Peres <martin.peres@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>, Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org, Tom O'Rourke <Tom.O'Rourke@intel.com>
Subject: Re: [RFC 00/22] Add support for GuC-based SLPC
Date: Tue, 9 Feb 2016 14:08:23 +0200 [thread overview]
Message-ID: <56B9D6B7.1040507@linux.intel.com> (raw)
In-Reply-To: <20160126170010.GE11240@phenom.ffwll.local>
On 26/01/16 19:00, Daniel Vetter wrote:
> On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote:
>> On 01/22/2016 09:00 AM, Daniel Vetter wrote:
>>> On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orourke@intel.com wrote:
>>>> From: Tom O'Rourke <Tom.O'Rourke@intel.com>
>
> I'd say we need to keep the boost-deboost stuff alive, e.g. by manually
> telling guc that the we want different limits, then resetting those limits
> again after the boost is done. Same for fast idling - kernel simply has a
> better idea if anyone is about to submit more work (we have execbuf hints
> for specific workloads like libva).
Since there is soon to be a GPU scheduler, the GuC could get this
information already, right? Unless you are talking about having mesa
signal when it starts creating a new batchbuffer and you would like the
GPU to prepare to ramp-up.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-02-09 12:08 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 2:26 [RFC 00/22] Add support for GuC-based SLPC tom.orourke
2016-01-21 2:26 ` [RFC 01/22] drm/i915: Enable GuC submission, where supported tom.orourke
2016-01-21 2:26 ` [RFC 02/22] drm/i915/slpc: Add has_slpc capability flag tom.orourke
2016-01-21 2:26 ` [RFC 03/22] drm/i915/slpc: Expose guc functions for use with SLPC tom.orourke
2016-01-21 2:26 ` [RFC 04/22] drm/i915/slpc: Use intel_slpc_* functions if supported tom.orourke
2016-01-21 2:26 ` [RFC 05/22] drm/i915/slpc: Enable/Disable RC6 in SLPC flows tom.orourke
2016-01-21 2:26 ` [RFC 06/22] drm/i915/slpc: If using SLPC, do not set frequency tom.orourke
2016-01-22 16:53 ` Daniel Vetter
2016-01-22 17:22 ` Daniel Vetter
2016-01-21 2:26 ` [RFC 07/22] drm/i915/slpc: Enable SLPC in guc if supported tom.orourke
2016-01-21 2:26 ` [RFC 08/22] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data tom.orourke
2016-01-21 2:26 ` [RFC 09/22] drm/i915/slpc: Setup rps frequency values during SLPC init tom.orourke
2016-01-21 2:26 ` [RFC 10/22] drm/i915/slpc: Update current requested frequency tom.orourke
2016-01-21 2:26 ` [RFC 11/22] drm/i915/slpc: Send reset event tom.orourke
2016-01-21 2:26 ` [RFC 12/22] drm/i915/slpc: Send shutdown event tom.orourke
2016-01-21 2:26 ` [RFC 13/22] drm/i915/slpc: Add Display mode event related data structures tom.orourke
2016-01-21 2:26 ` [RFC 14/22] drm/i915/slpc: Notification of Display mode change tom.orourke
2016-01-21 13:24 ` Zanoni, Paulo R
2016-01-28 9:43 ` Kamble, Sagar A
2016-01-22 17:14 ` Ville Syrjälä
2016-01-29 5:00 ` Kamble, Sagar A
2016-01-21 2:26 ` [RFC 15/22] drm/i915/slpc: Notification of Refresh Rate change tom.orourke
2016-01-21 2:26 ` [RFC 16/22] drm/i915/slpc: Add slpc_status enum values tom.orourke
2016-01-21 2:26 ` [RFC 17/22] drm/i915/slpc: Add i915_slpc_info to debugfs tom.orourke
2016-01-21 2:26 ` [RFC 18/22] drm/i915/slpc: Add dfps task info to i915_slpc_info tom.orourke
2016-01-21 2:26 ` [RFC 19/22] drm/i915/slpc: Add parameter unset/set/get functions tom.orourke
2016-01-21 2:26 ` [RFC 20/22] drm/i915/slpc: Add slpc support for max/min freq tom.orourke
2016-01-21 2:26 ` [RFC 21/22] drm/i915/slpc: Add enable/disable debugfs for slpc tom.orourke
2016-01-21 2:26 ` [RFC 22/22] drm/i915/slpc: Add has_slpc to skylake info tom.orourke
2016-01-21 13:50 ` ✗ Fi.CI.BAT: failure for Add support for GuC-based SLPC Patchwork
2016-01-21 23:16 ` O'Rourke, Tom
2016-01-22 17:07 ` Daniel Vetter
2016-01-22 17:00 ` [RFC 00/22] " Daniel Vetter
2016-01-26 15:45 ` Jesse Barnes
2016-01-26 17:00 ` Daniel Vetter
2016-01-26 17:17 ` Jesse Barnes
2016-01-27 1:17 ` O'Rourke, Tom
2016-02-09 12:08 ` Martin Peres [this message]
2016-02-10 7:37 ` Daniel Vetter
2016-02-10 10:31 ` Martin Peres
2016-02-03 20:25 ` Zanoni, Paulo R
2016-02-09 7:03 ` Kamble, Sagar A
2016-02-11 20:10 ` Zanoni, Paulo R
2016-02-09 11:56 ` Martin Peres
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=56B9D6B7.1040507@linux.intel.com \
--to=martin.peres@linux.intel.com \
--cc=Tom.O'Rourke@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.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;
as well as URLs for NNTP newsgroup(s).