All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.