Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Luca Coelho <luciano.coelho@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/6] drm/i915/wm: convert x/y-tiling bools to an enum
Date: Fri, 19 Sep 2025 11:36:37 +0300	[thread overview]
Message-ID: <aM0WFVMhQwIU-4QI@intel.com> (raw)
In-Reply-To: <20250908073734.1180687-5-luciano.coelho@intel.com>

On Mon, Sep 08, 2025 at 10:35:33AM +0300, Luca Coelho wrote:
> There are currently two booleans to define three tiling modes, which
> is bad practice because it allows representing an invalid mode.  In
> order to simplify this, convert these two booleans into one
> enumeration with three possible tiling modes.
> 
> Additionally, introduce the concept of Y "family" of tiling, which
> groups Y, Yf and 4 tiling, since they're effectively treated in the
> same way in the watermark calculations.  Describe the grouping in the
> enumeration definition.
> 
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
>  drivers/gpu/drm/i915/display/skl_watermark.c | 35 ++++++++++++++------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 0ce3420a919e..dd4bed02c3c0 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -53,9 +53,16 @@ struct intel_dbuf_state {
>  #define intel_atomic_get_new_dbuf_state(state) \
>  	to_intel_dbuf_state(intel_atomic_get_new_global_obj_state(state, &to_intel_display(state)->dbuf.obj))
>  
> +/* Tiling mode groups relevant to WM calculations */
> +enum wm_tiling_mode {
> +	WM_TILING_LINEAR,
> +	WM_TILING_X_TILED,	/* mostly like linear */

The _TILED suffix seems redundant here.

> +	WM_TILING_Y_FAMILY,	/* includes Y, Yf and 4 tiling */

I don't really like the "y family" invention. Doesn't really
unconfuse anything for the reader without going back to have
a look at the comment.

I think it would be better to just spell out each tilimg mode.
So I guess something like "WM_TILING_Y_Yf_4"

> +};
> +
>  /* Stores plane specific WM parameters */
>  struct skl_wm_params {
> -	bool x_tiled, y_tiled;
> +	enum wm_tiling_mode tiling;

That'll now be 4 bytes.

>  	bool rc_surface;
>  	bool is_planar;

and we'll have a two byte hole here.

>  	u32 width;
        u8 cpp;

And there's a 3 byte hole already here after the cpp.
Should group the u8 with the bools to avoid so many holes.

We could also shrink y_min_scanlines to a u8 and
stick it into the last 1 byte hole. That'd shrink the whole
struct by 4 bytes.

dbuf_block_size would also fit in a u16, but doesn't look
like we have any other holes where we could stick it. Hmm,
actually 'width' could probably also be shrunk to be a u16.
So could get rid of another 4 bytes here if we really
wanted to.

But I suppose all that repacking should be a separate patch...

> @@ -618,7 +625,8 @@ static unsigned int skl_wm_latency(struct intel_display *display, int level,
>  	     display->platform.cometlake) && skl_watermark_ipc_enabled(display))
>  		latency += 4;
>  
> -	if (skl_needs_memory_bw_wa(display) && wp && wp->x_tiled)
> +	if (skl_needs_memory_bw_wa(display) &&
> +	    wp && wp->tiling == WM_TILING_X_TILED)
>  		latency += 15;
>  
>  	return latency;
> @@ -1674,9 +1682,14 @@ skl_compute_wm_params(const struct intel_crtc_state *crtc_state,
>  		return -EINVAL;
>  	}
>  
> -	wp->x_tiled = modifier == I915_FORMAT_MOD_X_TILED;
> -	wp->y_tiled = modifier != I915_FORMAT_MOD_X_TILED &&
> -		intel_fb_is_tiled_modifier(modifier);
> +	if (modifier == I915_FORMAT_MOD_X_TILED)
> +		wp->tiling = WM_TILING_X_TILED;
> +	else if (modifier != I915_FORMAT_MOD_X_TILED &&

The modifier check here is redundant with the if-else construct.

> +		 intel_fb_is_tiled_modifier(modifier))
> +		wp->tiling = WM_TILING_Y_FAMILY;
> +	else
> +		wp->tiling = WM_TILING_LINEAR;

In fact we can avoid the entire intel_fb_is_tiled_modifier()
call with something like:

if (mod == LINEAR)
	tiling = LINEAR;
else if (mod == X)
	tiling = X;
else
	tiling = Y_Yf_4;

The wm code always pops up fairly high in cpu profiles, so
anything that makes it lighter is worth considering.

> +
>  	wp->rc_surface = intel_fb_is_ccs_modifier(modifier);
>  	wp->is_planar = intel_format_info_is_yuv_semiplanar(format, modifier);
>  
> @@ -1716,7 +1729,7 @@ skl_compute_wm_params(const struct intel_crtc_state *crtc_state,
>  		wp->y_min_scanlines *= 2;
>  
>  	wp->plane_bytes_per_line = wp->width * wp->cpp;
> -	if (wp->y_tiled) {
> +	if (wp->tiling == WM_TILING_Y_FAMILY) {
>  		interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line *
>  					   wp->y_min_scanlines,
>  					   wp->dbuf_block_size);
> @@ -1732,7 +1745,7 @@ skl_compute_wm_params(const struct intel_crtc_state *crtc_state,
>  		interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
>  					   wp->dbuf_block_size);
>  
> -		if (!wp->x_tiled || DISPLAY_VER(display) >= 10)
> +		if (wp->tiling != WM_TILING_X_TILED || DISPLAY_VER(display) >= 10)
>  			interm_pbpl++;
>  
>  		wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
> @@ -1820,7 +1833,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
>  				 latency,
>  				 wp->plane_blocks_per_line);
>  
> -	if (wp->y_tiled) {
> +	if (wp->tiling == WM_TILING_Y_FAMILY) {
>  		selected_result = max_fixed16(method2, wp->y_tile_minimum);
>  	} else {
>  		if ((wp->cpp * crtc_state->hw.pipe_mode.crtc_htotal /
> @@ -1870,7 +1883,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
>  
>  		/* Display WA #1126: skl,bxt,kbl */
>  		if (level >= 1 && level <= 7) {
> -			if (wp->y_tiled) {
> +			if (wp->tiling == WM_TILING_Y_FAMILY) {
>  				blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
>  				lines += wp->y_min_scanlines;
>  			} else {
> @@ -1889,7 +1902,7 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
>  	}
>  
>  	if (DISPLAY_VER(display) >= 11) {
> -		if (wp->y_tiled) {
> +		if (wp->tiling == WM_TILING_Y_FAMILY) {
>  			int extra_lines;
>  
>  			if (lines % wp->y_min_scanlines == 0)
> @@ -2015,7 +2028,7 @@ static void skl_compute_transition_wm(struct intel_display *display,
>  	 */
>  	wm0_blocks = wm0->blocks - 1;
>  
> -	if (wp->y_tiled) {
> +	if (wp->tiling == WM_TILING_Y_FAMILY) {
>  		trans_y_tile_min =
>  			(u16)mul_round_up_u32_fixed16(2, wp->y_tile_minimum);
>  		blocks = max(wm0_blocks, trans_y_tile_min) + trans_offset;
> -- 
> 2.50.1

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2025-09-19  8:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-08  7:35 [PATCH 0/6] drm/i915/wm: some clean-ups and a bit of refactoring Luca Coelho
2025-09-08  7:35 ` [PATCH 1/6] drm/i915/wm: clarify watermark ops with comments Luca Coelho
2025-09-16  8:52   ` Govindapillai, Vinod
2025-09-22 10:26     ` Luca Coelho
2025-09-08  7:35 ` [PATCH 2/6] drm/i915/wm: move intel_sagv_init() to avoid forward declaration Luca Coelho
2025-09-16  8:53   ` Govindapillai, Vinod
2025-09-08  7:35 ` [PATCH 3/6] drm/i915/wm: remove stale FIXME in skl_needs_memory_bw_wa() Luca Coelho
2025-09-16  9:21   ` Govindapillai, Vinod
2025-09-08  7:35 ` [PATCH 4/6] drm/i915/wm: convert x/y-tiling bools to an enum Luca Coelho
2025-09-08 12:43   ` Gustavo Sousa
2025-09-08 12:53     ` Luca Coelho
2025-09-19  8:36   ` Ville Syrjälä [this message]
2025-09-22 12:38     ` Luca Coelho
2025-09-22 12:48       ` Ville Syrjälä
2025-09-08  7:35 ` [PATCH 5/6] drm/i915/wm: convert tiling mode check in slk_compute_plane_wm() to a switch-case Luca Coelho
2025-09-08 12:51   ` Gustavo Sousa
2025-09-08 12:57     ` Luca Coelho
2025-09-08  7:35 ` [PATCH 6/6] drm/i915/wm: move method selection and calculation to a separate function Luca Coelho
2025-09-19 18:00   ` Ville Syrjälä
2025-09-29  7:21     ` Luca Coelho
2025-09-08 17:20 ` ✓ i915.CI.BAT: success for drm/i915/wm: some clean-ups and a bit of refactoring Patchwork
2025-09-09  2:47 ` ✗ i915.CI.Full: 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=aM0WFVMhQwIU-4QI@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=luciano.coelho@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