[Intel-gfx] [PATCH v2 4/5] drm/i915: Bump gen4+ fb stride limit to 256KiB

[Chris Wilson]

Quoting Ville Syrjala (2018-09-13 21:01:39)
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> With gtt remapping plugged in we can simply raise the stride
> limit on gen4+. Let's just arbitraily pick 256 KiB as the limit.
> 
> No remapping CCS because the virtual address of each page actually
> matters due to the new hash mode
> (WaCompressedResourceDisplayNewHashMode:skl,kbl etc.), and no remapping
> on gen2/3 due to lack of fence on the remapped vma.
> 
> v2: Rebase due to is_ccs_modifier()
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 93b0de594c5d..346572cf734a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2506,6 +2506,19 @@ static
>  u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
>                         u32 pixel_format, u64 modifier)
>  {
> +       /*
> +        * Arbitrary limit for gen4+. We can deal with any page
> +        * aligned stride via GTT remapping. Gen2/3 need a fence
> +        * for tiled scanout which the remapped vma won't have,
> +        * so we don't allow remapping on those platforms.
> +        *
> +        * Also the new hash mode we use for CCS isn't compatible
> +        * with remapping as the virtual address of the pages
> +        * affects the compressed data.
> +        */
> +       if (INTEL_GEN(dev_priv) >= 4 && !is_ccs_modifier(modifier))
> +               return 256*1024;

If arbitrary, why 256k? Will we not go beyond 8 bytes per pixel in the
future? If you used U32_MAX then we will just reject v.large strides on
other grounds (too large for GTT, stride/size overflow).

Hmm, or is the 256k to keep the overflow checks simpler?
-Chris