From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915: Compute use_sagv_wm differently
Date: Thu, 1 Feb 2024 10:17:18 +0200 [thread overview]
Message-ID: <ZbtTYsTncs0i3H8E@intel.com> (raw)
In-Reply-To: <20231219130756.25986-2-ville.syrjala@linux.intel.com>
On Tue, Dec 19, 2023 at 03:07:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> drm_atomic_check_only() gets upset if we try to add extra crtcs
> to any commit that isn't flagged with DRM_MODE_ATOMIC_ALLOW_MODESET.
> This conflicts with how SAGV watermarks work on pre-ADL as we
> need to manually switch over the SAGV watermarks before we can
> safely enable SAGV.
>
> So in order to make SAGV usage possible we need to compute each
> pipe's use of SAGV watermarks as if there aren't any other
> active pipes. Ie. if the current pipe isn't the one blocking
> SAGV then we make it use the SAGV watermarks, even if some
> other pipe prevents SAGV from actually being used. Otherwise
> we could end up with a pipes using the normal watermarks (but
> not blocking SAGV), and some other pipe in parallel enabling
> SAGV, which would likely cause underruns.
>
> The alternative approach of preventing SAGV usage until all
> pipes simultanously end up using SAGV watermarks would only
> really work if userspace always adds all pipes to every
> commits, which isn't the case typically.
>
> The downside of this is that we will end up using the less
> optimal SAGV watermarks even if some other pipe prevents
> SAGV from actually being enabled. In which case the system
> won't achieve the minimum possible power consumption.
This is quite sad, that we have to do that, basically means
we might end up using SAGV watermarks, which use a bit more
DBuf(taking into account SAGV related memory latency) just
because we can't sync properly with drm commit architecture
(as I understand the main problem is that crtc addition to the commit).
This is not catastrophical of course, but we are now basically
using the solution which we know for sure, that isn't optimal.
But as me personally and you probably as well, don't really
have time resource to spend for solving it more efficiently,
lets use this as a solution.
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 38 ++++++++++++--------
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 56588d6e24ae..9cee19cbe253 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -443,12 +443,35 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
>
> for_each_new_intel_crtc_in_state(state, crtc,
> new_crtc_state, i) {
> + struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
> +
> new_bw_state = intel_atomic_get_bw_state(state);
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> old_bw_state = intel_atomic_get_old_bw_state(state);
>
> + /*
> + * We store use_sagv_wm in the crtc state rather than relying on
> + * that bw state since we have no convenient way to get at the
> + * latter from the plane commit hooks (especially in the legacy
> + * cursor case).
> + *
> + * drm_atomic_check_only() gets upset if we pull more crtcs
> + * into the state, so we have to calculate this based on the
> + * individual intel_crtc_can_enable_sagv() rather than
> + * the overall intel_crtc_can_enable_sagv(). Otherwise the
> + * crtcs not included in the commit would not switch to the
> + * SAGV watermarks when we are about to enable SAGV, and that
> + * would lead to underruns. This does mean extra power draw
> + * when only a subset of the crtcs are blocking SAGV as the
> + * other crtcs can't be allowed to use the more optimal
> + * normal (ie. non-SAGV) watermarks.
> + */
> + pipe_wm->use_sagv_wm = !HAS_HW_SAGV_WM(i915) &&
> + DISPLAY_VER(i915) >= 12 &&
> + intel_crtc_can_enable_sagv(new_crtc_state);
> +
> if (intel_crtc_can_enable_sagv(new_crtc_state))
> new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> else
> @@ -478,21 +501,6 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
> return ret;
> }
>
> - for_each_new_intel_crtc_in_state(state, crtc,
> - new_crtc_state, i) {
> - struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
> -
> - /*
> - * We store use_sagv_wm in the crtc state rather than relying on
> - * that bw state since we have no convenient way to get at the
> - * latter from the plane commit hooks (especially in the legacy
> - * cursor case)
> - */
> - pipe_wm->use_sagv_wm = !HAS_HW_SAGV_WM(i915) &&
> - DISPLAY_VER(i915) >= 12 &&
> - intel_can_enable_sagv(i915, new_bw_state);
> - }
> -
> return 0;
> }
>
> --
> 2.41.0
>
next prev parent reply other threads:[~2024-02-01 8:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 13:07 [PATCH 0/3] drm/i915: Rework global state serialization Ville Syrjala
2023-12-19 13:07 ` [PATCH 1/3] drm/i915: Compute use_sagv_wm differently Ville Syrjala
2024-02-01 8:17 ` Lisovskiy, Stanislav [this message]
2023-12-19 13:07 ` [PATCH 2/3] drm/i915: Rework global state serializaiton Ville Syrjala
2024-02-01 8:48 ` Lisovskiy, Stanislav
2023-12-19 13:07 ` [PATCH 3/3] drm/i915: Extract intel_atomic_swap_state() Ville Syrjala
2024-01-15 11:10 ` Lisovskiy, Stanislav
2023-12-19 13:39 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Rework global state serialization Patchwork
2023-12-19 13:52 ` ✓ Fi.CI.BAT: success " Patchwork
2023-12-19 15:25 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-10 18:17 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Rework global state serialization (rev2) Patchwork
2024-01-10 18:30 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-10 22:20 ` ✗ Fi.CI.IGT: failure " Patchwork
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=ZbtTYsTncs0i3H8E@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.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 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.