Message ID | 20210923084858.5480-1-stanislav.lisovskiy@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | drm/i915: Tile F plane format support | expand |
On Thu, 23 Sep 2021, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote: > @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > return false; > break; > + case I915_FORMAT_MOD_F_TILED: > + if (!HAS_FTILE(dev_priv)) > + return false; > + fallthrough; > default: > return false; > } Seems odd. BR, Jani.
On Thu, Sep 23, 2021 at 01:28:21PM +0300, Jani Nikula wrote: > On Thu, 23 Sep 2021, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote: > > @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > > return false; > > break; > > + case I915_FORMAT_MOD_F_TILED: > > + if (!HAS_FTILE(dev_priv)) > > + return false; > > + fallthrough; > > default: > > return false; > > } > > Seems odd. I agree, however this wasn't even added by me. This patch got changed in ridiculous ways since last time, I ever touched it. Currently we have it internally exactly same way(wondering why) Unfortunately didn't pay attention to this, was assuming that if its r-bed and pushed - can trust it. Stan > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center
On Thu, Sep 23, 2021 at 01:44:11PM +0300, Lisovskiy, Stanislav wrote: > On Thu, Sep 23, 2021 at 01:28:21PM +0300, Jani Nikula wrote: > > On Thu, 23 Sep 2021, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote: > > > @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > > > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > > > return false; > > > break; > > > + case I915_FORMAT_MOD_F_TILED: > > > + if (!HAS_FTILE(dev_priv)) > > > + return false; > > > + fallthrough; > > > default: > > > return false; > > > } > > > > Seems odd. > > I agree, however this wasn't even added by me. > This patch got changed in ridiculous ways since last time, > I ever touched it. > Currently we have it internally exactly same way(wondering why) > Unfortunately didn't pay attention to this, was assuming > that if its r-bed and pushed - can trust it. Actually checked - seems to be result of wrong merge conflict resolution by me. It was initially that way: - case DRM_FORMAT_MOD_LINEAR: - case I915_FORMAT_MOD_X_TILED: - break; case I915_FORMAT_MOD_Y_TILED: if (IS_DG2(dev_priv)) return false; @@ -1928,6 +1934,13 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, if (IS_DG2(dev_priv)) return false; break; + case I915_FORMAT_MOD_F_TILED: + if (!HAS_FTILE(dev_priv)) + return false; + fallthrough; + case DRM_FORMAT_MOD_LINEAR: + case I915_FORMAT_MOD_X_TILED: + break; So my bad here. Need to put this back. Stan > > Stan > > > > > > BR, > > Jani. > > > > > > -- > > Jani Nikula, Intel Open Source Graphics Center
On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > TileF(Tile4 in bspec) format is 4K tile organized into > 64B subtiles with same basic shape as for legacy TileY > which will be supported by Display13. Why we still haven't done the F->tile64 rename? This is the last chance to fix this before we bake this into the uapi and are stuck with a name that doesn't match the spec and will just confuse everyone. > > Cc: Matt Roper <matthew.d.roper@intel.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com> > Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> > --- > drivers/gpu/drm/i915/display/intel_display.c | 3 ++ > drivers/gpu/drm/i915/display/intel_fb.c | 12 +++++- > drivers/gpu/drm/i915/display/intel_fbc.c | 1 + > .../drm/i915/display/skl_universal_plane.c | 37 ++++++++++++++----- > drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 +++- > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 1 + > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_pci.c | 1 + > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_device_info.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 1 + > include/uapi/drm/drm_fourcc.h | 8 ++++ > include/uapi/drm/i915_drm.h | 3 +- > 15 files changed, 71 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index 23b1e0ccc72d..7564b8812c5b 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -1335,6 +1335,7 @@ initial_plane_vma(struct drm_i915_private *i915, > break; > case I915_TILING_X: > case I915_TILING_Y: > + case I915_TILING_F: > obj->tiling_and_stride = > plane_config->fb->base.pitches[0] | > plane_config->tiling; I don't think tile64 supports fences so this shouldn't be here. > @@ -1376,6 +1377,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, > case DRM_FORMAT_MOD_LINEAR: > case I915_FORMAT_MOD_X_TILED: > case I915_FORMAT_MOD_Y_TILED: > + case I915_FORMAT_MOD_F_TILED: > break; > default: > drm_dbg(&dev_priv->drm, > @@ -9282,6 +9284,7 @@ static int intel_atomic_check_async(struct intel_atomic_state *state) > case I915_FORMAT_MOD_X_TILED: > case I915_FORMAT_MOD_Y_TILED: > case I915_FORMAT_MOD_Yf_TILED: > + case I915_FORMAT_MOD_F_TILED: > break; > default: > drm_dbg_kms(&i915->drm, > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c > index e4b8602ec0cd..d88070406098 100644 > --- a/drivers/gpu/drm/i915/display/intel_fb.c > +++ b/drivers/gpu/drm/i915/display/intel_fb.c > @@ -101,6 +101,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, int color_plane) > return 128; > else > return 512; > + case I915_FORMAT_MOD_F_TILED: > + /* > + * Each 4K tile consists of 64B(8*8) subtiles, with > + * same shape as Y Tile(i.e 4*16B OWords) > + */ > + return 128; > case I915_FORMAT_MOD_Y_TILED_CCS: > if (is_ccs_plane(fb, color_plane)) > return 128; > @@ -185,6 +191,8 @@ static unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier) > switch (fb_modifier) { > case I915_FORMAT_MOD_X_TILED: > return I915_TILING_X; > + case I915_FORMAT_MOD_F_TILED: > + return I915_TILING_F; If there are no tile64 fences I915_TILING_F shouldn't even exist. > case I915_FORMAT_MOD_Y_TILED: > case I915_FORMAT_MOD_Y_TILED_CCS: > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS: > @@ -264,6 +272,7 @@ unsigned int intel_surf_alignment(const struct drm_framebuffer *fb, > case I915_FORMAT_MOD_Y_TILED_CCS: > case I915_FORMAT_MOD_Yf_TILED_CCS: > case I915_FORMAT_MOD_Y_TILED: > + case I915_FORMAT_MOD_F_TILED: > case I915_FORMAT_MOD_Yf_TILED: > return 1 * 1024 * 1024; > default: > @@ -1282,7 +1291,8 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb, > } else { > if (tiling == I915_TILING_X) { > mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED; > - } else if (tiling == I915_TILING_Y) { > + } else if ((tiling == I915_TILING_Y) || > + (tiling == I915_TILING_F)) { This here is yet another fence related thing. Not relevant for tile64. > drm_dbg_kms(&dev_priv->drm, > "No Y tiling for legacy addfb\n"); > goto err; > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c > index b1c1a23c36be..015005cf2ba1 100644 > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > @@ -679,6 +679,7 @@ static bool tiling_is_valid(struct drm_i915_private *dev_priv, > switch (modifier) { > case DRM_FORMAT_MOD_LINEAR: > case I915_FORMAT_MOD_Y_TILED: > + case I915_FORMAT_MOD_F_TILED: > return DISPLAY_VER(dev_priv) >= 9; > case I915_FORMAT_MOD_X_TILED: > return true; > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c > index 724e7b04f3b6..09c00fc099f2 100644 > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c > @@ -206,6 +206,13 @@ static const u64 adlp_step_a_plane_format_modifiers[] = { > DRM_FORMAT_MOD_INVALID > }; > > +static const u64 dg2_plane_format_modifiers[] = { > + I915_FORMAT_MOD_X_TILED, > + I915_FORMAT_MOD_F_TILED, > + DRM_FORMAT_MOD_LINEAR, > + DRM_FORMAT_MOD_INVALID > +}; > + > int skl_format_to_fourcc(int format, bool rgb_order, bool alpha) > { > switch (format) { > @@ -793,6 +800,8 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier) > return PLANE_CTL_TILED_X; > case I915_FORMAT_MOD_Y_TILED: > return PLANE_CTL_TILED_Y; > + case I915_FORMAT_MOD_F_TILED: > + return PLANE_CTL_TILED_F; > case I915_FORMAT_MOD_Y_TILED_CCS: > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC: > return PLANE_CTL_TILED_Y | PLANE_CTL_RENDER_DECOMPRESSION_ENABLE; > @@ -1240,6 +1249,7 @@ static int skl_plane_check_fb(const struct intel_crtc_state *crtc_state, > fb->modifier == I915_FORMAT_MOD_Yf_TILED || > fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || > fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS || > + fb->modifier == I915_FORMAT_MOD_F_TILED || > fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS || > fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS || > fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC)) { Seems like it would be much simpler to swap this around to check for linear/X instead (+ adjust the debug message to match). > @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > return false; > break; > + case I915_FORMAT_MOD_F_TILED: > + if (!HAS_FTILE(dev_priv)) > + return false; > + fallthrough; > default: > return false; > } > @@ -1981,9 +1995,7 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > case DRM_FORMAT_Y216: > case DRM_FORMAT_XVYU12_16161616: > case DRM_FORMAT_XVYU16161616: > - if (modifier == DRM_FORMAT_MOD_LINEAR || > - modifier == I915_FORMAT_MOD_X_TILED || > - modifier == I915_FORMAT_MOD_Y_TILED) > + if (!is_ccs_modifier(modifier)) > return true; > fallthrough; > default: > @@ -1994,8 +2006,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > static const u64 *gen12_get_plane_modifiers(struct drm_i915_private *dev_priv, > enum plane_id plane_id) > { > + if (HAS_FTILE(dev_priv)) > + return dg2_plane_format_modifiers; > /* Wa_22011186057 */ > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > + else if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > return adlp_step_a_plane_format_modifiers; > else if (gen12_plane_supports_mc_ccs(dev_priv, plane_id)) > return gen12_plane_format_modifiers_mc_ccs; > @@ -2265,11 +2279,16 @@ skl_get_initial_plane_config(struct intel_crtc *crtc, > else > fb->modifier = I915_FORMAT_MOD_Y_TILED; > break; > - case PLANE_CTL_TILED_YF: > - if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) > - fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS; > - else > - fb->modifier = I915_FORMAT_MOD_Yf_TILED; > + case PLANE_CTL_TILED_YF: /* aka PLANE_CTL_TILED_F on XE_LPD+ */ > + if (DISPLAY_VER(dev_priv) >= 13) { > + plane_config->tiling = I915_TILING_F; Another fence related thing. > + fb->modifier = I915_FORMAT_MOD_F_TILED; > + } else { > + if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) > + fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS; > + else > + fb->modifier = I915_FORMAT_MOD_Yf_TILED; > + } > break; > default: > MISSING_CASE(tiling); > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h > index 3043fcbd31bd..d96bcab1f3e3 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h > @@ -326,7 +326,13 @@ static inline unsigned int > i915_gem_tile_height(unsigned int tiling) > { > GEM_BUG_ON(!tiling); > - return tiling == I915_TILING_Y ? 32 : 8; > + switch (tiling) { > + case I915_TILING_Y: > + case I915_TILING_F: Starting with this... > + return 32; > + default: > + return 8; > + } > } > > static inline unsigned int > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c > index ef4d0f7dc118..520b8fb7c870 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c > @@ -145,7 +145,8 @@ i915_tiling_ok(struct drm_i915_gem_object *obj, > } > > if (GRAPHICS_VER(i915) == 2 || > - (tiling == I915_TILING_Y && HAS_128_BYTE_Y_TILING(i915))) > + (tiling == I915_TILING_Y && HAS_128_BYTE_Y_TILING(i915)) || > + tiling == I915_TILING_F) > tile_width = 128; > else > tile_width = 512; > @@ -438,6 +439,7 @@ i915_gem_get_tiling_ioctl(struct drm_device *dev, void *data, > args->swizzle_mode = dev_priv->ggtt.bit_6_swizzle_x; > break; > case I915_TILING_Y: > + case I915_TILING_F: > args->swizzle_mode = dev_priv->ggtt.bit_6_swizzle_y; > break; > default: > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > index f8948de72036..f748bcbf46c3 100644 > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > @@ -77,7 +77,8 @@ static void i965_write_fence_reg(struct i915_fence_reg *fence) > val <<= 32; > val |= fence->start; > val |= (u64)((stride / 128) - 1) << fence_pitch_shift; > - if (fence->tiling == I915_TILING_Y) > + if (fence->tiling == I915_TILING_Y || > + fence->tiling == I915_TILING_F) > val |= BIT(I965_FENCE_TILING_Y_SHIFT); > val |= I965_FENCE_REG_VALID; > } > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > index fdbd46ff59e0..f43968fc16fe 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -82,6 +82,7 @@ static char get_tiling_flag(struct drm_i915_gem_object *obj) > case I915_TILING_NONE: return ' '; > case I915_TILING_X: return 'X'; > case I915_TILING_Y: return 'Y'; > + case I915_TILING_F: return 'F'; > } ... ending here is all about fences. So should be dropped. > } > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index cc355aa05dbf..dafa8b1f365a 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1586,6 +1586,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7) > > #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) > +#define HAS_FTILE(dev_priv) (INTEL_INFO(dev_priv)->has_ftile) > #define HAS_SNOOP(dev_priv) (INTEL_INFO(dev_priv)->has_snoop) > #define HAS_EDRAM(dev_priv) ((dev_priv)->edram_size_mb) > #define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6) > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index d4a6a9dcf182..81963d5876ef 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -970,6 +970,7 @@ static const struct intel_device_info adl_p_info = { > .display.has_cdclk_crawl = 1, > .display.has_modular_fia = 1, > .display.has_psr_hw_tracking = 0, > + .has_ftile = 1, \ > .platform_engine_mask = > BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2), > .ppgtt_size = 48, > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index cad84c3b864b..55c8a47ba047 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -7192,6 +7192,7 @@ enum { > #define PLANE_CTL_TILED_X (1 << 10) > #define PLANE_CTL_TILED_Y (4 << 10) > #define PLANE_CTL_TILED_YF (5 << 10) > +#define PLANE_CTL_TILED_F (5 << 10) > #define PLANE_CTL_ASYNC_FLIP (1 << 9) > #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8) > #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */ > diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h > index d328bb95c49b..76f783c10f81 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.h > +++ b/drivers/gpu/drm/i915/intel_device_info.h > @@ -125,6 +125,7 @@ enum intel_ppgtt_type { > func(has_64bit_reloc); \ > func(gpu_reset_clobbers_display); \ > func(has_reset_engine); \ > + func(has_ftile); \ > func(has_global_mocs); \ > func(has_gt_uc); \ > func(has_l3_dpf); \ > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 74fd6aa7afc7..6e68f259c4c1 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -5362,6 +5362,7 @@ skl_compute_wm_params(const struct intel_crtc_state *crtc_state, > } > > wp->y_tiled = modifier == I915_FORMAT_MOD_Y_TILED || > + modifier == I915_FORMAT_MOD_F_TILED || > modifier == I915_FORMAT_MOD_Yf_TILED || > modifier == I915_FORMAT_MOD_Y_TILED_CCS || > modifier == I915_FORMAT_MOD_Yf_TILED_CCS; > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 45a914850be0..a7d3027b5bdc 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -558,6 +558,14 @@ extern "C" { > * pitch is required to be a multiple of 4 tile widths. > */ > #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8) > +/* > + * Intel F-tiling(aka Tile4) layout > + * > + * This is a tiled layout using 4Kb tiles in row-major layout. > + * Within the tile pixels are laid out in 64 byte units / sub-tiles in OWORD > + * (16 bytes) chunks column-major.. > + */ > +#define I915_FORMAT_MOD_F_TILED fourcc_mod_code(INTEL, 10) > > /* > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index bde5860b3686..d7dc421c6134 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > #define I915_TILING_NONE 0 > #define I915_TILING_X 1 > #define I915_TILING_Y 2 > -#define I915_TILING_LAST I915_TILING_Y > +#define I915_TILING_F 3 > +#define I915_TILING_LAST I915_TILING_F fences... > > #define I915_BIT_6_SWIZZLE_NONE 0 > #define I915_BIT_6_SWIZZLE_9 1 > -- > 2.24.1.485.gad05a3d8e5
On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > TileF(Tile4 in bspec) format is 4K tile organized into > > 64B subtiles with same basic shape as for legacy TileY > > which will be supported by Display13. > > Why we still haven't done the F->tile64 rename? > This is the last chance to fix this before we bake > this into the uapi and are stuck with a name that doesn't > match the spec and will just confuse everyone. Probably should be Tile4 then, currently we have Tile4 and Tile64 in BSpec and that one was about Tile4. > > > > > Cc: Matt Roper <matthew.d.roper@intel.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> > > Signed-off-by: Matt Roper <matthew.d.roper@intel.com> > > Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 3 ++ > > drivers/gpu/drm/i915/display/intel_fb.c | 12 +++++- > > drivers/gpu/drm/i915/display/intel_fbc.c | 1 + > > .../drm/i915/display/skl_universal_plane.c | 37 ++++++++++++++----- > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 +++- > > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 4 +- > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 3 +- > > drivers/gpu/drm/i915/i915_debugfs.c | 1 + > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > drivers/gpu/drm/i915/i915_pci.c | 1 + > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > drivers/gpu/drm/i915/intel_device_info.h | 1 + > > drivers/gpu/drm/i915/intel_pm.c | 1 + > > include/uapi/drm/drm_fourcc.h | 8 ++++ > > include/uapi/drm/i915_drm.h | 3 +- > > 15 files changed, 71 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > > index 23b1e0ccc72d..7564b8812c5b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -1335,6 +1335,7 @@ initial_plane_vma(struct drm_i915_private *i915, > > break; > > case I915_TILING_X: > > case I915_TILING_Y: > > + case I915_TILING_F: > > obj->tiling_and_stride = > > plane_config->fb->base.pitches[0] | > > plane_config->tiling; > > I don't think tile64 supports fences so this shouldn't be here. Didn't find anything specific to Tile4, would prefer to recheck before removing, in order to avoid unexpected breakages. Stan > > > @@ -1376,6 +1377,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, > > case DRM_FORMAT_MOD_LINEAR: > > case I915_FORMAT_MOD_X_TILED: > > case I915_FORMAT_MOD_Y_TILED: > > + case I915_FORMAT_MOD_F_TILED: > > break; > > default: > > drm_dbg(&dev_priv->drm, > > @@ -9282,6 +9284,7 @@ static int intel_atomic_check_async(struct intel_atomic_state *state) > > case I915_FORMAT_MOD_X_TILED: > > case I915_FORMAT_MOD_Y_TILED: > > case I915_FORMAT_MOD_Yf_TILED: > > + case I915_FORMAT_MOD_F_TILED: > > break; > > default: > > drm_dbg_kms(&i915->drm, > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c > > index e4b8602ec0cd..d88070406098 100644 > > --- a/drivers/gpu/drm/i915/display/intel_fb.c > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c > > @@ -101,6 +101,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, int color_plane) > > return 128; > > else > > return 512; > > + case I915_FORMAT_MOD_F_TILED: > > + /* > > + * Each 4K tile consists of 64B(8*8) subtiles, with > > + * same shape as Y Tile(i.e 4*16B OWords) > > + */ > > + return 128; > > case I915_FORMAT_MOD_Y_TILED_CCS: > > if (is_ccs_plane(fb, color_plane)) > > return 128; > > @@ -185,6 +191,8 @@ static unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier) > > switch (fb_modifier) { > > case I915_FORMAT_MOD_X_TILED: > > return I915_TILING_X; > > + case I915_FORMAT_MOD_F_TILED: > > + return I915_TILING_F; > > If there are no tile64 fences I915_TILING_F shouldn't even exist. > > > case I915_FORMAT_MOD_Y_TILED: > > case I915_FORMAT_MOD_Y_TILED_CCS: > > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS: > > @@ -264,6 +272,7 @@ unsigned int intel_surf_alignment(const struct drm_framebuffer *fb, > > case I915_FORMAT_MOD_Y_TILED_CCS: > > case I915_FORMAT_MOD_Yf_TILED_CCS: > > case I915_FORMAT_MOD_Y_TILED: > > + case I915_FORMAT_MOD_F_TILED: > > case I915_FORMAT_MOD_Yf_TILED: > > return 1 * 1024 * 1024; > > default: > > @@ -1282,7 +1291,8 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb, > > } else { > > if (tiling == I915_TILING_X) { > > mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED; > > - } else if (tiling == I915_TILING_Y) { > > + } else if ((tiling == I915_TILING_Y) || > > + (tiling == I915_TILING_F)) { > > This here is yet another fence related thing. Not relevant for tile64. > > > drm_dbg_kms(&dev_priv->drm, > > "No Y tiling for legacy addfb\n"); > > goto err; > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c > > index b1c1a23c36be..015005cf2ba1 100644 > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > > @@ -679,6 +679,7 @@ static bool tiling_is_valid(struct drm_i915_private *dev_priv, > > switch (modifier) { > > case DRM_FORMAT_MOD_LINEAR: > > case I915_FORMAT_MOD_Y_TILED: > > + case I915_FORMAT_MOD_F_TILED: > > return DISPLAY_VER(dev_priv) >= 9; > > case I915_FORMAT_MOD_X_TILED: > > return true; > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c > > index 724e7b04f3b6..09c00fc099f2 100644 > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c > > @@ -206,6 +206,13 @@ static const u64 adlp_step_a_plane_format_modifiers[] = { > > DRM_FORMAT_MOD_INVALID > > }; > > > > +static const u64 dg2_plane_format_modifiers[] = { > > + I915_FORMAT_MOD_X_TILED, > > + I915_FORMAT_MOD_F_TILED, > > + DRM_FORMAT_MOD_LINEAR, > > + DRM_FORMAT_MOD_INVALID > > +}; > > + > > int skl_format_to_fourcc(int format, bool rgb_order, bool alpha) > > { > > switch (format) { > > @@ -793,6 +800,8 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier) > > return PLANE_CTL_TILED_X; > > case I915_FORMAT_MOD_Y_TILED: > > return PLANE_CTL_TILED_Y; > > + case I915_FORMAT_MOD_F_TILED: > > + return PLANE_CTL_TILED_F; > > case I915_FORMAT_MOD_Y_TILED_CCS: > > case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC: > > return PLANE_CTL_TILED_Y | PLANE_CTL_RENDER_DECOMPRESSION_ENABLE; > > @@ -1240,6 +1249,7 @@ static int skl_plane_check_fb(const struct intel_crtc_state *crtc_state, > > fb->modifier == I915_FORMAT_MOD_Yf_TILED || > > fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || > > fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS || > > + fb->modifier == I915_FORMAT_MOD_F_TILED || > > fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS || > > fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS || > > fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC)) { > > Seems like it would be much simpler to swap this around > to check for linear/X instead (+ adjust the debug message > to match). > > > @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > > return false; > > break; > > + case I915_FORMAT_MOD_F_TILED: > > + if (!HAS_FTILE(dev_priv)) > > + return false; > > + fallthrough; > > default: > > return false; > > } > > @@ -1981,9 +1995,7 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > > case DRM_FORMAT_Y216: > > case DRM_FORMAT_XVYU12_16161616: > > case DRM_FORMAT_XVYU16161616: > > - if (modifier == DRM_FORMAT_MOD_LINEAR || > > - modifier == I915_FORMAT_MOD_X_TILED || > > - modifier == I915_FORMAT_MOD_Y_TILED) > > + if (!is_ccs_modifier(modifier)) > > return true; > > fallthrough; > > default: > > @@ -1994,8 +2006,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, > > static const u64 *gen12_get_plane_modifiers(struct drm_i915_private *dev_priv, > > enum plane_id plane_id) > > { > > + if (HAS_FTILE(dev_priv)) > > + return dg2_plane_format_modifiers; > > /* Wa_22011186057 */ > > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > > + else if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > > return adlp_step_a_plane_format_modifiers; > > else if (gen12_plane_supports_mc_ccs(dev_priv, plane_id)) > > return gen12_plane_format_modifiers_mc_ccs; > > @@ -2265,11 +2279,16 @@ skl_get_initial_plane_config(struct intel_crtc *crtc, > > else > > fb->modifier = I915_FORMAT_MOD_Y_TILED; > > break; > > - case PLANE_CTL_TILED_YF: > > - if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) > > - fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS; > > - else > > - fb->modifier = I915_FORMAT_MOD_Yf_TILED; > > + case PLANE_CTL_TILED_YF: /* aka PLANE_CTL_TILED_F on XE_LPD+ */ > > + if (DISPLAY_VER(dev_priv) >= 13) { > > + plane_config->tiling = I915_TILING_F; > > Another fence related thing. > > > + fb->modifier = I915_FORMAT_MOD_F_TILED; > > + } else { > > + if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) > > + fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS; > > + else > > + fb->modifier = I915_FORMAT_MOD_Yf_TILED; > > + } > > break; > > default: > > MISSING_CASE(tiling); > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h > > index 3043fcbd31bd..d96bcab1f3e3 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h > > @@ -326,7 +326,13 @@ static inline unsigned int > > i915_gem_tile_height(unsigned int tiling) > > { > > GEM_BUG_ON(!tiling); > > - return tiling == I915_TILING_Y ? 32 : 8; > > + switch (tiling) { > > + case I915_TILING_Y: > > + case I915_TILING_F: > > Starting with this... > > > + return 32; > > + default: > > + return 8; > > + } > > } > > > > static inline unsigned int > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c > > index ef4d0f7dc118..520b8fb7c870 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c > > @@ -145,7 +145,8 @@ i915_tiling_ok(struct drm_i915_gem_object *obj, > > } > > > > if (GRAPHICS_VER(i915) == 2 || > > - (tiling == I915_TILING_Y && HAS_128_BYTE_Y_TILING(i915))) > > + (tiling == I915_TILING_Y && HAS_128_BYTE_Y_TILING(i915)) || > > + tiling == I915_TILING_F) > > tile_width = 128; > > else > > tile_width = 512; > > @@ -438,6 +439,7 @@ i915_gem_get_tiling_ioctl(struct drm_device *dev, void *data, > > args->swizzle_mode = dev_priv->ggtt.bit_6_swizzle_x; > > break; > > case I915_TILING_Y: > > + case I915_TILING_F: > > args->swizzle_mode = dev_priv->ggtt.bit_6_swizzle_y; > > break; > > default: > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > > index f8948de72036..f748bcbf46c3 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c > > @@ -77,7 +77,8 @@ static void i965_write_fence_reg(struct i915_fence_reg *fence) > > val <<= 32; > > val |= fence->start; > > val |= (u64)((stride / 128) - 1) << fence_pitch_shift; > > - if (fence->tiling == I915_TILING_Y) > > + if (fence->tiling == I915_TILING_Y || > > + fence->tiling == I915_TILING_F) > > val |= BIT(I965_FENCE_TILING_Y_SHIFT); > > val |= I965_FENCE_REG_VALID; > > } > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > > index fdbd46ff59e0..f43968fc16fe 100644 > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > @@ -82,6 +82,7 @@ static char get_tiling_flag(struct drm_i915_gem_object *obj) > > case I915_TILING_NONE: return ' '; > > case I915_TILING_X: return 'X'; > > case I915_TILING_Y: return 'Y'; > > + case I915_TILING_F: return 'F'; > > } > > ... ending here is all about fences. So should be dropped. > > > } > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > > index cc355aa05dbf..dafa8b1f365a 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -1586,6 +1586,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > > #define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7) > > > > #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) > > +#define HAS_FTILE(dev_priv) (INTEL_INFO(dev_priv)->has_ftile) > > #define HAS_SNOOP(dev_priv) (INTEL_INFO(dev_priv)->has_snoop) > > #define HAS_EDRAM(dev_priv) ((dev_priv)->edram_size_mb) > > #define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6) > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > > index d4a6a9dcf182..81963d5876ef 100644 > > --- a/drivers/gpu/drm/i915/i915_pci.c > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > @@ -970,6 +970,7 @@ static const struct intel_device_info adl_p_info = { > > .display.has_cdclk_crawl = 1, > > .display.has_modular_fia = 1, > > .display.has_psr_hw_tracking = 0, > > + .has_ftile = 1, \ > > .platform_engine_mask = > > BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2), > > .ppgtt_size = 48, > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > > index cad84c3b864b..55c8a47ba047 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -7192,6 +7192,7 @@ enum { > > #define PLANE_CTL_TILED_X (1 << 10) > > #define PLANE_CTL_TILED_Y (4 << 10) > > #define PLANE_CTL_TILED_YF (5 << 10) > > +#define PLANE_CTL_TILED_F (5 << 10) > > #define PLANE_CTL_ASYNC_FLIP (1 << 9) > > #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8) > > #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */ > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h > > index d328bb95c49b..76f783c10f81 100644 > > --- a/drivers/gpu/drm/i915/intel_device_info.h > > +++ b/drivers/gpu/drm/i915/intel_device_info.h > > @@ -125,6 +125,7 @@ enum intel_ppgtt_type { > > func(has_64bit_reloc); \ > > func(gpu_reset_clobbers_display); \ > > func(has_reset_engine); \ > > + func(has_ftile); \ > > func(has_global_mocs); \ > > func(has_gt_uc); \ > > func(has_l3_dpf); \ > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > > index 74fd6aa7afc7..6e68f259c4c1 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -5362,6 +5362,7 @@ skl_compute_wm_params(const struct intel_crtc_state *crtc_state, > > } > > > > wp->y_tiled = modifier == I915_FORMAT_MOD_Y_TILED || > > + modifier == I915_FORMAT_MOD_F_TILED || > > modifier == I915_FORMAT_MOD_Yf_TILED || > > modifier == I915_FORMAT_MOD_Y_TILED_CCS || > > modifier == I915_FORMAT_MOD_Yf_TILED_CCS; > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > > index 45a914850be0..a7d3027b5bdc 100644 > > --- a/include/uapi/drm/drm_fourcc.h > > +++ b/include/uapi/drm/drm_fourcc.h > > @@ -558,6 +558,14 @@ extern "C" { > > * pitch is required to be a multiple of 4 tile widths. > > */ > > #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8) > > +/* > > + * Intel F-tiling(aka Tile4) layout > > + * > > + * This is a tiled layout using 4Kb tiles in row-major layout. > > + * Within the tile pixels are laid out in 64 byte units / sub-tiles in OWORD > > + * (16 bytes) chunks column-major.. > > + */ > > +#define I915_FORMAT_MOD_F_TILED fourcc_mod_code(INTEL, 10) > > > > /* > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > index bde5860b3686..d7dc421c6134 100644 > > --- a/include/uapi/drm/i915_drm.h > > +++ b/include/uapi/drm/i915_drm.h > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > #define I915_TILING_NONE 0 > > #define I915_TILING_X 1 > > #define I915_TILING_Y 2 > > -#define I915_TILING_LAST I915_TILING_Y > > +#define I915_TILING_F 3 > > +#define I915_TILING_LAST I915_TILING_F > > fences... > > > > > #define I915_BIT_6_SWIZZLE_NONE 0 > > #define I915_BIT_6_SWIZZLE_9 1 > > -- > > 2.24.1.485.gad05a3d8e5 > > -- > Ville Syrjälä > Intel
On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > TileF(Tile4 in bspec) format is 4K tile organized into > > 64B subtiles with same basic shape as for legacy TileY > > which will be supported by Display13. > > Why we still haven't done the F->tile64 rename? > > This is the last chance to fix this before we bake > this into the uapi and are stuck with a name that doesn't > match the spec and will just confuse everyone. I think you're confusing the formats here. The bspec uses both terms "TileF" and "Tile4" for the same format in different places. There's a completely different format that's referred to as both "TileS" and "Tile64" in the bspec that we don't use at the moment. So tile64 wouldn't be a correct rename, but tile4 could be. In general Tile4 is much more common in the bspec than TileF is (TileF terminology is mostly found in the media sections). And bspec 44917 is the most authoritative bspec page on the subject, and it refers to it as Tile4, so I agree that switching over "Tile4" would probably be a good move. > > > ... > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > index bde5860b3686..d7dc421c6134 100644 > > --- a/include/uapi/drm/i915_drm.h > > +++ b/include/uapi/drm/i915_drm.h > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > #define I915_TILING_NONE 0 > > #define I915_TILING_X 1 > > #define I915_TILING_Y 2 > > -#define I915_TILING_LAST I915_TILING_Y > > +#define I915_TILING_F 3 > > +#define I915_TILING_LAST I915_TILING_F > > fences... Recognizing TileF/Tile4 separately from TileY is important to code outside of display as well. There are blitter instructions that require different settings for TileY vs Tile4/F so if we drop the tracking of this as a unique tiling type, it will break the blitting/copying and some of the upcoming local memory support for Xe_HP-based platforms. Matt > > > > > #define I915_BIT_6_SWIZZLE_NONE 0 > > #define I915_BIT_6_SWIZZLE_9 1 > > -- > > 2.24.1.485.gad05a3d8e5 > > -- > Ville Syrjälä > Intel
On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > 64B subtiles with same basic shape as for legacy TileY > > > which will be supported by Display13. > > > > Why we still haven't done the F->tile64 rename? > > > > This is the last chance to fix this before we bake > > this into the uapi and are stuck with a name that doesn't > > match the spec and will just confuse everyone. > > I think you're confusing the formats here. The bspec uses both terms > "TileF" and "Tile4" for the same format in different places. There's a > completely different format that's referred to as both "TileS" and > "Tile64" in the bspec that we don't use at the moment. So tile64 > wouldn't be a correct rename, but tile4 could be. Right, tile64 is the macro tile variant I think. So like Ys which we never bothered implementing, so I guess we''l not bother with tile64 either. > > In general Tile4 is much more common in the bspec than TileF is (TileF > terminology is mostly found in the media sections). And bspec 44917 is > the most authoritative bspec page on the subject, and it refers to it as > Tile4, so I agree that switching over "Tile4" would probably be a good > move. > > > > > > > ... > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > index bde5860b3686..d7dc421c6134 100644 > > > --- a/include/uapi/drm/i915_drm.h > > > +++ b/include/uapi/drm/i915_drm.h > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > #define I915_TILING_NONE 0 > > > #define I915_TILING_X 1 > > > #define I915_TILING_Y 2 > > > -#define I915_TILING_LAST I915_TILING_Y > > > +#define I915_TILING_F 3 > > > +#define I915_TILING_LAST I915_TILING_F > > > > fences... > > Recognizing TileF/Tile4 separately from TileY is important to code > outside of display as well. There are blitter instructions that require > different settings for TileY vs Tile4/F so if we drop the tracking of > this as a unique tiling type, it will break the blitting/copying and > some of the upcoming local memory support for Xe_HP-based platforms. These are uapi definitions for set_tiling(). You are not meant to add anything there. Just like we didn't add anything for Yf.
On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote: > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > > 64B subtiles with same basic shape as for legacy TileY > > > > which will be supported by Display13. > > > > > > Why we still haven't done the F->tile64 rename? > > > > > > This is the last chance to fix this before we bake > > > this into the uapi and are stuck with a name that doesn't > > > match the spec and will just confuse everyone. > > > > I think you're confusing the formats here. The bspec uses both terms > > "TileF" and "Tile4" for the same format in different places. There's a > > completely different format that's referred to as both "TileS" and > > "Tile64" in the bspec that we don't use at the moment. So tile64 > > wouldn't be a correct rename, but tile4 could be. > > Right, tile64 is the macro tile variant I think. So like Ys > which we never bothered implementing, so I guess we''l not bother > with tile64 either. > > > > > In general Tile4 is much more common in the bspec than TileF is (TileF > > terminology is mostly found in the media sections). And bspec 44917 is > > the most authoritative bspec page on the subject, and it refers to it as > > Tile4, so I agree that switching over "Tile4" would probably be a good > > move. > > > > > > > > > > > ... > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > > index bde5860b3686..d7dc421c6134 100644 > > > > --- a/include/uapi/drm/i915_drm.h > > > > +++ b/include/uapi/drm/i915_drm.h > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > > #define I915_TILING_NONE 0 > > > > #define I915_TILING_X 1 > > > > #define I915_TILING_Y 2 > > > > -#define I915_TILING_LAST I915_TILING_Y > > > > +#define I915_TILING_F 3 > > > > +#define I915_TILING_LAST I915_TILING_F > > > > > > fences... > > > > Recognizing TileF/Tile4 separately from TileY is important to code > > outside of display as well. There are blitter instructions that require > > different settings for TileY vs Tile4/F so if we drop the tracking of > > this as a unique tiling type, it will break the blitting/copying and > > some of the upcoming local memory support for Xe_HP-based platforms. > > These are uapi definitions for set_tiling(). You are not meant to add > anything there. Just like we didn't add anything for Yf. Yeah, I think that's the real problem --- we define some values here in the uapi header, but we also wind up using the same set of values for driver-internal non-uapi purposes too rather than having a separate enum (containing a superset of the uapi values) that can be used for those other things. Display code can use FB modifiers for some things, but core/lmem code needs a way to refer to Tile4 and such and doesn't have a good way to do that today. I think most (all?) of the non-display code that's relying on a definition of I915_TILING_F is in various selftests that are still being prepared for upstreaming, so maybe there's a better way to handle the selection of possible formats specifically in the selftest code itself. That's really the only area of the kernel code that should need to be aware of the specific internal layout of various buffers. Matt > > -- > Ville Syrjälä > Intel
On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote: > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote: > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > > > 64B subtiles with same basic shape as for legacy TileY > > > > > which will be supported by Display13. > > > > > > > > Why we still haven't done the F->tile64 rename? > > > > > > > > This is the last chance to fix this before we bake > > > > this into the uapi and are stuck with a name that doesn't > > > > match the spec and will just confuse everyone. > > > > > > I think you're confusing the formats here. The bspec uses both terms > > > "TileF" and "Tile4" for the same format in different places. There's a > > > completely different format that's referred to as both "TileS" and > > > "Tile64" in the bspec that we don't use at the moment. So tile64 > > > wouldn't be a correct rename, but tile4 could be. > > > > Right, tile64 is the macro tile variant I think. So like Ys > > which we never bothered implementing, so I guess we''l not bother > > with tile64 either. > > > > > > > > In general Tile4 is much more common in the bspec than TileF is (TileF > > > terminology is mostly found in the media sections). And bspec 44917 is > > > the most authoritative bspec page on the subject, and it refers to it as > > > Tile4, so I agree that switching over "Tile4" would probably be a good > > > move. > > > > > > > > > > > > > > > ... > > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > > > index bde5860b3686..d7dc421c6134 100644 > > > > > --- a/include/uapi/drm/i915_drm.h > > > > > +++ b/include/uapi/drm/i915_drm.h > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > > > #define I915_TILING_NONE 0 > > > > > #define I915_TILING_X 1 > > > > > #define I915_TILING_Y 2 > > > > > -#define I915_TILING_LAST I915_TILING_Y > > > > > +#define I915_TILING_F 3 > > > > > +#define I915_TILING_LAST I915_TILING_F > > > > > > > > fences... > > > > > > Recognizing TileF/Tile4 separately from TileY is important to code > > > outside of display as well. There are blitter instructions that require > > > different settings for TileY vs Tile4/F so if we drop the tracking of > > > this as a unique tiling type, it will break the blitting/copying and > > > some of the upcoming local memory support for Xe_HP-based platforms. > > > > These are uapi definitions for set_tiling(). You are not meant to add > > anything there. Just like we didn't add anything for Yf. > > Yeah, I think that's the real problem --- we define some values here in > the uapi header, but we also wind up using the same set of values for > driver-internal non-uapi purposes too rather than having a separate enum > (containing a superset of the uapi values) that can be used for those > other things. Display code can use FB modifiers for some things, but > core/lmem code needs a way to refer to Tile4 and such and doesn't have a > good way to do that today. > > I think most (all?) of the non-display code that's relying on a > definition of I915_TILING_F is in various selftests that are still being > prepared for upstreaming, so maybe there's a better way to handle the > selection of possible formats specifically in the selftest code itself. > That's really the only area of the kernel code that should need to be > aware of the specific internal layout of various buffers. So I will proceed with the renaming at least. Ville, suppose, I still need part of fencing related code? Stan > > > Matt > > > > > -- > > Ville Syrjälä > > Intel > > -- > Matt Roper > Graphics Software Engineer > VTT-OSGC Platform Enablement > Intel Corporation > (916) 356-2795
On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote: > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote: > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote: > > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > > > > 64B subtiles with same basic shape as for legacy TileY > > > > > > which will be supported by Display13. > > > > > > > > > > Why we still haven't done the F->tile64 rename? > > > > > > > > > > This is the last chance to fix this before we bake > > > > > this into the uapi and are stuck with a name that doesn't > > > > > match the spec and will just confuse everyone. > > > > > > > > I think you're confusing the formats here. The bspec uses both terms > > > > "TileF" and "Tile4" for the same format in different places. There's a > > > > completely different format that's referred to as both "TileS" and > > > > "Tile64" in the bspec that we don't use at the moment. So tile64 > > > > wouldn't be a correct rename, but tile4 could be. > > > > > > Right, tile64 is the macro tile variant I think. So like Ys > > > which we never bothered implementing, so I guess we''l not bother > > > with tile64 either. > > > > > > > > > > > In general Tile4 is much more common in the bspec than TileF is (TileF > > > > terminology is mostly found in the media sections). And bspec 44917 is > > > > the most authoritative bspec page on the subject, and it refers to it as > > > > Tile4, so I agree that switching over "Tile4" would probably be a good > > > > move. > > > > > > > > > > > > > > > > > > > ... > > > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > > > > index bde5860b3686..d7dc421c6134 100644 > > > > > > --- a/include/uapi/drm/i915_drm.h > > > > > > +++ b/include/uapi/drm/i915_drm.h > > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > > > > #define I915_TILING_NONE 0 > > > > > > #define I915_TILING_X 1 > > > > > > #define I915_TILING_Y 2 > > > > > > -#define I915_TILING_LAST I915_TILING_Y > > > > > > +#define I915_TILING_F 3 > > > > > > +#define I915_TILING_LAST I915_TILING_F > > > > > > > > > > fences... > > > > > > > > Recognizing TileF/Tile4 separately from TileY is important to code > > > > outside of display as well. There are blitter instructions that require > > > > different settings for TileY vs Tile4/F so if we drop the tracking of > > > > this as a unique tiling type, it will break the blitting/copying and > > > > some of the upcoming local memory support for Xe_HP-based platforms. > > > > > > These are uapi definitions for set_tiling(). You are not meant to add > > > anything there. Just like we didn't add anything for Yf. > > > > Yeah, I think that's the real problem --- we define some values here in > > the uapi header, but we also wind up using the same set of values for > > driver-internal non-uapi purposes too rather than having a separate enum > > (containing a superset of the uapi values) that can be used for those > > other things. Display code can use FB modifiers for some things, but > > core/lmem code needs a way to refer to Tile4 and such and doesn't have a > > good way to do that today. > > > > I think most (all?) of the non-display code that's relying on a > > definition of I915_TILING_F is in various selftests that are still being > > prepared for upstreaming, so maybe there's a better way to handle the > > selection of possible formats specifically in the selftest code itself. > > That's really the only area of the kernel code that should need to be > > aware of the specific internal layout of various buffers. > > So I will proceed with the renaming at least. > > Ville, suppose, I still need part of fencing related code? Nah. Just nuke it all. Someone will have to fix whatever self test is abusing the uapi definitions though. A local #define should suffice if nothing else is deemed appropriate. IIRC igt also has a local definition like this for Yf. We should perhaps rename those to some igt specific namespace as well...
On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote: > On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote: > > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote: > > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote: > > > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > > > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > > > > > 64B subtiles with same basic shape as for legacy TileY > > > > > > > which will be supported by Display13. > > > > > > > > > > > > Why we still haven't done the F->tile64 rename? > > > > > > > > > > > > This is the last chance to fix this before we bake > > > > > > this into the uapi and are stuck with a name that doesn't > > > > > > match the spec and will just confuse everyone. > > > > > > > > > > I think you're confusing the formats here. The bspec uses both terms > > > > > "TileF" and "Tile4" for the same format in different places. There's a > > > > > completely different format that's referred to as both "TileS" and > > > > > "Tile64" in the bspec that we don't use at the moment. So tile64 > > > > > wouldn't be a correct rename, but tile4 could be. > > > > > > > > Right, tile64 is the macro tile variant I think. So like Ys > > > > which we never bothered implementing, so I guess we''l not bother > > > > with tile64 either. > > > > > > > > > > > > > > In general Tile4 is much more common in the bspec than TileF is (TileF > > > > > terminology is mostly found in the media sections). And bspec 44917 is > > > > > the most authoritative bspec page on the subject, and it refers to it as > > > > > Tile4, so I agree that switching over "Tile4" would probably be a good > > > > > move. > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > > > > > index bde5860b3686..d7dc421c6134 100644 > > > > > > > --- a/include/uapi/drm/i915_drm.h > > > > > > > +++ b/include/uapi/drm/i915_drm.h > > > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > > > > > #define I915_TILING_NONE 0 > > > > > > > #define I915_TILING_X 1 > > > > > > > #define I915_TILING_Y 2 > > > > > > > -#define I915_TILING_LAST I915_TILING_Y > > > > > > > +#define I915_TILING_F 3 > > > > > > > +#define I915_TILING_LAST I915_TILING_F > > > > > > > > > > > > fences... > > > > > > > > > > Recognizing TileF/Tile4 separately from TileY is important to code > > > > > outside of display as well. There are blitter instructions that require > > > > > different settings for TileY vs Tile4/F so if we drop the tracking of > > > > > this as a unique tiling type, it will break the blitting/copying and > > > > > some of the upcoming local memory support for Xe_HP-based platforms. > > > > > > > > These are uapi definitions for set_tiling(). You are not meant to add > > > > anything there. Just like we didn't add anything for Yf. > > > > > > Yeah, I think that's the real problem --- we define some values here in > > > the uapi header, but we also wind up using the same set of values for > > > driver-internal non-uapi purposes too rather than having a separate enum > > > (containing a superset of the uapi values) that can be used for those > > > other things. Display code can use FB modifiers for some things, but > > > core/lmem code needs a way to refer to Tile4 and such and doesn't have a > > > good way to do that today. > > > > > > I think most (all?) of the non-display code that's relying on a > > > definition of I915_TILING_F is in various selftests that are still being > > > prepared for upstreaming, so maybe there's a better way to handle the > > > selection of possible formats specifically in the selftest code itself. > > > That's really the only area of the kernel code that should need to be > > > aware of the specific internal layout of various buffers. > > > > So I will proceed with the renaming at least. > > > > Ville, suppose, I still need part of fencing related code? > > Nah. Just nuke it all. Someone will have to fix whatever self test is > abusing the uapi definitions though. > > A local #define should suffice if nothing else is deemed appropriate. > IIRC igt also has a local definition like this for Yf. We should > perhaps rename those to some igt specific namespace as well... As Matt mentioned, removing I915_TILING_F completely is going to break way more than selftest, but also blitter/copy and local mem support. In fact I remember, I had to add part of those in order to get some tests working, another part was added by somebody else, so not even sure how much other stuff its going to break. Sounds like a bit too much for simple upstreaming of the patch, we already had internally for more than a year, just wondering why this popped up only by now. Stan > > -- > Ville Syrjälä > Intel
On Tue, Sep 28, 2021 at 11:36:51PM +0300, Lisovskiy, Stanislav wrote: > On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote: > > > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote: > > > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote: > > > > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > > > > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > > > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > > > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > > > > > > 64B subtiles with same basic shape as for legacy TileY > > > > > > > > which will be supported by Display13. > > > > > > > > > > > > > > Why we still haven't done the F->tile64 rename? > > > > > > > > > > > > > > This is the last chance to fix this before we bake > > > > > > > this into the uapi and are stuck with a name that doesn't > > > > > > > match the spec and will just confuse everyone. > > > > > > > > > > > > I think you're confusing the formats here. The bspec uses both terms > > > > > > "TileF" and "Tile4" for the same format in different places. There's a > > > > > > completely different format that's referred to as both "TileS" and > > > > > > "Tile64" in the bspec that we don't use at the moment. So tile64 > > > > > > wouldn't be a correct rename, but tile4 could be. > > > > > > > > > > Right, tile64 is the macro tile variant I think. So like Ys > > > > > which we never bothered implementing, so I guess we''l not bother > > > > > with tile64 either. > > > > > > > > > > > > > > > > > In general Tile4 is much more common in the bspec than TileF is (TileF > > > > > > terminology is mostly found in the media sections). And bspec 44917 is > > > > > > the most authoritative bspec page on the subject, and it refers to it as > > > > > > Tile4, so I agree that switching over "Tile4" would probably be a good > > > > > > move. > > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > > > > > > index bde5860b3686..d7dc421c6134 100644 > > > > > > > > --- a/include/uapi/drm/i915_drm.h > > > > > > > > +++ b/include/uapi/drm/i915_drm.h > > > > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > > > > > > #define I915_TILING_NONE 0 > > > > > > > > #define I915_TILING_X 1 > > > > > > > > #define I915_TILING_Y 2 > > > > > > > > -#define I915_TILING_LAST I915_TILING_Y > > > > > > > > +#define I915_TILING_F 3 > > > > > > > > +#define I915_TILING_LAST I915_TILING_F > > > > > > > > > > > > > > fences... > > > > > > > > > > > > Recognizing TileF/Tile4 separately from TileY is important to code > > > > > > outside of display as well. There are blitter instructions that require > > > > > > different settings for TileY vs Tile4/F so if we drop the tracking of > > > > > > this as a unique tiling type, it will break the blitting/copying and > > > > > > some of the upcoming local memory support for Xe_HP-based platforms. > > > > > > > > > > These are uapi definitions for set_tiling(). You are not meant to add > > > > > anything there. Just like we didn't add anything for Yf. > > > > > > > > Yeah, I think that's the real problem --- we define some values here in > > > > the uapi header, but we also wind up using the same set of values for > > > > driver-internal non-uapi purposes too rather than having a separate enum > > > > (containing a superset of the uapi values) that can be used for those > > > > other things. Display code can use FB modifiers for some things, but > > > > core/lmem code needs a way to refer to Tile4 and such and doesn't have a > > > > good way to do that today. > > > > > > > > I think most (all?) of the non-display code that's relying on a > > > > definition of I915_TILING_F is in various selftests that are still being > > > > prepared for upstreaming, so maybe there's a better way to handle the > > > > selection of possible formats specifically in the selftest code itself. > > > > That's really the only area of the kernel code that should need to be > > > > aware of the specific internal layout of various buffers. > > > > > > So I will proceed with the renaming at least. > > > > > > Ville, suppose, I still need part of fencing related code? > > > > Nah. Just nuke it all. Someone will have to fix whatever self test is > > abusing the uapi definitions though. > > > > A local #define should suffice if nothing else is deemed appropriate. > > IIRC igt also has a local definition like this for Yf. We should > > perhaps rename those to some igt specific namespace as well... > > As Matt mentioned, removing I915_TILING_F completely is going to break > way more than selftest, but also blitter/copy and local mem support. No. The only non-fence use of I915_TILING_F I see is a blitter self test of some sort. > In fact I remember, I had to add part of those in order to get some > tests working, another part was added by somebody else, so not even > sure how much other stuff its going to break. > > Sounds like a bit too much for simple upstreaming of the patch, we > already had internally for more than a year, just wondering why > this popped up only by now. Because someone tried to sneak in gem uapi additions under the cover of darkness? All gem changes must be cc:dri-devel btw, uapi doubly so. Oh, and drm_fourcc.h changes really need to go there too.
On Tue, Sep 28, 2021 at 11:47:51PM +0300, Ville Syrjälä wrote: > On Tue, Sep 28, 2021 at 11:36:51PM +0300, Lisovskiy, Stanislav wrote: > > On Tue, Sep 28, 2021 at 10:02:34PM +0300, Ville Syrjälä wrote: > > > On Tue, Sep 28, 2021 at 03:49:11PM +0300, Lisovskiy, Stanislav wrote: > > > > On Mon, Sep 27, 2021 at 10:24:11PM -0700, Matt Roper wrote: > > > > > On Mon, Sep 27, 2021 at 09:29:07PM +0300, Ville Syrjälä wrote: > > > > > > On Mon, Sep 27, 2021 at 11:23:35AM -0700, Matt Roper wrote: > > > > > > > On Thu, Sep 23, 2021 at 06:49:59PM +0300, Ville Syrjälä wrote: > > > > > > > > On Thu, Sep 23, 2021 at 11:48:58AM +0300, Stanislav Lisovskiy wrote: > > > > > > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > > > > > > > > 64B subtiles with same basic shape as for legacy TileY > > > > > > > > > which will be supported by Display13. > > > > > > > > > > > > > > > > Why we still haven't done the F->tile64 rename? > > > > > > > > > > > > > > > > This is the last chance to fix this before we bake > > > > > > > > this into the uapi and are stuck with a name that doesn't > > > > > > > > match the spec and will just confuse everyone. > > > > > > > > > > > > > > I think you're confusing the formats here. The bspec uses both terms > > > > > > > "TileF" and "Tile4" for the same format in different places. There's a > > > > > > > completely different format that's referred to as both "TileS" and > > > > > > > "Tile64" in the bspec that we don't use at the moment. So tile64 > > > > > > > wouldn't be a correct rename, but tile4 could be. > > > > > > > > > > > > Right, tile64 is the macro tile variant I think. So like Ys > > > > > > which we never bothered implementing, so I guess we''l not bother > > > > > > with tile64 either. > > > > > > > > > > > > > > > > > > > > In general Tile4 is much more common in the bspec than TileF is (TileF > > > > > > > terminology is mostly found in the media sections). And bspec 44917 is > > > > > > > the most authoritative bspec page on the subject, and it refers to it as > > > > > > > Tile4, so I agree that switching over "Tile4" would probably be a good > > > > > > > move. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > > > > > > > > > index bde5860b3686..d7dc421c6134 100644 > > > > > > > > > --- a/include/uapi/drm/i915_drm.h > > > > > > > > > +++ b/include/uapi/drm/i915_drm.h > > > > > > > > > @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { > > > > > > > > > #define I915_TILING_NONE 0 > > > > > > > > > #define I915_TILING_X 1 > > > > > > > > > #define I915_TILING_Y 2 > > > > > > > > > -#define I915_TILING_LAST I915_TILING_Y > > > > > > > > > +#define I915_TILING_F 3 > > > > > > > > > +#define I915_TILING_LAST I915_TILING_F > > > > > > > > > > > > > > > > fences... > > > > > > > > > > > > > > Recognizing TileF/Tile4 separately from TileY is important to code > > > > > > > outside of display as well. There are blitter instructions that require > > > > > > > different settings for TileY vs Tile4/F so if we drop the tracking of > > > > > > > this as a unique tiling type, it will break the blitting/copying and > > > > > > > some of the upcoming local memory support for Xe_HP-based platforms. > > > > > > > > > > > > These are uapi definitions for set_tiling(). You are not meant to add > > > > > > anything there. Just like we didn't add anything for Yf. > > > > > > > > > > Yeah, I think that's the real problem --- we define some values here in > > > > > the uapi header, but we also wind up using the same set of values for > > > > > driver-internal non-uapi purposes too rather than having a separate enum > > > > > (containing a superset of the uapi values) that can be used for those > > > > > other things. Display code can use FB modifiers for some things, but > > > > > core/lmem code needs a way to refer to Tile4 and such and doesn't have a > > > > > good way to do that today. > > > > > > > > > > I think most (all?) of the non-display code that's relying on a > > > > > definition of I915_TILING_F is in various selftests that are still being > > > > > prepared for upstreaming, so maybe there's a better way to handle the > > > > > selection of possible formats specifically in the selftest code itself. > > > > > That's really the only area of the kernel code that should need to be > > > > > aware of the specific internal layout of various buffers. > > > > > > > > So I will proceed with the renaming at least. > > > > > > > > Ville, suppose, I still need part of fencing related code? > > > > > > Nah. Just nuke it all. Someone will have to fix whatever self test is > > > abusing the uapi definitions though. > > > > > > A local #define should suffice if nothing else is deemed appropriate. > > > IIRC igt also has a local definition like this for Yf. We should > > > perhaps rename those to some igt specific namespace as well... > > > > As Matt mentioned, removing I915_TILING_F completely is going to break > > way more than selftest, but also blitter/copy and local mem support. > > No. The only non-fence use of I915_TILING_F I see is a blitter self test > of some sort. > > > In fact I remember, I had to add part of those in order to get some > > tests working, another part was added by somebody else, so not even > > sure how much other stuff its going to break. > > > > Sounds like a bit too much for simple upstreaming of the patch, we > > already had internally for more than a year, just wondering why > > this popped up only by now. > > Because someone tried to sneak in gem uapi additions under the > cover of darkness? All gem changes must be cc:dri-devel btw, > uapi doubly so. Oh, and drm_fourcc.h changes really need to go > there too. I assume "internal" is "darkness" here? :) What I actually meant is that, we could avoid all those issues and danger of breaking the existing stuff, if all of that was discussed in the very beginning. To be honest, I wasn't aware of that kind of rules, my idea was just to add I915_TILING_* just same way as it exists in the current code, like I915_TILING_X/Y, because it seems "kind of" logical. Otherwise for sure, something else would have been done. Moreover after this patch has been pushed to internal and I even stopped following what was happening with it to be honest, as it was already edited by multiple people and grew lots of other changes, I'm completely unaware of. So what I just want to emphasize here, is that we should have had those discussions one year ago and probably throughout the whole year when this patch has been edited, not in the very last moment when it goes to upstream - that way we would just avoid _more_ "wrong" changes coming and now I'll have to sort out all this mess, instread of investigating more urgent problems, we currently have. Stan > > -- > Ville Syrjälä > Intel
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 23b1e0ccc72d..7564b8812c5b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -1335,6 +1335,7 @@ initial_plane_vma(struct drm_i915_private *i915, break; case I915_TILING_X: case I915_TILING_Y: + case I915_TILING_F: obj->tiling_and_stride = plane_config->fb->base.pitches[0] | plane_config->tiling; @@ -1376,6 +1377,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc, case DRM_FORMAT_MOD_LINEAR: case I915_FORMAT_MOD_X_TILED: case I915_FORMAT_MOD_Y_TILED: + case I915_FORMAT_MOD_F_TILED: break; default: drm_dbg(&dev_priv->drm, @@ -9282,6 +9284,7 @@ static int intel_atomic_check_async(struct intel_atomic_state *state) case I915_FORMAT_MOD_X_TILED: case I915_FORMAT_MOD_Y_TILED: case I915_FORMAT_MOD_Yf_TILED: + case I915_FORMAT_MOD_F_TILED: break; default: drm_dbg_kms(&i915->drm, diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c index e4b8602ec0cd..d88070406098 100644 --- a/drivers/gpu/drm/i915/display/intel_fb.c +++ b/drivers/gpu/drm/i915/display/intel_fb.c @@ -101,6 +101,12 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, int color_plane) return 128; else return 512; + case I915_FORMAT_MOD_F_TILED: + /* + * Each 4K tile consists of 64B(8*8) subtiles, with + * same shape as Y Tile(i.e 4*16B OWords) + */ + return 128; case I915_FORMAT_MOD_Y_TILED_CCS: if (is_ccs_plane(fb, color_plane)) return 128; @@ -185,6 +191,8 @@ static unsigned int intel_fb_modifier_to_tiling(u64 fb_modifier) switch (fb_modifier) { case I915_FORMAT_MOD_X_TILED: return I915_TILING_X; + case I915_FORMAT_MOD_F_TILED: + return I915_TILING_F; case I915_FORMAT_MOD_Y_TILED: case I915_FORMAT_MOD_Y_TILED_CCS: case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS: @@ -264,6 +272,7 @@ unsigned int intel_surf_alignment(const struct drm_framebuffer *fb, case I915_FORMAT_MOD_Y_TILED_CCS: case I915_FORMAT_MOD_Yf_TILED_CCS: case I915_FORMAT_MOD_Y_TILED: + case I915_FORMAT_MOD_F_TILED: case I915_FORMAT_MOD_Yf_TILED: return 1 * 1024 * 1024; default: @@ -1282,7 +1291,8 @@ int intel_framebuffer_init(struct intel_framebuffer *intel_fb, } else { if (tiling == I915_TILING_X) { mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED; - } else if (tiling == I915_TILING_Y) { + } else if ((tiling == I915_TILING_Y) || + (tiling == I915_TILING_F)) { drm_dbg_kms(&dev_priv->drm, "No Y tiling for legacy addfb\n"); goto err; diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c index b1c1a23c36be..015005cf2ba1 100644 --- a/drivers/gpu/drm/i915/display/intel_fbc.c +++ b/drivers/gpu/drm/i915/display/intel_fbc.c @@ -679,6 +679,7 @@ static bool tiling_is_valid(struct drm_i915_private *dev_priv, switch (modifier) { case DRM_FORMAT_MOD_LINEAR: case I915_FORMAT_MOD_Y_TILED: + case I915_FORMAT_MOD_F_TILED: return DISPLAY_VER(dev_priv) >= 9; case I915_FORMAT_MOD_X_TILED: return true; diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c index 724e7b04f3b6..09c00fc099f2 100644 --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c @@ -206,6 +206,13 @@ static const u64 adlp_step_a_plane_format_modifiers[] = { DRM_FORMAT_MOD_INVALID }; +static const u64 dg2_plane_format_modifiers[] = { + I915_FORMAT_MOD_X_TILED, + I915_FORMAT_MOD_F_TILED, + DRM_FORMAT_MOD_LINEAR, + DRM_FORMAT_MOD_INVALID +}; + int skl_format_to_fourcc(int format, bool rgb_order, bool alpha) { switch (format) { @@ -793,6 +800,8 @@ static u32 skl_plane_ctl_tiling(u64 fb_modifier) return PLANE_CTL_TILED_X; case I915_FORMAT_MOD_Y_TILED: return PLANE_CTL_TILED_Y; + case I915_FORMAT_MOD_F_TILED: + return PLANE_CTL_TILED_F; case I915_FORMAT_MOD_Y_TILED_CCS: case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC: return PLANE_CTL_TILED_Y | PLANE_CTL_RENDER_DECOMPRESSION_ENABLE; @@ -1240,6 +1249,7 @@ static int skl_plane_check_fb(const struct intel_crtc_state *crtc_state, fb->modifier == I915_FORMAT_MOD_Yf_TILED || fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS || fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS || + fb->modifier == I915_FORMAT_MOD_F_TILED || fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS || fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS || fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC)) { @@ -1941,6 +1951,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) return false; break; + case I915_FORMAT_MOD_F_TILED: + if (!HAS_FTILE(dev_priv)) + return false; + fallthrough; default: return false; } @@ -1981,9 +1995,7 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, case DRM_FORMAT_Y216: case DRM_FORMAT_XVYU12_16161616: case DRM_FORMAT_XVYU16161616: - if (modifier == DRM_FORMAT_MOD_LINEAR || - modifier == I915_FORMAT_MOD_X_TILED || - modifier == I915_FORMAT_MOD_Y_TILED) + if (!is_ccs_modifier(modifier)) return true; fallthrough; default: @@ -1994,8 +2006,10 @@ static bool gen12_plane_format_mod_supported(struct drm_plane *_plane, static const u64 *gen12_get_plane_modifiers(struct drm_i915_private *dev_priv, enum plane_id plane_id) { + if (HAS_FTILE(dev_priv)) + return dg2_plane_format_modifiers; /* Wa_22011186057 */ - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) + else if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) return adlp_step_a_plane_format_modifiers; else if (gen12_plane_supports_mc_ccs(dev_priv, plane_id)) return gen12_plane_format_modifiers_mc_ccs; @@ -2265,11 +2279,16 @@ skl_get_initial_plane_config(struct intel_crtc *crtc, else fb->modifier = I915_FORMAT_MOD_Y_TILED; break; - case PLANE_CTL_TILED_YF: - if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) - fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS; - else - fb->modifier = I915_FORMAT_MOD_Yf_TILED; + case PLANE_CTL_TILED_YF: /* aka PLANE_CTL_TILED_F on XE_LPD+ */ + if (DISPLAY_VER(dev_priv) >= 13) { + plane_config->tiling = I915_TILING_F; + fb->modifier = I915_FORMAT_MOD_F_TILED; + } else { + if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE) + fb->modifier = I915_FORMAT_MOD_Yf_TILED_CCS; + else + fb->modifier = I915_FORMAT_MOD_Yf_TILED; + } break; default: MISSING_CASE(tiling); diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index 3043fcbd31bd..d96bcab1f3e3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -326,7 +326,13 @@ static inline unsigned int i915_gem_tile_height(unsigned int tiling) { GEM_BUG_ON(!tiling); - return tiling == I915_TILING_Y ? 32 : 8; + switch (tiling) { + case I915_TILING_Y: + case I915_TILING_F: + return 32; + default: + return 8; + } } static inline unsigned int diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c index ef4d0f7dc118..520b8fb7c870 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c @@ -145,7 +145,8 @@ i915_tiling_ok(struct drm_i915_gem_object *obj, } if (GRAPHICS_VER(i915) == 2 || - (tiling == I915_TILING_Y && HAS_128_BYTE_Y_TILING(i915))) + (tiling == I915_TILING_Y && HAS_128_BYTE_Y_TILING(i915)) || + tiling == I915_TILING_F) tile_width = 128; else tile_width = 512; @@ -438,6 +439,7 @@ i915_gem_get_tiling_ioctl(struct drm_device *dev, void *data, args->swizzle_mode = dev_priv->ggtt.bit_6_swizzle_x; break; case I915_TILING_Y: + case I915_TILING_F: args->swizzle_mode = dev_priv->ggtt.bit_6_swizzle_y; break; default: diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c index f8948de72036..f748bcbf46c3 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c @@ -77,7 +77,8 @@ static void i965_write_fence_reg(struct i915_fence_reg *fence) val <<= 32; val |= fence->start; val |= (u64)((stride / 128) - 1) << fence_pitch_shift; - if (fence->tiling == I915_TILING_Y) + if (fence->tiling == I915_TILING_Y || + fence->tiling == I915_TILING_F) val |= BIT(I965_FENCE_TILING_Y_SHIFT); val |= I965_FENCE_REG_VALID; } diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index fdbd46ff59e0..f43968fc16fe 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -82,6 +82,7 @@ static char get_tiling_flag(struct drm_i915_gem_object *obj) case I915_TILING_NONE: return ' '; case I915_TILING_X: return 'X'; case I915_TILING_Y: return 'Y'; + case I915_TILING_F: return 'F'; } } diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index cc355aa05dbf..dafa8b1f365a 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1586,6 +1586,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7) #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) +#define HAS_FTILE(dev_priv) (INTEL_INFO(dev_priv)->has_ftile) #define HAS_SNOOP(dev_priv) (INTEL_INFO(dev_priv)->has_snoop) #define HAS_EDRAM(dev_priv) ((dev_priv)->edram_size_mb) #define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index d4a6a9dcf182..81963d5876ef 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -970,6 +970,7 @@ static const struct intel_device_info adl_p_info = { .display.has_cdclk_crawl = 1, .display.has_modular_fia = 1, .display.has_psr_hw_tracking = 0, + .has_ftile = 1, \ .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2), .ppgtt_size = 48, diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index cad84c3b864b..55c8a47ba047 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -7192,6 +7192,7 @@ enum { #define PLANE_CTL_TILED_X (1 << 10) #define PLANE_CTL_TILED_Y (4 << 10) #define PLANE_CTL_TILED_YF (5 << 10) +#define PLANE_CTL_TILED_F (5 << 10) #define PLANE_CTL_ASYNC_FLIP (1 << 9) #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8) #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */ diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index d328bb95c49b..76f783c10f81 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -125,6 +125,7 @@ enum intel_ppgtt_type { func(has_64bit_reloc); \ func(gpu_reset_clobbers_display); \ func(has_reset_engine); \ + func(has_ftile); \ func(has_global_mocs); \ func(has_gt_uc); \ func(has_l3_dpf); \ diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 74fd6aa7afc7..6e68f259c4c1 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5362,6 +5362,7 @@ skl_compute_wm_params(const struct intel_crtc_state *crtc_state, } wp->y_tiled = modifier == I915_FORMAT_MOD_Y_TILED || + modifier == I915_FORMAT_MOD_F_TILED || modifier == I915_FORMAT_MOD_Yf_TILED || modifier == I915_FORMAT_MOD_Y_TILED_CCS || modifier == I915_FORMAT_MOD_Yf_TILED_CCS; diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 45a914850be0..a7d3027b5bdc 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -558,6 +558,14 @@ extern "C" { * pitch is required to be a multiple of 4 tile widths. */ #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8) +/* + * Intel F-tiling(aka Tile4) layout + * + * This is a tiled layout using 4Kb tiles in row-major layout. + * Within the tile pixels are laid out in 64 byte units / sub-tiles in OWORD + * (16 bytes) chunks column-major.. + */ +#define I915_FORMAT_MOD_F_TILED fourcc_mod_code(INTEL, 10) /* * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index bde5860b3686..d7dc421c6134 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1522,7 +1522,8 @@ struct drm_i915_gem_caching { #define I915_TILING_NONE 0 #define I915_TILING_X 1 #define I915_TILING_Y 2 -#define I915_TILING_LAST I915_TILING_Y +#define I915_TILING_F 3 +#define I915_TILING_LAST I915_TILING_F #define I915_BIT_6_SWIZZLE_NONE 0 #define I915_BIT_6_SWIZZLE_9 1