From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 03/15] drm/i915: Fix plane relative_data_rate calculation
Date: Thu, 27 Jan 2022 10:21:06 +0200 [thread overview]
Message-ID: <20220127082106.GC31846@intel.com> (raw)
In-Reply-To: <20220118092354.11631-4-ville.syrjala@linux.intel.com>
On Tue, Jan 18, 2022 at 11:23:42AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We are currently computing the relative data rates as
> src_size * scale_factor where scale_factor is src_size / dst_size.
> Thus relative data rate is src_size * src_size / dst_size,
> which is just utter nonsense. What we really seem to want is
> just a reasonable estimate on how much data will be fetched
> which is just src_size. So let's do that instead.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Omg, how could it stay like this all the time?
I actually had similar question, but thought that there just might
be again some magical/empirical heuristics behind this.
Need to challenge more anything, which can't be explained with
BSpec formulas or by common sense...
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 63 ++-------------------------------
> 1 file changed, 2 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9a9d4acb2988..e8fb56f288b4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4373,55 +4373,6 @@ void skl_pipe_ddb_get_hw_state(struct intel_crtc *crtc,
> intel_display_power_put(dev_priv, power_domain, wakeref);
> }
>
> -/*
> - * Determines the downscale amount of a plane for the purposes of watermark calculations.
> - * The bspec defines downscale amount as:
> - *
> - * """
> - * Horizontal down scale amount = maximum[1, Horizontal source size /
> - * Horizontal destination size]
> - * Vertical down scale amount = maximum[1, Vertical source size /
> - * Vertical destination size]
> - * Total down scale amount = Horizontal down scale amount *
> - * Vertical down scale amount
> - * """
> - *
> - * Return value is provided in 16.16 fixed point form to retain fractional part.
> - * Caller should take care of dividing & rounding off the value.
> - */
> -static uint_fixed_16_16_t
> -skl_plane_downscale_amount(const struct intel_crtc_state *crtc_state,
> - const struct intel_plane_state *plane_state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> - u32 src_w, src_h, dst_w, dst_h;
> - uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
> - uint_fixed_16_16_t downscale_h, downscale_w;
> -
> - if (drm_WARN_ON(&dev_priv->drm,
> - !intel_wm_plane_visible(crtc_state, plane_state)))
> - return u32_to_fixed16(0);
> -
> - /*
> - * Src coordinates are already rotated by 270 degrees for
> - * the 90/270 degree plane rotation cases (to match the
> - * GTT mapping), hence no need to account for rotation here.
> - *
> - * n.b., src is 16.16 fixed point, dst is whole integer.
> - */
> - src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
> - src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> - dst_w = drm_rect_width(&plane_state->uapi.dst);
> - dst_h = drm_rect_height(&plane_state->uapi.dst);
> -
> - fp_w_ratio = div_fixed16(src_w, dst_w);
> - fp_h_ratio = div_fixed16(src_h, dst_h);
> - downscale_w = max_fixed16(fp_w_ratio, u32_to_fixed16(1));
> - downscale_h = max_fixed16(fp_h_ratio, u32_to_fixed16(1));
> -
> - return mul_fixed16(downscale_w, downscale_h);
> -}
> -
> struct dbuf_slice_conf_entry {
> u8 active_pipes;
> u8 dbuf_mask[I915_MAX_PIPES];
> @@ -4932,10 +4883,7 @@ skl_plane_relative_data_rate(const struct intel_crtc_state *crtc_state,
> {
> struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> - u32 data_rate;
> - u32 width = 0, height = 0;
> - uint_fixed_16_16_t down_scale_amount;
> - u64 rate;
> + int width, height;
>
> if (!plane_state->uapi.visible)
> return 0;
> @@ -4961,14 +4909,7 @@ skl_plane_relative_data_rate(const struct intel_crtc_state *crtc_state,
> height /= 2;
> }
>
> - data_rate = width * height;
> -
> - down_scale_amount = skl_plane_downscale_amount(crtc_state, plane_state);
> -
> - rate = mul_round_up_u32_fixed16(data_rate, down_scale_amount);
> -
> - rate *= fb->format->cpp[color_plane];
> - return rate;
> + return width * height * fb->format->cpp[color_plane];
> }
>
> static u64
> --
> 2.32.0
>
next prev parent reply other threads:[~2022-01-27 8:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 9:23 [Intel-gfx] [PATCH 00/15] drm/i915: Fix bandwith related cdclk calculations Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 01/15] drm/i915: Drop pointless dev_priv argument Ville Syrjala
2022-01-27 8:15 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 02/15] drm/i915: Extract skl_ddb_entry_init() Ville Syrjala
2022-01-27 8:16 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 03/15] drm/i915: Fix plane relative_data_rate calculation Ville Syrjala
2022-01-27 8:21 ` Lisovskiy, Stanislav [this message]
2022-01-27 8:50 ` Ville Syrjälä
2022-01-18 9:23 ` [Intel-gfx] [PATCH 04/15] drm/i915: Introduce skl_plane_ddb_iter Ville Syrjala
2022-01-27 8:22 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 05/15] drm/i915: Extract skl_allocate_plane_ddb() Ville Syrjala
2022-01-27 8:24 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 06/15] drm/i915: Extract skl_crtc_calc_dbuf_bw() Ville Syrjala
2022-01-27 8:24 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 07/15] drm/i915: Tweak plane ddb allocation tracking Ville Syrjala
2022-02-01 8:06 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 08/15] drm/i915: Split plane data_rate into data_rate+data_rate_y Ville Syrjala
2022-02-01 8:08 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 09/15] drm/i915: Pre-calculate plane relative data rate Ville Syrjala
2022-02-01 8:11 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 10/15] drm/i915: Remove total[] and uv_total[] from ddb allocation Ville Syrjala
2022-02-01 8:26 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk() Ville Syrjala
2022-02-01 8:52 ` Lisovskiy, Stanislav
2022-02-01 10:05 ` Ville Syrjälä
2022-02-01 11:18 ` Lisovskiy, Stanislav
2022-02-01 13:45 ` Ville Syrjälä
2022-02-01 14:38 ` Lisovskiy, Stanislav
2022-01-18 9:23 ` [Intel-gfx] [PATCH 12/15] drm/i915: Round up when calculating display bandwidth requirements Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 13/15] drm/i915: Properly write lock bw_state when it changes Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 14/15] drm/i915: Fix DBUF bandwidth vs. cdclk handling Ville Syrjala
2022-01-18 9:23 ` [Intel-gfx] [PATCH 15/15] drm/i915: Add "maximum pipe read bandwidth" checks Ville Syrjala
2022-01-18 9:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix bandwith related cdclk calculations Patchwork
2022-01-18 9:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-18 10:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-18 11:32 ` [Intel-gfx] ✗ 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=20220127082106.GC31846@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 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).