public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@kernel.org>
Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPS thresholds in sysfs
Date: Mon, 22 May 2023 13:03:48 +0100	[thread overview]
Message-ID: <ab7760d5-af5d-2dd7-83c3-9972e0b68c7a@linux.intel.com> (raw)
In-Reply-To: <ZGfiYracxton0/S5@rdvivi-mobl4>


On 19/05/2023 21:56, Rodrigo Vivi wrote:
> On Fri, Apr 28, 2023 at 09:44:53AM +0100, Tvrtko Ursulin wrote:
>>
>> On 28/04/2023 09:14, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> User feedback indicates significant performance gains are possible in
>>> specific games with non default RPS up/down thresholds.
>>>
>>> Expose these tunables via sysfs which will allow users to achieve best
>>> performance when running games and best power efficiency elsewhere.
>>>
>>> Note this patch supports non GuC based platforms only.
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389
>>
>> [snip]
>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c
>>> index a5a7315f5ace..f790e81546ff 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
>>> @@ -2588,7 +2588,12 @@ static int rps_set_threshold(struct intel_rps *rps, u8 *threshold, u8 val)
>>>    	ret = mutex_lock_interruptible(&rps->lock);
>>>    	if (ret)
>>>    		return ret;
>>> -	*threshold = val;
>>> +	if (*threshold != val) {
>>> +		*threshold = val;
>>> +		intel_rps_set(rps, clamp(rps->cur_freq,
>>> +					 rps->min_freq_softlimit,
>>> +					 rps->max_freq_softlimit));
>>> +	}
>>>    	mutex_unlock(&rps->lock);
>>>    	return 0;
>>
>> This hunk belongs to a previous patch - moved locally.
> 
> I probably missed something then becuase I didn't miss this in any
> of the previous patches. To the point that this looked like a new
> separated patch.

Depends how you look at it. 3/4 adds a helper which changes the 
threshold, but it was only updating the sw state and so when those 
values would actually get written into registers (derived) would depend 
on the workload. So I thought it was important to move the call to 
intel_rps_set, which actually will trigger hw reprogramming, into the 
patch which claims to be adding the helper.

Note v2 of the helper (just sent) which actually fixes this further by 
forcing this re-programming to happen.

Regards,

Tvrtko

  reply	other threads:[~2023-05-22 12:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28  8:14 [Intel-gfx] [RFC v2 0/4] Expose RPS thresholds in sysfs Tvrtko Ursulin
2023-04-28  8:14 ` [Intel-gfx] [RFC 1/4] drm/i915: Move setting of rps thresholds to init Tvrtko Ursulin
2023-04-28  8:14 ` [Intel-gfx] [RFC 2/4] drm/i915: Record default rps threshold values Tvrtko Ursulin
2023-04-28  8:14 ` [Intel-gfx] [RFC 3/4] drm/i915: Add helpers for managing rps thresholds Tvrtko Ursulin
2023-05-19 20:56   ` Rodrigo Vivi
2023-05-22 12:00     ` Tvrtko Ursulin
2023-04-28  8:14 ` [Intel-gfx] [RFC 4/4] drm/i915: Expose RPS thresholds in sysfs Tvrtko Ursulin
2023-04-28  8:44   ` Tvrtko Ursulin
2023-05-19 20:56     ` Rodrigo Vivi
2023-05-22 12:03       ` Tvrtko Ursulin [this message]
2023-05-19 19:36   ` Prahlad Kilambi
2023-05-19 21:00     ` Rodrigo Vivi
2023-04-28  8:39 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Expose RPS thresholds in sysfs (rev2) Patchwork
2023-04-28  8:39 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-28  8:55 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2023-04-27 12:45 [Intel-gfx] [RFC 0/4] Expose RPS thresholds in sysfs Tvrtko Ursulin
2023-04-27 12:45 ` [Intel-gfx] [RFC 4/4] drm/i915: " Tvrtko Ursulin

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=ab7760d5-af5d-2dd7-83c3-9972e0b68c7a@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=rodrigo.vivi@kernel.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