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